大多数构建 RAG 系统的团队在第一个月都花在流水线（pipeline）上——分块策略、嵌入模型选择、向量数据库配置、检索微调。他们让系统跑通了。演示顺利通过。利益相关者印象深刻。
六个月后，系统开始悄无声息地退化。支持工单提到了错误的流程。机器人引用了一个已经在第三季度停用的价格档位。客户得到了关于一个在他们注册前就已弃用的产品功能的肯定回答。流水线没问题，问题出在知识库上。
这是 72% 的企业级 RAG 部署在第一年都会遇到的模式。团队事后才发现，构建 RAG 系统是容易的部分。难点在于持续的人工过程——创建、验证和注销知识内容——而且几乎没有人会在最初的架构中为此做计划。
摄入管道谬论
知识库搭建最省事的方法是将摄入管道指向任何现有的文档。Notion 导出、Confluence 转储、内部维基、PDF 文件夹——全部加载、分块、嵌入并发布。
这种方法在出问题之前一直有效。摄入管道对内容是否正确、是否最新或是否矛盾没有主见。它只是忠实地将你提供的内容转换为向量。一份 2022 年的入职指南与 2025 年的流程更新并排被嵌入。一个已弃用的 API 参考与当前的参考并存。两者都被检索到。模型选择了其中一个，却没有标记冲突。
结果是基于陈旧定义的肯定回答。一个忠实度（faithfulness）评分为 0.95 的 RAG 流水线——这意味着它忠实地合成了检索到的内容——在检索索引过期八个月时，仍然可能返回错误的业务答案。标准的评估指标并不衡量检索到的内容在 业务层面是否正确，而只衡量模型是否准确地表达了它发现的内容。
跳过策展时的三种失败模式
来自陈旧来源、听起来权威的回答。 这是最隐蔽的失败，因为从指标的角度来看，它看起来很健康。模型并没有产生幻觉——它只是在忠实地合成恰好是错误的文档。使用 RAG 系统的支持代理可能会引用三个月前被取代的服务条款版本中的退款政策。答案在内部逻辑上是连贯的，并且引用了真实的文档。只是该文档不再准确。
斯坦福大学对法律 RAG 的研究发现，即使在准确性至关重要的重大利益领域，RAG 系统产生的幻觉也是“大量的、广泛的且具有潜在隐蔽性的”。讽刺的是，引用显示——这一旨在建立信任的机制——实际上可能会增加错误的信心，因为它营造了经过验证的信息的假象，却缺乏实质内容。
噪声内容导致的低检索精度。 当知识库积累了过时的流程、重复的解释、从未定稿的草稿以及被取代但未删除的文章时，检索质量会明显下降。一个本应呈现两个精确答案的查询，却检索到了七个文档，其中五个是略微相关的噪声。模型接收到矛盾的信号并开始含糊其辞，或者更糟，自信地选择了错误的文档。
检索到的每一个不相关的文档都会消耗上下文窗口的 token，并稀释来自相关文档的信号。检索精度（retrieval precision）——即检索到的文档中实际有帮助的比例——直接限制了生成质量的上限。没有任何提示工程（prompt engineering）或模型升级能够克服一个含有 40% 噪声的知识库。
隐性覆盖缺口。 第三种失败模式是最难检测的：即没有文档涵盖实际问题的查询。知识库是自然积累内容的，这意味着它们积累的是人们想到要写的内容，而不是用户实际询问的内容。当用户询问一个无人记录的流程时，RAG 系统会检索听起来最接近的文档，并生成一个看似合理但可能完全是捏造的答案。没有明显的失败信号——模型不会说“我不知道”。它会根据近似的上下文自信地作答。
识别覆盖缺口需要主动将查询分布映射到知识库中——这在仅限摄入的流水线中从未发生过。
余下内容仅对会员开放。
会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
- 完整文章，包含未公开存档的部分
- 可落地的工作框架，附带权衡与决策依据
- 新文章抢先看，先于公开发布
随时取消 · 一次订阅，畅读全部