Rerank 模型
flowchart LR
A["Rerank 模型"]
A --> B["分类：检索增强 (RAG)"]
A --> C["关键词：RAG"]
A --> D["关键词：Rerank"]
A --> E["关键词：Cross-encoder"]
A --> F["关键词：检索"]初检（Embedding + 向量搜索，或 Hybrid Recall）追求的是“快”和“尽量别漏”，排序往往比较粗。Rerank 模型的职责，是在一批候选文档里做更精细的相关性判断，重新排序，选出真正值得送进 LLM 的 top-n。Sentence Transformers 的官方文档对这一点讲得很清楚：典型做法是先用高效的 Bi-Encoder 召回 top-100，再用 Cross-Encoder 对这些候选逐个打分重排。(sbert.net)
延伸阅读
这篇文章会讲什么
前一篇讲了检索质量优化，强调了一个核心观点：
检索 ≠ 一次向量搜索
检索 = Recall + Ranking
这一篇就是继续往下拆第二部分：Ranking。
很多人刚做 RAG 时，会把系统停留在：
Query → Dense / Hybrid Search → Top-k → LLM这条链可以工作，但在真实系统里很快会暴露一个问题：
- 候选里通常“有相关文档”
- 但排在最前面的，不一定是“最该给模型看”的那几个
从工程上看，很多 RAG 失败不是因为“检索完全没找到”，而是因为：
找到了，但排序不够好。
这时 Rerank 的价值就出来了。它不是替代初检，而是在初检之后做精排，把“找回来”变成“排对顺序”。
先说结论：Rerank 不是可有可无的小优化，而是很多生产 RAG 的质量分水岭
如果你只记住一句话，那应该是：
Embedding 检索负责粗召回，Rerank 负责把前几条真正排准。
这件事之所以重要，是因为 LLM 最终能看到的上下文通常非常有限：
- 你也许召回了 50 条
- 但真正送给模型的，可能只有 3–10 条
- 这 3–10 条的顺序，直接决定模型会优先相信谁
Sentence Transformers 的 Cross-Encoder 文档明确强调，Cross-Encoder 通过让 query 和 document 一起进入模型，可以得到更高的相关性判断质量，但因为它不能像 Bi-Encoder 那样预计算文档向量，所以速度明显更慢，不适合海量召回，只适合后置 rerank。(sbert.net)
所以 Rerank 的系统定位很清楚：
- 不负责全库搜索
- 不负责大规模召回
- 专门负责“把已经召回的一小批结果排好”
这正是它在 RAG 里的最佳位置。
一、为什么初检通常不够
先看定义：初检的目标是 Recall，不是最终排序质量；它必须先快、先广，天然不够“精”。
初检为什么偏“粗”
无论你用的是：
- 向量检索
- BM25
- Sparse + Dense Hybrid
第一阶段检索通常都在做一件事：
先把可能相关的东西尽量找回来。
这就意味着它的优化目标，往往是：
- 不要漏掉正确文档
- 延迟要低
- 成本要可控
而不是：
- 保证前 3 条就是最优顺序
- 精确判断 query 和每个 chunk 的细粒度关系
所以初检的常见问题包括：
| 初检特点 | 典型问题 |
|---|---|
| Bi-encoder / Dense Search | query 和 doc 独立编码，交互信息有限 |
| Sparse Search | 关键词命中强，但不一定理解真实问法 |
| Hybrid Recall | 候选更全，但融合后的排序不一定细致 |
| 速度优先 | 为大规模检索而设计，无法对每个 query-doc 对深度推理 |
这也是为什么“检索到了正确文档”不等于“它会排在前几名”。
一个很典型的失败例子
用户问：
“员工试用期结束后年假怎么算？”
初检召回的前几条可能同时包含：
- 年假总则
- 试用期政策
- 入职规则
- 员工福利汇总
- 真正相关的“试用期转正后的年假计算规则”
这些结果“都不算完全离题”，但前几条里真正最值得给模型看的，未必排在最前。 如果你没有 rerank，LLM 很可能会优先参考一条“相关但不最相关”的文档，于是回答开始偏。
所以很多 RAG 系统的问题，不是 Recall Failure，而是 Ranking Failure。
二、Bi-encoder vs Cross-encoder
先看定义：Bi-encoder 适合海选，Cross-encoder 适合决赛。
这是理解 Rerank 的核心。
Bi-encoder 是怎么工作的
Bi-encoder 会把：
- Query 单独编码
- Document 单独编码
然后再用相似度（如 cosine / dot product）来比较。
这类方法的最大优势是：
- 文档向量可以预计算
- 搜索时只需编码 query
- 非常适合大规模检索
所以 Bi-encoder 天然适合做第一阶段召回。Sentence Transformers 文档就是这么定义它在 semantic search / retrieval 里的位置的。(sbert.net)
Cross-encoder 是怎么工作的
Cross-encoder 则不同。它会把：
- Query
- Document
一起输入同一个 Transformer，然后直接输出一个相关性分数。Sentence Transformers 的 CrossEncoder 文档明确说明：CrossEncoder 接受一对文本作为输入，输出一个分数或标签，它本身不会产出可单独复用的句向量。(sbert.net)
这意味着它能做更细粒度的判断，因为模型内部可以直接建模 query 和 document 之间的 token-level interaction。
直觉上怎么理解
Bi-encoder 像是：
先分别给 query 和文档拍照，再比较两张照片像不像。
Cross-encoder 像是：
把 query 和文档摆在一起，让模型直接判断“这个文档是不是在回答这个问题”。
后者自然更精细，但也更贵。
对比总结
| 类型 | 编码方式 | 速度 | 精度 | 典型用途 |
|---|---|---|---|---|
| Bi-encoder | Query 和 Doc 独立编码，再算相似度 | 快 | 中 | 初检、召回 |
| Cross-encoder | Query 和 Doc 联合输入，直接输出相关性分数 | 慢 | 高 | Rerank、精排 |
先看定义：Bi-encoder 负责“找回来”，Cross-encoder 负责“排前面”。
三、为什么 Cross-encoder 不能直接拿来做全库检索
先看定义：不是它不准，而是它太贵。
Cross-encoder 的问题不在效果，而在计算方式。因为它无法像 Bi-encoder 那样提前把所有文档都编码成向量缓存起来，所以它必须对每一个 (query, document) 对单独前向计算一次。
这意味着：
- 如果你要对 100 个候选 rerank，就要做 100 次 query-doc scoring
- 如果你要对 100 万篇文档做全库检索，那就是 100 万次前向推理
- 对实时系统来说，这通常不可接受
Sentence Transformers 官方文档明确写到：Cross-Encoder 性能更好，但对成千上万甚至上百万对 query-document 做打分会非常慢，因此应先用 retriever 生成一小批候选，再做 rerank。(sbert.net)
所以一个非常重要的系统边界是：
Cross-encoder 不负责大海捞针，它只负责在已经捞出来的一小堆候选里精排。
四、Rerank 的工作方式
先看定义：Rerank 的标准工作流，就是先召回一批候选，再逐个打分，最后只保留最相关的少数结果。
一个最典型的流程如下：
- 初检返回 top-50 或 top-100 候选文档
- 对每个
(query, doc)对，Cross-encoder 输出一个相关性分数 - 按分数重新排序
- 取 top-3、top-5 或 top-10 送给 LLM
Query + Doc1 → Cross-encoder → score_1
Query + Doc2 → Cross-encoder → score_2
...
→ 按 score 排序 → 取 top-n这就是一个标准的 two-stage retrieval 模式。SBERT 官方文档几乎用同样的描述来介绍 retrieve-and-rerank pipeline。(sbert.net)
五、主流 Rerank 模型与路线
先看定义：当前常见路线大致分三类：API 型 rerank、开源 Cross-encoder rerank、以及更复杂的 late interaction 系列。
1. Cohere Rerank
Cohere 官方文档把 Rerank 描述为：对已有搜索结果进行重新排序的模型，并且最新的 Rerank 4 系列支持多语言文本和半结构化 JSON 文档。(docs.cohere.com)
特点
- API 直接可用
- 多语言支持较好
- 支持文档和半结构化数据
- 适合不想自建 rerank 服务的团队
适用
- 快速上线
- 不想自己部署 Cross-encoder
- 中等请求量、能接受 API 成本
2. BGE Reranker / SBERT Cross-encoder 一类开源模型
这类模型通常基于 Cross-encoder 思路，自己部署，优点是：
- 成本可控
- 可自托管
- 方便做量化和吞吐优化
- 中文 / 中英场景通常有更灵活的选型空间
Sentence Transformers 本身就提供了大量 CrossEncoder 模型和用法文档。(sbert.net)
适用
- 自建 RAG 平台
- 成本敏感
- 有一定模型部署能力
- 想控制延迟和吞吐
3. ColBERT / Late Interaction 路线
ColBERT 原始论文提出的是一种 late interaction 架构：query 和 document 先分别编码，但在打分时保留更细粒度的 token-level similarity，而不是压缩成单一向量。(arxiv.org)
ColBERTv2 则进一步改进了空间占用和效果，在多个 benchmark 上取得很强表现。(arxiv.org)
这类模型的定位
它们不是最朴素的“Cross-encoder rerank”，而是一条介于：
- 全向量检索
- 纯 Cross-encoder 精排
之间的高精度路线。
适用
- 对检索质量要求非常高
- 愿意接受更复杂实现
- 有能力维护更复杂索引与 serving 架构
一个简单的选型判断
| 路线 | 特点 | 更适合什么团队 |
|---|---|---|
| Cohere Rerank | 省心、API 化、多语言好 | 快速落地团队 |
| 开源 Cross-encoder | 灵活、自托管、成本可控 | 平台型或成本敏感团队 |
| ColBERT / Late Interaction | 更复杂、潜力更高 | 高精度检索系统 |
六、两阶段检索模式：Rerank 在系统里到底放哪
先看定义：Rerank 的标准位置，是放在初检和 Prompt Assembly 之间。
一个典型两阶段结构如下：
Stage 1: 快速召回 (top-100) ← Bi-encoder / Hybrid
Stage 2: 精确 Rerank (top-5) ← Cross-encoder| 阶段 | 目标 | 手段 |
|---|---|---|
| Recall | 不漏掉相关文档 | 向量检索、BM25、Hybrid、大 top-k |
| Precision | 把真正相关的排到前面 | Rerank、小 top-n |
这其实就是前一篇“检索质量优化”里说的多阶段检索，在这里被具体化到了 Rerank 这一层。
一个最容易记住的系统图
Query
↓
Recall（Dense / Hybrid / Sparse）
↓
Top-k Candidates
↓
Rerank（Cross-encoder / Late Interaction）
↓
Top-n Context
↓
Prompt Assembly
↓
LLM这张图里最重要的是：
Rerank 不是检索的替代品，而是检索后的二次判断。
七、Rerank 到底对多少文档做最合适
先看定义：Rerank 的候选太少，提升不明显；太多，延迟和成本会迅速上升。
一个常见的经验区间如下：
| 初检 top-k | Rerank 数量 | 说明 |
|---|---|---|
| 20–50 | 全部 rerank | 大多数场景都比较稳 |
| 50–100 | 常见生产区间 | 召回和延迟比较平衡 |
| 100+ | 需谨慎 | 只有在高召回场景才常见 |
| 200+ | 通常不作为默认 | 成本和延迟明显上升 |
一个实用经验
很多系统会这样做：
- 初检先召回 50–100
- Rerank 全部或其中前 50
- 最终只把 top-3 到 top-10 送进 LLM
为什么最后只送很少的结果？ 因为对 LLM 来说，文档太多也会引入噪声。Rerank 的一个核心价值，就是帮你把“很多候选”压缩成“少量最值得看的证据”。
八、Rerank 对 RAG 质量的真实价值
先看定义：Rerank 的最大价值，不是让系统“找到更多文档”，而是让最终进入模型的文档更对、更干净、更有顺序。
它对 RAG 的提升，通常体现在三个方面：
1. 减少噪声注入
没有 rerank 时，相关但不最相关的片段很容易混进 prompt。 Rerank 能把这类“差一点点”的内容排到后面。
2. 提升前几条上下文质量
很多时候，模型是否答对，取决于前 3 条是不是刚好把关键信息给全了。
3. 间接降低幻觉
RAG 里很多幻觉，其实不是“模型空想”，而是因为模型拿到的材料就不够准。 Rerank 不能从根本上消灭幻觉，但它能减少“错误上下文把模型带偏”的概率。
Sentence Transformers 官方 Retrieve & Re-rank 文档明确指出，Cross-Encoder reranker 可以“substantially improve the final results for the user”。(sbert.net)
九、什么时候不一定要上 Rerank
先看定义：Rerank 很有价值，但不是所有系统都必须一开始就上。
可以暂时不加的场景
| 场景 | 建议 |
|---|---|
| 文档量很小 | 初检 top-5 已经很稳，可以先不加 |
| 延迟极度敏感 | 先优化 recall 与 chunking，再评估是否值得加 |
| 原型阶段 | 先把系统闭环跑通，再决定是否上精排 |
| 成本很敏感 | 如果是 API 型 rerank，先做 A/B 再决定 |
一个很现实的原则是：
Rerank 值不值得上，不要靠“感觉应该更强”，而要靠评测和 A/B。
十、Rerank 与 Prompt 的配合：排序不只是过滤，还影响模型注意力
Rerank 的结果，不只是“选哪些文档”，还决定了文档的顺序。
而这个顺序对 LLM 很重要，因为：
- 排在前面的文档更容易被优先使用
- 如果前几条已经足够回答问题，后面的资料可能几乎不会被认真参考
- 顺序混乱会让模型更难抓重点
所以一个很实用的工程经验是：
- 把 rerank 后最相关的文档放前面
- 不要盲目把过多文档塞给模型
- 如有引用需求，尽量保留来源 metadata
- prompt 中可明确要求“优先参考前面的资料”
所以 Rerank 的作用不仅是过滤噪声，也是在帮助模型建立“证据优先级”。
十一、多阶段 Rerank：高精度系统里的进一步演化
在更复杂或更大规模场景里，系统还可能继续把 rerank 拆层。
例如：
- Stage 1：轻量 reranker 或规则先快速缩小候选
- Stage 2：更重的 Cross-encoder 做高精度精排
这类设计适用于：
- 初检候选非常多
- 高精度要求高
- 可以接受更复杂架构
不过对大多数企业 RAG 场景来说，单阶段 rerank 已经够用。不要一开始就把系统做得太重。
十二、Rerank 的部署与工程考量
1. GPU vs CPU
Cross-encoder 在 GPU 上通常明显更快。 如果 QPS 不高，CPU 也不是完全不可用；但只要进入中高流量，GPU 通常更现实。
2. 批量推理
Rerank 很适合做 batch。
因为你本来就要对一批 (query, doc) 对打分，批量可以明显提升吞吐。
3. 缓存
如果同一 query 高频出现，或者 query-doc 组合重复率高，可以缓存部分 rerank 结果。
4. 量化
量化后的 reranker 往往能显著降低显存和延迟，尤其在开源模型自建场景里很常见。
所以从工程视角看，Rerank 并不只是“加一个模型”，而是要一起考虑：
- 候选规模
- 模型大小
- 吞吐需求
- 延迟预算
- 部署形态
十三、一个真正实用的接入顺序
如果你已经有一个可用的 RAG baseline，接入 Rerank 更稳的顺序通常是：
-
先确认 Recall 已经够用
-
观察前几条排序是否经常不准
-
选一个简单 rerank baseline（API 或轻量 Cross-encoder）
-
对比：
- Recall 不变时，前几条质量是否明显提升
- 最终回答准确率是否上升
- 延迟是否在可接受范围内
-
再决定是否扩大 rerank 范围或换更强模型
先看定义：
Rerank 最适合在“召回已经基本能找到，但排序还不够好”的阶段引入。
十四、一个最好记住的原则：Rerank 解决的是“前几条不够准”，不是“全都没找到”
如果你只想记住一句话，那就是：
Rerank 的前提是：正确文档已经被召回进候选集。
也就是说：
- 如果正确文档根本没被找回来，那是 Recall 问题，不是 Rerank 问题
- 如果正确文档在 top-50 里，但没进 top-5，那才是 Rerank 最擅长解决的问题
这也是为什么你不应该把 Rerank 当成万能补丁。 它非常有用，但它解决的是检索系统里的排序问题，不是所有问题。
小结
Rerank 是两阶段检索里的“精排”环节。Bi-encoder 或 Hybrid Recall 负责快速召回一批候选，Cross-encoder 或 late interaction 路线再对这些候选做更细粒度的相关性判断。Sentence Transformers 官方文档明确推荐 retrieve-and-rerank 作为高质量检索的标准模式；Cohere 提供了开箱即用的 API 型 rerank 模型；ColBERT 则代表了更复杂但更强的 late interaction 路线。(sbert.net) (docs.cohere.com) (arxiv.org)
对大多数生产 RAG 来说，Rerank 往往是一项很有性价比的增强： 它不一定最便宜，但很常是把“检索到候选”推进到“模型真正用对证据”的关键一步。
核心概念速查
| 概念 | 一句话 |
|---|---|
| Bi-encoder | Query 和 Doc 独立编码算相似度，快但交互弱 |
| Cross-encoder | Query 和 Doc 联合输入打分，慢但排序更准 |
| Two-stage Retrieval | 先召回 top-k，再精排取 top-n 的检索结构 |
| Rerank | 在候选文档上做更细粒度相关性排序 |
| Late Interaction | 介于纯向量检索和 Cross-encoder 之间的高精度路线 |
| Recall Problem | 正确文档根本没进入候选集 |
| Ranking Problem | 正确文档召回了，但没有排到前面 |
| Top-k / Top-n | 前者常指初检候选数，后者常指最终送给模型的文档数 |