完整题目
在检索增强生成（RAG）系统中，如果整体生成效果不佳，你会如何系统性地定位问题是出在检索模块还是生成模块？请说明具体的诊断步骤与评估指标。
本文目录
答案要点
- 明确区分检索问题与生成问题的诊断思路
- 掌握检索侧的核心评估指标（Recall@K、MRR、NDCG）
- 掌握生成侧的核心评估指标（Faithfulness、Answer Relevance、Context Precision）
- 能够设计消融实验或黄金文档实验验证假设
- 提出端到端追踪与人工分析的具体方法
核心诊断思路：模块解耦 + 端到端追踪
第一步：判断是否为检索问题
黄金文档实验（Golden Document Test）
- 将标准答案依赖的文档直接注入context，若生成质量显著提升 → 检索是瓶颈
- 若仍有问题 → 生成模块或prompt设计有问题
检索侧关键指标
| 指标 | 用途 | 健康阈值 |
|---|---|---|
| Recall@K | 相关文档是否被召回 | >0.8（K=5/10） |
| MRR/NDCG | 排序质量 | 视场景，MRR>0.5 |
| Context Precision | 检索结果中噪声比例 | 越高越好 |
快速诊断信号
- 用户问题与召回文档语义明显不相关 → Embedding模型或分块策略问题
- 相关文档召回但排名靠后 → 需要重排序（Rerank）或混合检索
第二步：判断是否为生成问题
生成侧关键指标
- Faithfulness（忠实度）：生成内容是否基于context，可用NLI模型或人工抽样
- Answer Relevance：答案是否回应问题，可用BERTScore或人工判断
- Context Utilization：模型是否有效利用了检索到的关键信息
典型生成故障模式
| 现象 | 根因 | 解法 |
|---|---|---|
| 忽略检索内容，依赖参数知识 | Prompt未强调"严格基于上下文" | 显式指令 + citation要求 |
| 拼接多个文档信息产生幻觉 | 长context注意力分散 | 压缩context或重排序去噪 |
| 答案正确但未引用来源 | 缺乏训练或指令跟随不足 | SFT/RLHF强化引用格式 |
第三步：系统化追踪工具
- RAGAS / ARES：自动化评估检索→生成的全链路
- LangSmith / Phoenix：可视化trace，查看每步输入输出
- 人工抽样分析：建立bad case分类体系（检索失败/理解失败/整合失败）
关键原则
不要同时优化两端。先固定一端验证另一端，避免变量混杂。通常优先保证检索质量（Recall），再优化生成忠实度。
换一种问法，检查是否真正理解
场景切入
假设你在做一个电商客服RAG系统，用户问“这个订单什么时候发货”，结果模型答了退货政策，明显没对上。你会怎么一步步排查是检索没找到相关文档，还是模型压根没读检索结果？
层层追问
RAG效果不好，你觉得可能哪些环节出问题？……检索和生成，哪个更容易定位？……如果我把正确答案依赖的文档直接塞进上下文，生成变好了，那问题出在哪？……那如果还是不行呢？
直球架构
请你说说系统性地诊断RAG中检索模块和生成模块问题的具体步骤和评估指标，比如召回率、忠实度这些，怎么用实验设计来解耦两个模块？
练习口述回答 · 约4分钟
- 本质是模块解耦找瓶颈
- 黄金文档实验定位检索侧
- 检索指标与常见根因
- 生成侧故障模式与解法
- 端到端追踪与取舍判断
这道题其实问的是，[[RAG]]系统效果不好时，怎么快速定位到底是检索没找到对的文档，还是模型看了文档但没好好用。我的思路很简单：把两个模块解耦，先固定一个测另一个，别上来就两边一起调。
具体第一步，我会做黄金文档实验。把标准答案依赖的那部分文档，直接塞进生成模块的上下文，如果生成质量一下子好了，那问题基本就锁在检索侧。如果生成质量还是不行，那就说明生成模块或者prompt设计本身有问题。这个实验非常便宜，不需要任何额外标注，跑几轮就能下判断。
假设实验指向检索侧，我会先看召回率，就是Recall@K。比如Top-5召回率低于0.8，大概率是[[Embedding]]模型或者[[分块]]策略不够好。举个例子，客服退款场景里，用户问的是‘我买的东西降价了能退差价吗’，如果召回的是‘退货政策’而不是‘价格保护条款’，那分块粒度就偏了。这时候我会检查分块是不是把意思相近但不同的条款切到了一起，或者Embedding对价格、退款这类语义区分不够。如果召回率还行但排序靠后，那就说明需要加[[重排]]或者[[混合检索]]，把关键词和向量结合起来。
反过来，如果黄金文档实验发现生成模块有问题，我会重点看[[忠实度]]。模型有没有忽略检索到的内容，去依赖自己的参数知识？典型的故障模式是，prompt里没强调‘严格基于上下文’，或者上下文太长模型注意力散了。我见过一个企业SOP合规场景，文档明明写了‘审批金额不超过五万’，模型却生成‘十万以下走简易流程’，这就是典型的[[幻觉]]。解法也很直接：prompt里加显式指令，要求每个答案必须引用来源段落，必要时做[[SFT]]强化引用格式。但这里有个前提：如果检索内容本身噪声很大，模型很难从中提炼正确信息，所以要先确保检索质量再调生成。
系统化追踪的话，我会用[[RAGAS]]或者LangSmith跑全链路trace，看每一步的输入输出。但说实话，自动化指标只能筛出明显的问题，真正决定效果上限的是人工bad case分析。我会按检索失败、理解失败、整合失败三类建个分类体系，每个case拆开看。
这里我多说一句：很多人一上来就调Embedding模型或者换大模型，其实更常见的问题是分块策略太粗糙。比如固定512字符切分，很容易把一句完整逻辑切散。我倾向于先做语义分块，用[[Parent Document]]结构保留上下文，这样召回时既能拿到高精度的小块，又能附上完整的父文档，对生成质量帮助很大。
所以我的整体判断是：优先保证检索的Recall，再优化生成的Faithfulness。两边不要同时动，否则变量混杂，你永远不知道是哪个改动起了作用。