企业知识库与 RAG 的失败原因

失败往往不在模型那一层

企业上线知识问答系统后，最常听到的反馈是"答得不对"。如果顺着技术栈往下查，会发现相当一部分问题在更靠前的位置：文档本身有多个版本、术语没有统一、答案散落在两三份文件里、有权看到答案的人却查不到。

RAG（检索增强生成）的基本原理是把检索到的片段交给模型组织成答案。也就是说，答案的上限由检索到的内容决定。检索质量不行，后面的提示词工程做得再细，也只能把错误说得更流畅。

知识源没理清，后面都是补丁

常见的知识源问题包括：

• 同一制度存在多个版本，新旧文件同时在库里，检索可能命中的是已废止版本；
• 口径不统一，不同部门对同一指标的定义不同，模型无法判断该采信哪个；
• 答案分散，一个完整答案需要跨三份文件拼合，而检索只召回其中一份；
• 格式混杂，扫描件、图片型 PDF、表格截图缺少可提取文本；
• 时效标注缺失，文档没有有效期或修订记录，无法按时间过滤。

建议在动工前做一次知识盘点，产出至少三样东西：文档清单（含版本与责任人）、术语与口径表、失效文档的处理规则。这份清单的维护责任要落到具体岗位，而不是留给项目组临时整理。

切片与元数据决定检索上限

切片策略没有放之四海皆准的答案，但有可判断的原则：

• 优先按文档的天然结构切（章节、条款、表格），而不是按固定字数硬切；
• 保留必要的上下文信息，例如标题层级、所属制度名称、生效日期；
• 对问答型内容，可以把"问题—答案"成对存为一条知识；
• 对表格类内容，保留表头与单位，避免把数字单独切出来。

元数据的作用常被低估。至少应带上：来源文件、版本、生效日期、所属业务域、密级、责任人。这些字段既能用于过滤，也能用于答案溯源——用户能看到出处，才愿意相信结论，也才能在发现错误时快速定位。

权限不是事后配置

知识库的权限问题通常出现在两类场景：一是检索把无权查看的内容带进了答案；二是下游系统权限做了隔离，但知识库这份副本没有同步。

一种可行的做法是沿用企业现有的身份与权限体系，把访问控制做在检索之前，而不是在生成之后做过滤。这样做的代价是需要在数据入库时就把权限标签打准，但可以避免"答案已经生成、才发现不该说"的被动局面。对于跨部门共用的知识，建议明确一个数据责任人，由他决定哪些内容可以被哪些角色检索。

没有评测集就没有改进

上线之后，团队往往只能靠用户反馈判断好坏。建议在建设阶段就准备一份小型评测集：

1. 收集五十到两百条真实问题，覆盖高频问题、跨文档问题、易混淆问题和"库里没有答案"的问题；
2. 为每条问题标注期望答案与来源出处；
3. 每次调整切片、检索策略或提示词后重跑一遍，记录结果变化；
4. 把线上真实失败案例持续补进评测集。

评测集的价值在于把"感觉变好了"变成"哪一类问题变好了、哪一类变差了"。

上线前自查清单

• 知识库里是否还存在已废止的文件？
• 每条知识是否都能说明来源、版本与责任人？
• 术语与口径是否已经统一，冲突项是否有裁决机制？
• 切片是否保留了必要的上下文与表头？
• 权限标签是否覆盖全部内容，且与下游系统一致？
• 系统能否在回答中给出来源出处？
• 是否有评测集，且最近一次调整后重跑过？
• 对"库里没有答案"的问题，系统是否会明确表示无法回答？
• 是否有把用户反馈转化为知识修订的流程？

这份清单看起来偏"土"，但企业知识库的问题大多出在这些地方。把基础工作做扎实，再谈检索策略与提示词优化，投入产出比通常更高。