Reranker 模型

向量检索已经会按相似度返回结果，为什么还需要 Reranker？

因为第一阶段召回追求的是 “快速找出可能相关的内容”，而不是在少量候选中做最精细的判断。Reranker 模型接收用户问题和候选文档，重新计算相关性并调整顺序：

flowchart LR
    A["全部文档"] --> B["BM25 / 向量 / 混合召回"]
    B --> C["Top-N 候选"]
    C --> D["Reranker 重新评分"]
    D --> E["Top-K 文档"]
    E --> F["LLM 生成答案"]

Reranker 解决的是 “答案已经被召回，但排名不够靠前”，不能找回第一阶段完全漏掉的文档。

它和 Embedding 模型有什么区别？

Embedding 模型分别编码问题和文档：

e_{q} = f (q), e_{d} = f (d)

再通过向量相似度计算相关性：

s_{dense} (q, d) = sim (e_{q}, e_{d})

文档向量可以提前计算，适合在海量文档中快速搜索。但问题和文档在编码时彼此不可见，所有相关性信息都必须被压缩进两个固定长度向量。

Reranker 则把问题和单个候选文档放进同一次模型推理：

s_{rerank} (q, d) = g (q, d)

模型可以直接比较两侧 token，因此更容易识别：

否定关系；
数字和时间条件；
实体组合；
问题是否真的能由该段文档回答；
措辞相似但实际含义不同的内容。

对比项	Embedding 模型	Reranker 模型
输入	分别输入 query 和 document	同时输入 query-document pair
输出	两个向量	一个相关性分数
文档预计算	可以	不可以
处理范围	全部文档	少量召回候选
速度	快	慢
RAG 中的职责	第一阶段召回	第二阶段精排

Cross-Encoder 如何工作？

最常见的 Reranker 是 Cross-Encoder。它把问题和文档拼成一条输入：

[CLS] query [SEP] document [SEP]

经过 Transformer 后，分类头输出一个相关性分数：

flowchart LR
    A["Query + Document"] --> B["Tokenizer"]
    B --> C["Transformer"]
    C --> D["Classification Head"]
    D --> E["Relevance Score"]

因为问题和文档在同一个注意力计算中，模型能执行 token 级交互。代价是每个候选都要重新推理。

如果召回了 $N$ 个候选，就需要计算 $N$ 个 query-document pair。因此，Reranker 适合处理几十或几百个候选，不适合直接扫描整个知识库。

生成式 Reranker

Decoder-only 模型也可以把相关性判断写成生成任务：

Instruction: 判断文档能否回答问题
Query: 如何降低大模型推理延迟？
Document: KV Cache 可以避免重复计算历史 token。
Answer: yes

模型可以读取 yes 和 no 对应 token 的 logits，将它们转换为相关性分数，而不必真正生成一段解释。

这种方式可以复用生成式模型主干，并支持自然语言检索指令，但通常比专用分类模型更慢。模型的 Prompt、取分位置和 logits 计算必须遵循模型卡。

Late Interaction

Late-interaction 模型位于 Embedding 和 Cross-Encoder 之间。

它分别计算 query 和 document 的多个 token 向量，再在检索时执行细粒度匹配，例如对每个 query token 寻找最相似的 document token：

s (q, d) = i \in q \sum j \in d max e_{q_{i}}^{⊤} e_{d_{j}}

这类模型能预计算文档表示，又比单向量保留更多局部信息。代价是索引更大，查询计算和服务实现也更复杂。

普通 RAG 可以先使用 Cross-Encoder。只有性能评测证明它太慢，或单向量表示损失了重要信息时，再考虑 late interaction。

什么时候需要 Reranker？

先建立一个不带 Reranker 的检索基线，再根据评测结果决定。

评测现象	应该处理的位置
正确文档没有进入召回 top-N	改进分块、召回模型、查询或过滤条件
正确文档进入 top-N，但排不到最终 top-K	增加或改进 Reranker
正确证据已稳定进入 top-K，答案仍错误	检查上下文构造、Prompt 和生成模型
现有排序已经满足指标	不增加 Reranker

Reranker 特别适合：

BM25 和向量检索合并后的候选；
候选中有大量措辞相似的文档；
top-K 上下文预算很小；
查询包含数字、否定和多个限制条件；
第一阶段 Recall 较高但 MRR、nDCG 较低。

关键参数

召回数量 N

$N$ 太小，正确文档可能根本没有进入候选； $N$ 太大，Reranker 延迟随候选数量增加。

先通过 Recall@N 确认候选集合覆盖答案，再调整精排性能。

最终数量 K

$K$ 太小可能缺少回答所需的多段证据； $K$ 太大会增加上下文 token，并把无关信息交给 LLM。

最大输入长度

Reranker 的输入长度由 query 和 document 共同占用。文档被截断后，答案可能正好落在被删除的部分。应记录截断方向，并在必要时继续切分过长候选。

批处理大小

一个 query 对应多个候选 pair，天然适合批处理。批量过小浪费吞吐，批量过大则增加显存和 padding。

如何评测？

Reranker 应在固定的第一阶段候选集上评测，避免把召回变化和重排变化混在一起。

至少观察：

MRR：第一个相关结果是否更靠前；
nDCG@k：多个相关结果的排序是否改善；
Hit Rate@k：前 k 条是否包含相关内容；
P95 延迟和单次查询成本；
接入 Reranker 前后的端到端回答质量。

如果 Reranker 没有稳定改善排序指标，就不应为了 “标准架构” 保留它。

一句话总结

Embedding 模型负责从全库快速召回候选，Reranker 模型负责在少量候选中做更细致的相关性判断。正确证据没有被召回时，Reranker 无能为力；正确证据已经出现但排名不好时，它才真正有用。

starmountain1997

探索