设想一个内部知识库问答界面：提问后，答案给出了一段看似完整的结论，还附上文档标题和段落编号。点开原文，相关段落只提到流程背景，并没有这句结论。用户会以为系统“读错了”，但问题往往不在模型一处，而在检索与生成之间的缝隙。
检索增强生成的基本思路并不复杂：先从资料中找出可能相关的片段，再把片段和问题一起交给模型组织答案。它把“凭参数记忆回答”改成“带着材料回答”。这句描述容易让人产生一种错觉，仿佛只要接上知识库，答案就会自动可靠。实际运行时，材料可能没被找到，找到的材料可能不完整，完整材料之间还可能互相矛盾。
先别急着换模型
许多回答质量问题，在检索阶段已经埋下。文档切得太碎，上下文被切断；切得太粗，噪声挤占上下文窗口。文件名、更新时间、适用范围这些元数据如果缺失，检索只能靠语义相似度碰运气。权限控制若只做在界面层，模型仍可能把不该出现的内容带进答案。这些问题不会因为换模型自动消失。
评估也需要拆开看。至少应分别观察：召回的资料是否包含回答所需信息；答案中的每句关键结论能否在引用片段中找到依据；资料不足时，系统是否愿意说“无法确认”。如果只看最终答案是否流畅，容易把措辞问题误判为知识问题。把“引用是否支持结论”做成检查项，有助于暴露真实短板。
- 检索日志是否保留原始问题、召回片段和最终引用？
- 无答案场景是否被纳入测试，而不是只测有标准答案的问题？
- 资料更新后，旧结论是否会被及时撤下？
边界同样需要说清。检索增强生成不能保证模型理解材料，也不能替代知识库治理。它只是把一部分记忆责任转移给外部资料。如果资料本身过期、冲突或缺少适用范围，模型仍要在矛盾中做选择。此时系统设计的重点不是让回答更像人，而是让不确定性可见：标明来源、保留原文入口、允许拒答、记录证据链。
我更愿意把这项技术看成一套“可追溯的回答流程”，而不是一个即插即用的功能。它的价值不在于让模型显得无所不知，而在于让每个结论都有机会回到材料。检索增强生成真正考验的，是团队是否愿意把知识库当作长期维护的产品，而不是一次性接入的插件。