在公司内部问答里，常见一幕是：员工问“出差住宿标准怎么算”，通用模型答得流畅，却把旧制度当成了现行规则。问题不在表达，而在它根本没看过那几页文档。检索增强生成要解决的，正是这个“先找依据，再组织回答”的环节。
它补的不是知识，而是“此刻可用的依据”
把检索增强生成理解成“模型外挂一个搜索框”，只说对了一半。更准确地说，它把用户问题先变成检索请求，从指定资料库里取回若干片段，再把这些片段和问题一起交给模型。模型负责归纳、改写和解释，资料负责提供事实边界。两者分开后，知识更新不必每次都重训模型，改文档、重建索引往往更现实。
但这也是容易出问题的地方。检索没找到对的段落，后面生成得再顺，也只是把错误包得更像答案。很多团队一开始只盯着模型参数，忽略了文档质量：同一制度有多个版本、表格被切碎、标题和正文分离、权限没有同步。检索增强生成的效果，常常在进入模型之前就决定了大半。
回答里的引用，比“像不像人话”更值得看
实际使用时，我会先看答案有没有给出可核对的出处，再看它是否老老实实承认“资料里没有”。一个带引用的回答，即使措辞生硬，也比一段没有依据的流畅解释更有用。因为前者能让人回到原文，后者只能让人凭感觉判断。对内部知识库来说，这种可追溯性比多写几句漂亮话重要。
另一个常被低估的环节是切分。文档切得太碎，片段缺少上下文；切得太长，检索又不够精准。比较务实的做法，是让每个片段保留小标题、适用范围和更新日期，再按问题类型调整召回数量。不是把所有文档一股脑塞进去就叫检索增强生成，资料的组织方式会直接影响答案是否站得住。
它不是万能插件，更像一套需要维护的工作流
有人把检索增强生成当成“接上知识库就完事”的插件，实际运行后才发现，索引会过期，权限会变化，用户问法也远比测试集复杂。它适合资料相对明确、答案需要出处的场景，比如制度查询、产品说明、操作手册；对于需要实时判断或资料本身矛盾的问题，它只能把矛盾暴露出来，不能替人做决定。
所以更稳妥的预期是：把它当成一条可检查的回答流水线，而不是一个不会犯错的答案机器。先确认资料值得检索，再确认检索结果能被引用，最后才谈生成风格。顺序反了，系统看起来聪明，用起来却让人更累。