RG 系统效果差怎么排查?

30 秒回答

1. 建立分层诊断框架，区分检索侧、生成侧、协同侧三类问题
2. 掌握定量指标（Recall@K、上下文相关性、忠实度）与定性分析（bad case分析）结合的方法
3. 理解检索-生成耦合效应（如检索冗余、信息冲突）
4. 具备实际可落地的排查工具链和实验设计能力

回答与解析

答案要点

• 建立分层诊断框架，区分检索侧、生成侧、协同侧三类问题
• 掌握定量指标（Recall@K、上下文相关性、忠实度）与定性分析（bad case分析）结合的方法
• 理解检索-生成耦合效应（如检索冗余、信息冲突）
• 具备实际可落地的排查工具链和实验设计能力

核心排查框架：分层隔离诊断

把RAG系统拆成三个独立可测的环节，逐个验证：

一、定位检索模块问题

关键指标

• Recall@K：正确答案是否在Top-K检索结果中
• MRR/NDCG：相关片段的排序质量

诊断方法

• 人工标注100个查询的"黄金文档"，计算检索命中率
• 分析未命中的case：是query理解偏差（需改写/扩展）、还是向量空间不对齐（需调整embedding或分块策略）

快速实验：用人工精选的上下文替换检索结果，若生成质量显著提升 → 问题在检索侧

二、定位生成模块问题

关键指标

• 忠实度（Faithfulness）：生成内容是否被上下文支持
• 答案相关性：是否回答了用户问题

诊断方法

• 固定输入"完美上下文"（人工构造含答案的片段），观察模型是否仍能正确生成
• 若仍出错：检查指令遵循能力、长上下文理解、或SFT数据分布偏移

三、定位协同环节问题

常见耦合故障：

四、实用工具链

• LangSmith/RAGAS：自动化指标追踪
• 可视化检索结果：看query与召回片段的语义距离
• A/B实验：固定一端、扰动另一端，量化影响幅度

决策优先级：通常先保检索Recall（无米之炊），再优化生成和协同（锦上添花）。

口语版讲法(约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 两个指标来监控，看哪个指标先改善，就能判断瓶颈在哪里。

所以整体我的排查思路就是：先保检索的Recall，确保“无米之炊”这个前提不存在；再优化生成的忠实度和相关性；最后才调协同。如果让我排优先级，我更倾向把70%的精力放在检索侧，因为检索是地基，地基没打好，生成和协同怎么调都是空中楼阁。

关键一句:评估时每次只动一个变量，用RAGAS的Faithfulness和Context Recall两个指标监控，看哪个先改善来判断瓶颈。

面试官还可能这样问

1. 问法 1 · 场景切入

   假设你正在做一个电商客服的RAG系统，用户问了个售后问题，系统返回的答案却牛头不对马嘴。你会先从哪里查起？是检索没找到对的内容，还是模型没用好这些内容？

2. 问法 2 · 层层追问

   RAG系统效果不好，你一般从哪些角度排查？……检索和生成都有嫌疑时，怎么隔离它们？……有没有什么指标或者实验能帮你把问题锁定到具体模块？

3. 问法 3 · 直球架构

   请说一下在RAG系统中，当整体效果不佳时，如何系统性地定位问题是出在检索、生成还是协同环节？具体排查步骤和诊断方法是什么？