Chapter6 RAG 系统评估

本文学习来源 all-in-rag
个人学习笔记整理总结，有错误或者遗漏希望大家指正

导读

RAG 系统不能只看“能不能回答”，还要能量化判断“哪里好、哪里坏、为什么坏”。

评估的核心价值是把主观感受拆成可观察、可对比、可回归测试的指标：

用户问题
-> 检索上下文
-> 生成答案
-> 评估检索是否相关
-> 评估答案是否忠实
-> 评估答案是否切题
-> 定位问题属于检索、生成还是端到端体验

两个模块

1. 评估方法论：RAG 三元组、检索评估、响应评估、经典指标和 LLM-as-Judge。
2. 评估工具：LlamaIndex Evaluation、RAGAS、Phoenix。

它们对应两个层次：

方法论回答：应该评估什么？
工具回答：怎么落地评估？

1. 为什么需要 RAG 评估

RAG 系统的失败通常不是单点失败，而是链路失败。

例如用户问：

IPCC 第六次评估报告中，海洋变暖对生态系统有什么影响？

系统可能失败在不同地方：

• 检索器没有召回相关章节。
• 检索器召回了相关内容，但混入大量噪声。
• 生成模型看到了正确上下文，但自己编了结论。
• 生成模型忠实于上下文，但没有直接回答用户问题。
• 答案本身还行，但引用、格式、覆盖范围不满足业务要求。

所以 RAG 评估不能只问：

答案对不对？

更应该拆成：

上下文找对了吗？
答案基于上下文吗？
答案回答问题了吗？

这样才能定位优化方向：

• 如果上下文不相关，应该优化切分、Embedding、召回、重排。
• 如果上下文相关但答案不忠实，应该优化 Prompt、模型、引用约束、生成策略。
• 如果答案忠实但不切题，应该优化查询理解、响应模板、答案组织方式。

2、方法论

2.1 RAG 评估三元组

RAG 三元组包含三个维度：

Context Relevance 上下文相关性
Faithfulness 忠实度 / Groundedness 可信度
Answer Relevance 答案相关性

1 > 上下文相关性

上下文相关性评估的是检索器。

核心问题：

检索回来的上下文，是否真的和用户问题相关？

如果这个维度低，说明 RAG 的第一步就错了。

常见原因：

• 文档切分太粗或太细。
• Embedding 模型不适合当前语料。
• 用户问题和文档表达方式差异太大。
• Top-K 设置不合理。
• 缺少重排模型。
• 元数据过滤条件错误。

这个维度决定了后续生成的上限：

上下文错了，生成模型越会编，结果越危险。

2 > 忠实度 / 可信度

忠实度评估的是生成答案是否基于检索上下文。

核心问题：

答案里的每个关键事实，能不能从上下文中找到依据？

低忠实度通常意味着模型产生了幻觉。

典型问题：

• 上下文没有提到某个事实，但答案里出现了。
• 答案把上下文中的事实夸大了。
• 答案混入模型预训练知识或常识推断。
• 答案引用了看似专业但上下文不存在的结论。

忠实度高不等于答案好，只说明：

答案基本没有脱离材料自由发挥。

3 > 答案相关性

答案相关性评估的是最终答案是否回应了用户问题。

核心问题：

答案是否直接、完整、有效地回答了原始问题？

它更接近用户体验。

一个答案可能忠实但不相关。例如：

问题：法国在哪里，首都是哪里？
答案：法国在西欧。

这个答案没有编造，忠实度可以很高，但它漏掉了“首都是哪里”，所以答案相关性不高。

因此要区分：

忠实度：有没有乱说。
答案相关性：有没有答到点上。

2.2 两类评估流程

RAG 评估可以按链路拆成两类：

检索评估
响应评估

1 > 检索评估

检索评估关注：

给定一个 query，retriever 找回来的 chunks/documents 是否正确？

它通常需要标注数据集：

query -> 真实相关文档或 chunk

这是偏白盒的评估，因为它绕过最终生成，直接检查检索环节。

适合回答这些问题：

• 新的切分策略是否更好？
• 换 Embedding 模型有没有提升召回？
• Top-K 设置为 3、5、10 哪个更合适？
• 加 reranker 后排序有没有改善？
• 元数据过滤是否误伤了相关文档？

2 > 响应评估

响应评估关注：

完整 RAG 系统生成的最终 answer 是否可靠、切题？

它通常会用到：

• 用户问题 question
• 检索上下文 contexts
• 系统答案 answer
• 可选的标准答案 ground_truth

响应评估更接近端到端体验。

适合回答这些问题：

• 用户最终看到的答案质量如何？
• 两套 RAG 策略谁更好？
• Prompt 修改后有没有引入回归？
• 模型升级后是否更容易幻觉？
• 答案是否变得更啰嗦或答非所问？

2.3. 检索评估指标

检索评估常用信息检索领域的指标。

1 > Precision@k

Precision@k 关注：

检索出来的前 k 个结果里，有多少是相关的？

公式：

Precision@k = 前 k 个结果中的相关文档数 / k

它衡量检索结果的准确性。

高 Precision 说明：

召回结果噪声少。

适合关注“不要把无关内容塞给模型”的场景。

2 > Recall@k

Recall@k 关注：

所有真实相关文档里，有多少被前 k 个结果找回来了？

公式：

Recall@k = 前 k 个结果中的相关文档数 / 所有真实相关文档数

它衡量检索结果的完整性。

高 Recall 说明：

关键信息不容易漏。

适合问答、法规、医疗、报告解读等不能漏信息的场景。

3 > F1-Score

F1 是 Precision 和 Recall 的调和平均。

适合在准确性和完整性之间取平衡：

F1 = 2 * Precision * Recall / (Precision + Recall)

当 Precision 和 Recall 都高时，F1 才会高。

4 > MRR

MRR 是 Mean Reciprocal Rank，平均倒数排名。

它关注：

第一个相关结果排在第几位？

如果第一个相关结果排第 1，得分是 1。
如果排第 2，得分是 1/2。
如果排第 5，得分是 1/5。

MRR 适合用户通常只看第一个或前几个结果的场景。

5 > MAP

MAP 是 Mean Average Precision。

它综合考虑：

• 相关文档是否被找回。
• 相关文档在结果列表中的排名是否靠前。

MAP 比 Precision@k 更细，因为它不仅看前 k 个里面有几个相关，还看这些相关结果出现的位置。

6 > 指标选择建议

不同目标对应不同指标：

目标	更关注的指标	原因
减少无关上下文	Precision@k	看召回结果是否干净
避免遗漏关键信息	Recall@k	看相关信息是否找全
兼顾干净和完整	F1	平衡 Precision 和 Recall
第一个正确结果很重要	MRR	看首个相关结果是否靠前
多个相关结果的排序质量	MAP	看整体排序表现

2.4. 响应评估指标

响应评估主要围绕两个问题：

答案是否基于上下文？
答案是否回答了问题？

1 > LLM-as-Judge

LLM-as-Judge 是用一个大模型作为评估者。

它可以做更语义化的判断：

question + contexts + answer -> evaluator LLM -> score / passing / explanation

常见评估方式：

• 将答案拆成多个 claims。
• 判断每个 claim 是否能被 contexts 支持。
• 综合得到忠实度分数。
• 对比 question 和 answer，判断答案是否切题、完整。

优点：

• 能理解语义，不局限于字面重叠。
• 可以评估开放式问答。
• 不一定需要标准答案。
• 能输出解释，方便排查问题。

局限：

• 成本高。
• 速度慢。
• 评估者模型也可能误判。
• Prompt 和模型选择会影响分数。
• 不同评估模型之间的分数不一定可比。

实践中最好固定：

评估模型
评估 Prompt
温度参数
测试集
指标计算方式

否则版本之间的评估结果容易漂移。

2 > 经典文本指标

经典指标通常需要标准答案。

代表指标：

• ROUGE
• BLEU
• METEOR

它们主要基于词汇或 n-gram 重叠。

3 > ROUGE

ROUGE 偏召回。

它关注：

参考答案里的内容，生成答案覆盖了多少？

适合评估摘要、报告提炼这类“有没有说全”的任务。

局限是：

同义改写可能被低估。

4 > BLEU

BLEU 偏精确率。

它关注：

生成答案里的 n-gram，有多少出现在参考答案里？

它还会用长度惩罚避免过短答案。

更常用于机器翻译，也可以作为问答评估的辅助指标。

局限是：

开放式问答中，正确答案可能有很多种表达。

5 > METEOR

METEOR 试图平衡 Precision 和 Recall，并考虑词干、同义词、语序惩罚。

相比 BLEU，它通常更接近人类判断，但仍然属于基于参考答案的文本相似指标。

6 > LLM 指标和经典指标的关系

可以这样理解：

经典指标：便宜、快、客观，但语义理解弱。
LLM 评估：语义强、解释性好，但贵、慢、有偏差。

实践中通常组合使用：

大规模快速筛选：经典指标或轻量规则
小规模深度分析：LLM-as-Judge
线上问题定位：Trace + 人工复核 + LLM 评估

3、评估工具

3.1. LlamaIndex Evaluation

LlamaIndex Evaluation 是 LlamaIndex 内置的评估模块。

适合场景：

项目本身已经用 LlamaIndex 搭 RAG，希望在开发阶段快速比较不同策略。

典型流程：

准备评估数据集
-> 构建一个或多个 QueryEngine
-> 初始化 Evaluator
-> 用 BatchEvalRunner 批量评估
-> 汇总 passing / score
-> 对比不同 RAG 策略

3.2. RAGAS

RAGAS 是独立的 RAG 评估框架，不强绑定某个 RAG 开发框架。

适合场景：

希望用统一指标评估不同 RAG 管道，或者做版本迭代后的回归测试。

1 > 数据格式

标准数据通常包含：

• question：用户问题
• answer：RAG 系统生成的答案
• contexts：检索到的上下文
• ground_truth：标准答案，可选但部分指标需要

2 > 常用指标

RAGAS 常见指标：

• faithfulness：答案中有多少信息能被上下文支持。
• answer_relevancy：答案是否切题。
• context_precision：检索上下文中真正相关的比例。
• context_recall：标准答案所需信息是否被上下文召回。

可以把它们映射到 RAG 三元组：

RAG 三元组	RAGAS 指标
上下文相关性	context_precision / context_recall
忠实度	faithfulness
答案相关性	answer_relevancy

4 > 使用特点

RAGAS 的优势：

• 框架无关。
• 指标体系完整。
• 支持无参考或少参考评估。
• 适合做批量评估和回归测试。

需要注意：

• 仍然依赖评估模型质量。
• 指标解释要结合具体样本。
• 不要只看平均分，要看 bad cases。

3.3. Phoenix

Phoenix 是 LLM 应用可观测性与评估平台。

它更偏线上诊断，而不是单纯离线打分。

适合场景：

系统已经有真实用户流量，需要追踪每次请求的检索、生成、耗时、错误和评估结果。

1 >核心思想

Phoenix 通过 tracing 把 RAG 链路展开：

用户请求
-> 检索调用
-> Embedding 调用
-> 向量库查询
-> LLM 生成
-> 后处理
-> 最终响应

这样可以看清楚：

• 哪一步慢。
• 哪一步失败。
• 哪一步输入输出异常。
• 哪些 query 容易产生低分答案。
• 哪些文档或 chunk 经常导致问题。

2 > OpenTelemetry 和插桩

Phoenix 通常通过 OpenTelemetry 做 instrumentation。

可以理解成：

在应用代码里埋点
-> 自动捕获调用链路
-> 生成 traces
-> 在 Phoenix UI 中查看和分析

这对于生产环境很重要，因为线上问题往往不能靠单个 demo 复现。

3 > Phoenix 的价值

Phoenix 更适合：

• 生产环境监控。
• Bad Case 分析。
• 延迟和成本分析。
• 数据漂移观察。
• 线上样本筛选和标注。

它和 RAGAS / LlamaIndex Evaluation 不冲突。

可以组合成：

LlamaIndex Evaluation：开发阶段快速比较方案
RAGAS：离线批量评估和回归测试
Phoenix：线上追踪、诊断和持续监控