同事在内部系统里问：“设备重启前要先做哪几步？”回答看起来完整，却把旧版流程和新版入口混在一起。问题未必出在生成模型本身，而在它拿到的上下文。检索增强生成要处理的，正是这类“答得像，但依据不对”的尴尬。
拆开看并不神秘：先把问题改写成可检索的查询，从文档库取回若干片段，再把片段与问题一起交给模型组织答案。检索增强生成把“知道”与“会说”分开：资料由检索环节提供，表达由生成环节完成。它不保证答案天然正确，但让答案有机会带上出处，也让资料更新不必每次都重训模型。
它像一条资料流水线
很多团队一开始只盯着向量库和模型接口，真正耗时的却是流水线上的琐碎环节。文档切分过粗，片段里会混进无关章节；切分过细，语义又容易断。元数据缺失，系统分不清现行版本和过期附件。权限没有同步，检索可能把不该进入上下文的段落带出来。这些问题不会因为换一个生成模型自动消失。
把所有资料一股脑塞进上下文，看似省掉检索，实际会让无关内容稀释注意力，也让响应变慢、成本上升；文档持续更新时，维护窗口也不现实。检索增强生成的价值不在于让模型记住全部资料，而在于按问题临时取用，并让取用过程可追踪。
边界常常不在模型，而在文档
我见过不少内部问答的原型演示：回答流畅，引用却指向一份早已作废的说明。要避免这种错觉，评估时不能只看句子是否顺。需要看检索是否召回了正确片段，答案是否忠实于片段，无法回答时是否明确说不知道。若只盯最终回答的流畅度，检索失败很容易被语言能力掩盖。
另一个容易被低估的地方是拒绝回答。资料没有覆盖、问题超出权限、片段之间互相矛盾时，系统应当停下来，而不是拼出一个看似合理的结论。把“不知道”设计成正常出口，往往比追问模型能不能再聪明一点有用。
从窄场景开始，先把资料管清楚
如果企业刚开始尝试，可以从问题相对集中、文档版本可追踪的内部问答做起。以下检查项不花哨，却决定系统能不能长期用：
- 文档来源、更新责任和失效标记是否明确；
- 片段是否带版本、权限和生效时间；
- 回答是否附引用，引用能否回到原文；
- 无命中或低置信时是否有兜底话术；
- 日志能否还原检索、拼装上下文和生成的过程。
这些问题往往先于“用哪个模型”。我的判断是，检索增强生成不是给模型加一个搜索框就结束，它把知识治理、权限设计和回答规范重新拉回台面。模型可以换，资料是否可信、更新是否及时、边界是否说清，仍然要由人来安排。