RAG 系统的评估：指标、测试集与 LLM 裁判

4.1 没有评估的 RAG 是玄学

上一章结尾留了一个问题：流水线上旋钮这么多——块大小、overlap、top-k、混合检索的配比、要不要重排——怎么知道拧了之后是好是坏？

大多数人的实际做法是：改完参数，随手问两三个问题，看看答案顺不顺眼，顺眼就算改进成功。这个做法的问题不在于不严谨，在于它会系统性地骗你。两三个问题的样本，方差大到任何结论都可能是噪声；"顺眼"这个标准，会被答案的流畅度和自信程度带偏——而流畅和自信恰恰是大模型最不缺的东西，一个引用了错误段落的答案照样可以文采斐然。于是你调了一星期参数，每次都"感觉好了一点"，实际效果原地踏步甚至倒退，这就是"玄学调参"的典型现场。

出路只有一条，跟所有实验学科一样：固定一套测试题，固定一套打分标准，每次改动前后各跑一遍，比较分数。本章就讲这三件事怎么做：失败怎么归因（4.2）、检索和生成各用什么指标（4.3、4.4）、打分和出题怎么自动化（4.5、4.6）。

4.2 先拆开：检索失败还是生成失败

RAG 是两段式流水线，端到端地看"答案对不对"是不够的——同样是答错，病根可能在完全不同的地方，药方也完全不同。诊断的第一步永远是拆开归因：

检索失败：相关的块压根没被找回来。模型巧妇难为无米之炊，要么老实说"资料里没有"，要么更糟——退回参数化知识开始编。这时候该修的是检索层：换切块策略、调 top-k、加混合检索、加重排。去调 prompt 是没有用的，米都没有，怎么改锅都煮不出饭。

生成失败：相关的块明明找回来了、就在 prompt 里，模型却没用上、用错了，或者掺进了资料之外的私货。这时候该修的是生成层：改 prompt 指令、要求引用编号、换模型。去调检索是没有用的，米已经在锅里了。

反过来还有一种容易漏诊的情况：端到端答对了，不代表系统是好的。模型可能靠参数化知识蒙对了答案，检索层实际上完全失灵——换一个私有领域的问题立刻现形。所以严肃的评估要分层打分：检索单独一套指标（找没找到），生成单独一套指标（用没用好），端到端再来一套（最终对不对）。

4.3 检索指标：找没找到、排得靠不靠前

检索评估需要一个前提：对每个测试问题，预先标注好语料库里哪些块是相关的（这个标注集叫 golden set，怎么造它是 4.6 节的事）。有了标注，指标都是简单的数数。

Recall@k（召回率）：相关的块里，有多少被排进了前 $k$ 名——

$$ \mathrm{Recall}@k = \frac{|\{\text{相关块}\} \cap \{\text{top-}k\}|}{|\{\text{相关块}\}|} $$

这是 RAG 里最重要的检索指标，原因很直接：进不了 top-k 就进不了 prompt，模型就永远看不到。Recall@k 低，下游一切免谈。

Precision@k（精确率）：前 $k$ 名里有多少是真相关的——

$$ \mathrm{Precision}@k = \frac{|\{\text{相关块}\} \cap \{\text{top-}k\}|}{k} $$

它衡量的是 prompt 的"干净程度"。精确率低意味着 prompt 里塞满了无关块——第 1 章讲过的上下文污染。召回和精确天然此消彼长：$k$ 开大，召回涨、精确跌。RAG 的典型取舍是优先保召回（漏了就彻底没救，脏一点模型还有机会自己甄别），再靠重排序把精确率拉回来——这正是第 3 章两阶段架构"宁滥勿缺 + 精选排准"的量化表达。

MRR（Mean Reciprocal Rank，平均倒数排名）：第一个相关块排在第几名——

$$ \mathrm{MRR} = \frac{1}{|Q|} \sum_{i=1}^{|Q|} \frac{1}{\mathrm{rank}_i} $$

其中 $\mathrm{rank}_i$ 是第 $i$ 个问题的首个相关块的名次。排第 1 得 1 分，排第 5 只得 0.2 分。它关心位置：同样是"找到了"，排在第 1 和排在第 8 对模型的实际影响不同（lost in the middle 又见面了）。此外还有把"多个相关块、相关程度有梯度"都考虑进去的 NDCG，搜索引擎评估的主力指标，RAG 场景通常用前三个就够了。

这些指标的价值在于它们把检索层隔离成一个可以独立优化的模块：不用跑生成、不用人看答案，改一版切块策略，几秒钟跑完全部测试题的 Recall@5，数字说话。调优循环的大部分迭代应该发生在这一层——快、便宜、信号干净。

4.4 生成指标：拿着正确的资料，答得好不好

生成层的评估维度不同——这里没有"标准排名"可对，评的是答案的质量，主要看三个维度：

忠实度（faithfulness）：答案里的每一个论断，是否都能在检索出的资料里找到依据。这是 RAG 生成评估的核心指标，直接对应我们做 RAG 的初衷——答案必须来自资料，而不是模型的自由发挥。忠实度低的表现俗称"资料外幻觉"：资料说了 A 和 B，答案却冒出了资料里没有的 C。注意忠实度不等于正确性：如果检索回来的资料本身是错的，一个忠实的答案也是错的——但那是检索层或语料本身的锅，归因要分清。

答案相关性（answer relevance）：答案是否正面回应了所问的问题。模型有时会忠实地大段复述资料，却答非所问——每句话都有出处，就是没回答问题。

引用质量（citation quality）：如果系统要求模型标注引用（第 6 章的实战会这么做），还要检查引用是否落在真正支撑该论断的块上。引用既是给用户的可验证性，也是免费的评估信号——引用错位往往是忠实度问题的前兆。

4.5 LLM-as-judge：让模型当裁判

指标定义好了，谁来打分？忠实度这种指标，要把答案逐句和资料比对——人来做又慢又贵，规则匹配又根本做不了（同一个意思有无数种说法）。2023 年之后的标准答案是：让另一个 LLM 来打分，即 LLM-as-judge。

做法直白：把问题、检索出的资料、系统的答案一起交给一个裁判模型，配一份明确的评分规程（rubric），让它输出判断。一个忠实度裁判的 prompt 骨架大致是：

下面是资料和一个基于资料的回答。请把回答拆成一条条独立论断，逐条判断：该论断能否从资料中得到支持？对每条给出"支持 / 不支持 / 资料未涉及"的判定和依据，最后输出不支持论断的比例。

实践中有几条经验能显著提高裁判的可靠性。评分规程要具体："给答案打 1-10 分"这种模糊指令，裁判分数会大幅漂移；拆成一条条二元判断（支持/不支持），一致性立刻上来。首选二元或三元判定而不是打分，分数粒度越细越不稳定。要求先说理由再给结论，强迫裁判展示比对过程，既提高质量也便于人工抽查。

同时要清醒地知道裁判自己的偏差。位置偏差：对比两个答案时，裁判系统性偏爱先出现的那个——解法是交换顺序跑两遍取平均。自恋偏差（self-preference）：模型偏爱自己（或同家族模型）生成的文本——裁判尽量别用与生成器同源的模型。长度偏差：更长、更详尽的答案容易得高分，哪怕内容并不更对。校准：LLM 裁判不是免检产品，上岗前抽几十个样本人工标注一遍，对比裁判与人工的一致率——一致率够高（比如 90% 以上）才放心让它自动跑。裁判不是替代人类判断，而是把人类判断放大：你人工校准 50 条，它替你按同一标准跑 5000 条。

4.6 测试集：从语料反向造题

最后一块拼图：测试题从哪来？手写当然最好——你最清楚用户会问什么——但手写几百道题并标注相关块，工作量劝退。好在 RAG 评估有一个得天独厚的捷径：从语料反向生成。

流程是评估流水线的逆向：从语料库随机抽一个块，让 LLM 依据这个块出一道"答案就在块中"的问题——于是问题与相关块的配对是天然免费的，golden set 的标注成本直接归零。批量跑一遍，几百道带标注的测试题就有了。第 6 章会实际操作。

反向造题有两个要当心的坑。其一，问题分布偏移：由块生成的问题往往措辞与原文过于贴近（造题模型会不自觉地复用原文用词），检索难度系统性偏低，测出来的 Recall 虚高。缓解办法是在造题 prompt 里明确要求换一种说法提问、模拟真实用户的口吻，并混入一部分手写的真实问题作对照。其二，覆盖不了跨块问题：单块造题天然都是"局部问题"，而真实用户会问需要综合多个块甚至多篇文档的"全局问题"——这类问题恰恰是 RAG 的难点（第 5 章讲 GraphRAG 时再展开）。测试集里要刻意补充一些。

另外，测试集是资产，要跟代码一样管理：入版本库、持续补充线上遇到的真实 badcase、定期审查过时的题。评估驱动的调优循环最终长这样：

一次改一个变量，每次都过数字这一关——RAG 调优从此告别玄学。原理层面的三章（检索、工程细节、评估）到此配齐，下一章把镜头拉远，看看这套技术在 2026 年的真实世界里活成了什么样子。