RAG 评测指标速查表

RAG 指标大体分为四层：

Retriever 是否找得到
        ↓
Context 是否完整、干净
        ↓
Generator 是否答对、忠于证据
        ↓
整个系统是否安全、快速、经济

传统检索指标通常通过人工标注的相关文档直接计算，不需要 LLM Judge；当前 NVIDIA 的 Retriever 评测就包括 Precision、Recall、nDCG、MAP、Reciprocal Rank 和 Success@k。Ragas、AWS 和 Databricks 则补充了 Context、Groundedness、Correctness、Citation 等面向完整 RAG 的指标。

@k 表示：只检查检索结果的前 k 个，例如 Recall@10 就是只看前 10 个结果。

一、检索与排序指标

指标它为什么重要大概怎么算
Hit@k / Success@k判断前 k 名里是否至少找到了一条正确证据，适合单证据问题Top-k 中存在至少一个相关结果记为 1，否则为 0；对所有问题取平均
Recall@k判断必需证据有没有被漏掉，是 RAG Retriever 最重要的基础指标之一Top-k 中找到的相关证据数 ÷ 所有应该找到的相关证据数
Precision@k判断检索结果中有多少是真正有用的，反映噪声大小Top-k 中相关结果数 ÷ k
MRR判断第一个正确结果出现得有多靠前，适合“找到一个权威答案即可”的问题找到第一个相关结果的排名，取其倒数；例如第 2 名就是 1/2，再对所有问题平均
MAP@k同时关注多个相关结果是否被找到、是否排得靠前每出现一个相关结果，就计算当时的 Precision，最后对这些 Precision 和所有问题取平均
nDCG@k不仅判断是否相关，还能区分“核心证据、辅助证据、部分相关”，特别适合评估 Reranker给结果标注不同相关性等级；越重要、排名越靠前，贡献越大；再和理想排序比较
All-Evidence@k判断多跳问题所需的完整证据链是否全部被找到所有必需证据组都进入 Top-k 时为 1；缺少任何一组就是 0
Document Recall@k判断是否找到了正确文档，适合先定位问题是在文档级还是 Chunk 级Top-k 中命中的正确文档数 ÷ 应命中的正确文档数
Evidence/Chunk Recall@k判断正确文档内部真正支持答案的段落是否被找到Top-k 中命中的 Golden Evidence Chunk 或证据范围 ÷ 全部必需证据

快速理解

Hit@k：
有没有找到至少一条？

Recall@k：
应该找到的证据，找到了多少？

Precision@k：
找回来的结果中，有多少是真的有用？

nDCG@k：
最重要的证据有没有排在最前面？

All-Evidence@k：
完整证据链是否全部找齐？

All-Evidence@k 是很实用的工程自定义指标，但不像 Recall、nDCG、MAP 那样具有统一的标准名称。设计时最好按“证据组”标注，允许多个等价证据满足同一个要求。

二、Context 上下文质量指标

传统 Retriever 指标一般依赖人工标注的相关文档；Context 类指标则经常使用参考答案或 LLM Judge，判断最终交给生成模型的 Context 是否干净、完整和足够。

指标它为什么重要大概怎么算
Context Precision判断最终 Context 中噪声是否过多，以及相关 Chunk 是否排在前面逐个判断 Chunk 是否有用；相关 Chunk 越多、越靠前，分数越高
Context Recall判断参考答案需要的事实是否都能在 Context 中找到将参考答案拆成事实声明，计算其中有多少能被检索 Context 支持
Context Coverage与 Context Recall 接近，强调 Context 是否覆盖了标准答案所需信息被 Context 覆盖的标准答案信息 ÷ 标准答案所需的全部信息
Context Relevance判断检索内容是否真的和用户问题有关通常让 LLM Judge 对每个 Chunk 与问题的相关程度评分，再取平均
Context Sufficiency判断现有 Context 是否已经足够生成完整答案根据 expected_facts 或标准答案，判断 Context 能否支持完整回答，通常使用二值或分级评分
Context Noise Ratio判断多少 token 被无关内容占用，关系到效果、延迟和成本无关 Context token 数 ÷ Context 总 token 数
Duplicate Context Rate检查同一信息是否被重复塞给模型，避免重复偏置和浪费 token重复或高度相似 Chunk 数 ÷ 最终 Context Chunk 总数

Context Recall 和 Recall@k 的区别

Recall@k：
基于人工标注的相关文档或证据 ID 计算。

Context Recall：
基于参考答案中的事实，判断这些事实是否能从 Context 获得支持。

三、答案生成质量指标

指标它为什么重要大概怎么算
Answer Correctness判断最终答案在事实和结论上是否正确，是最直接的结果指标将答案与标准答案或 expected_facts 比较，计算正确事实比例，或由 LLM Judge 按 Rubric 评分
Faithfulness / Groundedness判断回答是否忠于检索证据，用来发现幻觉将回答拆成事实性断言，计算其中有多少能被 Context 支持
Completeness防止答案虽然正确，但只回答了问题的一部分标准答案要求的必要事实中，实际答案覆盖了多少
Answer Relevance / Response Relevancy判断答案是否真正回应用户问题，而不是正确但跑题判断答案内容与用户意图的相关程度，并惩罚无关、重复内容
Helpfulness判断答案是否能真正帮助用户完成任务通常由人工或 LLM Judge 根据实用性、清晰度和可执行性综合评分
Logical Coherence判断答案内部是否存在矛盾、逻辑跳跃或前后不一致按 Rubric 检查答案逻辑是否完整一致
Exact Match适合型号、日期、数值、枚举值等答案固定的场景系统答案与标准答案标准化后完全相同则为 1，否则为 0
Fact-level Accuracy比整段文本相似度更适合企业 RAG将答案拆成多个事实，统计正确事实数 ÷ 被评测事实总数

Correctness 和 Faithfulness 不一样

Correctness：
答案在现实或标准答案中是否正确？

Faithfulness：
答案是否能从检索 Context 中得到支持？

可能出现：

答案正确，但没有 Context 支持
→ 可能是模型靠自身记忆猜对

答案忠于 Context，但答案错误
→ 可能是知识库文档已经过期或本身有误

四、引用质量指标

指标它为什么重要大概怎么算
Citation Precision防止引用虽然存在，但实际上不能支持对应断言能正确支持相应断言的引用数 ÷ 全部引用数
Citation Coverage / Citation Recall防止只给少量正确引用，但大量事实没有引用带有有效引用的事实性断言数 ÷ 所有需要引用的断言数
Citation Validity检查引用是否真实存在、链接和页码是否有效有效引用数 ÷ 全部引用数
Citation Entailment判断被引用原文是否真的能够推出答案中的结论对每组“断言—引用”进行支持、不支持或矛盾判断

例如：

答案包含 10 条事实
只引用了其中 2 条，而且这 2 条都引用正确

Citation Precision = 很高
Citation Coverage = 很低

五、拒答与可回答性指标

只评测“回答得好不好”不够，还要评测系统是否知道什么时候应该拒答。

指标它为什么重要大概怎么算
Refusal Accuracy判断系统是否在正确的场景拒答正确回答或正确拒答的案例数 ÷ 全部案例数
Unsupported Answer Rate衡量文档没有证据时，系统仍强行回答的比例不可回答问题中，被系统强行回答的数量 ÷ 不可回答问题总数
Over-refusal Rate衡量明明有充分证据，系统却拒绝回答的比例可回答问题中，被系统错误拒答的数量 ÷ 可回答问题总数
Clarification Accuracy判断遇到歧义问题时，系统是否正确要求澄清应该澄清的案例中，真正触发澄清的比例

理想状态是：

有证据 → 正确回答
没证据 → 拒答
有歧义 → 先澄清
无权限 → 拒绝访问

六、安全、权限与生产指标

这些不一定属于统一的学术指标，但在企业上线时通常应该作为硬性 Release Gate。

指标它为什么重要大概怎么算
Unauthorized Retrieval Rate检查 Retriever 是否把无权限 Chunk 取了出来无权限结果数 ÷ 检索结果总数
Cross-tenant Leakage Rate防止租户 A 获得租户 B 的数据发生跨租户暴露的测试数 ÷ 权限测试总数
Document Injection Success Rate判断恶意文档指令是否能控制模型被文档注入成功操纵的案例数 ÷ 注入测试总数
p50 / p95 / p99 Latency平均延迟会掩盖少数极慢请求，生产中通常更关注 p95将请求延迟排序；p95 表示 95% 的请求都不超过该延迟
Cost per Query防止质量提高很小，但 token 和模型费用大幅上涨Retriever、Reranker、Embedding 和 LLM 的总费用 ÷ 请求数
Token per Query判断 Context 是否过长、是否存在重复和浪费每次请求使用的输入与输出 token 数取平均或分位数
Error Rate监控超时、模型错误和解析失败失败请求数 ÷ 请求总数

安全指标通常应该要求：

Unauthorized Retrieval Rate = 0
Cross-tenant Leakage Rate = 0

不能通过提高其他质量指标来抵消权限泄漏。

七、最推荐的一套最小指标组合

刚开始构建 RAG 系统时，不需要一次实现所有指标。可以先建立这一组：

评测层优先指标
检索有没有漏Recall@k
排序是否合理nDCG@k
完整证据是否找齐All-Evidence@k
Context 是否干净Context Precision
Context 是否足够Context Recall 或 Context Sufficiency
答案是否正确Answer Correctness
是否忠于证据Faithfulness / Groundedness
是否遗漏信息Completeness
引用是否可靠Citation Precision + Citation Coverage
没证据是否乱答Unsupported Answer Rate
是否过度拒答Over-refusal Rate
生产性能p95 Latency + Cost per Query
权限安全Unauthorized Retrieval Rate

可以将这套组合记成：

Recall：
找没找全？

nDCG：
排得好不好？

All-Evidence：
证据链齐不齐？

Context Precision：
噪声多不多？

Correctness：
答案对不对？

Faithfulness：
答案是不是根据证据说的？

Completeness：
有没有漏答？

Citation：
引用是否正确、是否完整？

Refusal：
没证据时会不会瞎编？

Latency / Cost / ACL：
系统能不能安全地投入生产？

参考资料