RAG 系统的失败不是单一的——从文档解析到最终生成，每个环节都有独特的失败模式。系统性地将失败分类、定位根因、建立诊断流程，是 RAG 工程从"能用"到"好用"的关键跃迁。

一句话解释

RAG 的失败可以按环节分为五大类：检索失败、噪声检索、上下文丢失、生成偏离、幻觉放大——每类有不同的根因和修复策略。

核心问题

为什么需要系统性分析失败模式？

1. RAG 是管道系统：一个环节失败会导致下游全部失效，但表象可能出现在最终生成环节
2. "回答错了"不等于"检索错了"：生成失败和检索失败的修复方向完全不同
3. 可预防：大部分失败模式是可预测、可检测、可修复的
4. 评估驱动优化：知道失败在哪里，才能针对性地优化（详见 RAG评估与优化）

五大失败模式分类

一、检索失败（Retrieval Failure）

定义：相关文档存在于知识库中，但未被检索到。

根因分析：

根因	具体表现	诊断方法
Embedding 质量差	语义相近的文档向量距离远	对比测试：人工判断相关的文档对，检查其向量相似度
Chunk 切分不当	关键信息被切分到不同 Chunk，单个 Chunk 无法完整表达	检查检索结果中是否出现"半句话"或不完整的段落
词汇不匹配	用户用"价格"，文档用"费用"，向量检索可能遗漏	对比 BM25 和向量检索的结果差异
索引覆盖不足	文档未被正确解析或入库	检查文档解析日志和索引文档数量
Top-K 过小	相关文档存在但排名在 K 之后	增大 K 值观察结果变化

修复策略：

• 更换 Embedding 模型（或在领域数据上 fine-tune）
• 使用 Hybrid Search（BM25 + 向量检索互补）
• 调整 Chunk设计 参数
• 使用 Multi-query Retrieval 扩大召回

二、噪声检索（Noisy Retrieval）

定义：检索到了不相关或低质量的文档，这些"噪声"干扰了 LLM 的生成。

根因分析：

根因	具体表现	诊断方法
向量空间过于拥挤	不相关文档与 Query 的相似度也很高	检查 Top-K 结果的相关性分布
Chunk 粒度过大	大块包含多个主题，部分匹配导致整块被检索	检查检索到的 Chunk 中有多少段落真正相关
Metadata 过滤缺失	未按领域/时间/来源过滤	检查是否有明显不属于该领域的文档被检索到
查询过于宽泛	"介绍一下 AI" 匹配到几乎所有文档	分析 Query 的语义空间覆盖范围

修复策略：

• 添加 Rerank重排序 过滤低相关性文档
• 使用 Metadata设计 做预过滤
• 减小 Chunk 大小，提升语义聚焦度
• 使用 Query Rewrite查询改写 精确化 Query

三、上下文丢失（Context Loss）

定义：相关文档被检索到了，但关键信息在 Chunk 切分或上下文组装过程中丢失。

根因分析：

根因	具体表现	诊断方法
Chunk 边界切断关键信息	一个完整的概念/流程被切成两半	人工检查关键段落的完整性
跨 Chunk 引用断裂	"如上所述""参见前文"等引用指向的上下文不在同一 Chunk	搜索文档中的引用词，检查是否被切断
上下文窗口不足	检索到的 Chunk 总量超过 LLM 窗口，部分被截断	检查传入 LLM 的 token 数 vs 模型窗口
Parent-child 映射错误	Child 命中但 Parent 返回了错误的大块	验证 Child→Parent 映射关系

修复策略：

• 使用 Parent-child Chunk 架构
• 增加 Chunk Overlap
• 在 Chunk 中添加上下文提示（如章节标题、前文摘要）
• 使用 Sentence Window 扩展策略

四、生成偏离（Generation Drift）

定义：LLM 未充分利用检索到的上下文，生成偏离了检索内容的回答。

根因分析：

根因	具体表现	诊断方法
上下文过长/噪声多	LLM "迷失"在大量上下文中，忽略了关键信息	检查 LLM 回答是否引用了检索内容中的关键信息
Prompt 约束不足	LLM 过度依赖参数知识而非检索内容	对比 LLM 回答和检索内容的一致性
Temperature 过高	生成内容过于发散	降低 Temperature 对比效果
模型能力不足	小模型难以从长上下文中提取关键信息	换用更大的模型对比效果

修复策略：

• 在 System Prompt 中明确要求"基于检索内容回答"
• 使用 Rerank 减少噪声，让 LLM 聚焦关键信息
• 降低 Temperature（推荐 0-0.3 for RAG）
• 使用"Lost in the Middle"策略：将最重要的信息放在上下文开头和结尾

五、幻觉放大（Hallucination Amplification）

定义：RAG 系统不仅产生了幻觉，还因为"有检索内容支撑"而让幻觉更具迷惑性。

根因分析：

根因	具体表现	诊断方法
部分检索 + 部分编造	回答中混合了检索内容和编造内容	逐句验证回答是否有检索内容支撑
检索内容自相矛盾	多个检索结果信息冲突，LLM "调和"出错误答案	检查检索结果中是否有矛盾信息
过度推理	LLM 基于检索内容做了不合理的推断	检查回答中的推断链条是否合理
知识库本身有错误	检索到了正确文档，但文档内容本身过时或错误	定期审核知识库内容

修复策略：

• 要求 LLM 在回答中标注信息来源
• 使用 Faithfulness 评估指标检测幻觉
• 对检索结果做一致性检查
• 建立知识库内容的定期审核机制

端到端排查流程

当 RAG 系统出现问题时，按以下流程逐环节排查：

Step 1: 问题定位
 ├─ 回答完全错误 → 可能是检索失败或生成偏离
 ├─ 回答部分正确 → 可能是噪声检索或上下文丢失
 └─ 回答"看起来对但有编造" → 可能是幻觉放大

Step 2: 检索环节检查
 ├─ 检查 Top-K 结果：是否包含正确文档？
 │   ├─ 否 → 检索失败（检查 Embedding、Chunk、Top-K）
 │   └─ 是 → 进入 Step 3
 ├─ 检查 Top-K 结果：不相关文档占比？
 │   ├─ >50% → 噪声检索（检查 Rerank、Chunk 大小、过滤条件）
 │   └─ <50% → 进入 Step 3

Step 3: 上下文检查
 ├─ 传入 LLM 的上下文是否包含回答所需的全部信息？
 │   ├─ 否 → 上下文丢失（检查 Chunk 边界、上下文窗口）
 │   └─ 是 → 进入 Step 4

Step 4: 生成环节检查
 ├─ LLM 回答是否忠实于检索内容？
 │   ├─ 否 → 幻觉放大（检查 Prompt 约束、Temperature）
 │   └─ 是 → 可能是检索内容本身的问题

Step 5: 知识库检查
 └─ 知识库中是否有正确且最新的信息？
     ├─ 否 → 知识库需要更新
     └─ 是 → 回到 Step 2 深入排查

失败模式与 RAG 架构选择的对应关系

失败模式	高频原因	推荐架构改进
检索失败	Embedding 质量	Hybrid Search + 领域 fine-tune
噪声检索	缺乏精排	添加 Rerank + Metadata 过滤
上下文丢失	Chunk 切分不当	Parent-child Chunk + Sentence Window
生成偏离	Prompt 约束不足	改进 Prompt + 降低 Temperature
幻觉放大	缺乏忠实度控制	Faithfulness 评估 + 来源标注

失败模式与评估指标映射

失败模式	对应评估指标	检测工具
检索失败	Context Recall, Hit Rate	RAGAS, 自建评估集
噪声检索	Context Precision	RAGAS, TruLens
上下文丢失	Context Utilization	TruLens
生成偏离	Answer Relevance	RAGAS
幻觉放大	Faithfulness	RAGAS, TruLens

常见修复策略速查表

问题现象	最可能原因	第一步修复	进阶修复
回答"不知道"	检索失败	增大 Top-K，检查索引	Hybrid Search, Multi-query
回答包含错误信息	噪声检索	添加 Rerank	Metadata 过滤，减小 Chunk
回答不完整	上下文丢失	增加 Overlap	Parent-child Chunk
回答与检索内容矛盾	生成偏离	改进 Prompt 约束	降低 Temperature，换模型
回答"看起来对但实际编造"	幻觉放大	要求标注来源	Faithfulness 评估 + 过滤
回答过时	知识库过期	更新知识库	建立定期审核机制

常见误区

• 只看最终回答质量：检索环节的问题可能被 LLM "掩盖"，必须分别评估检索和生成
• 一有问题就换模型：80% 的 RAG 问题出在检索和数据质量，而非模型能力
• 不做端到端排查：只修一个环节而忽视其他环节的问题
• 忽视知识库质量：知识库本身有错误，再好的 RAG 也无法给出正确答案
• 不做回归测试：修复一个问题后引入新问题，需要建立评估集的回归测试

可继续补充的方向

• 失败模式的自动化检测与告警
• 基于 LLM 的自动诊断系统
• 失败模式的行业特定分析（医疗/法律/金融）
• 失败模式与 RAG 安全性的关系

关联笔记

• RAG评估与优化 — 评估指标与失败模式的映射
• RAG基础 — RAG 基础流程
• Chunk设计 — 上下文丢失的核心原因
• Rerank重排序 — 噪声检索的主要修复手段
• Query Rewrite查询改写 — 检索失败的修复手段之一
• Parent-child Chunk — 上下文丢失的架构级修复