企业 RAG 知识库：从数据治理到上线评测的七个步骤

本文目录

企业做 RAG，最容易跑通的是演示：导入一批文档，接上向量库，问题看起来都能回答。困难的部分会在进入业务时浮现。制度更新了，索引里还是旧版本；同一个问题对不同员工应该返回不同资料；系统给出了引用，但引用并不能支持答案。

因此，RAG 不应被当成一个独立聊天窗口。它更适合作为 AI 工作流中的检索与证据层：负责找到当前用户有权查看、能够支持下一步判断的材料。

下面七个步骤从这个目标出发。

第一步：先定义任务和验收问题

方向比数据更重要。不要从”把哪些文档导进去”开始。先写清用户在什么流程里提问，答案将被用来做什么。

同样是查询差旅制度，员工自助问答、财务审核和报销单自动检查需要的结果并不相同。前者重视易懂和出处，财务审核需要完整条款，自动检查还要求结构化字段和确定的规则版本。

第一版至少要确定：

主要用户和具体任务；
系统允许回答与必须拒绝的问题；
哪些来源可以作为依据；
正确答案、可接受的不完整答案和严重错误分别是什么；
结果如何进入后续业务步骤。

随后收集一批真实或经过脱敏的代表性问题。测试集要包含常见问题、边界情况、资料无法回答的问题，以及不同权限用户提出的相同问题。没有这批问题，后面的切分和模型选择只能靠感觉。

第二步：建立知识源和更新责任

知识库的根基是源头管理。为每类知识源建立清单：来源系统、内容负责人、更新频率、权限方式、保留期限和失效条件。Wiki、网盘、工单、CRM 和制度文件的同步方式不同，不应全部用同一条导入脚本处理。

入库时至少保留文档 ID、版本、来源地址、更新时间和负责人。原文被修改或删除后，索引也要更新或撤回；否则系统可能继续引用已经废止的制度。

这里还有一个经常被忽略的决定：什么内容不该进入 RAG。重复文件、扫描质量过低的材料、无明确所有者的旧文档，以及不允许被模型处理的敏感信息，应先隔离。含个人信息的材料还要单独走数据合规判断。面向公众提供服务的检索问答，本身属于生成式人工智能服务，需要按《生成式人工智能服务管理暂行办法》完成安全评估与算法备案，基于已备案模型构建的应用还要按执行口径办理应用登记，内容安全和数据来源都会进入核查范围；涉及境外供应商或跨境传输的，还要评估数据出境要求。这些判断应当发生在入库之前，而不是等系统上线后再补救。指望检索阶段自动修复，只会把问题往后推。

第三步：让权限跟着文档进入索引

权限问题拖到后期就是事故。”用户看不到原文，但模型可以搜到”不是一个可以接受的权限模型。文档、段落或数据记录的访问范围需要随内容进入索引，并在每次查询时根据调用者身份过滤。

具体实现可以使用文档级 ACL、角色字段或用户组过滤。关键是权限检查发生在检索阶段，而不是生成答案后再做关键词屏蔽。Microsoft 的文档级访问控制说明展示了一种实现方式：索引保存权限元数据，查询时排除调用者无权访问的结果。

权限也会变化。员工转岗、项目关闭或源文档调整权限时，索引中的权限元数据必须同步更新，并用测试验证旧权限确实失效。

第四步：按内容结构设计切分和元数据

切分没有万能公式。切分没有一个适合所有文档的固定字数。制度文件适合保留标题层级和条款编号；表格需要保持表头与行列关系；工单可以按问题、处理过程和结论组织；长报告可能需要父子块，让检索返回局部内容时仍能找到所属章节。

每个 chunk 建议携带：

文档与版本 ID；
标题路径、页码或条款编号；
来源、更新时间和内容类型；
权限字段；
与原文相邻内容或父级段落的关联。

embedding（把文本转换为可比较向量的嵌入）模型也不按参数大小直接决定。对中文企业知识库来说，选项并不少：智源开源的 BGE 系列（FlagEmbedding）针对中文做了专门优化，支持私有化部署，是国内项目里使用较广的选择之一；此外还有 M3E、GTE 等中文或中英混合模型。应使用同一批中文和领域问题比较召回质量、输入长度、成本与延迟，不能因为某个模型在通用榜单上分数高就直接采用。embedding 模型的更新同样会改变检索结果，应纳入和模型一致的变更管理。切分、元数据和 embedding 是一组联动参数，需要一起实验。Microsoft 的 RAG 设计指南也把切分、嵌入和检索选择放在同一套评测流程中。与其给出单一最佳方案，不如让团队在实验中找到适合自己的组合。

第五步：建立关键词、向量和混合检索基线

三种检索方式先跑一遍再说。纯向量检索擅长处理语义相近的表达，但可能漏掉产品编号、错误码、人名和精确条款。关键词检索正好相反。企业问题往往同时包含自然语言和专有名词，因此至少应比较三组基线：

关键词检索；
向量检索；
关键词与向量结合的混合检索。

在此基础上再评估重排序、查询改写、元数据过滤或多索引路由。重排序可能提高前几条结果的相关性，也会增加延迟和费用。是否采用，应由固定测试集上的收益决定。国内的基础设施选项同样丰富：Milvus 等开源向量数据库可以私有化部署，阿里云百炼的知识库服务以及腾讯云、百度千帆等平台则内置了解析、切片、混合检索与重排序能力，可以把向量库和检索链路托管出去。但平台内置不等于免评测，检索基线仍要用自己的样本跑一遍，差别只是实验工作从搭建系统变成了配置参数。Microsoft 的检索阶段指南列出了全文、向量、混合检索与重排序的实验方法。

不要只保存最终答案。还应记录查询、检索方式、返回的文档 ID、排名、过滤条件和耗时，这样才能知道问题来自检索、上下文拼装还是生成。

第六步：定义引用、回答和拒答规则

检索到的，不都能直接用。检索结果进入模型前，需要去重、按权限再次确认，并控制上下文长度。相关材料多不等于全部塞入提示词。重复或边缘相关的片段会挤占有效证据，也会增加模型给出含糊答案的机会。

回答协议至少应说明：

事实性结论必须引用具体来源；
引用要能定位到文档、章节或条款；
多个来源冲突时，展示冲突和版本时间，不替用户擅自合并；
检索不到足够证据时明确拒答或转人工；
需要执行后续动作时，只传递经过验证的结构化结果。

引用并不会自动带来可信度。需要检查的是：引用内容是否支持这句话、是否为当前有效版本、当前用户是否有权看到。

知识库正在从“给人查”变成“给智能体查”

过去 RAG 主要服务聊天窗口里的提问，现在越来越多的场景是智能体把知识库当成工具来调用。国产平台已把这一能力产品化：百度千帆提供 MCP Server，把文档解析、文字识别等能力接入智能体工具链；阿里云百炼的知识库服务支持 Agent 检索问答。趋势带来的变化不是换接口，而是对知识库本身提出三个新要求。

第一，检索结果要结构化。智能体与聊天用户不同，它会把答案写进工单、报表或下一个任务的输入，只给一段自然语言往往不够，还需要字段、来源 ID、版本和权限标记。第二，权限必须跟着调用者走。“人看不到、但智能体能查到”是比原来更危险的漏洞，因为智能体可以把检索到的内容继续转发到下游流程。第三，接口要能按协议被调用。多个智能体通过 MCP、A2A 等协议协作时，知识库不再只是给人看的页面，而是一个能被标准协议查询、带权限边界的服务。

第七步：分别评测检索、回答和业务结果

三层评测，一层都不能省。一张 RAG 评测表至少有三层：

层级	要回答的问题	可选指标
检索	相关材料有没有出现，排在什么位置	Precision@K、Recall@K、MRR、NDCG
回答	内容是否有依据、完整且直接回应问题	Groundedness、相关性、完整性、引用准确性
业务	用户是否完成任务，是否减少转人工或返工	任务完成率、转人工率、处理时间、人工修正类型

其中，Precision@K 和 Recall@K 衡量前 K 条结果的准确程度与覆盖范围，MRR 看第一个相关结果出现得多早，NDCG 则考虑多个相关结果的排序质量。

Precision@K、Recall@K 和 MRR 需要事先标注每个测试问题对应的相关文档；没有相关性标注时，数字看起来精确，实际无法解释。端到端评测还要覆盖证据一致性、回答相关性和完整性，具体定义可以参考 Microsoft RAG Evaluators。

上线后保留用户反馈，但不要把所有“点踩”直接加入回归集。一次负反馈可能来自检索失败、回答风格、权限问题或用户本身的问题描述不清。先由业务负责人归因和修正，再把有代表性的案例纳入测试集。

每次调整切分、embedding、检索参数、提示词或模型后重跑同一套回归集。与此同时观察线上查询分布、无答案率、权限拦截、延迟、成本和人工修正。离线评测负责防止旧问题回归，线上观测负责发现新的问题。

RAG 的边界要留在工作流里

检索只是手段，决策还得人来。RAG 擅长提供证据，不负责替企业决定所有事情。对付款、合同承诺、用工或权限变更等高后果任务，检索结果可以辅助判断，但最终动作仍需要确定的业务规则和相应审批。

如果知识检索只是更长流程的一部分，还要把它与工具调用、人工确认和异常恢复一起验收。可继续参考《AI 工作流上线前要验收什么？》。

完成这七步后，团队得到一套可以被更新、授权、评测和持续运营的检索能力。它既可以服务聊天界面，也可以作为带权限边界的数据服务，被审核、客服、销售或运营工作流里的智能体调用。

本文引用的外部资料：

参考资料

专题：RAG 与 Agent#RAG#知识库#向量检索#教程