有人问内部系统一个很具体的问题：某份项目复盘里提到的验收条件改过几次。模型没有去翻文档，却用很肯定的语气给出回答，还顺带编了一个条款编号。后来系统改成先找相关文档，再把片段交给模型组织语言，回答开始带出处，也愿意说“没找到”。这类变化常被归到检索增强生成。
先找资料，再组织回答
模型参数里的知识像一份压缩笔记，写起来顺畅，细节却容易发糊。检索增强生成在生成之前插入一步：把问题拆成检索意图，从文档库中取回片段，做重排和筛选，再塞进有限的上下文，让模型基于这些材料说话。它改变的不是模型性格，而是回答时能看到的材料。
但“接了检索”不等于答案可信。检索没有命中，上下文再工整也没用；文档本身过期或互相冲突，模型会把矛盾一起端上来；切片切得太碎，关键限定条件丢了，回答就可能只对一半。企业常把注意力放在模型选型上，实际工作量却在文档清洗、权限隔离、更新机制和引用展示。
难的不是接一个库
检索增强生成听起来像增加一个模块，做起来更像梳理知识流程。哪些文档可被谁检索，版本如何标记，旧版是否保留，片段如何带来源，回答里引用到哪一层，这些都要在系统里说清楚。否则员工看到的是一段顺滑文字，却不知道它从哪里来，也不敢拿去用。
- 切片要保留标题、章节和限定语，别只留一段孤立句子。
- 召回之后需要重排和去重，避免同一段材料反复占上下文。
- 回答应带可核查来源；找不到时允许拒答，不要把猜测包装成结论。
还有一个常被忽略的边界：上下文预算。塞入太多片段会稀释问题，塞入太少又可能漏掉条件。工程上往往要在召回数量、片段长度和回答自由度之间做取舍。这个取舍没有通用答案，只能跟着业务问题走。查制度条款和查项目复盘，需要的片段粒度并不一样。
把它当成知识流程的显影剂
我的判断是，检索增强生成的价值不止在“让模型多知道一点”，而在于它把组织里的知识治理问题显影出来：文档有没有人维护，权限是否清楚，术语是否统一，旧版本会不会混进新回答。模型只是把这些环节的结果放到用户面前。接一个向量库很快，让回答稳定可核查却慢。
评估时也不必只看回答像不像人话。可以看它能否定位到具体来源，能否在资料不足时收住，文档更新后会不会把新旧版本混在一起，遇到权限外的问题会不会越界。把这些行为放进日常抽检，单看一次演示容易漏掉问题。检索增强生成不是万能补丁，它适合知识密度高、更新频繁、又需要出处的场景；如果资料本身混乱，先整理资料可能是绕不开的一步。
所以，当下一次模型答得顺畅时，不妨多问一句：它刚才翻的是哪份资料？如果答案说不清，检索增强生成还没真正开始工作。