RAG 系统的典型排障场景：用户问了一个问题，系统给了一个自信但错误的答案。你把问题记下来，回头排查——是没检索到？检索到了但排序太靠后被截断？还是模型根本没用上给它的上下文、自己编了一段？只盯着最终答案打分的端到端评测，回答不了上面任何一个问题。
RAG 是检索（Retrieval）和生成（Generation）两段拼起来的管线。之前写过 RAG 入门：从切分到召回的一条完整链路，讲的是怎么搭；这篇讲怎么测。结论先放在这：检索的账和生成的账要分开记，否则调优就是开盲盒。
一、端到端分数为什么是个黑洞
最常见的评测方式：攒几十个问题，人写标准答案，看 RAG 的输出和标准答案像不像，像就得分。这个分数的问题不在不准，而在出错时什么都不敢说。
一个错误答案背后至少有四种可能：该召回的文档没召回；召回了但排到了 top-k 之外；召回了也排上了，但上下文太长被截断；文档全给了，模型没用或者干脆幻觉。四种原因对应四种完全不同的修法——换嵌入模型、加重排序器、调切分粒度、改提示词——而一个总分把它们全压成一锅。
更麻烦的是复现：LLM 打分本身有波动，今天 82 分明天 79 分，你分不清是管线退步还是裁判手抖。评测的价值不在于给出一个总分，而在于出错时告诉你该修哪一段。
二、检索质量：第一本账
把检索单独拿出来测，前提是有一份标注过的评测集：每个问题配好「相关文档列表」。建起来不轻松——从真实用户提问里抽样，人工判断哪些文档应该被召回——但这份评测集是整个 RAG 调优周期里回报率最高的投入。
有了它，检索指标就都能算了：
- 命中率（Recall@K / Hit Rate）：前 K 条结果里有没有该有的文档。最朴素也最要命——没命中，后面全白搭；
- MRR：正确文档第一次出现在第几位。排第 1 和排第 8，对被 top-k 截断的管线是两种命运；
- 上下文精确率：塞进 prompt 的内容里有多少是相关的。低精确率意味着上下文里全是噪声，既浪费 token 又干扰生成。
这本账的特点是便宜且确定：不涉及大模型，同样的输入永远同样的输出。嵌入模型换版本、切分策略调整、top-k 变化，每次跑一遍，几秒钟出回归结论。它是 RAG 的单元测试。
三、生成质量：第二本账
检索满分不代表答案满分。生成的账主要记三笔：
- 忠实度（Faithfulness）：答案里的每句话是否被检索到的上下文支撑。把答案拆成单句，逐句判断能不能从上下文推导出来，不能的就是幻觉的量。这是 RAG 区别于普通问答的命门指标；
- 答案相关性：有没有答非所问。上下文全对但答案跑偏，问题就出在指令跟随而不是检索；
- 引用归因：答案的每句话能不能指回具体文档。可核查性不只对用户负责，也让出错定位从「重跑一遍看看」变成「看第 3 句引用了哪段」。
这几笔账的计算都绕不开 LLM-as-judge，随机性比检索指标高。控制办法是老一套：固定裁判模型的版本与温度、抽样复核、对争议样本人审。评测方法论的通用部分之前在 智能体评测：怎么测才不是自欺欺人 里聊过，同样的坑在 RAG 这边一个不少。
四、两本账合起来才是调优
分开记账的意义在组合拳：检索命中率高但忠实度低——模型在无视上下文，改提示词或换指令跟随更强的模型；命中率高但答案还是不对——大概率是排序或截断问题；命中率本身就低——别碰生成端，去改切分、换嵌入模型、加重排序。
工具链现成：RAGAS 把忠实度、答案相关性、上下文精确率与召回率打包成了开箱的评测框架，TruLens 也提供了类似的原语。自托管场景尤其友好——评测集是你的真实业务文档，本来就不该出内网，这套东西在本地跑，裁判模型也换成自部署的，数据一个字节都不出门。
最后一个工程习惯：评测集要和管线配置一起版本化。切分策略、嵌入模型、top-k、重排序器，每改一项就跑同一套题，分数进表。三个月后你回看「我们 RAG 变好了」时，手里有的是逐项变好了多少的证据，而不是一个感觉。
小结
RAG 评测的核心不是打分，是拆账。检索的账管「料给没给对」，生成的账管「料用没用好」，两本分开记，调优才有方向。攒一份标注评测集，把检索当单元测试跑，把忠实度当幻觉监控用——这套做完，RAG 才从「感觉还行」变成「哪个环节行、行多少」都答得上来。
说明：本文为公开资料的整理与评述，信息来源包括 RAGAS 与 TruLens 官方文档、主流检索评测实践与公开工程博客，数据以各官方原文为准。本文由 AI 辅助整理，不构成技术选型或投资建议。
评论