客服同事遇到过一个尴尬问题：用户问某个功能在旧版本里是否还能用，模型答得很肯定，条款却引用了已经下线的政策。后来翻共享盘，正确说明躺在另一份更新过的文档里。问题不在模型不会说话，而在它根本没看到那份文档。检索增强生成要处理的，正是这类“知道该查什么、却查不到”的场面。
它的基本动作并不神秘：先把问题改写成适合检索的查询，从文档库里找出相关片段，再把这些片段和原问题一起交给模型，让答案尽量落在可查证的资料上。和微调不同，它不改模型参数；和把整份手册塞进提示词也不同，它需要在有限上下文里做取舍。检索增强生成更像一条信息供应链，检索质量决定回答质量，生成只是最后一公里。
链路里容易失手的地方不在生成
很多团队刚开始搭问答系统，会把注意力放在提示词和模型选择上，上线后才发现问题出在前面的资料层。常见故障大致有几类：
- 文档本身过期，或者同一件事存在多个口径，检索把旧说法和补充说明一起召回。
- 切块把条件句、例外条款拆散，模型拿到半句话，回答自然走样。
- 用户说的是业务口语，文档写的是内部术语，查询和原文对不上。
- 权限过滤放在生成之后，或者干脆没做，导致答案引用了不该出现的资料。
- 评测只看回答是否流畅，不检查引用的片段是否真的支持结论。
这些问题听起来琐碎，却决定了系统能不能被信任。检索增强生成的工程重点，往往落在文档治理、元数据、切块策略和召回评估上，而不是把希望寄托在换模型上。资料层没有整理好，后面的生成环节只能替混乱打补丁。
它适合什么，不适合什么
当知识更新频繁、回答需要出处、不同角色看到的内容还不一样时，检索增强生成有明确的用武之地。它把“模型记住什么”变成“模型这次能查到什么”，方便追溯，也方便在资料变更后快速修正。反过来，如果任务需要跨大量文档做长链条推理，或者资料本身缺少结构、互相矛盾，单靠检索并不能自动得到可靠答案。它也不会替模型补上推理能力的短板，只是把外部信息送进上下文。
我更愿意把它看作信息工程，而不是模型魔法。成功的项目通常有人负责文档生命周期，有人盯着召回结果，有人定义什么情况下应该拒答。只买一个向量库、接一个接口，离可用还有距离。
先把评测放在回答之前
评估时，不妨先问一个朴素问题：正确资料有没有进入候选片段？如果没有，后面再漂亮的回答也是碰运气。接着看引用是否真的支撑结论，以及证据不足时系统会不会收手。检索增强生成的价值不在让每句话都像标准答案，而在让不知道的时候有机会说不知道。资料混乱时，它只会把混乱更快地送到用户面前。