RAG 检索效果的系统化调试

一、先认清一个事实:RAG 答不好,九成是检索的锅

很多人 RAG 答不好,第一反应是"换更大的模型""改 prompt""加 rerank"。这都是没定位问题的瞎折腾。

RAG = 检索 + 生成。生成模型再强,喂进去的上下文是垃圾,出来的也是垃圾——Garbage in, garbage out。你用 GPT-4o 也好,Claude 也好,塞一段跟问题八竿子打不着的 chunk,它要么胡说,要么老老实实回一句"我不知道"。

所以调试 RAG 的第一条铁律:先证明检索没问题,再去动生成。

怎么证明?把中间过程全部捞出来看。不要只盯着最终答案猜哪坏了。

二、系统化排查:五层定位法

RAG 是条流水线,每一层都可能出问题。排查要逐层走,不要跳。

用户 query
   │
   ▼
① 召回(检索到哪些 chunk)────────── recall 层
   │
   ▼
② 相似度分数(排在前面的真更相关吗)── 排序层
   │
   ▼
③ rerank 后顺序(rerank 有没有帮倒忙)── 精排层
   │
   ▼
④ 喂给模型的上下文(截断了吗、乱序了吗)── 拼接层
   │
   ▼
⑤ 模型输出(模型真用了上下文吗)────── 生成层

定位方法:从上往下,每一层问一句"这层输出对不对"。哪层不对,问题就在哪层。千万别在第五层发现答案错了,就回头瞎改第二层——你压根不知道是哪层坏的。下面逐层讲判别。

① 看召回:检索到底捞到了什么

把 top-k 的 chunk 原文打出来,人工瞄一眼:跟问题相关的 chunk 在不在里面?

在 → recall 没问题,往下查。
不在 → recall 挂了,去查切分、embedding、过滤(见第三节)。

成本最低、收益最高的调试动作就是它。可惜很多人跳过,直接对着最终答案抓耳挠腮。

② 看相似度分数:排在前面的真的更相关吗

相关 chunk 召回来了,却排在 top-k 之外被截掉了?那是排序问题。

打印每个召回 chunk 的分数,看分布。正常情况下相关 chunk 的分数应明显高于不相关的。如果相关和不相关的分数挤成一团(比如都在 0.70~0.72),说明 embedding 区分度不够——要么模型不行,要么 query 和 doc 不在一个向量空间(常见于忘了给 query 加 instruction prefix)。

③ 看 rerank 后顺序:rerank 是帮忙还是帮倒忙

加了 rerank 的,对比 rerank 前后顺序。rerank 应当把更相关的 chunk 往前提。如果你发现它把原本排第 1 的相关 chunk 压到第 5、反倒把不相关的提上来——这叫 rerank 帮倒忙,通常是 rerank 模型跟你的领域不搭。

没加 rerank 的,先别急着加,确认前面几层没问题再说。

④ 看喂给模型的上下文:拼接有没有出岔子

走到这步说明前面都对,答案还是错。那就看实际拼进 prompt 的 context:

相关 chunk 有没有被 top-k 截断?
有没有因为 token 超限被砍掉一半?
chunk 顺序合理吗?(有些场景相关度高的应靠前)
chunk 之间有没有重复?有没有把一段完整语义切成两半?

⑤ 看模型输出:模型真用了上下文吗

最后才轮到生成层。前面都对、模型还是答错——看 prompt 有没有强约束模型"只能基于上下文回答"。prompt 写得松,模型就会拿自己的参数知识瞎编,这正是幻觉的温床。

三、没召回(recall):最常见的"检索挂了"

"没召回"又分三种病因,判别方法各不相同。

切分破坏语义。一个完整事实被切到两个 chunk,query 只命中一半,另一半丢了。判别:看召回 chunk 是不是断章取义。解法:按语义切分(段落/标题),别机械按字数切;切分保留 overlap;或上小切分 + 父子 chunk(parent document retrieval)策略。

embedding 不匹配。query 和 doc 用了不同 embedding 模型,或同一模型但 query 没加 instruction prefix(很多 embedding 模型对 query/doc 有不同前缀)。判别:拿一个已知相关的 query-doc 对看相似度,人觉得相关、模型打分却低,就是 embedding 的锅。

过滤过严。你在检索前加了 metadata 过滤(按时间、按类别、按权限),把相关 chunk 整片筛掉了。判别:临时关掉所有过滤,看 recall 有没有恢复。恢复了,过滤就是元凶。

四、召回了没用对(precision):捞得太多

相关 chunk 在召回结果里,却淹没在噪声中,模型分不清该信哪个。

rerank 缺失。纯向量检索的 precision 有限,top-10 里可能掺了一半不相关的。这时候 rerank 是真有用——前提是你已确认 recall 没问题。

top-k 太大。k 调太大,噪声涌入 context,反而拉低答案质量。k 不是越大越好,要做 ablation:从 k=3 试到 k=20,看哪个最准。

没有混合检索。纯向量对关键词、专有名词不敏感——query 里有个产品型号、一个人名,向量检索抓瞎。这时加 BM25/关键词检索做 hybrid search,recall 立竿见影。

五、召回了模型没用:prompt 的锅

检索都对,context 里就有正确答案,模型还是答错。这锅扣 prompt。

常见毛病:

prompt 没写"只能基于提供的上下文回答,上下文没有就说不知道";
没把 context 放在显眼位置,或者 context 和问题之间隔了一堆别的指令;
让模型"综合"多个 chunk,结果它自己脑补。

判别:把同一个 context + 问题,直接丢给模型单独问(不走检索),看它能不能答对。能答对 → 是 RAG 流水线拼接的问题;答不对 → prompt 本身要改。这是隔离"检索"和"生成"的关键实验。

六、调试工具箱

几样趁手工具,按必要性排序:

检索结果可视化:把 top-k chunk 连分数一起打印出来。最基本也最有效。LangSmith、Langfuse、Phoenix 这类 trace 工具都能干。
query-doc 相似度对比:对同一个 query,人工标注哪些 doc 相关,看 embedding 给的分数排序对不对——评估 embedding 质量的标准方法。
单 chunk 测试:拿一个已知含答案的 chunk,直接拼进 prompt 问模型。能答对 → 生成没问题,问题在检索;答不对 → 模型/prompt 层面有毛病。隔离检索和生成的关键实验。
bad case 回归集:把出错的 case 存下来,每次改完跑一遍,看修好没、有没有改出新问题。

七、别盲目优化:九成"加 rerank"是懒办法

说个得罪人的观点。

我见过太多团队,RAG 答不好的第一反应是"上 rerank""上更贵的 embedding""换 GPT-4"。这是拿钱砸问题,不是解决问题。

rerank 不是银弹。切分破坏语义,rerank 救不了;过滤过严,rerank 救不了;prompt 没约束,rerank 也救不了。rerank 只解决一类问题:recall 没问题但 precision 不够。

五层定位法的意义就在这:先定位,再优化。定位清楚了,往往一个很小的改动——调个切分粒度、加个 query prefix、改一句 prompt——就能搞定,而且改完心里有底,知道为什么好了。

盲目堆组件,即使效果变好你也不知道是哪个起的作用,下次坏了照样抓瞎。

八、把调试变可复现:bad case + trace 入回归集

调试最大的陷阱是"一次性"。今天撞上一个 bad case,改一改好像好了,明天上线又崩。为什么?因为你只测了一个 case。

正确做法:

每发现一个 bad case,连同它的完整 trace(召回的 chunk、分数、rerank 顺序、拼好的 prompt、模型输出)一起存下来;
标注预期答案;
每次改流水线,跑全量回归集,看通过率有没有提升、有没有回退;
回归集越大,你对每次改动的信心越足。

这套东西不复杂,但能把 RAG 调试从"玄学"变成"工程"。RAG 系统的可靠性是靠回归集一个一个堆出来的,不是靠一次灵感迸发。

小结

RAG 答不好,九成是检索。先证明检索没问题,再动生成,别本末倒置。
五层定位法:召回 → 相似度 → rerank → 拼接 → 生成,逐层确认,哪层不对修哪层。
没召回、召回了没用对、召回了模型没用,是三类不同问题,判别与解法完全不同,别混为一谈。
别盲目加 rerank。定位清楚再优化,一个小改动往往胜过一堆昂贵组件。
bad case + trace 入回归集。把调试从玄学变工程,可靠性是靠回归集堆出来的。

一句话:RAG 调试不是"调参",是"定位"。定位准了,问题就好了一半。