RAG评测

关注最新技术的发展和应用落地，聚焦性能优化与架构设计，欢迎关注！

一、RAG评测简介

1.目标与整体框架

RAG，即检索增强生成，通常包含以下主要环节：

用户问题   ↓查询理解与改写   ↓候选内容召回   ↓融合与重排   ↓上下文构建与压缩   ↓生成答案与引用

任何一个环节出现问题，都可能导致最终回答失败。例如，Retriever 没有召回关键证据、Reranker 把无关内容排在前面、上下文压缩删除了必要条件，或者生成模型在证据之外自行补充结论。

因此，RAG评测至少应回答四类问题：

• 检索是否完整：需要的证据有没有被找回来？

• 排序是否合理：最相关的证据是否排在前面？

• 回答是否正确：最终结论是否符合业务事实和参考答案？

• 回答是否有据可依：每个可验证结论是否得到检索资料支持？

不应只使用一个端到端分数评价整个系统。单一分数即使提高，也无法说明改进来自检索、排序还是生成，更无法指导下一步修改。

高质量评估集是RAG评测的基础。它通常称为 Golden Set，应该包含真实问题、人工确认的相关证据和可判定的参考答案。

(1)基础样本结构

每个样本至少应包含以下字段：

{"query_id": "q-001","question": "真实用户问题","relevant_chunk_ids": ["chunk-101", "chunk-205"],"reference_answer": "经业务专家确认的答案","required_claims": ["答案必须覆盖的关键点"  ],"forbidden_claims": ["不得出现的错误结论"  ]}

各字段的作用如下：

为了支持更精细的诊断，还可以补充：

{"answerable": true,"required_evidence_groups": [    ["chunk-101"],    ["chunk-205", "chunk-206"]  ],"query_type": "multi_hop","difficulty": "hard","slice_tags": ["合规", "跨文档", "版本敏感"],"source_snapshot": "kb-2026-10-01","annotation_notes": "需要同时覆盖适用范围和例外条件"}

• answerable 用于评估证据不足时的正确拒答；

• required_evidence_groups 可以表达“若干证据中命中任意一个即可”或“必须同时命中多组证据”；

• slice_tags 用于分场景统计。

(2) 评估集来源

评估样本可以来自：

• 脱敏后的真实用户查询；

• 线上失败案例和用户投诉；

• 客服、站内搜索、工单和知识库问答；

• 业务专家设计的关键、边界和高风险场景；

• 文档更新、权限变化或规则冲突产生的回归案例；

• 无答案、问题含糊、证据冲突等拒答场景。

评估集不应只包含表达清晰、答案唯一的简单问题。还应覆盖口语化表达、错别字、缩写、多轮上下文、跨文档推理、时间敏感问题和证据不足问题。

(3)数据集划分

训练或调参集、开发验证集和最终测试集应相互分开：

• 训练或调参集：用于调整 Prompt、Chunking、Retriever、Reranker 和阈值；

• 开发验证集：用于快速比较方案和选择参数；

• 最终测试集：只在候选方案确定后使用，用于报告最终效果；

• 长期回归集：持续加入线上严重失败案例，防止旧问题再次出现。

如果开发者反复查看测试集并据此修改系统，测试集实际上已经变成调参集，最终结果会过于乐观。

(4)标注质量

相关证据和参考答案应基于固定文档快照标注。否则，文档内容更新后，原有 Chunk ID、参考答案和事实有效期可能失效。

对于复杂或高风险样本，建议由两名标注者独立判断，再由业务专家处理分歧。应记录标注指南、争议原因和最终裁决，避免不同人员对“相关”“正确”或“有支持”采用不同标准。

3.测试集设计与管理

测试集用于衡量候选系统在未参与调参的问题上的真实效果。它应与训练集、Prompt调试集和开发验证集严格隔离。测试集中的问题、参考答案和评分标签不应被用于修改Prompt、选择参数或补充知识库，否则会产生测试集泄漏，使评测结果高于真实上线效果。

(1)测试集应覆盖的样本

一个完整的RAG测试集通常应包含：

测试集需要包含一定数量的简单问题，但不能全部由简单事实问答组成。否则，Hit Rate和答案正确率可能很高，却无法反映多跳推理、证据冲突和正确拒答等真实难点。

(2)测试样本建议字段

测试样本可以在基础评估集结构上增加测试管理字段：

{"query_id": "test-q-001","question": "真实用户问题","relevant_chunk_ids": ["chunk-101", "chunk-205"],"reference_answer": "经业务专家确认的答案","required_claims": ["必须覆盖的关键点"],"forbidden_claims": ["不得出现的错误结论"],"answerable": true,"test_category": "multi_hop","risk_level": "high","source_snapshot": "kb-2026-10-01","expected_behavior": "回答并引用两组必要证据","scoring_method": "required_claims_and_faithfulness"}

• test_category用于分场景统计，

• risk_level用于设置不同的上线门禁，

• expected_behavior描述系统应该回答、拒答还是请求澄清，

• scoring_method明确该样本采用规则、人工还是LLM Judge评分。

(3)测试集的几种形态

• 固定测试集：版本发布前运行，用于不同方案之间的稳定对比；

• 隐藏测试集：内容不向调参人员公开，降低针对固定问题优化的风险；

• 回归测试集：持续收录线上严重失败案例，每次发布都必须通过；

• 挑战测试集：集中测试多跳推理、冲突证据、长上下文和对抗问题；

• 时效测试集：验证文档更新、版本切换和旧知识失效后的表现；

• 权限测试集：验证不同角色、知识范围和访问控制下的回答行为。

固定测试集适合观察长期趋势，回归测试集适合守住已修复能力，挑战测试集用于发现系统上限。不同测试集应分别报告，不宜把所有结果混合成一个平均分。

(4)测试集质量检查

正式使用前应确认：

• 问题来自目标业务范围，且没有大量重复或近似重复样本；

• 参考答案已经过业务专家确认；

• 相关Chunk与当前文档快照一致；

• Required Claims和Forbidden Claims能够被明确判断；

• 可回答与不可回答样本的标注没有歧义；

• 高风险场景、边界场景和历史失败案例得到覆盖；

• 测试集没有进入训练、微调、Prompt示例或知识库增强材料；

• 每次更新都记录新增、删除和修改原因。

测试集应采用版本号管理，例如 rag-testset-v1.3，并与文档快照、索引版本和评判规则绑定。评测报告必须写明所使用的测试集版本，避免不同实验使用不同样本却直接比较分数。

Ragas是一个面向大语言模型应用的开源评测框架，常用于评估RAG系统的检索质量和生成质量。Ragas中的常用指标包括：

Ragas当前接口常用的数据字段与本文评估集字段可以按以下方式对应：

relevant_chunk_ids不能直接代替retrieved_contexts或reference_contexts。Chunk ID适合计算Recall@K等基于标识的检索指标，而Ragas的部分指标需要实际的上下文文本。

Ragas既包含依赖LLM评判的指标，也包含使用Embedding或字符串相似度的指标。评测结果会受到Ragas版本、评判模型、Embedding模型、Prompt和参数配置影响，因此实验报告应记录这些信息。

Ragas不同版本的字段名和API可能变化。当前常见字段为user_input、response和reference，旧版资料中可能写作question、answer和ground_truth。正式项目应固定依赖版本，并以对应版本的官方文档为准。

二、检索与上下文评测

检索指标用于评估 Retriever、Hybrid Search、查询改写、融合和 Reranker。计算前必须固定文档快照、Chunk 划分和相关性标注。

1.Recall@K

Recall@K= Top K 中相关 Chunk 数  / 该查询全部相关 Chunk 数

Recall@K回答的是：应该找到的证据，找到了多少？

适用场景：

• 判断 Retriever 是否漏掉关键证据；

• 对比 Dense、BM25、Hybrid 等检索方式；

• 比较不同 Candidate K 和查询改写方案；

• 评估需要多个证据的比较、归纳和合规问题。

局限：

• 不区分相关结果排在第1位还是第K位；

• K增大后 Recall 往往提高，但上下文噪声、延迟和成本也可能增加；

• 如果人工标注的相关证据不完整，Recall 会被低估。

复杂问题可能包含多个必要证据。此时，Recall@K 比只判断“是否命中一条”更合适。对于必须覆盖多组证据的问题，还可以增加 Evidence Group Recall，检查每组必要证据是否都至少命中一个。

2.Hit Rate@K

Hit Rate@K= Top K 至少包含一个相关 Chunk 的查询数  / 查询总数

Hit Rate@K回答的是：有多少问题至少找到了一条相关证据？

它适合单一事实问答或只需一条证据即可回答的问题。对于需要多个证据的比较、流程或合规问题，Hit Rate 可能看起来很好，但证据仍然不充分。

3.Precision@K

Precision@K= Top K 中相关 Chunk 数/ K

Precision@K衡量返回结果中有多少真正相关。它可以发现候选结果中过多的无关内容。较低的 Precision 会占用上下文窗口，干扰生成模型，并增加 Token 成本。

Recall 与 Precision 通常存在取舍。Candidate K 增大可能改善 Recall，但也可能降低 Precision。Reranker 的作用之一，就是在保持候选覆盖的同时，把更相关的证据排到前面。

4.MRR

MRR，即 Mean Reciprocal Rank，关注第一条相关结果的位置：

单个查询得分 = 1 / 第一条相关结果的排名MRR = 所有查询得分的平均值

如果第一条相关结果排第1，得分为1；排第2，得分为0.5。MRR适合第一条正确证据出现后就足以回答的问题，但不适合衡量多个证据是否全部覆盖。

5.nDCG@K

nDCG@K同时考虑相关程度和排名位置。高度相关的结果排在前面会获得更高分，适合存在“完全相关、部分相关、背景相关”等多级相关性标注的场景。

nDCG可以帮助判断：检索虽然找到了相关内容，但真正关键的证据是否被无关或弱相关内容挤到了后面。

6. Context Precision

Context Precision衡量提供给生成模型的上下文是否相关，以及相关证据是否排在更有利的位置。它属于检索和上下文构建质量指标，关注无关内容是否过多、排序是否合理。

Context Precision低时，模型可能受到噪声干扰。需要注意，上下文过少导致证据覆盖不足，主要应由 Context Recall 反映，而不是通过降低上下文数量单独追求高 Precision。

7.Context Recall

Context Recall衡量检索上下文是否覆盖参考答案所需的关键信息。它不只检查某个 Chunk ID 是否命中，还可以根据参考答案或 Required Claims 判断必要信息是否存在于上下文中。

Context Recall适合以下情况：

• Chunk ID 标注难以保持稳定；

• 同一事实可能出现在多个文档或多个 Chunk 中；

• 需要判断上下文是否足以支持完整回答；

• 评估压缩或摘要是否删除了必要信息。

三、生成引用与拒答评测

生成阶段应分别评价答案是否正确、是否切题，以及是否忠实于检索证据。这三个维度不能互相替代。

1.Answer Correctness

(1)什么是AnswerCorrectness

Answer Correctness用于评估整体回答质量，重点判断最终结论和关键事实是否符合参考答案、业务规则或真实世界事实。

(2)Ragas中的AnswerCorrectness

在Ragas中，AnswerCorrectness通过比较模型回答和参考答案，综合计算以下两个维度：

• 语义相似度 Semantic Similarity：比较模型回答与参考答案在整体语义上是否接近。该部分通常依赖Embedding计算相似度。

• 事实准确性 Factual Correctness：将回答和参考答案拆分为可验证Claim，根据TP、FP和FN衡量事实重合情况，并计算相应的F1分数。

• 回答和参考答案都是由大模型生成

最终分数由两个维度加权得到：

Ragas AnswerCorrectness= 事实准确性权重 × Factual Correctness  + 语义相似度权重 × Semantic Similarity

权重可以配置。部分Ragas版本的默认权重更强调事实准确性，例如使用[0.75, 0.25]分别表示事实准确性和语义相似度。由于默认值可能随版本变化，评测报告应记录Ragas版本和实际weights配置，而不应只记录最终分数。

Ragas中的AnswerCorrectness比较的是response与reference，不等同于Faithfulness。前者判断回答是否符合参考答案，后者判断回答是否受到本次retrieved_contexts支持。答案正确率必须先定义评分规则：

可以报告严格的答案正确率：

答案正确率= 判定为完全正确的回答数  / 回答总数

也可以将结果分为：

• 完全正确；

• 部分正确；

• 错误；

• 正确拒答。

报告中必须说明类别定义。例如，“部分正确”是遗漏次要信息，还是遗漏任何 Required Claim 都算部分正确，不能留给评判器自由发挥。

2.Answer Relevancy

Answer Relevancy衡量答案是否真正回答用户问题，关注的是“有没有答到点上”，而不是事实是否正确或是否有证据支持。

常见低相关表现包括：

• 重复问题但没有给出结论；

• 提供大量背景，却没有回答用户真正关心的字段；

• 回答相关主题，但偏离当前问题；

• 在用户只要求一个值时输出大量不必要内容；

• 忽略问题中的时间、对象或限制条件。

一个答案可能非常相关但事实错误，也可能事实正确但包含大量离题内容。因此，Answer Relevancy 应与 Answer Correctness 分开报告。

3.Faithfulness

Faithfulness衡量回答中的可验证 Claim 与检索资料是否事实一致，即答案是否忠实于提供给生成模型的上下文。

推荐使用 Claim 级口径：

Faithfulness= 得到上下文支持的可验证 Claim 数  / 全部可验证 Claim 数

评估时通常需要：

• 把回答拆分为最小可验证 Claim；

• 为每个 Claim 查找对应证据；

• 判定为 supported、unsupported 或 contradicted；

• 汇总得到 Faithfulness 分数。

Faithfulness高只说明回答与检索资料一致，不保证资料本身正确、最新或权威。

4.幻觉率

推荐采用 Claim 级定义：

Claim级幻觉率= 无支持或与证据矛盾的可验证 Claim 数  / 全部可验证 Claim 数

也可以采用回答级定义：

回答级幻觉率= 包含至少一个错误 Claim 的回答数  / 回答总数

两种口径不能混用，报告必须明确分母。

错误类型建议拆分为：

在 Claim 拆分和判定规则完全一致时，通常可以近似认为：

幻觉率 ≈ 1 - Faithfulness

如果两项指标使用不同的 Claim 范围、不同的中立类别处理方式或不同分母，就不能直接换算。

5.Answer Correctness与Faithfulness的区别

二者评价的参照物不同：

• Answer Correctness参照业务事实、参考答案或权威规则；

• Faithfulness参照本次RAG提供的检索上下文。

因此可能出现以下情况：

• 回答完全基于检索证据，但证据已经过期，Faithfulness高而Correctness低；

• 回答事实正确，但答案来自模型记忆而非提供的证据，Correctness高而Faithfulness低；

• 回答同时符合权威事实和检索证据，两项指标都高；

• 检索错误且回答继续依据错误证据生成，两项指标可能分别表现为高Faithfulness和低Correctness。

6.Citation Precision

Citation Precision衡量被引用证据中，真正支持对应 Claim 的比例：

Citation Precision= 有效支持对应 Claim 的引用数  / 全部引用数

它可以发现“引用存在，但引用内容与结论无关”的问题。

7.Citation Recall

Citation Recall衡量应当引用的 Claim 中，有多少实际获得了有效引用：

Citation Recall= 获得有效引用的应引用 Claim 数  / 全部应引用 Claim 数

如果答案包含多个关键结论，只给出一个笼统引用，Citation Precision可能不低，但Citation Recall会暴露引用覆盖不足。

8.Correct Rejection Rate

Correct Rejection Rate衡量证据不足、问题超出知识范围或存在冲突时，系统是否正确拒答或要求补充信息。

Correct Rejection Rate= 正确拒答的不可回答问题数  / 全部不可回答问题数

评估集中必须专门加入不可回答样本，否则无法判断系统是否倾向于在缺少证据时编造答案。

拒答过少会增加幻觉，拒答过多则会损害可用性。可以同时统计：

• 不可回答问题的正确拒答率；

• 可回答问题的错误拒答率；

• 拒答后是否清楚说明缺少什么证据。

四、指标解读与分层诊断

1.核心指标的区别

典型组合情况：

2.分层诊断

Reranker的价值主要通过 Precision、MRR、nDCG、Context Precision 和最终答案质量体现。只观察 Recall，可能看不出重排带来的改善。

3.评测执行与上线治理

(1)离线评估流程

推荐采用可复现的单变量实验流程：

固定文档快照和Golden Set          ↓运行Baseline          ↓一次修改一个主要变量          ↓比较Recall、nDCG、Correctness和Faithfulness          ↓同时比较P95延迟和成本          ↓通过回归门禁后上线

一次只改变一个主要变量，例如：

• Retriever或Embedding模型；

• Reranker模型；

• Candidate K；

• Rerank Top N；

• Chunk大小、重叠和切分策略；

• 查询改写或Query Decomposition；

• 上下文压缩策略；

• 证据Token Budget；

• Prompt模板；

• 生成模型或推理参数；

• 自检或校正轮数。

如果同时修改检索模型、Prompt和Top K，即使最终分数提高，也无法确定哪个改动真正有效。

①每次实验必须记录

• 评估集名称和版本；

• 文档快照和索引版本；

• Embedding、Retriever、Reranker和生成模型版本；

• Chunking参数；

• Candidate K和Rerank Top N；

• Prompt版本；

• 代码提交版本；

• 评判器版本和评分规则；

• 随机种子及关键推理参数；

• 平均延迟、P95延迟、Token和成本。

②分场景报告

除总体平均值外，还应按照以下维度切片：

• 简单事实、多跳推理、比较、汇总和计算；

• 单文档、跨文档和跨版本；

• 短问题、长问题、口语问题和含错别字问题；

• 高频业务、低频边界和高风险合规场景；

• 可回答、不可回答和证据冲突；

• 不同语言、部门、知识库和用户群体。

总体分数可能掩盖关键场景退化。例如，平均正确率提高，但高风险合规问题明显下降，仍然不应上线。

(2)评判器设计与校准

①优先使用确定性规则

编号、金额、日期、状态、计算结果和枚举字段应优先使用程序规则检查。确定性规则更稳定、可复现，也更容易解释。

对于多要点答案，可以把Required Claims转换为结构化检查项。只有语义表达多样、难以用规则覆盖时，再使用人工或LLM Judge。

②LLM Judge的使用原则

LLM Judge可以扩大评测规模，但不能直接当作绝对真值。建议：

• 提供明确评分Rubric和正反例；

• 把Correctness、Relevancy和Faithfulness分开判定；

• 要求输出结构化标签、理由和引用证据；

• 固定模型版本、Prompt和推理参数；

• 对高风险样本和低置信样本进行人工复核；

• 定期抽样比较LLM Judge与专家结论；

• 统计一致率，并分析系统性偏差；

• 不让Judge看到不应参与判定的信息。

例如，评估Faithfulness时，Judge只应依据问题、回答和检索上下文，不应利用自身知识替模型补充证据。评估Correctness时，则应提供经确认的参考答案或业务规则。

③Claim拆分原则

Claim应尽量是最小、独立、可验证的陈述。以下句子包含多个Claim：

该产品支持七天无理由退货，退款将在两个工作日内到账，所有地区均适用。

应拆分为：

• 该产品支持七天无理由退货；

• 退款将在两个工作日内到账；

• 该规则适用于所有地区。

如果不拆分，部分有证据、部分无证据的句子很难准确判定，也会导致幻觉率和Faithfulness失真。

(3)线上评估与补充指标

离线评测可以控制变量，但无法完全覆盖真实流量。上线后还应监控：

线上A/B测试必须同时观察质量、延迟、成本和安全指标。点击率或停留时间不能单独代表答案正确，因为错误但表达流畅的回答也可能获得较高互动。

建议补充以下专项评测：

• 对同义改写、错别字和语序变化是否稳定；

• 面对文档冲突时是否说明冲突，而不是任意选择；

• 面对过期文档时是否优先使用最新且权威的版本；

• 权限过滤是否会泄露无权访问的内容；

• Prompt Injection是否能诱导系统忽略知识库规则；

• 引用内容是否包含敏感信息；

• 对高风险问题是否触发人工审核或正确拒答。

4.评测报告与回归门禁

(1)推荐报告结构

实验名称：实验目标：Baseline版本：Candidate版本：文档快照：评估集版本：主要改动：检索指标：Recall@K、Hit Rate@K、Precision@K、MRR、nDCG上下文指标：Context Precision、Context Recall生成指标：Answer Correctness、Answer Relevancy、Faithfulness、幻觉率引用与拒答：Citation Precision、Citation Recall、Correct Rejection Rate工程指标：P50、P95、Token、单次成本分场景退化：严重失败案例：是否通过门禁：结论与后续动作：

(2)回归门禁示例

实际阈值应根据业务风险和Baseline确定，不能直接照搬固定数字。门禁可以采用以下结构：

• 核心高风险场景不得出现严重事实错误；

• Recall@K不得低于Baseline允许范围；

• Answer Correctness和Faithfulness必须达到最低标准；

• Citation Precision不得明显下降；

• 不可回答问题的正确拒答率必须达标；

• P95延迟和单次成本不得超过预算；

• 任一关键切片明显退化时阻止上线；

• 新发现的严重失败样本必须加入长期回归集。

除平均值外，建议同时报告样本量、分位数和置信区间。两个版本只相差很小但评估样本很少时，不能轻易断言新版本更好。

5.实施建议

• 先明确业务失败是什么：错误答案、漏证据、引用错误和响应过慢需要不同指标。

• 先做小而可靠的Golden Set：一百条高质量样本通常比上千条粗糙自动生成样本更有诊断价值。

• 检索与生成分开评估：先确认模型看到了什么，再判断它如何使用证据。

• 保持评测可复现：固定快照、版本、参数和评判规则。

• 优先分析失败样本：平均分只能描述结果，失败案例才能指导修改。

• 对高风险场景设置硬门禁：不要让总体平均值掩盖严重错误。

• 定期更新评估集：加入新的真实查询、线上失败和文档变化场景。

• 控制评测集污染：最终测试集不能长期暴露给调参人员或用于Prompt优化。

• 校准自动评判器：用人工专家样本检查LLM Judge的一致性和偏差。

• 同时优化质量、延迟和成本：最优系统不是单项分数最高，而是在业务约束下达到可接受平衡。