RAG 在政企场景的三个坑：时效、口径与「我不知道」

检索增强生成（RAG）的基本原理并不复杂：把问题拿去检索相关文档，再连同问题一起交给模型作答。网上的教程大多到此为止。

但我们在给政府部门和企事业单位做落地时发现，真正让项目卡在验收环节的，往往是通用教程不会讲的东西。这里挑三个最典型的说。

坑一：文档有生效日期，检索没有

政企文档有一个鲜明特点：大量内容带有明确的时间效力。某项补贴标准 2024 年是一个数，2025 年调整过；某个办事流程去年要五份材料，今年简化成三份。

向量检索只看语义相似度。问「申请需要哪些材料」，2023 年的旧版通知和 2025 年的新版通知在语义上几乎一样相似，检索器没有任何理由偏向新的那一份。结果就是模型可能拿着作废文件回答现行政策。

这个问题不能靠模型解决，要在检索层处理：

• 每份文档入库时必须带上生效日期和失效日期，作为可过滤的字段
• 检索时默认只召回当前有效的文档，过期文件直接排除
• 如果一份新文件明确废止了旧文件，建立替代关系，让旧文件不再被召回
• 确实需要查历史版本时，作为一个独立功能提供，而不是混在日常问答里

这件事的难点同样不在技术，在于有没有人负责维护这些日期。我们通常会建议客户把它并入既有的公文流转流程，新文件归档时顺手填上，而不是另起一套需要专人维护的台账。

坑二：口径不统一，模型只会让矛盾更明显

同一件事，不同处室的文件表述不一致，这在体量稍大的单位里几乎是常态。人工处理时，经办人凭经验知道该按哪份文件执行。但知识库会把两份文件一起检索出来，模型面对矛盾信息，通常有三种反应，每一种都不理想：

1. 挑一份回答，不说明还有另一种说法
2. 把两种说法拼在一起，读起来自相矛盾
3. 含糊其辞，回答等于没答

值得注意的是，第一种最危险，因为使用者完全看不出这里存在争议。

技术上能做的是把矛盾暴露出来而不是掩盖掉：当检索到的多份文档在关键信息上冲突时，明确告知使用者存在不同表述，并列出各自出处，让人来判断。

但根本解法还是回到管理侧：知识库上线过程中暴露出的口径冲突，应该反馈给业务部门去统一。我们做过的几个项目里，客户最认可的价值反而不是问答本身，而是借这个机会把积压多年的口径问题梳理了一遍。

坑三：模型不肯说「我不知道」

这是验收现场最容易翻车的场景。领导随口问一个知识库里根本没有的问题，模型编了一段像模像样的话，全场气氛立刻就变了。

模型倾向于给出答案而不是承认不知道，这是它的固有特性。缓解手段有几个层次：

• 设检索阈值：如果召回内容的相关度低于阈值，直接走「未找到相关资料」的固定回复，不让模型自由发挥
• 提示词里明确授权：告诉模型在资料不足时回答不知道是被期待的行为，而不是失败
• 强制引用：要求每个结论都必须对应到具体的原文片段，答不出引用的内容就不输出
• 给出路径：不知道的时候，顺带告诉使用者可以联系哪个部门，比单纯的「无法回答」体验好很多

其中检索阈值是最有效的一道闸门，因为它在模型开口之前就拦住了。代价是会有一部分本可以答对的问题被拦掉，需要根据实际使用情况反复调。我们的经验是宁可保守：政企场景里，一次一本正经的胡说八道造成的信任损失，要拿几十次正确回答才能补回来。

一句总结

RAG 在政企场景的难点，很少是模型能力不够，绝大多数是信息治理的问题被技术方案暴露了出来。

这也是我们做这类项目时的一个基本判断：如果客户内部的文档管理和口径统一没有基础，先做知识库大概率会失败。反过来，把这件事当作推动信息治理的抓手，效果往往超出预期。