一个常见的内部问答场景：同事问“报销流程里那张补充说明该找谁确认”，系统答得流畅，还给出了三步建议。可点开引用，链接指向一份两年前的制度文件，里面根本没有这句话。答案看起来像真的，出处却对不上。这类尴尬并不罕见，它把问题从“模型会不会说话”拉回到“资料是否被正确找到、被正确使用”。检索增强生成常被当作补丁：先搜资料，再让模型组织答案。听起来顺理成章，落地时却常卡在一些不显眼的环节。
先别急着换模型，检查“找到的东西”
检索增强生成的第一步工作不是生成，而是检索。不少失败场景里，模型并没有胡编，它只是拿到了不完整的段落。文档切分如果只按固定字数切，标题和上下文会被切断；一段话离开所在章节，语义就变了。另一种情况是查询和文档用词不一致：用户问“补充说明”，文档写的是“附件材料”，关键词匹配就容易漏掉。系统于是给出一个看似合理、实则缺少依据的回答。
工程上常见的补救是混合检索、查询改写、给文档加元数据，或者把相邻片段一起送入上下文。这些做法都有代价：查询改写可能引入偏差，扩大召回会把噪声带进来，元数据维护又依赖内容治理。我的判断是，先确认检索结果是否真的覆盖了回答问题所需的信息，再讨论提示词怎么写。否则只是在让模型更会包装错误材料。
引用不是装饰，是约束
不少系统把引用做成了页脚装饰：答案末尾挂几个链接，点开却无法定位到具体句子。对检索增强生成来说，引用应当承担约束作用——模型只能基于给定片段作答，片段里没有的内容要明确说不知道。这需要把“拒答”当成正常输出，而不是失败。实际使用中，用户往往更在意答案是否可核对，而不是句子是否漂亮。
实现层面，可以把回答拆成可追溯的断言，再逐条对应到片段；也可以要求模型在无法确认时给出缺失信息，而不是补全常识。后者听起来简单，做起来难，因为模型天然倾向于给出完整答案。产品设计要给“不知道”留位置，否则再怎么强调忠实度，也会被交互压力推回原点。
评估别只看答案像不像
检索增强生成的评估常被简化成人工看几条回答。这样能发现问题，却难以稳定复现。更务实的做法是把链路拆开：检索侧看目标片段是否进入上下文，生成侧看答案是否被片段支持，端到端再看是否解决了用户问题。三者混在一起，出了问题很难判断该改切分、改召回，还是改提示。
- 检索侧：准备一批问题，标注回答所需片段，观察漏检和噪声。
- 生成侧：检查答案中的关键断言能否在上下文中找到依据。
- 交互侧：记录用户追问和放弃的场景，回看是信息缺失还是表达不清。
这些工作不显眼，却决定了系统能不能长期用下去。检索增强生成不是把搜索和模型接在一起就结束了，它更像一套内容治理与答案约束的协作机制。资料版本、权限边界、更新频率，都会影响最终输出。模型能力在变，这些基础问题不会自动消失。
所以，当答案找不到出处时，先别急着追问“模型怎么又错了”。更有用的问题是：我们有没有把正确的资料，以可核对的方式交到它手里？如果这一步没做好，换更大的模型也只是换一种说法。