Agent丨如何评估 Rerank 的有效性，常用哪些指标？

type

Post

status

Published

date

Apr 23, 2026

slug

agent17

summary

1. Rerank 在 RAG 链路中的位置

典型链路如下：

一阶段召回通常追求 Recall：宁可多捞一些候选，也不要漏掉答案。Rerank 追求 Precision at top-k：把真正有用的 chunk 排到 LLM 最容易利用的位置。

Qdrant 的 Hybrid Search with Reranking 教程也采用类似思想：先用 dense embedding 和 sparse/BM25 扩大召回，再用 late-interaction embedding 做更精细的 reranking；官方文档明确指出，reranking 是在较小候选集上运行更昂贵模型，以提升 precision 并控制延迟。(Qdrant) Weaviate 对 reranking 的定义也很直接：使用另一套标准或更昂贵算法，对已有搜索结果重新排序。(docs.weaviate.io)

2. 先看源码：成熟项目怎么实现 Rerank

2.1 LangChain：CrossEncoderReranker 的核心逻辑

LangChain 的 CrossEncoderReranker 本质上是一个 DocumentCompressor：它接收一批候选文档，用 cross-encoder 给每个 (query, document) 对打分，然后按分数倒序排序，取 top_n。源码中可以看到它保存 model 和 top_n，并在 compress_documents 里对 query-doc pair 评分、排序、截断。(AiDocZh)

下面是简化后的实现逻辑：

关键点在这里：

向量检索阶段通常比较的是 embedding(query) 和 embedding(chunk) 两个独立向量；
Cross-Encoder 则把 query + chunk 一起输入模型，让模型直接判断这段 chunk 是否能回答这个 query。

所以评估 Rerank 的关键，不是问“它的分数是不是更像相似度”，而是问：

它是否把真正能回答问题的 chunk 排到了更靠前的位置？

2.2 LangChain + Cohere：保留 relevance_score 便于观测

LangChain 的 Cohere rerank 集成会调用 rerank API，并把结果里的 index 和 relevance_score 映射回原文档；在 compress_documents 里，还会把 relevance_score 写入文档 metadata，方便后续观测、日志和调试。(GitHub)

简化逻辑如下：

这个设计对评估很重要。线上系统不仅要知道“最终答案好不好”，还要知道每次进入 prompt 的 chunk 分数、排序、来源和是否被引用。

2.3 LlamaIndex：把 Rerank 当作 node_postprocessor 评估

LlamaIndex 的 RetrieverEvaluator 支持在 retriever 之后挂 node_postprocessors，也就是可以先 retrieve，再经过 rerank/postprocess，然后统一取最终 retrieved ids 和 texts 来计算指标。源码中可以看到 evaluator 会先调用 retriever，再依次应用 node postprocessor。(GitHub)

这说明 Rerank 的评估方式应该是：

不是只单测 reranker，而是对比：

Retriever only vs Retriever + Reranker

2.4 Haystack：Retriever top_k 与 Ranker top_k 要分开评估

Haystack 的 SentenceTransformersSimilarityRanker 文档强调：ranker 通常放在 retriever 之后；retriever 的 top_k 决定召回多少候选，ranker 的 top_k 决定最终返回多少文档。(docs.haystack.deepset.ai) Haystack 的 Ranker API 也把 query、documents、top_k 作为 rerank 的核心输入输出。(docs.haystack.deepset.ai)

这对实验设计非常关键：

阶段	参数	典型值	评估重点
Retriever	candidate_top_k	50 / 100 / 200	候选集中是否包含答案
Reranker	final_top_k	3 / 5 / 8	答案是否被排到 LLM 上下文前部
Generator	context_window	4k / 8k / 32k	LLM 是否能基于上下文生成正确答案

如果 candidate_top_k=20 时正确 chunk 根本没被召回，Rerank 再强也没用；如果 candidate_top_k=200 但 Rerank 太慢，线上体验也可能不可接受。

3. 常用指标一：Hit Rate / Success@K

Hit Rate@K 衡量：

Top K 结果中是否至少有一个相关文档。

公式：

Hit@K = 1，如果 top K 中存在任意相关文档；否则为 0。
对所有 query 求平均，就是整体 Hit Rate@K。

适用场景：

场景	是否适合
每个问题只需要命中一个关键 chunk	很适合
FAQ、政策问答、单点事实问答	很适合
多跳问题、需要多个证据片段	不够

LlamaIndex 的 HitRate 默认逻辑就是检查 retrieved ids 中是否存在任意 expected id；也支持更细粒度的 granular hit rate，即命中数除以 expected ids 数量。(GitHub)

示例：

Query	Gold Docs	Rerank 前 Top 3	Rerank 后 Top 3	Hit@3 变化
退款期限是多少天？	D7	D2, D4, D7	D7, D2, D9	1 → 1
是否支持企业微信登录？	D3	D9, D8, D1	D3, D8, D1	0 → 1

Hit@K 的问题是：只要命中就算 1，但它不关心相关文档排第 1 还是第 5。因此它适合做底线指标，不适合作为唯一指标。

4. 常用指标二：MRR@K

MRR，即 Mean Reciprocal Rank，关注：

第一个相关文档出现得有多靠前。

公式：

RR = 1 / rank
MRR = 所有 query 的 RR 平均值

如果第一个相关文档排第 1，RR = 1；排第 2，RR = 0.5；排第 5，RR = 0.2。

LlamaIndex 的 MRR 实现默认计算第一个相关 retrieved doc 的倒数排名；也有 granular 版本，会对多个相关文档的 reciprocal rank 求平均。(GitHub)

示例：

排序结果	第一个相关文档位置	RR
✅, ❌, ❌, ❌	1	1.00
❌, ✅, ❌, ❌	2	0.50
❌, ❌, ❌, ✅	4	0.25
❌, ❌, ❌, ❌	无	0

MRR 很适合评估 Rerank，因为 Rerank 的核心目标就是：

把第一个真正有用的 chunk 尽量提前。

在 RAG 中，MRR@3、MRR@5 往往比 Hit@10 更敏感。

5. 常用指标三：Precision@K

Precision@K 衡量：

Top K 里有多少比例是相关的。

公式：

Precision@K = Top K 中相关文档数 / K

适用场景：

场景	说明
LLM 上下文窗口很小	Top K 噪声越少越好
文档 chunk 很长	错误 chunk 会挤占上下文
要降低幻觉	无关上下文会诱导模型胡编
企业知识库问答	宁可少给，也不要乱给

LlamaIndex 的 Precision 指标实现就是取 retrieved ids 与 expected ids 的交集，再除以 retrieved set 大小。(GitHub)

例如：

Top 5 结果	相关数	Precision@5
✅ ✅ ❌ ❌ ❌	2	0.4
✅ ✅ ✅ ❌ ❌	3	0.6
❌ ❌ ✅ ❌ ❌	1	0.2

Rerank 后如果 Precision@5 提升，通常说明 LLM prompt 中的噪声明显减少。

6. 常用指标四：Recall@K

Recall@K 衡量：

所有应该被找到的相关文档中，有多少被放进了 Top K。

公式：

Recall@K = Top K 中相关文档数 / Gold 相关文档总数

LlamaIndex 的 Recall 指标实现是 retrieved set 与 expected set 的交集大小除以 expected set 大小。(GitHub) RAGAS 的 Context Recall 也强调“不要漏掉重要信息”，并指出计算 recall 需要 reference 或 reference contexts 作为参照。(Ragas)

Recall@K 在 Rerank 评估里要分两层看：

指标	说明
Candidate Recall@N	一阶段召回的候选 N 里是否包含答案
Final Recall@K	Rerank 后最终 K 个上下文里是否包含答案

常见故障是：

Candidate Recall@100 很高，但 Final Recall@5 很低。
说明 retriever 找到了答案，但 reranker 把答案排丢了。

这类问题不能怪向量库，应该重点看 reranker 模型、chunk 内容、query 改写、metadata 拼接方式。

7. 常用指标五：AP / MAP

AP，即 Average Precision，关注多个相关文档在排序列表中的整体分布。

直觉上：

相关文档越多、越靠前，AP 越高。

LlamaIndex 的 AP 实现会遍历 retrieved ids，每遇到一个相关文档，就累加当前位置的 precision，最后除以 expected set 的大小。(GitHub)

适用场景：

场景	说明
一个问题有多个证据 chunk	比 MRR 更全面
多段政策、合同、论文问答	需要多个 chunk 同时进入上下文
多跳问题	需要检索到多个事实链条

例如，问题是：

“请比较方案 A 和方案 B 的退款规则差异。”

Gold chunk 可能包含：

D1：方案 A 退款规则
D2：方案 B 退款规则
D3：特殊人群例外条款

此时只命中 D1 不够，MAP 比 Hit Rate 更合理。

8. 常用指标六：NDCG@K

NDCG，即 Normalized Discounted Cumulative Gain，关注：

高相关文档是否排在更靠前的位置，并且可以支持不同相关性等级。

它比 MRR 和 Precision 更细，因为可以把文档标成：

Label	含义
3	完全回答问题
2	部分回答问题
1	主题相关但证据不足
0	无关

LlamaIndex 的 NDCG 实现会计算 DCG 和 IDCG 的比值；它当前基于 expected ids 做二值相关性判断，相关文档 rel=1，否则 rel=0。(GitHub)

在 Rerank 场景中，NDCG@K 非常推荐作为主指标，尤其适合人工标注了 relevance grade 的测试集。

示例：

排名	文档	相关性等级
1	D7	3
2	D2	2
3	D9	0
4	D5	1

如果另一个 reranker 把 D7 排到第 4，即使 top 5 仍然命中，NDCG 也会明显下降。

9. RAGAS 指标：Context Precision / Context Recall

传统 IR 指标依赖 gold document ids，但很多 RAG 项目早期没有高质量 qrels。此时可以用 RAGAS 这类 RAG 评估工具。

9.1 Context Precision

RAGAS 的 Context Precision 用来评估：

相关 chunk 是否被排在 retrieved contexts 的前面。

官方定义中，Context Precision 会计算每个相关 chunk 位置上的 Precision@k，并对这些值做平均。(Ragas)

这非常适合评估 Rerank，因为 Rerank 最直接优化的就是上下文排序。

9.2 Context Recall

RAGAS 的 Context Recall 用来评估：

参考答案中的 claims，有多少可以被 retrieved context 支撑。

它更贴近最终回答质量，因为它不是只看 doc id，而是看参考答案中的信息是否被上下文覆盖。(Ragas)

9.3 ID-based Context Precision / Recall

如果你的知识库里每个 chunk 都有稳定 ID，优先用 ID-based 指标，因为便宜、稳定、可重复。RAGAS 的源码中也有基于 retrieved context IDs 与 reference context IDs 直接比较的 context precision 实现。(GitHub)

10. 指标选择建议

10.1 单跳事实问答

例如：

“企业版最多支持多少个成员？”

推荐：

主指标	辅指标
MRR@5	Hit@5、Precision@5、Answer Correctness

原因：

单跳问题通常只需要一个关键 chunk，最重要的是把它排到第 1 或前 3。

10.2 多证据问答

例如：

“请总结 2024 和 2025 两版合同的付款条款差异。”

推荐：

主指标	辅指标
MAP@K / NDCG@K	Recall@K、Context Recall、Faithfulness

原因：

多证据问题不能只看第一个相关 chunk，必须看多个必要证据是否都进入上下文。

10.3 客服 FAQ / 帮助中心

推荐：

主指标	辅指标
Precision@3	MRR@3、拒答准确率、人工满意度

原因：

客服场景中错误上下文很危险。Top 3 里宁可少，也不要混入高噪声 chunk。

10.4 企业知识库 / 内部制度问答

推荐：

主指标	辅指标
NDCG@5	Context Precision、Citation Accuracy、Faithfulness

原因：

企业知识库常常有相似制度、旧版本制度、不同部门制度，Rerank 要能区分“看起来相关”和“真正适用”。

11. 一套完整的离线评测实验

11.1 构建评测集

每条样本至少包含：

字段	示例
query	“试用期员工是否享受年假？”
gold_chunk_ids	`["hr_policy_2025_03_p12_c4"]`
gold_answer	“试用期员工在满足连续工作条件后可按比例享受年假。”
query_type	单跳 / 多跳 / 对比 / 摘要 / 计算
difficulty	easy / medium / hard
metadata	语言、部门、文档版本、时间范围

评测集来源可以有 4 种：

真实用户日志抽样
人工编写高频问题
从文档自动生成问题，再人工审核
从失败案例回流构造 hard set

LlamaIndex 官方 Retrieval Evaluation 示例也提到可以依赖 synthetic data generation 来降低构造 eval dataset 的负担。(Developer Documentation)

11.2 对比组设计

至少要有这些实验组：

组别	配置
A	Vector only
B	BM25 only
C	Hybrid: Vector + BM25
D	Vector + Rerank
E	Hybrid + Rerank
F	Hybrid + Rerank + Query Rewrite

RAGFlow 的文档中也能看到工程系统常用“关键词相似度 + 向量余弦相似度”的组合方式；如果启用 rerank，则改为关键词相似度与 reranking score 的加权组合，同时文档明确提醒 rerank 会显著增加响应时间。(RAGFlow)

所以评估时一定要记录：

指标提升多少？
延迟增加多少？
成本增加多少？
是否值得上线？

12. Python 实现：离线计算 Rerank 指标

下面是一个轻量版评估脚本，可以对比 baseline 与 rerank 后的排序结果。

使用方式：

13. Rerank 专属诊断指标

除了标准 IR 指标，建议额外做几个 Rerank 专属指标。

13.1 Rank Gain

衡量 gold chunk 被提前了多少位。

Query	Rerank 前 gold rank	Rerank 后 gold rank	Gain
Q1	8	2	+6
Q2	4	1	+3
Q3	2	6	-4

实现：

13.2 Top-k Promotion Rate

衡量：

原来不在 top-k，Rerank 后进入 top-k 的 gold query 占比。

例如：

指标	含义
Promotion@3	gold 从 Top 3 外进入 Top 3
Promotion@5	gold 从 Top 5 外进入 Top 5

这个指标非常适合给业务方解释 Rerank 价值。

13.3 Rerank Harm Rate

衡量：

原本在 top-k 的正确 chunk，被 Rerank 排出 top-k 的比例。

Rerank 不是永远正收益。尤其在以下场景可能伤害效果：

query 很短、歧义很强；
chunk 缺少标题、路径、表头等上下文；
reranker 训练语料与业务领域差异很大；
多语言或代码文档场景模型不适配。

Harm Rate 一定要监控，否则只看平均 NDCG 可能掩盖严重个案。

14. 端到端指标：不要只看检索分数

Rerank 是为最终回答服务的。所以离线检索指标提升后，还要看生成指标。

层级	指标	说明
Retrieval	Recall@K	是否拿到证据
Rerank	MRR / NDCG / Context Precision	证据是否靠前
Generation	Faithfulness	答案是否被上下文支撑
Generation	Answer Correctness	答案是否正确
Citation	Citation Precision / Recall	引用是否准确
Product	CTR / 解决率 / 人工满意度	用户是否真的受益
System	p50 / p95 latency	是否能上线
Cost	rerank cost per query	成本是否可接受

RAGAS 的 Context Precision 和 Context Recall 正好可以作为 retrieval/rerank 与生成质量之间的桥梁：前者关注相关上下文是否靠前，后者关注参考答案中的信息是否被 retrieved context 覆盖。(Ragas)

15. 延迟与成本指标

Rerank 常常是 RAG 链路里的延迟大户。RAGFlow 文档就明确提示，启用 rerank model 会显著增加响应时间。(RAGFlow)

建议记录：

指标	说明
rerank_latency_p50	Rerank 中位延迟
rerank_latency_p95	线上体验关键指标
rerank_latency_p99	大客户/高并发场景必须看
candidates_per_query	每次 rerank 的候选数量
tokens_per_candidate	每个候选 chunk 长度
rerank_cost_per_1k_queries	每千次请求成本
timeout_rate	Rerank 超时比例
fallback_rate	降级到无 rerank 的比例

典型评估表：

配置	NDCG@5	MRR@5	Context Precision	p95 延迟	成本
Vector Top 5	0.61	0.58	0.52	120ms	低
Hybrid Top 5	0.68	0.63	0.59	180ms	低
Hybrid Top 50 + Rerank Top 5	0.79	0.74	0.72	780ms	中
Hybrid Top 100 + Rerank Top 5	0.81	0.75	0.73	1350ms	高

如果 Top 100 相比 Top 50 只提升 0.02 NDCG，但 p95 延迟增加 570ms，线上未必值得。

16. 推荐的评估流程

17. Badcase 归因框架

当 Rerank 效果不好，不要只换模型，要先定位问题在哪一层。

现象	可能原因	应对
Candidate Recall@100 低	首阶段召回漏了	优化 embedding、BM25、hybrid、query rewrite
Candidate Recall 高，NDCG@5 低	Reranker 排序错	换 reranker、加标题/路径/表头、领域微调
NDCG 高，答案仍错	生成器没用好上下文	优化 prompt、引用约束、答案校验
Precision 高，Recall 低	Top K 太小	增大 final_top_k 或做上下文压缩
Rerank 后 Harm Rate 高	模型领域不匹配	分场景路由，部分 query 不启用 rerank
指标提升但延迟不可接受	candidate_top_k 太大	降低候选数、批处理、缓存、轻量 reranker
表格/代码/合同效果差	chunk 表达不完整	保留表头、章节标题、metadata、父子 chunk

18. 工程上如何选择 Reranker

18.1 Cross-Encoder Reranker

优点：

精度强，适合判断 query 与 chunk 是否直接相关。

缺点：

每个 query-doc pair 都要过模型，候选越多越慢。

适合：

企业知识库、FAQ、政策问答、客服问答。

18.2 LLM-based Listwise Reranker

优点：

可以一次看多个候选，理解复杂意图、多跳关系更强。

缺点：

贵、慢、不稳定，需要严格结构化输出。

适合：

高价值低频 query、复杂法律/金融/研究问答。

18.3 Late Interaction / ColBERT 风格

优点：

比单向量 embedding 更细粒度，能做 token-level interaction。

缺点：

存储和索引复杂度更高。

Qdrant 的教程中使用 dense、sparse、late interaction 三种表示，把 late interaction embedding 用于 reranking，并提醒要在 relevance 与成本之间做平衡。(Qdrant)

18.4 API Reranker

优点：

接入快，效果通常稳定。

缺点：

数据合规、成本、网络延迟、可控性要评估。

19. 一份可直接使用的指标面板

建议每次实验输出如下表格：

模型/策略	Candidate@N	Final@K	Hit@K	MRR@K	Recall@K	MAP@K	NDCG@K	Context Precision	Context Recall	Faithfulness	p95 Latency
vector only	20	5	0.71	0.54	0.48	0.42	0.55	0.50	0.61	0.72	120ms
hybrid	50	5	0.78	0.61	0.57	0.49	0.63	0.58	0.68	0.76	180ms
hybrid + bge-reranker	50	5	0.82	0.72	0.58	0.56	0.75	0.71	0.69	0.82	760ms
hybrid + cohere rerank	50	5	0.84	0.74	0.59	0.58	0.77	0.73	0.70	0.83	900ms

注意：

如果 Hit@K 没怎么变，但 MRR@K、NDCG@K、Context Precision 明显提升，这仍然说明 Rerank 有价值。
因为它不是“多找到了答案”，而是“把答案排得更靠前”。

20. 最佳实践总结

评估 Rerank 时，推荐把指标分为四层：

层级	推荐指标
候选召回层	Candidate Recall@50/100
重排质量层	MRR@K、NDCG@K、MAP@K、Precision@K
RAG 上下文层	Context Precision、Context Recall
端到端产品层	Faithfulness、Answer Correctness、Citation Accuracy、Latency、Cost

最推荐的主指标组合是：

单跳问答：MRR@5 + Precision@5 + Faithfulness
多证据问答：NDCG@5 + MAP@5 + Context Recall
企业知识库：NDCG@5 + Context Precision + Citation Accuracy
线上系统：NDCG@5 uplift / p95 latency uplift / cost uplift 一起看

最终判断标准不是“Rerank 分数高不高”，而是：

在可接受的延迟和成本下，Rerank 是否稳定地把正确证据排进 LLM 最容易使用的位置，并最终提升答案正确性与可信度。