一个常见场景是：员工在内部问答框里问“差旅报销标准今年变了吗”，系统给出了一段过期条款。模型语气笃定，依据却停在去年的文档里。问题往往不在它会不会说，而在该看的材料没有被带到眼前。
检索增强生成把这件事拆成检索与生成两段：先从知识库里找出与问题相关的片段，再让模型基于这些片段组织回答。听起来直接，真正做起来，麻烦大多发生在两段之间。
不是把文档塞进向量库就结束
项目常从“建库”开始：收集文档、切分、向量化、接入模型。演示能跑通，上线却容易露出缝隙。文档切得太碎，上下文断裂；切得太长，检索命中后噪声过多。表格、附件、版本说明、失效通知，这些内容在真实知识库里并不整齐。
检索层还要面对同义词、缩写、时间范围和权限。员工问“年假能不能延到明年”，系统要先判断他问的是制度条款还是个人余额，还要确认当前生效版本。权限没处理好，回答可能把不该看的内容拼进摘要。检索不是一次相似度计算，它实际上是把组织里的知识边界翻译成查询条件。
答案质量在生成之前就被决定了大半
不少人把检索增强生成当成提示词工程，实际上，检索结果的质量已经决定了回答的上限。问题改写得太宽，召回一堆泛泛材料；改写得太窄，又漏掉关键条款。生成阶段能做的，是依据片段收敛表述、标注来源、承认信息不足，而不是替检索补洞。
- 知识库是否覆盖了真实问题，而不是只覆盖容易整理的文档；
- 切分是否保留了条款、条件和例外；
- 权限与时效是否进入检索条件；
- 评估是否看回答依据，而不只看语气是否流畅。
另一处容易被忽略的是更新。制度改了，旧文档还在，检索仍可能带回旧片段。需要有人负责失效标记、版本切换和问题回流。把这些工作留给模型自动完成，风险不小。
它的边界也值得说清
检索增强生成适合答案有出处、知识会更新、需要可追溯的场景，比如内部制度问答、产品资料检索、客服知识辅助。它不擅长处理知识库里根本没有的内容，也不适合替代开放式推理。材料缺失时，系统应该显示不确定，而不是用流畅句子填满空白。
我的判断是，评估这类项目，先别急着看模型参数，去看知识是否可被找到、权限是否清楚、更新是否有人负责。选一个范围窄、反馈快的小流程跑通，再扩展。检索增强生成不是给大模型加一个外挂，而是把知识管理、检索和生成放进同一条工作流里。