有一次看客服机器人回答“退换货期限”，句子通顺，语气笃定，点开引用却是售后政策首页，没有条款。这个问题不在生成端，而在检索端：资料被找到了，却没有找到能回答问题的段落。检索增强生成常被描述成给模型外接一个知识库，实际做起来，它更像一条需要反复校准的链路。
链路的起点不是模型，而是问题。用户问得含糊，系统直接拿原句去检索，返回的多半是相关却不解决问题的文本。把问题拆成可检索的片段，识别时间、对象、条件，再决定查哪类资料，这一步常被跳过。这里没有一劳永逸的规则，业务语言越特殊，改写的空间越大。
检索结果回来以后，问题才真正开始。相似度高的段落不一定包含答案。常见故障可以列成几类：
- 一段话讲的是相邻话题，关键词重合却答非所问；
- 文档切得太碎，条款被拆散，单段看不出完整条件；
- 旧版本和新版本同时留在库里，检索时没有区分。
生成模型面对这些材料，会倾向于把缺口补圆，于是答案看起来顺，依据却悬空。
引用不是装饰
很多演示停在“给出答案并附链接”。这还不够。引用至少要能回答两个问题：这句话来自哪一段，这段是否支持当前结论。若只把文档标题挂上去，用户仍要自己翻找，信任没有被建立。检索增强生成要落地，输出侧得保留可追溯的片段，尽量让引用和句子有对应关系，而不是在末尾堆一串来源。
另一个容易被忽略的环节是拒绝。资料里没有答案时，系统应该承认不知道，或者把问题退回给人工，而不是用常识补写。这个边界需要在提示、检索和界面三处同时做：检索阶段设相关性门槛，生成阶段要求只依据给定材料，界面阶段给出“未找到依据”的状态。每一处都不复杂，难的是它们得同时成立。
它擅长的是有据可查
检索增强生成适合那些答案藏在文档里、且文档会更新的场景：内部规范查询、产品说明解释、工单辅助、合同条款定位。它不负责让模型变得全知。对于需要实时判断、开放推理或没有稳定资料支撑的问题，外接检索并不会自动带来可靠性，反而可能把无关片段包装成确定语气。
真正决定效果的，常常是资料治理这些不性感的工作：文档有没有版本标记，段落是否自包含，权限是否跟检索绑定，更新后旧内容是否下线。模型只是链路上的一个环节。把这些基础做扎实，检索增强生成才会从演示里的“能答”变成日常里的“敢用”。