RAG 系统的检索质量，到底该怎么评估？

做 RAG（Retrieval-Augmented Generation，检索增强生成）时，一个非常常见的问题是：

大模型回答错了，到底是模型不会，还是根本没检索到正确资料？

所以，评估 RAG 系统时，最好把“检索”和“生成”拆开来看。

这篇文章只讲其中一个问题：

RAG 的检索质量应该怎么评估？

一、什么叫“检索质量好”？

假设用户问：

Redis 为什么这么快？

知识库里有 10000 个文档，其中有 3 个文档真正能够回答这个问题。

RAG 检索器返回 Top 5 文档。

我们关心的其实就几个问题：

正确文档有没有被找出来？
找出来的文档里，有多少是真正相关的？
真正重要的文档排名靠不靠前？
返回的内容是否足够支持最终回答？

围绕这些问题，就产生了 RAG 中最常见的一批检索指标。

二、最重要的检索质量指标

1. Recall@K：该找的内容找回来了吗？

Recall@K，也叫 召回率。

它关注的是：

所有正确文档中，有多少被 Top K 检索结果找到了？

例如，一个问题有 3 个相关文档。

Top 5 检索结果中找到了其中 2 个。

那么：

Recall@5 = 2 / 3 = 66.7%

Recall 对 RAG 特别重要。

因为如果正确知识根本没有进入上下文，那么后面的大模型再强，也很难凭空生成正确答案。

因此很多 RAG 系统首先关注的都是：

Recall@5
Recall@10
Recall@20

简单理解：

Recall 看的是“有没有漏掉正确答案”。

2. Precision@K：找回来的内容准不准？

Precision@K，也叫 准确率 / 精确率。

它关注：

Top K 检索结果里面，有多少是真的相关？

例如：

Top 5 返回了 5 个文档
其中只有 2 个真正相关

那么：

Precision@5 = 2 / 5 = 40%

如果 Precision 很低，意味着检索结果里面混入了大量无关内容。

这会导致一个非常典型的问题：

正确资料明明检索到了，但同时塞进去太多垃圾文档，把大模型带偏了。

所以可以简单理解：

Recall 看“有没有漏”，Precision 看“有没有混进垃圾”。

三、Hit Rate：最简单实用的 RAG 指标

实际项目里还有一个特别常用的指标：

Hit Rate@K

它只关心：

Top K 里面有没有至少一个正确答案？

例如：

问题1：Top5 有正确文档 → 1
问题2：Top5 有正确文档 → 1
问题3：Top5 没有正确文档 → 0

一共有 100 个问题，其中 85 个问题 Top 5 中至少出现了一个正确文档：

Hit Rate@5 = 85%

对于很多问答型 RAG 系统来说，这个指标非常直观。

因为有时候一个问题只需要找到 一个足够好的文档，就已经能够回答。

因此：

Hit Rate@K

通常是 RAG 项目里非常值得优先看的指标之一。

四、MRR：正确答案排得够不够靠前？

假设正确文档虽然检索到了，但是排名第 10。

实际上也可能没什么用。

因为很多 RAG 系统只取：

Top 3
Top 5

作为大模型上下文。

所以我们不仅希望：

找到正确文档。

还希望：

正确文档尽可能排在前面。

这时候就会用到：

MRR（Mean Reciprocal Rank）

简单理解：

第一个正确答案排名越靠前，得分越高。

例如：

正确答案第一次出现的位置	得分
第 1 名	1
第 2 名	1/2
第 3 名	1/3
第 10 名	1/10

最后对所有问题求平均，就是 MRR。

因此 MRR 特别适合：

FAQ
问答系统
搜索系统
知识库 RAG

因为这些场景通常很关心：

最相关的答案能不能排在最前面。

五、NDCG：整个排序质量怎么样？

MRR 主要关注：

第一个正确答案在哪里？

但有些问题可能不只有一个相关文档。

例如用户问：

Transformer 的核心机制有哪些？

可能有多个相关文档：

Attention
Multi-Head Attention
Position Encoding
Feed Forward Network

这时候我们不仅关心有没有一个正确答案，而是希望：

越相关的文档排名越靠前。

这时候通常使用：

NDCG@K

NDCG 会同时考虑：

相关性
+
排名位置

而且可以支持不同相关程度：

3分：高度相关
2分：相关
1分：弱相关
0分：无关

所以 NDCG 更适合评估：

整个 Top K 排序到底好不好。

六、MAP：多个相关结果整体找得怎么样？

另外一个经典指标叫：

MAP
Mean Average Precision

它比较关注：

多个相关文档是否都能被比较靠前地检索出来。

MAP 在传统搜索、信息检索领域非常经典。

不过在普通 RAG 项目中，相比 MAP，我通常更建议优先关注：

Recall@K
Hit Rate@K
MRR
NDCG@K

因为它们更容易解释，也更符合大部分 RAG 问答系统的实际需求。

七、几个指标到底怎么看？

可以简单记成：

指标	主要回答的问题
Recall@K	正确资料找全了吗？
Precision@K	返回结果里面垃圾多不多？
Hit Rate@K	至少找到一个正确资料了吗？
MRR	第一个正确资料排得够前吗？
NDCG@K	整个排序合理吗？
MAP	多个相关资料整体排序好吗？

如果刚开始做 RAG，我建议优先看：

Recall@K
Hit Rate@K
MRR / NDCG

这几个指标基本已经能够发现大部分检索问题。

八、实际项目里怎么评估？

知道指标以后，更重要的问题来了：

“正确文档”到底是谁定义的？

因此真正做 RAG Evaluation，一般需要构建一套测试集。

例如：

Question
↓
用户问题

Ground Truth
↓
真正相关的文档 / Chunk

Retrieved Documents
↓
RAG 实际检索出来的 Top K

然后比较：

Ground Truth
vs
Retrieved Results

最后计算：

Recall@K
Precision@K
Hit Rate@K
MRR
NDCG

这就是最标准的 离线检索评估。

九、常见的 RAG 检索评估方法

实际项目中主要有几种。

方法一：人工标注 Ground Truth

最标准的方法。

人工准备：

问题 → 正确文档

例如：

问题：
Redis 为什么快？

正确文档：
redis_architecture_01
redis_memory_02

然后运行检索系统，看这些文档有没有出现在 Top K。

优点：

准确
稳定
容易比较不同版本

缺点：

人工标注成本比较高

但如果要认真做 RAG Benchmark，这是最推荐的方法。

方法二：LLM-as-a-Judge

如果没有人工标签，可以让 LLM 判断：

这个检索结果和问题是否相关？

例如：

Question:
Redis 为什么快？

Context:
Redis 数据主要存储在内存中……

LLM Judge:
相关性 = 5/5

于是可以让模型给每个 Chunk 打分：

0：完全无关
1：弱相关
2：部分相关
3：高度相关

这种方式非常适合快速构建 RAG Evaluation Pipeline。

但需要注意：

LLM Judge 本身也可能判断错误。

因此比较成熟的方案通常是：

人工标注一小部分
+
LLM 批量评估

十、不要只评 Retriever，还要评完整 Pipeline

现代 RAG 往往不是：

Query
↓
Vector Search
↓
Top K

而是：

Query
↓
Query Rewrite
↓
向量检索 / BM25
↓
Hybrid Search
↓
Reranker
↓
Top K
↓
LLM

所以最好分阶段评估。

例如：

Retriever Recall@20
↓
Reranker NDCG@5
↓
最终 Context Recall
↓
Answer Accuracy

这样一旦效果下降，就能快速判断：

是召回出了问题？

还是 Reranker 排序出了问题？

还是最后 LLM 生成出了问题？

这比只看最终回答准确率有效得多。

十一、线上系统还要看 A/B Test

离线指标很好，并不代表真实用户体验一定好。

因此成熟的 RAG 系统通常还会做线上 A/B Test。

例如：

A：旧 Retriever
B：新 Retriever

比较：

用户点击率
回答满意度
重新提问率
人工转接率
任务完成率

因此完整的 RAG 评估一般是：

离线指标
+
人工评估 / LLM Judge
+
最终回答质量
+
线上 A/B Test

十二、一个实用的 RAG 评估框架

如果让我从零开始搭建 RAG Retrieval Evaluation，我通常会这样做：

第一步
构造 100～1000 个真实问题

        ↓

第二步
给问题标注相关 Chunk / 文档

        ↓

第三步
跑 Retriever

        ↓

第四步
计算

Recall@5
Recall@10
Hit Rate@5
MRR
NDCG@5

        ↓

第五步
分析 Bad Case

        ↓

第六步
优化

Chunking
Embedding
Hybrid Search
Query Rewrite
Reranker

        ↓

第七步
重新跑 Benchmark

这其实才是 RAG 优化真正有效的方式：

不要凭感觉调参数，而是建立 Benchmark，然后用指标驱动优化。

总结

RAG 的检索质量，本质上主要解决三个问题：

有没有找回来？
↓
Recall / Hit Rate

找回来的准不准？
↓
Precision

正确结果排得够不够前？
↓
MRR / NDCG

对于大部分 RAG 项目，一个非常实用的指标组合就是：

Recall@K
+
Hit Rate@K
+
MRR / NDCG@K

再配合：

人工 Ground Truth
+
LLM-as-a-Judge
+
Bad Case Analysis
+
线上 A/B Test

基本就可以建立一套比较完整的 RAG 检索评估体系。

最后记住一句话：

RAG 优化的第一步，不是换 Embedding 模型，而是先建立一套可靠的 Evaluation Benchmark。

没有评估体系，你根本不知道 RAG 是真的变好了，还是只是“看起来好像变好了”。