即使是设计良好的RAG流程，有时也会产生不理想的结果。了解问题出在哪里以及原因对于评估性能和进行有针对性的改进非常重要。理解RAG系统常见的故障模式是十分重要的，因为识别这些模式有助于诊断实现中的问题。
检索故障：未能找到正确信息
检索器的职责是从您的知识库中找到最相关的文本块，以回答用户的查询。此阶段的失败意味着生成器（LLM）接收到质量差或不相关的信息，这使得生成正确且有用的回答变得非常困难，甚至不可能。
常见原因包括：
- 检索到不相关的块： 搜索机制返回的块在语义上与查询词相关，但实际上不包含答案或必要的上下文 (context)。如果查询模糊不清，或者嵌入 (embedding)模型不适合区分特定领域内含义上的细微差别，则常会发生这种情况。
- 遗漏相关块： 知识库中存在正确信息，但检索器未能识别并将其排名足够高，以包含在传递给生成器的上下文中。这可能源于使用了未能很好地捕捉文档语义的嵌入模型、将相关信息分散到不同块的无效文档分块策略，或次优的搜索参数 (parameter)。
- 检索到过时或错误信息： 知识库本身可能包含过时或错误文档，而检索器忠实地检索出这些不正确的信息。这突出强调了RAG系统知识来源中数据管理和版本控制的重要性。
- 覆盖范围不足： 知识库根本不包含回答查询所需的信息。检索器可能会返回最接近的可用块，但它们不足以回答问题。
影响： 当检索失败时，生成器收到有缺陷的输入。这通常导致回答事实不正确（幻觉 (hallucination)）、模糊不清，或者简单地声明信息不可用，即使信息存在但未被检索到。
生成故障：误解或忽视上下文 (context)
有时，检索器成功找到了完美的上下文，但生成器（LLM）仍然产生糟糕的回答。这些故障与LLM如何处理增强提示（原始查询 + 检索到的上下文）有关。
常见原因包括：
- 忽视提供的上下文： LLM可能会忽视检索到的块，并主要基于其内部的参数 (parameter)化知识生成回答。如果提示未能清楚地指示LLM优先使用提供的上下文，或者LLM对主题有强烈、预先存在（且可能不正确）的信念，这种情况会更常见。
- 合成错误： LLM难以结合来自多个检索到的块的信息，或未能平滑地整合上下文与查询意图。它可能会误解检索文本的细微之处，导致即使提供了正确的事实，回答中仍有事实错误。
- 尽管有上下文仍出现幻觉 (hallucination)： 即使有相关上下文，一些LLM仍可能引入听起来合理但实际上不正确的细节（产生幻觉），特别是在要求基于提供的信息进行推理 (inference)或推断时。
- “中间丢失”： 当呈现一个填充了许多检索块的长上下文窗口时，LLM有时难以注意到中间部分的信息。如果相关细节不在上下文块的开头或结尾附近，它们可能会被忽视。
影响： 生成故障导致回答未能准确反映检索到的信息。回答可能逻辑上有缺陷，与提供的上下文相比事实不符，或者尽管有必要信息却未能直接回答用户的查询。
集成故障：检索与生成之间的问题
纯粹发生在检索或生成内部的故障可能导致问题，这些问题源于这两个组件的相互作用方式或整个流程的编排方式。
常见原因包括：
- 上下文 (context)窗口限制： 检索器可能找到许多相关块，但总长度超过LLM的最大上下文窗口大小。用于处理这种溢出的策略（例如截断、选择top-k）可能会丢弃重要信息，导致最终回答不完整或不准确。
- 处理矛盾信息： 检索器可能会提取多个包含冲突细节的块（例如，来自不同文档的同一事件的不同日期）。LLM可能未被明确提示或不具备逻辑上解决这些冲突的能力，导致它任意选择一个、忽略两者，或产生令人困惑的回答。
- 缺乏来源归因： 系统成功检索信息并生成正确答案，但未能指明使用了哪些检索到的文档。这使得用户难以验证信息或进一步查看来源，降低了信任度和实用性，尤其是在需要高可靠性的应用中。
RAG流程的简化视图，显示了不同类型的故障通常源于何处：检索（1）、生成（2），或它们之间的集成（3）。
确定您的RAG系统中正在发生哪种故障模式是实现有针对性改进的第一步。接下来讨论的评估指标和策略将帮助您系统地诊断并解决这些问题。
