“我们不做「看起来很聪明」的知识库。”这句话不是口号是项目启动会上我拍的板。当时团队刚看完一轮友商演示检索飞快、回答流畅、界面确实漂亮但真要接企业内部上千万字的制度文档、技术手册和项目档案所有人都沉默了。Demo 知识库只有几十个文件数据权限基本没做引用溯源也经不起追问。企业级 RAG 平台根本不是把文档塞进向量库那么简单。这篇实录记录了我们从零搭建一套完整平台的全过程一共做了 37 屏真机界面从文档接入、混合检索、重排调优到权限隔离、评估闭环每一屏都在回答一个问题它能不能直接拿来给几千名员工用。不管你是准备自建、正在选型还是已经踩坑想找解法这套拆解都值得认真看完。1. 为什么「看起来很聪明」的知识库一上生产就翻车1.1 三个典型的「演示型」翻车现场先讲三个我们亲眼看过的场景几乎每个 Demo 型知识库都会在这里出事。第一个是权限穿透。某位普通员工在试用环境里问了一句“今年竞品报价最高的三个客户是哪几家”模型直接从索引里找到了相关数据并给了完整答案。问题在于这位员工所在部门根本没有客户数据的访问权限。答案本身是“聪明的”但这个回答不应该出现在这个人的屏幕上。很多演示版知识库根本不会绑定用户数据域所有访客共用同一个巨大的索引谁问都能得到全部内容。第二个是引用名存实亡。AI 回答的最后挂了一个索引编号点进去能跳到原文但细看就是张冠李戴。比如回答里提到“设备故障停机时间不得超过 4 小时”引用编号却指向一份关于采购流程的文档。原因是检索到的 Top Chunk 和最终生成的答案之间没有做硬性绑定模型自由发挥后系统把检索结果里第一条拿来当引用压根没核对是否支持回答内容。第三个是旧版制度反复被命中。企业制度文档每半年修订一次很正常但演示系统里没有人管文档版本。平台上线三周后同事提问“请假审批最长几天”模型还在用两年前的老版本回答。旧版分块没有下线索引里新老文档混在一起模型自然偏向检索到的最相似内容而不是最新内容。这类问题一旦落到业务场景里就是实打实的误导轻则办事流程走错重则触发合规风险。企业级知识库不是做出来“能回答”就行而是要在权限、版本、引用、审计这些无人喝彩的地方扛住压力。否则演示越漂亮上线后摔得越重。1.2 「企业级」和「Demo」的真正分水岭在哪里Demo 像玩具飞机企业级平台像载客飞机。玩具飞机飞起来很讨喜但没人敢坐上去跨洋飞行两者对安全、故障容错、可维护性的要求完全不在一个量级。企业级 RAG 平台至少要过五道关权限隔离不同角色、部门、密级的用户检索范围必须严格过滤。这不是前端按钮能解决的必须在检索链路层面按用户身份动态注入过滤条件。引用可溯模型输出的每一个关键信息点都要能找到对应的原文出处精确到文档、章节、段落甚至行号。数据治理文档要有版本状态草稿、生效、停用、归档各归其位。政策更新后旧版不会继续被检索答复里还要带上生效日期。可运维性调用量、响应耗时、失败请求、Token 消耗、命中率趋势都要有监控面板否则出了问题只能靠用户投诉才知道。评估闭环判断平台改好还是改差不能靠人工抽看几条例子需要一套固定的评估集和回归测试流程。这五条没做扎实其余所有炫酷功能都是空中楼阁。下面要讲的 37 屏系统每一屏的设置都是为了解决这五类问题而不是为了把界面做复杂。2. 37 屏后台的完整地图先拆模块再谈界面2.1 五大功能区与屏数分布很多人听到“37 屏”第一反应是“太重了”这其实是误解。屏数多不等于功能乱只要每个模块边界清晰、数据闭环完整界面多一点反而便于不同角色操作。真正的混乱是没有边界地堆功能而不是按业务域拆得足够细。这套平台最终由 9 个子模块构成合计 37 屏。子模块屏数覆盖页面身份与工作台3登录、双因素验证、数据总览工作台知识库管理6库列表、文档上传、解析任务、文档详情、分块预览、元数据编辑检索调优5测试问答、检索链路调试、参数配置、重排调试、引用比对用户与权限4成员管理、角色权限、数据域授权、审批流配置运营监控6调用总览、响应耗时、Token 用量、命中率趋势、失败日志、反馈看板系统配置4模型配置、Prompt 配置、向量模型管理、缓存与限流审计合规5操作日志、问答审计、数据变更记录、导出记录、权限变更记录评估闭环4评估集管理、标注作业、Bad Case 列表、回归测试报告这个屏数不是提前规划出来的而是做业务梳理时发现的真实需求。比如“审计合规”这个模块一开始只有 2 屏后来合规团队提出要能按员工查问答记录才补成了 5 屏。你可以把屏数理解成业务复杂度的投影而不是项目规模的自嗨指标。2.2 每一屏背后的「数据闭环」逻辑设计整个后台时我们给自己定了一条硬规矩任意一次用户问答都必须能完整回答五个问题。谁在什么时间问了什么检索命中了哪些知识库和文档最终生成回答引用了哪些原文片段模型的完整输出是什么整个链路耗时多久、排了什么状态这五个问题对应到界面里就是工作台的调用详情、审计模块的问答记录、检索调优的 Chunk 命中展示和引用比对页面。任何一个问题在界面里找不到答案都说明链路有数据断层真正上线后你没法定位问题。举一个实际运维场景。某天领导问“为什么员工总是收到过时答案”如果没有完整的链路数据你只能靠猜。但有了数据闭环后你可以直接查那天所有相关问答的命中文档列表发现老版本文档的权限状态没有更新再顺着数据变更记录找到是哪天、哪位管理员改了状态。整个排查过程不超过十分钟。37 屏不是用来给用户看的每个界面背后都是一道数据验证关卡。屏与屏之间不是孤立的而是把完整的数据流串成了闭环。3. 核心链路逐屏拆解上传、切分、检索、生成、溯源3.1 文档接入层格式校验、双通道加载与解析失败兜底文档接入是整条链路的起点但也是最容易被低估的环节。真实企业环境里的文档长得五花八门有扫描版 PDF、有加密文件、有十几年前的老 Word 文档、有嵌着大量流程图的 HTML 页面。如果接入层不够健壮后面所有环节都会受影响。我们在接入层做了三道防线。第一道是格式校验。文件上传后先做检查不是只看后缀名还看真实内容是否匹配。比如一个文件改名成 PDF实际内部是扫描图片后缀校验根本发现不了。这道防线会记录文件类型、大小、页数、是否加密不合格的直接打回。第二道是双通道加载。结构化文本可复制的 PDF、Word、Markdown走普通解析通道扫描件和图片型文档走 OCR 通道。两条通道产出物格式统一都转成带布局信息的 Markdown。这样做是为了保住表格结构很多团队把 PDF 直接转成纯文本表格里的行列关系全丢了后面切分再智能也救不回来。第三道是解析失败兜底。PDF 加密、超大文件超过 300 页、OCR 识别率低于阈值这些情况不会静默失败而是自动进入人工确认队列。我们最初没有这个队列结果上线第一天就有一批扫描文件“消失”在知识库里用户根本不知道为什么。元数据打标也放在接入环节。文档的密级内部公开/机密/绝密、所属部门、生效日期、失效日期都在这个环节录入。后期检索层的所有权限过滤全靠这批标签。3.2 切分与向量化用 300 份真实文档试出来的参数切分参数是 RAG 项目里最容易引发争论的问题。市面上很多教程直接告诉你 chunk_size 设 512、overlap 设 32但真实企业文档根本没法用一套固定参数通吃。做法是先按文档形态分类再定切分策略。制度类文档管理办法、审批流程、组织架构有明确的标题层级我们按 Markdown 标题结构切分一级标题下面是完整的一个章节。表格单独识别成结构化块不跟正文混在一起。技术手册类文档设备操作说明、项目档案没有严格的标题规范我们采用语义段落加滑动窗口先按空行和章节标题粗切再用 window 方式重叠避免上下文被切断。对话记录和 FAQ 类数据走独立的处理方式一条对话或一问一答就是一个 Chunk。300 份真实文档的实验中我们把 chunk_size 放在 200 到 600 个字符之间做过对比。结果很有意思过短200 字符以下导致单块信息量不够检索时召回很多碎片过长600 字符以上导致一块里包含多个主题重排精度下降。最终我们主要落在 300500 字符区间overlap 比例根据文档类型调整制度类用 10%技术手册类用 20%。向量化这块要特别强调合规问题。企业内网环境绝对不允许调用外部 API 做 Embedding这是多数大型企业的硬性要求。我们私有化部署了开源中文向量模型全部请求走内网。实际测试中段落级 Embedding 比句子级 Embedding 的召回效果更稳定。句子级向量单独检索经常命中一些语义相似但不包含关键实体的碎片段落级向量单块信息量更足。3.3 混合检索与重排从 Top 20 到 Top 5 的调优记录刚开始做检索时团队也存在一个误区向量检索已经很好了为什么还要混合真实数据很快就教育了我们。向量检索擅长语义近似召回但对企业文档里的精准关键词非常不敏感。员工常问“请问 BG-2024-07 号合同是否已归档”这里的“BG-2024-07”是一段精确编号向量模型对这类 ID 的匹配能力很差经常召回一堆无关文档。但同时 BM25 对编号的精确匹配几乎是秒杀级表现。两种检索各有优势融合才是正解。于是做了混合检索方案第一轮向量检索和 BM25 倒排检索同步执行各自取 Top 30再用 RRF 算法融合排序取 Top 20 进入重排阶段。RRF 的核心思路是融合时看文档在多个结果中的排序位置不是看具体分数。融合参数 k 设为 60效果最好。重排选用开源重排模型推理成本较高所以只对第一轮的 Top 20 做精排输出最终 Top 5。这个两级结构的原因很朴素重排模型精度高但计算开销大直接用 Top 5 进重排会漏掉潜在正确答案用 Top 50 全量重排又扛不住并发。Top 20 是性能和精度的平衡点实测最稳。调优记录可以分享一组真实数据纯向量检索的命中率为 62%加入 BM25 混合之后到 78%再叠加重排模型后到 89%。这 27 个百分点的提升就是在检索链路里一步步抠出来的没有捷径。3.4 生成策略与引用溯源怎么让模型「只讲有依据的话」检索做好了生成阶段同样有大量细节。这个环节的核心不是让模型变聪明而是让它老老实实基于证据说话。Prompt 设计上我们把检索到的 Top 5 Chunk 作为强约束上下文明确要求模型只能基于这些内容回答禁止使用内部知识补全。当检索内容不足以回答问题时模型直接输出“未检索到有效资料”并引导用户联系知识库管理员。这个拒答策略至关重要因为最怕的不是模型说不知道而是模型一本正经地胡说八道。温度参数调到了 0.2让输出更稳定。但单靠 Prompt 和参数挡不住一切幻觉根源还是在引用绑定。生成阶段模型输出的每个关键事实点都会和对应的 Chunk 做映射前端返回结果时把命中的 Chunk ID 一并返回。用户看到的回答里每一段关键内容旁边都有引用角标点击后能跳到原文的对应页面和段落。我们要求做到“引用里的每个字都能在原文找到”不然审计过不了。这套机制实现之后之前引用名存实亡的问题才算彻底解决。4. 真机实录上线前一个月踩过的 6 个生产级坑4.1 权限穿透普通员工问到了财务数据这是所有坑里最吓人的一个。测试同学用一个普通员工账号登录随口问了一句“某产品的毛利率是多少”系统竟然给出了准确数字。查完之后发现检索层的向量库根本没有接用户数据域过滤只是在 UI 上做了菜单隐藏。有个前端同学图省事以为页面不显示入口就够了但检索接口本身没有任何权限校验。修复方案是彻底重构检索入口所有检索请求统一经过一个权限网关根据用户的角色、部门、数据域标签动态拼过滤条件传给向量库和倒排索引。这一步必须在数据链路层面完成而不是期待前端按钮做好隔离。自那以后权限测试被列入每次发版的必测项。4.2 切分错误导致「张冠李戴」某个技术手册里有一张检修计划表表格同时包含“检修周期”和“责任人”两列。切分阶段没有做表格结构化处理直接把纯文本切开了结果模型把第一列的检修周期和第二列的责任人串在了一起给出了完全错误的对照关系。这个问题表面上是模型理解错了实际上根源在切分阶段的表格破坏。修复方案是增强表格识别能力切分之前先解析行列关系把表头、表体、单元格做结构化标记。修复之后这类问题没有再出现。4.3 并发一上来检索服务先崩了做压测那天我们信心满满地上了 12 路并发。结果重排模型直接在 GPU 上排队接口响应从单线程下的 1.2 秒涨到 12 秒几轮之后直接超时。定位后发现瓶颈不在向量检索重排模型虽然是瓶颈之一但最大的问题是缓存完全没有做。同一个问题被不同用户重复询问时系统每次都重新执行全部检索和重排。修复方案做了三层第一Top 20 的粗排结果加了 5 分钟缓存相同或相似的查询直接命中第二向量化的 Embedding 结果做了预生成和持久化避免每个请求重新算第三重排模型加了一个排队监控超出队列长度直接降级为粗排结果保证服务不挂。4.4 幻觉不全是模型的错有一次业务方反馈回答里的数据是错的。排查到最后发现模型引用的数字来自一份已经作废的旧版制度。两份内容高度相似的制度文档同时存在旧版没有下线照样参与检索模型无法区分哪个是现行版本。这个问题直接推动我们建立了文档版本状态机草稿、生效、停用、归档四种状态检索时只查生效状态的文档回答里自动附带版本号和生效日期。数据治理这一关不过调再多参数都白搭。4.5 引用溯源与技术文档版本冲突早期引用只显示文档标题没法定位到具体页面。有人问一句“规范里说了什么”系统答完引用链接跳到文档首页审计人员还得在几十页里自己找。修复方案是在分块阶段给每个 Chunk 记录页码、段落序号、章节路径。引用展示时直接跳到原文档的具体段落所有信息逐字可查。这一步工作量不算大但对审计验收来说是决定性的。4.6 审计日志缺失差点让平台无法验收合规验收前一周对方要求查“某部门上周有哪些人问了合同相关问题”我们打开日志一看只记录了问题内容没记录用户身份当时后背就凉了。连夜补审计模块每次问答都必须记录八个字段用户、部门、会话、知识库、命中文档、Top Chunk、模型回答、响应耗时。日志保留 90 天。补完之后合规顺利通过但这个过程提醒我们审计日志应该在设计阶段就做好而不是临时补。5. 评估闭环怎么证明平台不是「看起来很聪明」5.1 评估集建设从随手抽问到 2000 对人工标注没有评估集就没有办法客观回答“平台上个月到底变好还是变差了”。我们第一版评估是从真实工单和员工提问里抽取了 200 对问答人工标注“正确、部分正确、错误”三档。这 200 对的作用是逼出第一批 Bad Case用来迭代。之后扩展到 2000 对覆盖制度问答、技术手册、流程办理、数据查询四类场景。每类场景至少 500 对确保评估不偏向某一种文档类型。评估集独立存放绝不进入向量库否则就被污染了评估结果不再可信。5.2 三个关键指标命中率、引用准确率、拒答率评估阶段我们主要盯三个指标。命中率反映的是模型回答的核心要点是否都出现在命中文档里。引用准确率验证的是回答里的每个引用编号是否真的对应正确来源这部分主要靠人工复核。拒答率衡量的是系统在无把握的时候是否果断拒答而不是硬编答案。三个指标相互制衡只看其中一个容易走偏。比如一味提高命中率模型的拒答率可能下降反而开始强行回答一些问题。指标评估方式目标值命中率核心要点是否都在命中文档中≥ 90%引用准确率引用编号与来源逐一比对≥ 95%拒答率无依据问题是否拒答可控范围内目标是反馈出的参考值真正上线后要根据业务场景调整。越核心的业务流程越要允许“拒答”保证回答正确性比回答覆盖率重要得多。5.3 持续优化循环线上反馈如何倒逼数据治理评估不是一次性工作而是一个长期循环。我们在每个用户端的回答卡片下放了“对、错、引用错误”三个反馈按钮。反馈数据自动进入 Bad Case 池每周跟评估集合并跑一次回归。更关键的是反馈数据会反哺数据治理。某篇文档被频繁标记“引用错误”系统会自动提醒管理员检查这篇文档的切分质量或者版本状态。之前聊天提到的旧版制度问题就是靠这个机制被主动揪出来的。平台上线三个月后Bad Case 的每周新增数量明显下降这就是闭环在起作用。6. 常见问题速查与避坑自检清单6.1 高频问题与排查思路速查表症状可能原因排查思路检索结果明显不准切分粒度过大或过小、Embedding 模型不匹配先检查 Chunk 是否完整保留了关键实体再做不同切分参数的对照测试回答引用与内容不符Chunk 标号映射错误、生成阶段未绑定引用检查引用 ID 与 Chunk ID 的对应关系确认生成阶段是硬绑定而非事后补充权限数据泄露检索层未按用户数据域过滤直接用越权账号测检索接口看返回结果是否包含过滤条件并发一高就变慢重排模型排队、缺缓存看压测报告定位耗时最高的环节优先加粗排缓存和异步处理旧版制度总被命中版本状态未管理检查文档元数据的生效状态确认索引里是否混入停用版本模型答非所问Prompt 约束不足、Top 召回内容不够精准先看召回 Top 5 是否正确再优化 Prompt 的强约束表述问答不可追溯审计日志缺失字段补全用户身份、部门、命中文档、耗时等核心字段6.2 上线前必须过的自检清单文档密级元数据是否在检索链路全局生效而不是只在 UI 层隐藏引用能否做到逐字回溯原文精确到章节和段落审计日志是否覆盖问答、数据变更、权限变更、导出四类动作评估集是否稳定可用且独立于训练数据并发和限流是否压测过重排降级方案有没有启用数据更新与下线是否走完版本状态机旧版不会继续参与检索这套自检清单是我们踩了无数坑之后整理出来的成本很低但能拦住绝大部分上线事故。最后说点个人体会。做完这套平台我最深的感触是RAG 项目的成败技术选型和模型调参只占一小部分真正的难点在于数据治理、权限隔离、审计追溯这些看不见的底座。如果只让我给后来者留一条经验那就是不要在模型和参数上沉迷太久先把数据治理和权限做扎实。检索链路可以慢慢调但底座不牢再多漂亮界面都撑不起企业级这三个字。
“我们不做「看起来很聪明」的知识库。”这句话不是口号是项目启动会上我拍的板。当时团队刚看完一轮友商演示检索飞快、回答流畅、界面确实漂亮但真要接企业内部上千万字的制度文档、技术手册和项目档案所有人都沉默了。Demo 知识库只有几十个文件数据权限基本没做引用溯源也经不起追问。企业级 RAG 平台根本不是把文档塞进向量库那么简单。这篇实录记录了我们从零搭建一套完整平台的全过程一共做了 37 屏真机界面从文档接入、混合检索、重排调优到权限隔离、评估闭环每一屏都在回答一个问题它能不能直接拿来给几千名员工用。不管你是准备自建、正在选型还是已经踩坑想找解法这套拆解都值得认真看完。1. 为什么「看起来很聪明」的知识库一上生产就翻车1.1 三个典型的「演示型」翻车现场先讲三个我们亲眼看过的场景几乎每个 Demo 型知识库都会在这里出事。第一个是权限穿透。某位普通员工在试用环境里问了一句“今年竞品报价最高的三个客户是哪几家”模型直接从索引里找到了相关数据并给了完整答案。问题在于这位员工所在部门根本没有客户数据的访问权限。答案本身是“聪明的”但这个回答不应该出现在这个人的屏幕上。很多演示版知识库根本不会绑定用户数据域所有访客共用同一个巨大的索引谁问都能得到全部内容。第二个是引用名存实亡。AI 回答的最后挂了一个索引编号点进去能跳到原文但细看就是张冠李戴。比如回答里提到“设备故障停机时间不得超过 4 小时”引用编号却指向一份关于采购流程的文档。原因是检索到的 Top Chunk 和最终生成的答案之间没有做硬性绑定模型自由发挥后系统把检索结果里第一条拿来当引用压根没核对是否支持回答内容。第三个是旧版制度反复被命中。企业制度文档每半年修订一次很正常但演示系统里没有人管文档版本。平台上线三周后同事提问“请假审批最长几天”模型还在用两年前的老版本回答。旧版分块没有下线索引里新老文档混在一起模型自然偏向检索到的最相似内容而不是最新内容。这类问题一旦落到业务场景里就是实打实的误导轻则办事流程走错重则触发合规风险。企业级知识库不是做出来“能回答”就行而是要在权限、版本、引用、审计这些无人喝彩的地方扛住压力。否则演示越漂亮上线后摔得越重。1.2 「企业级」和「Demo」的真正分水岭在哪里Demo 像玩具飞机企业级平台像载客飞机。玩具飞机飞起来很讨喜但没人敢坐上去跨洋飞行两者对安全、故障容错、可维护性的要求完全不在一个量级。企业级 RAG 平台至少要过五道关权限隔离不同角色、部门、密级的用户检索范围必须严格过滤。这不是前端按钮能解决的必须在检索链路层面按用户身份动态注入过滤条件。引用可溯模型输出的每一个关键信息点都要能找到对应的原文出处精确到文档、章节、段落甚至行号。数据治理文档要有版本状态草稿、生效、停用、归档各归其位。政策更新后旧版不会继续被检索答复里还要带上生效日期。可运维性调用量、响应耗时、失败请求、Token 消耗、命中率趋势都要有监控面板否则出了问题只能靠用户投诉才知道。评估闭环判断平台改好还是改差不能靠人工抽看几条例子需要一套固定的评估集和回归测试流程。这五条没做扎实其余所有炫酷功能都是空中楼阁。下面要讲的 37 屏系统每一屏的设置都是为了解决这五类问题而不是为了把界面做复杂。2. 37 屏后台的完整地图先拆模块再谈界面2.1 五大功能区与屏数分布很多人听到“37 屏”第一反应是“太重了”这其实是误解。屏数多不等于功能乱只要每个模块边界清晰、数据闭环完整界面多一点反而便于不同角色操作。真正的混乱是没有边界地堆功能而不是按业务域拆得足够细。这套平台最终由 9 个子模块构成合计 37 屏。子模块屏数覆盖页面身份与工作台3登录、双因素验证、数据总览工作台知识库管理6库列表、文档上传、解析任务、文档详情、分块预览、元数据编辑检索调优5测试问答、检索链路调试、参数配置、重排调试、引用比对用户与权限4成员管理、角色权限、数据域授权、审批流配置运营监控6调用总览、响应耗时、Token 用量、命中率趋势、失败日志、反馈看板系统配置4模型配置、Prompt 配置、向量模型管理、缓存与限流审计合规5操作日志、问答审计、数据变更记录、导出记录、权限变更记录评估闭环4评估集管理、标注作业、Bad Case 列表、回归测试报告这个屏数不是提前规划出来的而是做业务梳理时发现的真实需求。比如“审计合规”这个模块一开始只有 2 屏后来合规团队提出要能按员工查问答记录才补成了 5 屏。你可以把屏数理解成业务复杂度的投影而不是项目规模的自嗨指标。2.2 每一屏背后的「数据闭环」逻辑设计整个后台时我们给自己定了一条硬规矩任意一次用户问答都必须能完整回答五个问题。谁在什么时间问了什么检索命中了哪些知识库和文档最终生成回答引用了哪些原文片段模型的完整输出是什么整个链路耗时多久、排了什么状态这五个问题对应到界面里就是工作台的调用详情、审计模块的问答记录、检索调优的 Chunk 命中展示和引用比对页面。任何一个问题在界面里找不到答案都说明链路有数据断层真正上线后你没法定位问题。举一个实际运维场景。某天领导问“为什么员工总是收到过时答案”如果没有完整的链路数据你只能靠猜。但有了数据闭环后你可以直接查那天所有相关问答的命中文档列表发现老版本文档的权限状态没有更新再顺着数据变更记录找到是哪天、哪位管理员改了状态。整个排查过程不超过十分钟。37 屏不是用来给用户看的每个界面背后都是一道数据验证关卡。屏与屏之间不是孤立的而是把完整的数据流串成了闭环。3. 核心链路逐屏拆解上传、切分、检索、生成、溯源3.1 文档接入层格式校验、双通道加载与解析失败兜底文档接入是整条链路的起点但也是最容易被低估的环节。真实企业环境里的文档长得五花八门有扫描版 PDF、有加密文件、有十几年前的老 Word 文档、有嵌着大量流程图的 HTML 页面。如果接入层不够健壮后面所有环节都会受影响。我们在接入层做了三道防线。第一道是格式校验。文件上传后先做检查不是只看后缀名还看真实内容是否匹配。比如一个文件改名成 PDF实际内部是扫描图片后缀校验根本发现不了。这道防线会记录文件类型、大小、页数、是否加密不合格的直接打回。第二道是双通道加载。结构化文本可复制的 PDF、Word、Markdown走普通解析通道扫描件和图片型文档走 OCR 通道。两条通道产出物格式统一都转成带布局信息的 Markdown。这样做是为了保住表格结构很多团队把 PDF 直接转成纯文本表格里的行列关系全丢了后面切分再智能也救不回来。第三道是解析失败兜底。PDF 加密、超大文件超过 300 页、OCR 识别率低于阈值这些情况不会静默失败而是自动进入人工确认队列。我们最初没有这个队列结果上线第一天就有一批扫描文件“消失”在知识库里用户根本不知道为什么。元数据打标也放在接入环节。文档的密级内部公开/机密/绝密、所属部门、生效日期、失效日期都在这个环节录入。后期检索层的所有权限过滤全靠这批标签。3.2 切分与向量化用 300 份真实文档试出来的参数切分参数是 RAG 项目里最容易引发争论的问题。市面上很多教程直接告诉你 chunk_size 设 512、overlap 设 32但真实企业文档根本没法用一套固定参数通吃。做法是先按文档形态分类再定切分策略。制度类文档管理办法、审批流程、组织架构有明确的标题层级我们按 Markdown 标题结构切分一级标题下面是完整的一个章节。表格单独识别成结构化块不跟正文混在一起。技术手册类文档设备操作说明、项目档案没有严格的标题规范我们采用语义段落加滑动窗口先按空行和章节标题粗切再用 window 方式重叠避免上下文被切断。对话记录和 FAQ 类数据走独立的处理方式一条对话或一问一答就是一个 Chunk。300 份真实文档的实验中我们把 chunk_size 放在 200 到 600 个字符之间做过对比。结果很有意思过短200 字符以下导致单块信息量不够检索时召回很多碎片过长600 字符以上导致一块里包含多个主题重排精度下降。最终我们主要落在 300500 字符区间overlap 比例根据文档类型调整制度类用 10%技术手册类用 20%。向量化这块要特别强调合规问题。企业内网环境绝对不允许调用外部 API 做 Embedding这是多数大型企业的硬性要求。我们私有化部署了开源中文向量模型全部请求走内网。实际测试中段落级 Embedding 比句子级 Embedding 的召回效果更稳定。句子级向量单独检索经常命中一些语义相似但不包含关键实体的碎片段落级向量单块信息量更足。3.3 混合检索与重排从 Top 20 到 Top 5 的调优记录刚开始做检索时团队也存在一个误区向量检索已经很好了为什么还要混合真实数据很快就教育了我们。向量检索擅长语义近似召回但对企业文档里的精准关键词非常不敏感。员工常问“请问 BG-2024-07 号合同是否已归档”这里的“BG-2024-07”是一段精确编号向量模型对这类 ID 的匹配能力很差经常召回一堆无关文档。但同时 BM25 对编号的精确匹配几乎是秒杀级表现。两种检索各有优势融合才是正解。于是做了混合检索方案第一轮向量检索和 BM25 倒排检索同步执行各自取 Top 30再用 RRF 算法融合排序取 Top 20 进入重排阶段。RRF 的核心思路是融合时看文档在多个结果中的排序位置不是看具体分数。融合参数 k 设为 60效果最好。重排选用开源重排模型推理成本较高所以只对第一轮的 Top 20 做精排输出最终 Top 5。这个两级结构的原因很朴素重排模型精度高但计算开销大直接用 Top 5 进重排会漏掉潜在正确答案用 Top 50 全量重排又扛不住并发。Top 20 是性能和精度的平衡点实测最稳。调优记录可以分享一组真实数据纯向量检索的命中率为 62%加入 BM25 混合之后到 78%再叠加重排模型后到 89%。这 27 个百分点的提升就是在检索链路里一步步抠出来的没有捷径。3.4 生成策略与引用溯源怎么让模型「只讲有依据的话」检索做好了生成阶段同样有大量细节。这个环节的核心不是让模型变聪明而是让它老老实实基于证据说话。Prompt 设计上我们把检索到的 Top 5 Chunk 作为强约束上下文明确要求模型只能基于这些内容回答禁止使用内部知识补全。当检索内容不足以回答问题时模型直接输出“未检索到有效资料”并引导用户联系知识库管理员。这个拒答策略至关重要因为最怕的不是模型说不知道而是模型一本正经地胡说八道。温度参数调到了 0.2让输出更稳定。但单靠 Prompt 和参数挡不住一切幻觉根源还是在引用绑定。生成阶段模型输出的每个关键事实点都会和对应的 Chunk 做映射前端返回结果时把命中的 Chunk ID 一并返回。用户看到的回答里每一段关键内容旁边都有引用角标点击后能跳到原文的对应页面和段落。我们要求做到“引用里的每个字都能在原文找到”不然审计过不了。这套机制实现之后之前引用名存实亡的问题才算彻底解决。4. 真机实录上线前一个月踩过的 6 个生产级坑4.1 权限穿透普通员工问到了财务数据这是所有坑里最吓人的一个。测试同学用一个普通员工账号登录随口问了一句“某产品的毛利率是多少”系统竟然给出了准确数字。查完之后发现检索层的向量库根本没有接用户数据域过滤只是在 UI 上做了菜单隐藏。有个前端同学图省事以为页面不显示入口就够了但检索接口本身没有任何权限校验。修复方案是彻底重构检索入口所有检索请求统一经过一个权限网关根据用户的角色、部门、数据域标签动态拼过滤条件传给向量库和倒排索引。这一步必须在数据链路层面完成而不是期待前端按钮做好隔离。自那以后权限测试被列入每次发版的必测项。4.2 切分错误导致「张冠李戴」某个技术手册里有一张检修计划表表格同时包含“检修周期”和“责任人”两列。切分阶段没有做表格结构化处理直接把纯文本切开了结果模型把第一列的检修周期和第二列的责任人串在了一起给出了完全错误的对照关系。这个问题表面上是模型理解错了实际上根源在切分阶段的表格破坏。修复方案是增强表格识别能力切分之前先解析行列关系把表头、表体、单元格做结构化标记。修复之后这类问题没有再出现。4.3 并发一上来检索服务先崩了做压测那天我们信心满满地上了 12 路并发。结果重排模型直接在 GPU 上排队接口响应从单线程下的 1.2 秒涨到 12 秒几轮之后直接超时。定位后发现瓶颈不在向量检索重排模型虽然是瓶颈之一但最大的问题是缓存完全没有做。同一个问题被不同用户重复询问时系统每次都重新执行全部检索和重排。修复方案做了三层第一Top 20 的粗排结果加了 5 分钟缓存相同或相似的查询直接命中第二向量化的 Embedding 结果做了预生成和持久化避免每个请求重新算第三重排模型加了一个排队监控超出队列长度直接降级为粗排结果保证服务不挂。4.4 幻觉不全是模型的错有一次业务方反馈回答里的数据是错的。排查到最后发现模型引用的数字来自一份已经作废的旧版制度。两份内容高度相似的制度文档同时存在旧版没有下线照样参与检索模型无法区分哪个是现行版本。这个问题直接推动我们建立了文档版本状态机草稿、生效、停用、归档四种状态检索时只查生效状态的文档回答里自动附带版本号和生效日期。数据治理这一关不过调再多参数都白搭。4.5 引用溯源与技术文档版本冲突早期引用只显示文档标题没法定位到具体页面。有人问一句“规范里说了什么”系统答完引用链接跳到文档首页审计人员还得在几十页里自己找。修复方案是在分块阶段给每个 Chunk 记录页码、段落序号、章节路径。引用展示时直接跳到原文档的具体段落所有信息逐字可查。这一步工作量不算大但对审计验收来说是决定性的。4.6 审计日志缺失差点让平台无法验收合规验收前一周对方要求查“某部门上周有哪些人问了合同相关问题”我们打开日志一看只记录了问题内容没记录用户身份当时后背就凉了。连夜补审计模块每次问答都必须记录八个字段用户、部门、会话、知识库、命中文档、Top Chunk、模型回答、响应耗时。日志保留 90 天。补完之后合规顺利通过但这个过程提醒我们审计日志应该在设计阶段就做好而不是临时补。5. 评估闭环怎么证明平台不是「看起来很聪明」5.1 评估集建设从随手抽问到 2000 对人工标注没有评估集就没有办法客观回答“平台上个月到底变好还是变差了”。我们第一版评估是从真实工单和员工提问里抽取了 200 对问答人工标注“正确、部分正确、错误”三档。这 200 对的作用是逼出第一批 Bad Case用来迭代。之后扩展到 2000 对覆盖制度问答、技术手册、流程办理、数据查询四类场景。每类场景至少 500 对确保评估不偏向某一种文档类型。评估集独立存放绝不进入向量库否则就被污染了评估结果不再可信。5.2 三个关键指标命中率、引用准确率、拒答率评估阶段我们主要盯三个指标。命中率反映的是模型回答的核心要点是否都出现在命中文档里。引用准确率验证的是回答里的每个引用编号是否真的对应正确来源这部分主要靠人工复核。拒答率衡量的是系统在无把握的时候是否果断拒答而不是硬编答案。三个指标相互制衡只看其中一个容易走偏。比如一味提高命中率模型的拒答率可能下降反而开始强行回答一些问题。指标评估方式目标值命中率核心要点是否都在命中文档中≥ 90%引用准确率引用编号与来源逐一比对≥ 95%拒答率无依据问题是否拒答可控范围内目标是反馈出的参考值真正上线后要根据业务场景调整。越核心的业务流程越要允许“拒答”保证回答正确性比回答覆盖率重要得多。5.3 持续优化循环线上反馈如何倒逼数据治理评估不是一次性工作而是一个长期循环。我们在每个用户端的回答卡片下放了“对、错、引用错误”三个反馈按钮。反馈数据自动进入 Bad Case 池每周跟评估集合并跑一次回归。更关键的是反馈数据会反哺数据治理。某篇文档被频繁标记“引用错误”系统会自动提醒管理员检查这篇文档的切分质量或者版本状态。之前聊天提到的旧版制度问题就是靠这个机制被主动揪出来的。平台上线三个月后Bad Case 的每周新增数量明显下降这就是闭环在起作用。6. 常见问题速查与避坑自检清单6.1 高频问题与排查思路速查表症状可能原因排查思路检索结果明显不准切分粒度过大或过小、Embedding 模型不匹配先检查 Chunk 是否完整保留了关键实体再做不同切分参数的对照测试回答引用与内容不符Chunk 标号映射错误、生成阶段未绑定引用检查引用 ID 与 Chunk ID 的对应关系确认生成阶段是硬绑定而非事后补充权限数据泄露检索层未按用户数据域过滤直接用越权账号测检索接口看返回结果是否包含过滤条件并发一高就变慢重排模型排队、缺缓存看压测报告定位耗时最高的环节优先加粗排缓存和异步处理旧版制度总被命中版本状态未管理检查文档元数据的生效状态确认索引里是否混入停用版本模型答非所问Prompt 约束不足、Top 召回内容不够精准先看召回 Top 5 是否正确再优化 Prompt 的强约束表述问答不可追溯审计日志缺失字段补全用户身份、部门、命中文档、耗时等核心字段6.2 上线前必须过的自检清单文档密级元数据是否在检索链路全局生效而不是只在 UI 层隐藏引用能否做到逐字回溯原文精确到章节和段落审计日志是否覆盖问答、数据变更、权限变更、导出四类动作评估集是否稳定可用且独立于训练数据并发和限流是否压测过重排降级方案有没有启用数据更新与下线是否走完版本状态机旧版不会继续参与检索这套自检清单是我们踩了无数坑之后整理出来的成本很低但能拦住绝大部分上线事故。最后说点个人体会。做完这套平台我最深的感触是RAG 项目的成败技术选型和模型调参只占一小部分真正的难点在于数据治理、权限隔离、审计追溯这些看不见的底座。如果只让我给后来者留一条经验那就是不要在模型和参数上沉迷太久先把数据治理和权限做扎实。检索链路可以慢慢调但底座不牢再多漂亮界面都撑不起企业级这三个字。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
