设想一个内部知识库问答界面：员工问“出差住宿标准有没有调整”，系统流畅地给出条款，还附了链接。点开链接，却发现是两年前的版本。答案的语气很确定，问题却出在它引用的材料上。这类尴尬让检索增强生成从“模型能力”话题，落回到更朴素的工程问题：知识怎么被找到、怎么被信任。
检索增强生成的基本思路并不复杂：模型在回答前先去外部资料中检索相关片段，再把片段与问题一起组织成上下文。它把一部分记忆负担从参数里挪到可更新的文档里，听上去适合企业知识库。但真正落地时，检索环节往往比生成环节更考验耐心。用户的问题口语化、带省略、夹着组织内部简称，文档却按章节和制度语言写成。两边对不上，召回就可能偏。
先别急着问模型会不会答
一个常被忽略的细节是切片。把长文档切成小段，是为了让检索命中更细的内容；切得太碎，上下文断裂，模型拿到的只是半句话；切得太粗，一段里混着多个主题，检索分数被稀释。更麻烦的是权限和时效：同一句话，对不同角色可见性不同；同一主题，新旧版本并存。若检索层没有把元数据、生效时间、访问范围一并处理，生成层再流畅也只是在放大误差。
所以我更愿意把检索增强生成看作一套“知识供应链”，而不是一个模型插件。它至少涉及文档治理、检索策略、上下文编排和结果评估。评估也不能只看回答像不像人话。可以拆成几层看：检索到的片段是否覆盖了回答问题所需的信息；回答中的关键结论能否在片段里找到依据；当资料不足时，系统是否愿意说“不知道”。最后一点尤其重要，因为企业问答里，承认信息缺口通常比编一个圆滑答案更有价值。
边界比能力更值得先写清楚
检索增强生成也有它不擅长的地方。它不负责判断制度本身是否合理，也不能替代知识库的日常维护。文档长期不更新，检索层只能忠实找回旧内容；权限模型混乱，系统也很难凭空推断谁该看到什么。它适合的是“资料存在、结构尚可、需要快速定位并组织答案”的场景；如果知识本身散落在聊天记录和附件里，先做整理可能比接模型更迫切。
回到开头那个问题，答案引用过期制度，不一定是生成模型太会编，也可能是检索层没有把“时效”当作一等字段。把版本、生效日期、适用范围写进检索与评分逻辑，再让模型在资料冲突时明确提示，这类工作听起来不性感，却决定系统能不能被长期使用。检索增强生成的价值，不在于让模型显得无所不知，而在于让它在有限资料里给出可核对的回答。对企业来说，可核对往往比流畅更接近可用。