一个结构性矛盾：快的不准，准的不快
做过 RAG 的人大概都遇到过同一种沮丧：文档库里明明有答案，检索回来的却是「沾边但不中」的段落。换更强的嵌入模型、调切块策略，提升总是有限——因为问题常常不在某个模型，而在单阶段检索的结构性矛盾上。
现代检索有两条经典路线。双塔模型（bi-encoder，即日常说的嵌入模型）把查询和文档各自独立编码成一个向量，靠余弦相似度在向量库里做近邻搜索，百万级文档毫秒级响应。代价是查询和文档在编码时互相看不见，所有语义交互被压缩成两个向量的点积，「Word 与 Excel 的区别」这种 token 级的细微差异就此丢失。交叉编码器（cross-encoder）则反过来：把查询和文档拼成一条输入送进模型，让两边的每个 token 通过注意力机制充分交互后，直接输出一个相关性分数，排序质量显著更高。代价同样明显——每评一对就要跑一次完整前向传播，候选一多就慢到没法用（这两条路线的取舍，Weaviate 与 Pinecone 的工程指南讲得最清楚，见文末参考资料）。
一个负责快，一个负责准，单选谁都有硬伤。产业界给出的标准答案是：都要。
两阶段检索：快的负责海选，准的负责终审
这就是 Reranker 的角色：它不是一个「更强的检索器」，而是管线里的第二阶段。完整流程是——
flowchart LR
Q[用户查询] --> H{混合召回}
H -->|向量检索| C[候选池]
H -->|BM25 关键词| C
C -->|top 100| R[Reranker 逐对精排]
R -->|top 5-10| L[LLM 生成答案]
第一阶段用双塔（常与 BM25 混合，BM25 的原理本站已有专文）从全库快速捞出 50-100 条候选；第二阶段把交叉编码器当「终审法官」，逐对给这 50-100 条候选重新打分排序，只留 5-10 条进下游。交叉编码器再慢，算 100 对也就零点几秒，而它的质量优势恰好只在「区分几十条相似候选」这种精细活上体现。Pinecone 与 Weaviate 的指南都把这个「召回 50-100、精排留 5-10」作为典型配置——数字不是铁律，但候选数比这小，重排提升有限；比这大，延迟开始明显上涨。
代码上通常只有几行。以开源的 bge-reranker-v2-m3 为例：
from sentence_transformers import CrossEncoder
reranker = CrossEncoder("BAAI/bge-reranker-v2-m3")
pairs = [(query, doc.text) for doc in candidates] # 召回的 50-100 条候选
scores = reranker.predict(pairs) # 每对一个前向，输出相关性 logit
ranked = sorted(zip(candidates, scores), key=lambda x: -x[1])
top_docs = [doc for doc, s in ranked[:5]] # 分数也可过 sigmoid 转 0-1 后设阈值
为什么重排能明显提升质量？看一个直觉例子：查询「如何取消订单」，召回回来的两条候选分别是「如何取消订单」和「如何下单」。在双塔里，两段文本与查询的向量相似度可能都很高——它们本来就语义相近。但交叉编码器能注意到 token 级的差别：「取消」这个词有没有出现、出现在哪个位置、和「订单」怎么搭配，排序立刻分出高下。粗排看轮廓，精排看细节，这是整个两阶段设计的核心逻辑。
第三条路：ColBERT 的晚交互
双塔和交叉编码器之外，还有一条经常被忽略的中间路线——晚交互（late interaction），代表作是斯坦福 2020 年的 ColBERT（Khattab 与 Zaharia，SIGIR 2020）。
它的想法很巧：文档编码仍然离线逐 token 做、查询在线编码，两边都不看对方（像双塔一样快）；但不把文档压成一个向量，而是保留每个 token 的上下文化向量（原始版本压缩到 128 维）。打分时，查询的每个 token 向量去文档的所有 token 向量里找最相似的那个，取最大值，再把查询所有 token 的得分加起来——这个操作叫 MaxSim。它保留了「取消有没有匹配上」这种 token 级的交互证据，却不用像交叉编码器那样把查询和文档塞进同一次前向。
效果在论文里有明确数字：质量与当时的 BERT 交叉编码器模型相当，检索速度快约两个数量级，每查询的 FLOPs 低了四个数量级。2022 年的 ColBERTv2 又用残差压缩把 token 向量的存储开销压掉一个数量级。晚交互的定位介于两者之间：既能当高精度重排器，也能靠多向量索引直接做端到端检索，Weaviate、Vespa、Qdrant 等引擎后来都加了原生支持。
晚交互不是没有代价：存储。双塔一篇文档一个向量，而 ColBERT 一篇文档几百个 token 向量，索引体积直接大两个数量级——这也是 128 维压缩与 ColBERTv2 残差编码存在的原因，都为了把多向量的存储账压回可接受的范围。选它之前先算存储账，再算查询收益。
重排器是怎么训练出来的
理解训练方式，能帮你判断一个重排器在你的场景里靠不靠谱。主流重排器几乎都从同样的配方里长出来：以 MS MARCO 这类「查询-段落」标注数据集为底，训练目标是判断「这个段落是否回答了这个查询」，再逐步升级训练粒度——从逐条二分类（pointwise），到成对比较（pairwise），再到整列表排序（listwise）。
决定重排器上限的往往不是损失函数，而是困难负样本（hard negatives）：训练时不能只喂随机抽的负例——它们与查询差得太远，模型学不到精细判别。标准做法是先用第一阶段检索器捞出「排得靠前但不相关」的段落当负样本，逼模型学会区分「看起来像」和「真的对」。这也是为什么把通用重排器直接用到垂直领域（法律、医疗、代码）收益会打折：它没见过你领域的「看起来像」，困难负样本的分布完全不同，必要时得在你的数据上继续微调。
另一条值得关注的线是蒸馏：用大交叉编码器当老师给海量查询-文档对打分，让双塔学生去拟合老师的分数——把交叉编码器的判别力以知识蒸馏的方式「搬回」双塔，兼得质量与速度。近年来不少嵌入式模型榜单排名的跃升，背后都有这套「重排器教检索器」的流水线。重排与召回不是竞争关系，而是同一条质量流水线上的上下游。
三种架构的取舍可以放进一张表：
| 架构 | 交互时机 | 速度 | 排序质量 | 典型角色 |
|---|---|---|---|---|
| 双塔 bi-encoder | 无（向量点积） | 最快，可 ANN 检索 | 基线 | 第一阶段召回 |
| 晚交互 ColBERT | 延后（MaxSim） | 快，文档可离线预计算 | 接近交叉编码器 | 召回或重排均可 |
| 交叉编码器 | 最早（拼输入） | 最慢，逐对前向 | 最高 | 第二阶段精排 |
2026 年的选型：商用 API、开源权重与 LLM 兼职
重排器在今天已经是一条成熟赛道，选型分三派。
商用 API 以 Cohere Rerank 为代表：2025 年 12 月 11 日发布的 Rerank 4 分为 rerank-v4.0-pro（面向最高质量与复杂场景）与 rerank-v4.0-fast（低延迟高吞吐）两个版本，上下文长度从 3.5 代的 4K 提升到 32K，支持多语言与 JSON 半结构化数据检索，超长文档会自动切分处理。Voyage、Jina 也提供同类托管服务。买 API 的好处是零运维、质量有保障，坏处是每千次查询都花钱、数据要出域。
开源权重 这两年进步飞快。轻量级首选 bge-reranker-v2-m3（BAAI 出品，多语言、易部署、推理快）；要质量可以直接上 Qwen3-Reranker（Apache 2.0 许可，0.6B 与 4B 两档，支持 100+ 语言、32K 上下文），它把重排做成了生成式判断，也是目前开源榜单上的常青树。自建的前提是有 GPU 预算与运维能力，换来的是零调用成本和数据不出域。
LLM 兼职重排 是 2023 年 RankGPT 论文（Sun et al.）带火的路线：不训练任何模型，直接让 LLM 阅读候选列表、输出排序（listwise 排列生成）。候选超过上下文就用滑动窗口从后往前逐窗重排。这条路线的优势是零样本、可利用 LLM 的推理能力处理复杂查询，劣势是延迟和成本都远高于专用小模型，一般只在候选极少、查询极难的场景使用。
| 方案 | 代表 | 成本 | 延迟 | 适用 |
|---|---|---|---|---|
| 商用 API | Cohere Rerank 4 | 按调用付费 | 低 | 不想运维、数据可出域 |
| 开源小模型 | bge-reranker-v2-m3 | 免费，自建 GPU | 低 | 大多数自建 RAG |
| 开源大模型 | Qwen3-Reranker-4B | 免费，GPU 门槛高 | 中 | 质量优先的多语言场景 |
| LLM listwise | RankGPT 式 | 按 token 付费 | 高 | 难查询、小候选集 |
Reranker 救不了你：它的三个边界
重排器常被当成 RAG 提效的万金油，但它有三个明确的失效边界，动手前先对号入座。
第一，召回缺失，重排无力。 重排器只能在召回的候选池里挑最好的，正确的文档如果根本没进 top 100，精排得再好也是从错误答案里选优。2026 年 Atlan 的工程分析把这一点列为重排失效的首因——遇到「召回不行」，该做的是混合检索、调切块或做查询改写（查询侧的优化，本站《一篇读懂查询改写》有专文），而不是加重排器。
第二，延迟与成本随候选数线性增长。 交叉编码器是逐对前向，候选从 50 加到 200，重排耗时也跟着涨三四倍。产品对首 token 延迟敏感时，重排这一段可能比 LLM 生成还贵——这是不少团队先把重排候选砍半、再谈模型升级的原因。
第三，基线已强时收益递减。 如果你的嵌入模型本来就好、查询大多是简单事实型，重排带来的 NDCG 提升可能只有一两个点，却要为此多维护一个模型服务。Meilisearch 的文档里专门列了「什么时候不需要重排」，值得发布前读一遍。先建评测基线（NDCG@10、MRR），量化提升再上重排，而不是因为它流行。
顺手说清这两个指标怎么读。MRR（平均倒数排名）只关心第一条正确答案排第几：排第 1 记 1 分，排第 3 记 1/3，直观衡量「用户第一眼能不能看到对的」。NDCG@10 更精细：它给不同相关等级打不同分，且排名越靠后折扣越大，衡量的是「整个前 10 排得有多准」。重排器的提升通常在这两个指标上最直观——它本来就是干「把对的往前挪」这件事的。评测集要用你自己的真实查询，公开基准的分布和你的业务查询往往是两回事。
落地清单
把上面的分析压缩成一份可执行清单：
- 管线顺序固定为「混合召回 → 重排 → 截断」，召回 50-100 条、输出 5-10 条起步，按延迟预算调；
- 轻量自建选
bge-reranker-v2-m3，质量优先选 Qwen3-Reranker，不想运维选 Cohere Rerank 4； - 重排分数过 sigmoid 后可以当置信度用：设阈值过滤低分候选，比固定条数更稳；
- 上线前用 NDCG@10 建基线，重排的提升必须过评测再上线；
- 召回有问题先修召回，重排不是检索质量的退路。
小结
Reranker 解决的不是「模型不够好」，而是「快和准不可兼得」的结构矛盾：让双塔负责从百万文档里海选，让交叉编码器在几十条候选里终审。ColBERT 的晚交互在中间搭了第三条路，商用 API 与开源权重则把这条管线做成了随取随用的组件。它的边界也同样清楚——召回不行时重排无力，延迟预算紧时重排是奢侈品。把「先评测、再重排」当成纪律，这个组件才会真正替你赚到质量。
参考资料
- ColBERT: Efficient and Effective Search via Lightweight Late Interaction（SIGIR 2020）：晚交互与 MaxSim 的原始论文。
- Using Cross-Encoders as Reranker in Multistage Vector Search（Weaviate）：双塔与交叉编码器取舍的经典工程讲解。
- Refine Retrieval Quality with Pinecone Rerank（Pinecone）：两阶段检索的工程配置参考。
- Introducing Rerank 4（Cohere，2025-12-11）：商用重排器最新旗舰，pro/fast 双版本与 32K 上下文。
- sunnweiwei/RankGPT（GitHub）：LLM listwise 重排与滑动窗口的官方实现。
- BAAI/bge-reranker-v2-m3（Hugging Face）：最常用的轻量开源重排器模型卡。
读者留言
COMMENTS 暂无还没有留言，来说第一句？