让模型直接回答一个企业内部的流程问题，常常会遇到一种尴尬：语气很确定，内容却和最新文档对不上。模型并不是故意编造，它只是在用训练时留下的语言模式做概率续写。要让它少一点“凭印象”，一个常见思路是先把相关资料找出来，再让模型基于资料作答，这就是检索增强生成。
它补的不是知识量，而是回答前的动作
检索增强生成的核心并不神秘：用户提问后，系统先在文档库、知识库或业务资料中检索相关片段，再把片段和问题一起交给模型，要求它依据给定材料组织答案。模型仍然负责理解和表达，但“事实来源”从参数记忆部分转移到外部资料。这个变化带来的直接好处是，回答可以更贴近组织当前使用的文档，也更有机会给出处。
不过，它不等于给模型接上一个搜索框就结束了。检索环节找到什么，往往决定生成环节能说什么。资料切分过粗，片段里会混入无关内容；切分过细，上下文又可能缺少必要条件。权限控制也需要提前考虑：检索器不能把用户无权查看的文档片段带进答案。换句话说，检索增强生成的难点很少只在模型本身，更多在资料治理和流程设计。
一个容易被忽略的边界：查得到，不等于答得对
实际使用中，常见问题不是“完全查不到”，而是“查到了但不够贴切”。比如问题里包含多个条件，检索只命中了其中一个；或者文档版本较旧，却和最新材料混在一起。此时模型如果直接拼接片段，可能给出看似有依据、实际不完整的回答。更稳妥的做法，是让系统在资料不足时明确说“不确定”，并把命中的原文片段展示出来，方便用户核对。
- 先看检索结果是否覆盖问题中的关键条件，而不是只看答案是否通顺。
- 给文档加上来源、时间和适用范围，减少旧资料被误用的概率。
- 对权限、脱敏和日志做前置设计，别等上线后再补。
落地时，先把问题问小一点
如果一开始就想覆盖所有部门和所有文档，系统很容易变成“什么都能答，什么都答不稳”。更务实的路径是选一个边界清楚的问题域，比如产品文档查询、内部制度问答或售后知识检索，先把资料整理到可维护的状态，再观察模型在真实问题上的表现。评估时也别只看单次回答是否漂亮，要看它在缺少资料、资料冲突和问题模糊时怎么处理。
我的判断是，检索增强生成更像一种工程约束，而不是一次模型升级。它把“模型应该知道什么”拆成“去哪里找、找得准不准、找到后怎么用”三个环节。把这几个环节做扎实，模型的可信度才会慢慢上来；只盯着生成端调提示词，往往会绕开真正的问题。