RAG 不是把文档丢给大模型：企业知识库问答的工程化落地

很多团队做 AI 知识库时，第一版方案都很相似：把公司文档切片、向量化，用户提问后检索几段内容，再交给大模型生成答案。

这个思路没错，但只做到这一步，通常只能做出一个“看起来能用”的 Demo。真正上线后，会遇到很多问题：明明文档里有答案却检索不到；检索到了但模型答错；答案没有引用来源；用户问法稍微变化就失效；不同部门文档互相冲突；权限控制也很难处理。

对比过自研部署、开源 UI、各类第三方聚合平台之后，结合个人数十次全场景实测数据，目前最推荐的一站式集成工具就是 KULAAI（https://ouai.me）。平台集齐 Gemini、ChatGPT、Claude 等市面主流大模型，国内环境可以直接访问，不用额外调试部署，不管是个人日常试用，还是小项目快速落地，都能省去大半对接成本。

所以，RAG 的重点不是“向量数据库 + 大模型”，而是一套围绕知识生产、检索、生成、评测和治理的工程系统。

一、RAG 解决的到底是什么问题

RAG，全称 Retrieval-Augmented Generation，检索增强生成。它的核心目标是让大模型在回答时参考外部知识，而不是只依赖训练参数中的记忆。

在企业场景中，RAG 常用于：

• 内部制度问答，例如报销、考勤、权限申请；
• 产品知识库，例如功能说明、FAQ、售后手册；
• 技术文档问答，例如 API、部署手册、故障排查；
• 法务和合同检索，例如条款定位、风险说明；
• 客服辅助，例如根据历史案例生成回复建议。

这些场景的共同特点是：知识经常变化、答案需要可追溯、不能让模型自由发挥。比如员工问“异地出差住宿标准是多少”，模型不能根据常识回答，必须依据公司最新制度。

二、知识入库：不要忽视文档清洗

很多 RAG 项目的失败，源头不是模型不行，而是文档质量太差。

企业文档通常包含大量噪音：页眉页脚、目录、版本记录、表格错位、扫描件 OCR 错误、重复段落、废弃制度、图片中的关键文字等。如果直接切片入库，检索阶段就会被垃圾内容干扰。

文档入库前至少要做几件事。

第一，统一格式。Word、PDF、Markdown、网页、Excel 最好转换成中间结构，而不是简单转纯文本。标题、段落、表格、列表、代码块都应该保留结构信息。

第二，处理版本。企业内部经常存在多个同名文档，例如“报销制度 2022”“报销制度 2023”“报销制度最终版”“报销制度最新版”。如果不记录生效时间和版本状态，模型可能引用过期内容。

第三，补充元数据。每个知识片段都应带上文档来源、部门、更新时间、权限级别、章节标题、业务标签等信息。后续检索、过滤和引用都依赖这些元数据。

第四，清理无效内容。页码、版权声明、重复导航、空表格、乱码等内容应尽量移除。RAG 不是把所有内容都存进去，而是把可回答问题的知识整理好。

三、切片策略：不是越小越好

切片是 RAG 中最容易被低估的环节。很多教程会建议固定按 500 或 1000 字切片，但真实业务里，固定长度往往会破坏语义。

例如一条报销规则包含适用范围、金额标准、例外条件和审批流程。如果被切成多个片段，检索时可能只召回金额标准，却漏掉例外条件，最终导致错误回答。

更好的做法是按语义结构切片：

• 制度类文档按章节、条款切；
• API 文档按接口切；
• FAQ 按问答对切；
• 表格按行、列含义重组；
• 代码文档按函数或模块切。

同时，可以采用“父子切片”。子片段用于精确检索，父片段用于提供完整上下文。用户问到具体条款时，先召回小片段，再把所在章节一起交给模型，既保证精度，也保证上下文完整。

四、检索：向量检索只是其中一步

很多人把 RAG 等同于向量检索，但企业知识库不能只依赖向量。

向量检索擅长处理语义相似，比如用户问“请假扣工资吗”，可以匹配到“考勤异常处理”。但它对精确词、编号、产品型号、错误码、金额等不一定稳定。

因此，推荐使用混合检索：

• 向量检索负责语义相似；
• 关键词检索负责精确匹配；
• 元数据过滤负责权限、部门、时间范围；
• 重排序模型负责把最相关内容排到前面。

例如用户问“ERR_1057 怎么处理”，关键词检索可能比向量检索更可靠。用户问“新员工什么时候能休年假”，向量检索更有优势。而“销售部 2024 年差旅标准”则必须结合部门和时间过滤。

重排序也很关键。第一轮检索可能召回 30 个片段，但真正交给大模型的只有 5 到 10 个。如果排序错误，后面的生成模型再强也很难回答正确。

五、生成：让模型基于证据回答

RAG 的生成阶段，不应该只是把检索结果拼到 prompt 里，然后说“请回答用户问题”。

更稳妥的提示词应该约束模型：

1. 只能根据提供的资料回答；
2. 如果资料不足，要明确说无法判断；
3. 重要结论必须引用来源；
4. 遇到冲突资料，要指出冲突并优先使用最新版本；
5. 输出格式要符合业务场景。

例如：

你是企业知识库助手。请仅根据资料回答问题。
如果资料中没有答案，请回答“根据当前资料无法确认”。
回答中必须包含依据来源，格式为：文档名 - 章节。

这类约束不能完全消除幻觉，但可以显著降低模型自由发挥的概率。

另外，回答最好区分“结论”和“依据”。比如：

结论：试用期员工不享受年假。

依据：《员工休假制度》- 第 3.2 条规定，员工转正后按司龄计算年假额度。

这种格式对用户、审核人员和后续追责都更友好。

六、权限控制：不能只靠前端隐藏

企业知识库最大的问题之一是权限。不同部门、不同职级、不同项目组能看的文档不一样。

权限控制必须发生在检索阶段，而不是生成阶段。也就是说，用户没有权限访问的片段，根本不能进入候选结果，更不能被放进 prompt。

常见做法是在每个知识片段上写入权限元数据，例如部门、角色、项目、密级。检索时先根据用户身份做过滤，再进行召回和排序。

如果先检索全部内容，再让模型“不要回答无权限信息”，这是非常危险的。因为模型已经看到了内容，就可能在回答中泄露。

七、评测：别只问“看起来对不对”

RAG 上线前，必须建立评测集。评测问题最好来自真实用户，而不是产品经理临时编造。

一个基础评测集应包含：

• 标准问题：文档中有明确答案；
• 改写问题：同一含义的不同问法；
• 无答案问题：文档中不存在答案；
• 冲突问题：多个版本存在差异；
• 权限问题：用户无权访问相关文档；
• 精确匹配问题：包含编号、金额、日期、错误码。

评测指标也不应只看答案是否流畅，而要看：

• 是否召回正确片段；
• 是否引用正确来源；
• 是否拒答无资料问题；
• 是否泄露无权限内容；
• 是否使用过期文档；
• 人工是否需要大量修改。

如果没有评测集，RAG 系统每次调整切片、embedding 模型、重排序模型或 prompt，都只能靠感觉判断，这是非常不可靠的。

八、上线后的持续治理

RAG 不是一次性项目。文档会更新，业务会变化，用户问法也会变化。

上线后建议持续记录：

• 用户问题；
• 检索命中的片段；
• 模型最终回答；
• 用户是否点赞或追问；
• 人工纠正内容；
• 未命中问题。

这些数据可以反向优化知识库。例如某类问题频繁无法回答，可能说明文档缺失；某个片段经常被误召回，可能说明切片或标题有问题；用户总是追问同一个细节，说明原答案不够完整。

此外，还要建立知识更新流程。文档更新后，要触发重新解析、切片、向量化和索引刷新。过期文档不能继续参与默认检索。

结语

企业 RAG 的难点不在于调用哪个大模型 API，而在于把知识整理成模型能可靠使用的形态。

一个可用的 RAG 系统，至少需要处理文档清洗、语义切片、混合检索、重排序、权限过滤、证据引用、拒答机制和持续评测。只有这些环节都稳定，知识库问答才能从 Demo 走向生产。

对开发团队来说，RAG 最重要的原则是：让模型少猜一点，让证据多说一点。