企业知识库落地：为什么「上传文档就能问」在真实业务里不够用

我们在给客户做企业知识库时，几乎每次都要先纠正同一个预期：把文档上传上去，就能准确回答问题。

Demo 阶段这个说法基本成立。挑十几份干净的文档，问几个文档里写得明明白白的问题，效果确实很好。但把范围扩大到一个部门真实的几千份文件，准确率会肉眼可见地掉下来。掉下来的原因往往不是模型不行，而是下面这四件事没做。

一、文档本身没整理，检索就无从谈起

真实企业的文档长什么样，做过内部信息化的人都清楚：

• 同一份制度有 v1、v2、终版、最终版、最终版（确认）五个文件，内容互相矛盾
• 大量扫描件 PDF，本质是图片，没有文字层
• 关键信息在 Excel 的合并单元格里，或者在 PPT 的文本框里
• 正文里写着「详见附件三」，而附件三从来没有一起上传

检索增强的前提是能检索到正确的那一段文字。上面每一条都会直接导致检索失败，而模型对检索失败的典型反应不是说"我不知道"，是顺着问题编一个看起来合理的答案。

所以知识库项目的第一阶段，通常不是技术工作，是文档治理：确定权威版本、淘汰过期文件、把扫描件做 OCR、把表格转成结构化数据。这部分工作量经常被严重低估，我们的经验是它能占到整个项目周期的三到四成。

一个可操作的判断标准：如果一份文档，公司里的老员工也要翻半天才能确认哪个版本有效，那它现在还不该进知识库。

二、切分方式决定了答案的完整度

文档要切成小块才能做向量检索。很多开箱即用的方案默认按固定字数切，比如每 500 字一段。这对连续叙述的文章还行，对企业文档往往是灾难。

制度文件的典型结构是「条款标题 + 若干子项」。按字数硬切，很容易把标题和它的适用条件切到两段里去。检索时命中了子项那一段，模型看不到前提条件，就会把一条有适用范围的规定回答成一条普适规定。这类错误最危险，因为它读起来完全通顺。

更稳的做法是按文档结构切分：

1. 优先按章、条、款等既有层级切，保留标题作为每一段的前缀
2. 表格整行切分，不要把表头和数据行拆开
3. 每一段带上它的来源路径，比如「员工手册 / 第四章 考勤 / 第 12 条」
4. 段与段之间留一点重叠，避免恰好切在句子中间

三、权限必须在检索层解决，不能靠提示词

这是政企和中大型企业项目里最容易出事的一点。

有的实现方式是把全部文档一起检索，然后在提示词里加一句「如果用户无权查看，请不要回答」。这在工程上是不成立的。提示词是建议不是约束，用户换一种问法就可能绕过去；更重要的是，内容已经进了模型上下文，日志、缓存、调试信息里都可能留下痕迹。

正确的做法是把权限做到检索这一层：用户发起提问时，先根据其身份确定可访问的文档范围，检索只在这个范围内进行。模型自始至终看不到越权内容，自然也就无从泄露。

这也意味着知识库不能是一个独立的孤岛，它需要和企业既有的组织架构、岗位角色打通。项目排期时要把这部分对接时间算进去。

四、答案必须可溯源，否则没人敢用

一个不标注出处的答案，在企业场景里的可用性接近于零。因为使用者无法判断该不该信它。

我们的做法是每一条答案都必须附带引用，点开能直接跳到原文对应段落。这带来三个实际好处：

• 使用者可以自己核对，把最终判断权留在人手里
• 一旦答案有问题，能立刻定位是文档错了还是检索错了
• 出现争议时有据可查，这对政企客户尤其重要

顺带一提，可溯源还会改变使用者的心态。知道答案能被核对之后，大家更愿意把它当成一个「帮我快速定位文件」的工具，而不是一个「替我做决定」的黑盒。这个定位反而更符合当前技术的实际能力。

落地节奏的建议

如果你正在评估企业知识库，我们建议的推进顺序是：

1. 先选一个小场景，比如只做 HR 制度问答，文档控制在几十份以内
2. 把这批文档治理干净，跑通检索、权限、溯源全链路
3. 收集真实提问，统计答不准的比例，逐条分析是文档问题还是检索问题
4. 确认这个场景稳定之后，再横向扩展到下一个部门

反过来，一上来就把全公司文档一起导入的项目，我们见过的基本都卡在准确率上，最后沦为无人使用的摆设。

知识库不是一个买回来就能用的软件，它更接近一个持续运营的内部信息工程。真正决定成败的，是文档治理机制能不能长期维持下去。