RAG 评测体系

RAG 评测体系

flowchart TD
  A[RAG 系统] --> B[检索质量]
  A --> C[回答忠实度]
  A --> D[回答相关性]
  B --> B1[Context Relevance]
  C --> C1[Faithfulness / Groundedness]
  D --> D1[Answer Relevance]
  A --> E[离线评测]
  A --> F[线上反馈]
  A --> G[回归测试]

前面几篇一直在讲如何把 RAG 做出来：怎么切 chunk、怎么检索、怎么 rerank、什么时候该用 Agentic RAG、什么时候该引入图、长上下文和多模态又该怎么配合。

但一个系统真到了要落地的时候，很快就会遇到一个比“怎么做”更棘手的问题：

我们怎么知道它真的变好了？

这正是 RAG 评测的核心。

因为 RAG 和普通生成任务不太一样。 它不是只有一个模型输出，而是一个链路：

• 上游要把知识切好、存好
• 中间要把对的内容检出来、排出来
• 下游要基于这些内容回答，还要尽量不胡编
• 最后还可能要带引用、可追溯、可审计、可上线

所以，RAG 的“好”从来不是单维度的。 一个答案看起来很像对，不代表它检索得对； 检索得对，也不代表回答忠实； 回答忠实，也不代表它真的回答了用户想问的问题。

这也是为什么 RAG 评测比很多人想象中更像系统诊断，而不是简单打个总分。

为什么 RAG 评测比普通问答更难

RAG 评测难，不是因为没有分数，而是因为分数太容易掩盖问题发生在哪一层。

假设一个系统回答错了，原因可能完全不同：

• chunk 切坏了，关键句被拆开
• 检索没召回关键证据
• rerank 把好证据排到后面
• 生成阶段忽略了检索结果
• 模型补了 context 里没有的“常识”
• 引用存在，但其实引用错了
• 答案本身不算错，却没有真正回答用户关心的点

这些问题如果最后都只变成一个“用户不满意”，你几乎无法有方向地优化。

所以，RAG 评测的第一个原则是：

不要只评最终答案，要尽量把链路拆开评。

这也是很多评测框架都强调 component-wise evaluation 的原因。Ragas 明确把 RAG 看成可拆分评估的系统，不同指标对应不同环节；TruLens 也把 RAG triad 拆成 context relevance、groundedness 和 answer relevance 来分别观察检索与回答之间的关系。(Ragas)

一个更实用的总原则：把评测分成三层

如果要用一句最实用的话来概括 RAG 评测，我会建议这样理解：

离线评测看“系统能力”，在线评测看“真实使用效果”，回归评测看“改动有没有把系统带偏”。

这三层缺一不可。

第一层：离线能力评测

解决的是：

• 当前版本在测试集上表现怎样
• 检索质量有没有提升
• 忠实度是否足够高
• 生成是否更切题

这是你做实验、调参数、比较策略时最核心的一层。

第二层：线上行为评测

解决的是：

• 用户是否真正受益
• 延迟、成本、失败率是否可接受
• 用户是否频繁追问、改问、点踩
• 某类问题是否线上持续失效

这是你判断系统“能不能用”的一层。

第三层：回归评测

解决的是：

• 这次改 chunking、prompt、retriever、reranker 之后，系统是不是退化了
• 哪类问题退化了
• 退化是整体性的，还是只影响某个子集

这是你把 RAG 做成工程系统，而不是一次性 demo 的关键。

很多团队的问题不是没有评测，而是只有第一层，没有第二层和第三层。 于是离线看起来不错，线上还是不稳； 或者线上刚调好，一个新版本上线又把旧问题带回来了。

RAG 评测最常见的三根主轴

现在很多框架和实践，最后都会收敛到三个核心问题：

1. 检索到的内容对不对
2. 答案是不是基于这些内容说的
3. 答案有没有真正回答用户的问题

这也是 RAG triad 最有价值的地方。TruLens 目前公开文档中就把 triad 描述为 context relevance、groundedness 和 answer relevance；Ragas 也提供了 faithfulness、answer relevance 以及一组面向 retrieval 的指标。(TruLens)

如果把这些概念翻成更工程化的话，可以这样理解：

评测主轴	你真正想知道的事
Context Relevance	你查回来的东西，到底是不是和问题有关
Faithfulness / Groundedness	你最后说的话，到底是不是有证据支持
Answer Relevance	你虽然说得像样，但到底有没有回答问题本身

这三者之所以重要，是因为它们分别对应三类完全不同的失败模式。

• Context Relevance 低：系统根本没找到该看的证据
• Faithfulness 低：系统看了证据，但回答时还是编了或越界了
• Answer Relevance 低：系统虽然基于证据说话，但没有真正回答用户的问题

这意味着，它们不是三个“差不多的分数”，而是三种不同故障的定位工具。

Faithfulness：RAG 里最不能省的指标

在所有 RAG 指标里，Faithfulness 往往最关键。 因为用户最不能接受的，不是系统答得简短，而是系统答得很像对，但其实是编的。

Ragas 对 faithfulness 的定义很直接：如果回答中的 claim 能从检索到的 context 中推出，就认为回答是 faithful 的；其计算方式通常是先从回答中识别 claim，再判断这些 claim 是否被 context 支持。(Ragas)

把它翻成更朴素的话就是：

答案里的每一个事实性陈述，能不能在检索证据中找到依据。

这里有几个很重要的细节。

第一，Faithfulness 不是“事实真伪”，而是“是否有据可依”

这点很多人一开始会混淆。

例如某个答案说了一个常识上也许正确的结论，但检索上下文里并没有这个信息。 从 RAG 的 faithfulness 角度看，它仍然可能要被判低分。 因为 RAG 关心的不只是“有没有说对”，还关心“是不是基于检索证据说对”。

这尤其重要于企业、法律、金融、医疗等场景。 因为这些系统要的不是“模型看起来懂”，而是“模型只在证据边界内说话”。

第二，Faithfulness 最怕“局部有证据，整体靠补全”

这是 RAG 中最常见、也最隐蔽的失败模式之一。

例如回答里 A 和 C 都能在 context 找到，但中间的 B 是模型自己补出来的。 整个句子读起来很流畅，甚至八成内容都“有出处”，但关键逻辑桥梁是幻觉。

所以，faithfulness 真正要检查的不是“整体像不像对”，而是：

• 回答里有哪些明确 claim
• 这些 claim 是否逐条有支持
• 是否存在 unsupported leap

第三，Faithfulness 高不等于答案好

一个答案完全基于 context，但只回答了问题的一半，或者答得非常保守、非常没用，它仍然可能有很高的 faithfulness。

所以，faithfulness 是必要条件，但不是充分条件。 它更像一个底线指标：

先确保不胡编，再谈是否回答得好。

Context Relevance：很多问题其实死在“查错了”

Faithfulness 很重要，但在 RAG 里，很多失败其实更早发生——发生在检索阶段。

TruLens 把 context relevance 作为 triad 的第一环，用来判断 retrieval 回来的 chunk 是否与输入问题相关；Ragas 与 DeepEval 也都提供了 retrieval 相关指标，用于评估 context 是否相关、是否排得对、是否覆盖到应有信息。(TruLens)

这类指标的核心问题非常简单：

系统到底把“该看的东西”找回来没有？

但它在工程上又不能只做成“相关 / 不相关”这么粗糙。 因为 context relevance 里通常至少有三层问题：

1. 是否命中了正确主题

这是最基础的一层。 例如问产品保修政策，结果召回了一堆产品介绍而不是售后政策。

2. 是否命中了真正关键的证据

有时召回内容大方向是对的，但缺少最关键的一条。 比如问“是否支持自动续约”，召回了合同正文的大量背景内容，却没召回自动续约条款本身。

3. 是否引入了太多噪声

相关内容太少当然不好； 但相关内容被大量无关 chunk 稀释，也会降低下游效果。 因为模型上下文预算有限，噪声越多，真正有用的信息越容易被淹没。

所以，Context Relevance 的实际意义不是“有没有查到一点相关内容”，而是：

在有限上下文预算里，系统是否高密度地放入了真正有帮助的证据。

只看 Relevance 还不够，检索评测还要看排序和覆盖

很多团队做 retrieval 评测时，只看“召回了一些相关 chunk”，这往往不够。

因为检索效果至少还涉及两个额外维度：

排序是否合理

即使 Top-10 里有对的 chunk，如果关键 chunk 排在第 9、第 10，而系统只给模型喂 Top-3，那在生成层看来，它仍然等于没检到。

这也是为什么 precision、ranking quality、contextual precision 这类指标很重要。DeepEval 就明确提供了 contextual precision，关注的是相关节点是否被排在更前面。(DeepEval)

覆盖是否足够

有些问题不是一条证据就能答，需要多条证据共同支持。 例如比较题、多跳题、跨文档综合题。

这时，retrieval 不只是要“命中”，还要“覆盖够”。DeepEval 的 contextual recall 就是在这类思路下定义的：它更关心 retrieval 是否抓到了完成理想答案所需的 relevant information。(DeepEval)

所以，一个更完整的 retrieval 评测至少要区分：

• 相关性：找回来的东西相关吗
• 排序：最关键的内容排得靠前吗
• 覆盖：回答这个问题所需的关键信息找全了吗

这三者是不同问题，不能互相替代。

Answer Relevance：很多答案不算错，但就是没回答问题

RAG 还有一类问题特别常见： 系统给出的答案很安全、很流畅、甚至部分正确，但它就是没有真正回答用户的问题。

Ragas 的 answer relevance 指标关注的就是生成答案与用户问题是否真的相关、是否完整、是否没有无意义冗余；TruLens 的 triad 中也把 answer relevance 作为独立一环。(Ragas)

这类问题为什么重要？因为用户最终不是在评检索器，而是在评“这个回答对我有没有用”。

例如：

• 用户问“支持自动续约吗”，系统回答“这是一份关于 SaaS 服务的合同”
• 用户问“张三现在在哪个部门”，系统回答“张三曾在多个项目中担任负责人”
• 用户问“和微软相比如何”，系统只答了苹果营收，没有做比较
• 用户问“为什么失败”，系统只复述了日志片段，没有给出结论

这些回答可能：

• 有一定相关性
• 没明显幻觉
• 甚至还能引用出处

但它们依然不是用户想要的答案。

所以，Answer Relevance 的真实作用，是判断：

系统是不是把“有证据”变成了“有用回答”。

这也解释了为什么很多 RAG 系统离线看 faithfulness 不错，用户还是不满意。 因为“忠实”解决的是别瞎编，“相关”解决的是别答偏。两者必须同时成立。

Citation Accuracy：生产级 RAG 里经常被低估的一环

到了真正上线的 RAG 系统，尤其是企业、政策、法律、风控、医疗这类高可信场景，仅有 faithfulness 和 relevance 往往还不够。

你还得关心：

这个答案中的结论，能不能准确地回指到来源。

也就是 Citation Accuracy。

它通常至少包括三件事：

检查项	你真正想验证的内容
引用是否存在	该引用的地方有没有引用
引用是否对得上	所引用的证据是否真的支持该结论
是否漏引或错引	有没有把 A 的结论引到 B 的证据上

这件事为什么重要？因为它直接影响三类能力：

可解释性

系统不是只给一个答案，而是能告诉你“为什么这么说”。

可审计性

出了问题，团队可以回溯到底是检索错了、引用错了，还是生成错了。

可合规性

在高风险领域，很多系统不是“最好有引用”，而是“必须能证明答案来自哪里”。

很多团队上线后才发现： 引用不是装饰功能，而是 RAG 从“像个助手”走向“像个可用系统”的关键一步。

参考集与无参考评测：什么时候用哪种方法

RAG 评测大致有两类方法：

• 有参考（reference-based）
• 无参考（reference-free）

这两类都重要，但解决的问题不同。

有参考评测：适合做稳定回归和能力验证

你先准备一批带标准答案、期望要点或 golden context 的样本，然后拿系统输出去和这些参考进行比较。

优点是：

• 更稳定
• 更适合回归测试
• 更适合做版本对比
• 结果解释性更强

缺点是：

• 标注贵
• 维护贵
• 很容易覆盖不全
• 一旦测试集老化，系统会对它过拟合

无参考评测：适合快速覆盖和在线抽样

Ragas、TruLens triad、很多 LLM-as-Judge 方案都很适合在没有完整 ground truth 的情况下先跑出一套质量画像。TruLens 也明确区分了 ground-truth-based workflow 与 reference-free triad：前者适合你有 curated golden contexts 的情况，后者更适合缺乏标注数据时的快速评估。(TruLens)

优点是：

• 启动快
• 覆盖广
• 不需要大规模人工标注
• 适合持续抽样和线上监控

缺点是：

• 评测模型本身会有偏差
• 与人类判断并非完全一致
• 分数更适合相对比较，不适合当绝对真理

一个更务实的原则是：

没有参考集时，先用无参考评测建立基础观测；一旦系统进入稳定迭代期，就尽快补一套高质量 golden set。

LLM-as-Judge：很有用，但不要把它当裁判长里的裁判长

现在很多 RAG 评测都会用 LLM-as-Judge。 也就是：用一个更强或更擅长评判的模型，对另一个系统的输出打分或分类。

它之所以流行，是因为确实解决了两个现实问题：

1. 全靠人工太贵、太慢
2. 很多维度本来就难以写成简单规则

尤其对于 faithfulness、answer relevance、citation matching 这类需要语义判断的任务，LLM judge 非常实用。

但它也有几个必须清楚的边界：

第一，它不是客观真值

评判模型本身有偏好、提示敏感性和温度波动。 不同 judge 模型对同一个答案，可能给出不同结论。

第二，它可能和生成模型“口味相近”

如果 judge 和被评系统同源或风格相近，可能会出现过宽松或过严格的问题。 这在同家模型互评时尤其要小心。

第三，它容易把“语言好看”误判成“质量高”

如果 prompt 设计不好，judge 模型可能更偏爱流畅、结构清楚的回答，而不是更严格地检查证据和问题匹配。

所以，一个更稳妥的做法通常是：

用 LLM-as-Judge 做大规模初筛和回归，再用人工抽检去校准 judge 的偏差。

它非常有用，但更适合当“高效率的质量代理”，而不是唯一真理来源。

Golden Set：不是可选项，而是你后面所有迭代的地基

一套好的 Golden Set，几乎决定了你能不能把 RAG 做成稳定系统。

因为没有 Golden Set，你每次改动之后其实并不知道：

• 整体是不是变好了
• 是对所有问题都变好，还是只对某一类变好
• 哪类问题退化了
• 退化是检索层的，还是生成层的

一个实用的 Golden Set 不一定要很大，但要足够“有代表性”。 相比一开始追求 1000 道题，很多团队更应该先追求 50～200 个分布合理的问题样本。

这套样本应该尽量覆盖什么

至少建议覆盖：

• 简单事实题
• 多跳题
• 跨文档题
• 对比题
• 需要拒答的无答案题
• 高风险题
• 容易混淆的近义题
• 历史 bad case

标注不一定非要写“唯一标准答案”

很多 RAG 问题并不适合只有一个标准句子。 更实用的形式通常是：

• 关键要点列表
• 期望证据
• 可接受答案范围
• 必须提到的约束条件
• 不应出现的错误结论

这样后续评测会更稳，也更贴近真实业务。

Golden Set 不是一次性资产

它必须随着系统迭代。 最有价值的新增样本，往往不是你在会议室里拍脑袋想出来的，而是：

线上真的失败过、用户真的卡住过、团队真的返工过的问题。

所以，Golden Set 最好的来源之一，永远是线上 bad case。

一个更完整的评测流水线长什么样

如果把前面的原则落成一条实践流水线，一个比较健康的 RAG 评测流程通常会像这样：

Golden Set / 抽样问题集
        ↓
   跑完整 RAG Pipeline
        ↓
  记录 retrieval、rerank、answer、citation
        ↓
  自动评测（faithfulness / relevance / citation / retrieval）
        ↓
  报表与分桶分析
        ↓
  人工抽检校准
        ↓
  作为基线进入回归测试

这里最重要的不是“跑了一个总分”，而是每次跑完后，最好都能回答这些问题：

• 哪类问题退化最多
• 是 retrieval 退化，还是 generation 退化
• faithfulness 提升是不是用 answer relevance 换来的
• citation 数量变多了，但准确性有没有下降
• 某个新 prompt 是否只对一类问题有效
• 成本和延迟有没有被明显推高

这意味着，评测报告最好不是一个总表，而是至少带这些切片：

• 按问题类型分桶
• 按数据源分桶
• 按是否多跳分桶
• 按是否需要拒答分桶
• 按是否带引用分桶

否则你很容易被平均分骗过。

生产环境里，离线分数并不是全部

很多团队前期会过度专注离线指标，这是可以理解的。 因为离线指标最容易做、最容易量化。

但一旦系统上线，生产环境真正关心的通常还包括另一组指标：

指标	你真正关心的问题
P50 / P95 / P99 延迟	用户是否等得起
单次请求成本	这个质量值不值得这笔钱
检索失败率	系统是否经常“查不到”或查偏
拒答率 / 误拒答率	该答的时候有没有过度保守
用户追问率	第一个答案是否真的解决问题
点赞 / 点踩 / 工单升级率	用户最终是否认可
来源点击率	用户是否愿意看证据，证据是否可用

这类指标和离线分数不冲突，而是互补。

一个系统可能离线很好，但线上很慢、很贵、很少被用户信任。 也可能离线分数一般，但在某个明确场景里用户非常满意。

所以，真正成熟的 RAG 评测一定是：

离线看质量上限，线上看真实价值。

一个很容易被忽略的能力：拒答评测

很多文章讲 RAG 评测时，重点都放在“答对”。 但在真实系统里，另一个同样重要的问题是：

当知识库里没有答案时，系统能不能体面地不乱答。

这类能力常常比“回答得很聪明”更重要。 因为用户往往更能接受“我没找到”，而不能接受“你一本正经地瞎说”。

因此，Golden Set 里一定要有负例：

• 知识库没有答案的问题
• 需要明确说明不确定的问题
• 来源冲突、应该保守回答的问题
• 超出系统边界的问题

而拒答评测通常至少要看两件事：

该拒时是否真的拒了

避免 hallucinated confidence。

不该拒时是否过度保守

避免系统明明有答案，却总说“信息不足”。

这两个方向经常互相拉扯。 一个系统把拒答率拉高，faithfulness 可能会上升，但 answer usefulness 可能下降。 这也是为什么评测永远不是单目标优化。

评测最怕的不是“没有指标”，而是“指标把你带偏”

RAG 评测里最危险的情况之一，不是没做评测，而是做了评测后开始为了分数优化，却逐渐偏离真实目标。

这通常表现为几种典型陷阱。

1. 过拟合 Golden Set

模型、prompt、规则开始越来越适应那几十或几百道测试题，但对新问题泛化不行。

2. 追求 Faithfulness 时把答案做得过于保守

系统越来越少犯错，但也越来越少真正解决问题。

3. 追求 Relevance 时牺牲了引用和可审计性

答案更像“好答案”了，但来源变模糊了。

4. 平均分提升掩盖了长尾退化

例如 FAQ 题表现大涨，但多跳问题全面退化； 因为简单题数量多，平均分看起来仍然提升。

5. 评测集长期不更新

线上世界已经变了，评测还停留在半年前的问题分布上。

所以，评测真正健康的状态应该是：

指标服务于问题定位，而不是反过来让系统围着分数表演。

阈值怎么定：不要迷信通用数字

很多人喜欢问：

• Faithfulness 到多少算好？
• Answer relevance 超过 0.9 是不是就能上线？
• Context relevance 0.8 够不够？

这类问题没有统一答案。

虽然一些框架和社区会给出经验阈值，但这些数字强烈依赖于：

• 评测模型
• prompt 模板
• 任务类型
• 业务风险级别
• 样本难度分布

这意味着，同样是 0.85，在两个系统里可能完全不是一回事。

更实用的做法通常是：

1. 先选一个固定 judge 和固定评测模板
2. 在你的业务样本上跑出 baseline
3. 让人工抽检一部分高分样本和低分样本
4. 找到“这个分数段在你这里到底意味着什么”
5. 以后都相对这个校准过的基线来比较

所以，比“行业优秀阈值”更重要的是：

你自己的分数和人工体验之间，是否已经建立了稳定映射。

把评测接进 CI/CD：RAG 才真正开始像工程系统

一旦你有了稳定的 Golden Set、自动打分和基础报表，下一步最值得做的事情，就是把评测接进回归流程。

理想状态下，每次你改这些东西，都应该自动触发一轮评测：

• chunking 策略
• embedding 模型
• retriever 参数
• rerank 逻辑
• prompt 模板
• citation 规则
• answer policy
• Agent 路由
• 文档解析方式

这样你就能知道：

• 这次改动到底提升了什么
• 是否引入了新坏例
• 是不是只对某个子集有效
• 有没有出现不可接受的退化

一个很实用的做法是设置发布门槛，例如：

• faithfulness 不得低于基线某阈值
• 高风险问题集不得退化
• citation accuracy 不得下降
• P95 延迟和单次成本上升不得超过某门槛

这时，评测才从“研究时偶尔跑一下”，变成了“系统每次演化都必须经过的质量闸门”。

如果只能记住一套最小可用框架

如果你现在还没有完整评测体系，但想尽快搭起一个真正可用的版本，我会建议从下面这套最小闭环开始：

第一步：先做一套 50～100 题的 Golden Set

覆盖：

• 简单题
• 多跳题
• 跨文档题
• 无答案题
• 高风险题
• 历史 bad case

第二步：至少跟踪这几类离线指标

• Retrieval relevance
• Faithfulness / groundedness
• Answer relevance
• Citation accuracy
• 拒答正确率

第三步：加一层人工抽检

不要全人工，只抽样校准 judge 偏差即可。

第四步：补上线上指标

至少看：

• 延迟
• 成本
• 用户追问率
• 点踩 / 负反馈
• 检索失败率

第五步：把它变成回归测试

每次改系统都跑，不再靠感觉上线。

如果真要再压缩成一句话，那就是：

RAG 评测不是为了得到一个漂亮总分，而是为了知道：系统在哪一层出错、改动之后有没有进步、这种进步是否值得上线。

小结

RAG 评测之所以重要，不是因为它能给你一个统一分数，而是因为 RAG 本身就是一个多环节系统。 如果没有评测，你看到的只会是“用户觉得不太行”； 而有了评测，你才能进一步知道：

• 是检索错了
• 还是证据虽然对，但回答编了
• 还是回答虽然忠实，却没有真正解决问题
• 还是引用、拒答、成本、延迟出了问题

所以，一套真正有用的 RAG 评测体系，通常至少要同时覆盖：

• 检索质量：有没有找到该找的内容，排得是否合理，覆盖是否足够
• 回答质量：是否忠实、切题、完整
• 引用质量：能否准确回指证据
• 拒答能力：没答案时是否不乱说
• 生产指标：延迟、成本、失败率、用户反馈
• 回归能力：每次改动能否自动发现退化

更克制地说：

RAG 评测不是“最后打个分”，而是把一个原本黑箱化的知识系统，拆成可观测、可比较、可迭代的工程对象。

如果前几篇更多是在讨论“如何把 RAG 设计好”，这一篇真正补上的，是另一个同样关键的问题：

当系统开始进入持续迭代期，我们靠什么判断它真的在变好，而不是只是看起来更复杂。

这也正好引向下一篇： 当评测、检索、生成、缓存、权限、观测、回归测试都开始同时出现时，RAG 就不再只是一个 demo pipeline，而会变成一套真正的生产级系统架构。

核心概念速查

概念	一句话
RAG Triad	围绕检索与生成的三类核心问题：context relevance、faithfulness/groundedness、answer relevance (TruLens)
Faithfulness	回答中的 claim 是否都能被检索到的 context 支持，是 RAG 防幻觉的底线指标 (Ragas)
Context Relevance	检索结果是否真的与问题相关，决定系统是否把“该看的证据”找了回来 (TruLens)
Answer Relevance	回答是否真正切题、完整、有用，而不只是“看起来相关” (Ragas)
Citation Accuracy	结论是否能正确回指到支持它的来源，是可解释性与可审计性的基础
LLM-as-Judge	用强模型批量评判系统输出，适合大规模自动评测，但需要人工抽检校准
Golden Set	一组代表性测试问题与期望答案/要点/证据，是回归测试和版本比较的基础
Retrieval Metrics	不只看相关性，还要看排序和覆盖，避免“查到但喂不到模型”或“关键证据没找全” (DeepEval)
生产级评测	离线指标保证质量方向，线上指标验证真实价值，回归测试保障系统迭代不退化

---