RAG失败了——但究竟是哪一层真正失败了？一种诊断方法

RAG 系统返回了一个薄弱、错误、不完整或缺乏支持的答案。通常的诊断是“检索失败”或“模型产生了幻觉”。这两个标签都过于宽泛，无法发挥作用。生产环境中的 RAG 流水线可能在检索之前、检索期间、排序期间、组装上下文期间、生成期间，或在生成之后检查证据和有效性时失败。

为什么“RAG 失败了”不是一种诊断

检索增强生成结合了多种机制：用户请求被解释，构建一个或多个搜索，检索候选材料，对结果进行过滤或重新排序，将选定的证据插入模型上下文，模型生成答案。生产系统可能还会添加权限、元数据过滤器、时效性规则、引用、查询重写、混合搜索、工具调用、记忆和外部状态。

因此，错误的最终答案并不能告诉你哪个组件失败了。模型可能收到了错误的证据。它可能收到了正确的证据，但混杂了太多噪声。证据可能是正确的，但已经过时。来源可能从未包含答案。或者模型可能忽略了完全足够的上下文。

OpenAI 的 RAG 指南已经对检索失败和模型失败做出了根本区分：系统可能提供了错误的上下文，也可能提供了正确的上下文但仍然生成了错误的答案。AWS 同样将仅检索评估与检索并生成评估分开。对于生产诊断，这种区分应该更进一步。

RAG 故障栈

第 1 层 — 来源覆盖：系统究竟能否回答这个问题？

在调整嵌入、重排序器或提示之前，请验证答案是否存在于系统被允许使用的知识空间中。这听起来显而易见，但许多 RAG 故障实际上是语料库故障。所请求的事实可能缺失、隐藏在未索引的附件中、仅在较新的文档中可用、存储在 RAG 语料库之外的系统中，或被权限阻止。

检索指标无法恢复从未被索引的信息。更大的 top-k 无法检索流水线中不包含的文档。如果来源覆盖测试失败，正确的修复方法是摄取、来源选择、权限，或明确的“无法根据可用证据回答”行为。

第 2 层 — 查询构建：系统是否向语料库提出了正确的问题？

用户查询并不总是检索查询。生产系统会重写问题、解析代词、提取实体、翻译语言、添加元数据约束、拆分复杂问题或生成多个搜索。每一次转换都可以改善检索，但每一次转换也可能破坏信息。

诸如“在九月更新之后，该政策是否仍然适用于德国的承包商？”这样的请求至少包含一个实体、一个人群、一个司法管辖区和一个时间边界。被重写为“承包商政策”的查询可能会检索到语义相关的文本，但会丢失决定答案是否有效的变量。

第3层——候选检索：相关证据是否进入了集合？

候选检索主要是一个召回问题。诊断问题还不是最佳结果是否排名第一；而是相关证据是否出现在候选池中的任何位置。如果已知的正确来源没有出现，请调查索引、分块、嵌入、词汇匹配、元数据、混合搜索、语言处理、同义词和查询扩展。

这就是仅检索评估有价值的地方。AWS为仅检索RAG评估提供了上下文相关性和上下文覆盖率。重要的生产习惯是在生成之前评估检索，这样精致的最终答案就无法掩盖薄弱的候选集。

第4层——排序和过滤：正确的证据是否被丢弃或埋没？

一个系统可以有良好的召回率，但仍然失败，因为相关证据的排名低于嘈杂但语义相似的材料。重排序器、新近度提升、权威权重、语言偏好、租户过滤器、访问控制、产品状态过滤器和去重都会改变最终上下文中保留的内容。

因此，调试应保留完整的候选列表，而不仅仅是最终的top-k。如果黄金证据在第18位被检索到，而重排序器将其移除，那么修复方法与检索遗漏不同。

第5层——上下文组装：有用的证据是否变成了可用的上下文？

检索成功并不能保证上下文成功。相关的块可能被截断、与其限定词分离、重复直到主导提示、与矛盾版本混合，或被足够的无关文本包围，以至于决定性段落失去显著性。

块边界尤其重要。一个句子可能包含规则，而下一个句子包含例外。如果它们被单独索引，并且只检索到第一个，检索器可能看起来相关，而组装的上下文变得具有误导性。

第6层——生成：模型能否正确使用正确的证据？

一旦系统明显提供了足够的证据，生成就可以独立测试。模型可能过度概括、组合不兼容的段落、忽略否定陈述、未能遵循请求的答案格式、在事实之间发明桥梁，或从参数记忆而不是检索到的证据中回答。

这就是为什么仅端到端正确性不足以进行诊断。OpenAI建议将评估作为理解应用程序行为的一种结构化方式，而Anthropic的代理评估指南强调多次试验、评分器、跟踪和现实的失败案例。对于RAG，生成器应在正常检索和受控黄金上下文下进行测试。

第7层——证据归因：答案是否真正得到支持？

一个带有引用的看似合理的答案仍然可能基础薄弱。引用的文档可能与主题相关，但不支持具体主张。一个句子可能得到支持，而另一个是推断的。引用可能指向一个来源，一旦阅读其条件，就会与答案相矛盾。

因此，引用评估属于生成之后。AWS区分引用精确度和引用覆盖率：引用的段落是否被正确引用，以及答案是否得到引用的充分支持。在生产中，主张级别的支持比将任何引用的存在视为证据质量更有用。

第8层——有效性和新鲜度：证据对于这个现实版本是否正确？

RAG可以检索到一个完全真实、高度相关、忠实引用的来源，但如果该来源对当前问题不再有效，仍然会产生错误答案。政策会变化。API被弃用。价格变动。软件行为在不同版本之间变化。产品库存变化。权限变化。游戏补丁改变机制。

这是一个与幻觉不同的失败类别。证据是真实的；其适用性是错误的。因此，一个稳健的系统需要时间戳、相关时的版本或司法管辖区元数据、来源权威、取代规则，以及一个明确的机制来决定何时必须限制或放弃旧证据。

最快的隔离方法：oracle上下文测试

最有用的第一步拆分很简单：手动向生成器提供一小部分你知道足以回答问题的证据。保持任务和预期答案不变。

生产诊断序列

不要同时改变三层

一个常见的调试错误是在一次迭代中改变嵌入、块大小、top-k、提示和模型。如果分数提高，你不知道原因。如果变差，你不知道哪个改变导致了回归。

将RAG调试视为实验诊断：尽可能保持流程不变，用一个受控输入替换一个不确定的组件。黄金文档隔离检索。黄金块隔离块选择。固定上下文隔离生成。固定模型隔离检索变化。固定语料库隔离摄取和索引变化。

常见RAG症状的故障矩阵

用每层实际能影响的指标来衡量

正确答案仍可能隐藏RAG缺陷

反向问题也很重要。RAG系统可以在检索损坏的情况下产生正确答案。模型可能已经从训练中知道答案，从弱证据中推断出来，或者猜对了。如果评估只看最终答案，系统可能看起来健康，直到问题涉及仅存在于私有语料库中的信息。

这与更广泛的代理系统中出现的可靠性问题相同：结果正确性不足以证明执行路径是可靠的。对于RAG，跟踪应至少保留检索查询、候选集、排序、最终上下文、答案、引用、模型版本、语料库/索引版本和相关过滤器。

使用竞争假设，而不是最喜欢的解释

如果一个糟糕的回答立刻被归为“嵌入问题”，那么调查就已经带有偏见了。更强大的调试方法是在改变系统之前写下相互竞争的假设：缺失来源、查询重写不佳、检索召回率低、重排序不佳、上下文截断、版本冲突、生成失败、引用失败或证据过时。

然后选择一个能够区分这些假设的测试。这比收集更多支持第一种解释的例子更有效率。同样的原则也适用于一般的人工智能辅助技术推理：有用的诊断是能够通过区分性测试的诊断，而不仅仅是听起来合理的诊断。

什么会改变这个答案？

确切的诊断层会随架构而变化。一个简单的单文档RAG应用可能没有查询重写、重排序器或引用层。一个代理式检索系统可能会增加规划、多次搜索、工具选择、记忆、权限和迭代证据收集。结构化数据库查找可能根本不使用块或嵌入。

核心方法仍然成立：识别能够独立改变结果的组件，构建受控测试，用已知良好的输入替换不确定的组件，并使用适合该层的证据来测量每个组件。

局限性

真实的失败往往是耦合的。一个弱的查询会降低召回率，进而改变重排序，进而改变上下文，进而增加生成方差。预言机上下文测试是一种诊断捷径，并不能证明某个组件是唯一原因。评估数据集也可能不具有代表性，而基于模型的评分器可能引入自身的错误。

因此，所提出的堆栈最好用作调查结构：记录管道、隔离变量、重现失败、测试相互竞争的解释，并在层级别修复后进行端到端评估。

结论

“RAG失败了”应该是调查的开始，而不是结论。有用的诊断能够识别系统是缺乏证据、搜索不正确、未能检索到、排序不佳、组装了不可用的上下文、生成不正确、归因不当，还是应用了超出其有效性边界的证据。

实用规则很简单：一次一层地用受控证据替换不确定性。从预言机上下文测试开始。将仅检索评估与生成评估分开。保留完整跟踪。然后修复实际失败的组件，而不是凭直觉调整整个RAG堆栈。

常见问题

术语表

主要来源和进一步阅读