有时一个看似普通的提问，会让对话系统露出底牌：问它某份刚更新的内部说明，它先给出流畅回答，再补一句“请以正式文件为准”。问题不在语气，而在知识来源。模型参数里装着训练时见过的东西，却不知道昨天刚改过的条款。检索增强生成，正是在这个缝隙里被频繁提起。
补的不是“智商”，是可核对的上下文
常见做法是先把问题交给检索模块，从文档库、知识库或网页里找出相关片段，再把片段和原问题一起交给生成模型。模型不再只凭记忆组织答案，而是围绕刚取回的材料说话。听起来像外接了一个资料柜，实际难点却在资料柜怎么整理、怎么找、找到后怎么用。
检索增强生成的价值，常出现在需要出处、需要更新、需要限定范围的问题里。客服要引用最新流程，研发要查接口说明，运营要确认活动规则，这些场景的共同点不是问题多难，而是答案必须能回到某段材料。模型负责表达，检索负责把表达拴在可追溯的文本上。
链路一长，薄弱处未必在模型一侧
一些失败并非生成模型“不会答”，而是检索阶段就没拿到对的段落。文档切得太碎，上下文断掉；切得太大，噪声混进来；标题、表格、附件没有处理好，召回的内容看似相关，实际答非所问。再往后，重排、去重、权限过滤、引用标注，每一步都会影响最终答案。
- 文档质量决定可用程度：版本混杂、扫描件难解析、口径不统一，都会把问题带到下游。
- 切分方式影响召回：段落边界、标题层级和表格结构，需要在切分时保留。
- 引用不是装饰：能指回原文，用户才有机会判断答案是否适用于眼前问题。
所以，把检索增强生成当成“接个向量库就完事”，通常会在真实问题前碰壁。它更像一项资料治理工程：谁维护文档，多久更新，哪些内容可被谁检索，答案引用到哪一层，这些安排对体验的影响很直接。
边界感比宣传语重要
它也有不擅长的地方。需要跨多份材料推理、材料本身互相矛盾、问题缺少明确检索线索时，单纯增加召回数量未必有用，反而可能把噪声推给模型。对实时性要求高的场景，还要权衡索引更新与响应延迟。若材料没有覆盖问题，模型仍可能顺着语言惯性补充，这时系统应允许“不知道”，而不是鼓励硬答。
务实一点，先把问题限定在可维护的资料范围内，再观察失败来自检索、切分、重排还是生成。把每次回答的引用摊开看，能帮助定位问题；只盯一句答案是否顺眼，往往看不出症结。检索增强生成不是让模型突然博学，而是让它在一组可管理的材料里说话，并为说过的话留下线索。