完整题目
在检索-生成（Retrieval-Generation, RG）系统中，如果整体效果不佳，应如何系统性地定位问题是出在检索模块、生成模块还是两者之间的协同环节？请说明排查思路和常用诊断方法。
本文目录
答案要点
- 建立分层诊断框架，区分检索侧、生成侧、协同侧三类问题
- 掌握定量指标（Recall@K、上下文相关性、忠实度）与定性分析（bad case分析）结合的方法
- 理解检索-生成耦合效应（如检索冗余、信息冲突）
- 具备实际可落地的排查工具链和实验设计能力
核心排查框架：分层隔离诊断
把RAG系统拆成三个独立可测的环节，逐个验证：
一、定位检索模块问题
关键指标
- Recall@K：正确答案是否在Top-K检索结果中
- MRR/NDCG：相关片段的排序质量
诊断方法
- 人工标注100个查询的"黄金文档"，计算检索命中率
- 分析未命中的case：是query理解偏差（需改写/扩展）、还是向量空间不对齐（需调整embedding或分块策略）
快速实验：用人工精选的上下文替换检索结果，若生成质量显著提升 → 问题在检索侧
二、定位生成模块问题
关键指标
- 忠实度（Faithfulness）：生成内容是否被上下文支持
- 答案相关性：是否回答了用户问题
诊断方法
- 固定输入"完美上下文"（人工构造含答案的片段），观察模型是否仍能正确生成
- 若仍出错：检查指令遵循能力、长上下文理解、或SFT数据分布偏移
三、定位协同环节问题
常见耦合故障：
| 现象 | 根因 | 验证方式 |
|---|---|---|
| 答案在上下文里，模型却"看不见" | 检索片段过长/冗余，关键信息被淹没 | 截断/重排序实验 |
| 多片段信息冲突，模型选错 | 缺乏冲突消解机制 | 单片段 vs 多片段输入对比 |
| 检索到相关但非最优片段 | 排序模型与生成偏好不对齐 | 交换Top-1和Top-2观察生成变化 |
四、实用工具链
- LangSmith/RAGAS：自动化指标追踪
- 可视化检索结果：看query与召回片段的语义距离
- A/B实验：固定一端、扰动另一端，量化影响幅度
决策优先级：通常先保检索Recall（无米之炊），再优化生成和协同（锦上添花）。
换一种问法，检查是否真正理解
场景切入
假设你正在做一个电商客服的RAG系统，用户问了个售后问题，系统返回的答案却牛头不对马嘴。你会先从哪里查起？是检索没找到对的内容，还是模型没用好这些内容？
层层追问
RAG系统效果不好，你一般从哪些角度排查？……检索和生成都有嫌疑时，怎么隔离它们？……有没有什么指标或者实验能帮你把问题锁定到具体模块？
直球架构
请说一下在RAG系统中，当整体效果不佳时，如何系统性地定位问题是出在检索、生成还是协同环节？具体排查步骤和诊断方法是什么？
练习口述回答 · 约4分钟
- 一句话定本质：RAG效果不好，核心是隔离排查各环节
- 先查检索：看召回率，人工标黄金文档，用完美上下文做快速实验
- 再查生成：给完美上下文看模型能否答对，查指令遵循或SFT问题
- 最后查协同：信息淹没、冲突、排序偏好三坑，用对比实验定位
- 收尾：先保检索Recall，再优化生成，最后调协同；留可延伸点问评估
这道题表面问的是[[RAG]]系统效果不好怎么排查，但其实本质是问你能不能把检索、生成、协同这三个环节剥离开来，各自独立验证。我一般会按先检索、再生产、再协同的顺序来排查，每一步都做定量和定性结合的分析，并且每一步都有快速实验可以确认问题是不是出在这里。
先说检索。我会先看 Recall@K，具体做法是人工标注100个查询对应的黄金文档，然后看检索模块能不能把这些文档召回。如果Recall偏低，那问题基本就在检索侧。我会进一步分析那些没召回的case：是query理解有偏差，比如用户说“退运费”但模型没把它映射到“退货退款”这个意图上，那就可能需要做query改写或扩展；还是向量空间本身没对齐，比如文档[[分块]]策略不对，或者[[embedding]]模型跟业务语义不匹配，那就得调分块大小或换embedding。快速验证的方法很简单：用人工精选的上下文替换检索结果，如果生成质量明显提升，那问题就锁定在检索侧。
检索没问题了，再看生成。我会固定输入一个“完美上下文”，就是人工构造的、明确包含答案的片段，然后看模型能不能正确生成。如果这时候还出错，那问题就在生成模块本身。常见原因有三个：一是指令遵循能力弱，比如[[系统提示]]没写清楚“只用给定上下文回答”；二是长上下文理解有退化，比如上下文太长，关键信息被淹没在中间；三是 [[SFT]] 数据分布偏移，模型在训练时没见过这种格式的输入。这里有个前提：你必须先确认检索侧已经没问题，否则生成端的诊断会被污染。
检索和生成都确认正常，那就要看协同环节了。协同出问题，我见过三种典型场景。第一种是信息淹没，比如检索返回了10个片段，每个都很长，答案藏在第三个片段的中间，模型根本“看不见”。这种我会做截断或[[重排序]]实验，比如只保留Top-3或者用 Rerank 把最相关的片段排到最前面。第二种是信息冲突，比如两个片段里价格不一致，模型不知道该信哪个。这种我会对比单片段输入和多片段输入的效果，如果单片段效果好，那就是模型缺乏冲突消解能力，需要加一个片段选择或投票机制。第三种是排序偏好不对齐，比如模型总是倾向于用Top-1片段，但有时候Top-2才是最优的。这种我会交换Top-1和Top-2，看生成结果有没有跟着变，如果变了，说明模型太依赖排序，那就得调整生成策略或者用 [[Self-RAG]] 让模型自己学会反思。
举个例子，在电商客服退款场景里，用户问“我昨天买的那个订单为什么还没退款”，检索可能返回订单状态、退款规则、客服对话记录等多个片段。如果协同没做好，模型可能只看到订单状态说“处理中”，就回答“正在处理”，但忽略了退款规则里写着“大额退款需人工审核，预计3个工作日”，结果用户还是不满意。这个问题就是协同环节没把关键信息对齐。
说到评估，其实这里有个更深的坑：很多时候你修复了一个环节，但整体效果没有提升，那是因为你修的环节不是当前瓶颈。所以我会坚持每次只动一个变量，比如只换embedding或者只改chunk大小，同时用 [[RAGAS]] 里的 [[Faithfulness]] 和 [[Context Recall]] 两个指标来监控，看哪个指标先改善，就能判断瓶颈在哪里。