深挖-重排序

一句话理解

对初检阶段召回的候选结果进行二次排序，将最相关的文档排到最前面，显著提升 RAG 系统的精度和答案质量。

零基础理解

想象你在图书馆查询”人工智能的历史”：

初检（Retrieval）：图书馆员快速浏览书架，抱来 50 本相关书籍。速度很快，但排序粗糙——可能把《AI 简史》和《Python 入门》混在一起。
重排序（Reranking）：一位专家仔细阅读每本书的目录和摘要，重新排列这 50 本书——把真正讲 AI 历史的排前面，把只是顺带提到 AI 的排后面。

重排序在 RAG 中的作用就是这位”专家”——在初检的 50-100 条候选中，用更精准的模型重新打分排序，最终只把 Top-5 或 Top-10 送给 LLM 生成答案。

核心概念

两阶段检索 (Two-Stage Retrieval)

现代 RAG 系统的标准架构：

用户Query
  │
  ▼
┌─────────────────────────────┐
│  第一阶段：初检 (Retrieval)   │
│  - Bi-Encoder / Embedding    │
│  - 速度快，覆盖面广           │
│  - 召回 Top-K (50-1000 条)   │
└──────────────┬──────────────┘
               │
               ▼
┌─────────────────────────────┐
│  第二阶段：重排序 (Reranking) │
│  - Cross-Encoder / LLM      │
│  - 速度慢，精度高             │
│  - 精排 Top-N (5-20 条)      │
└──────────────┬──────────────┘
               │
               ▼
         送给 LLM 生成答案

Cross-Encoder vs Bi-Encoder

这是理解重排序最核心的技术对比：

维度	Bi-Encoder	Cross-Encoder
原理	分别编码 query 和 document，然后算余弦相似度	将 query 和 document 拼接后一起编码，输出相关性分数
速度	快（文档向量可预计算）	慢（每个 query-doc 对需重新推理）
精度	中等	高（捕捉 query-doc 交互信息）
适用阶段	初检（海量候选）	重排序（少量候选）
典型模型	bge-large, text-embedding-3	bge-reranker, Cohere Rerank
时间复杂度	O(1) 每文档（向量已缓存）	O(N) 每文档，N 为候选数

重排序的代价

延迟增加：重排序阶段通常增加 50-500ms 延迟
计算成本：Cross-Encoder 推理比向量相似度计算贵 10-100 倍
候选数量限制：通常只重排 Top-50 到 Top-200，不能对全量文档做重排序

2026 年主流重排序方案对比

方案	类型	开源	延迟 (单条)	精度	多语言	成本	适用场景
Cohere Rerank 3	商业 API	否	~50ms	高	是 (100+ 语言)	按调用付费	英文、快速上线
bge-reranker-v2	Cross-Encoder	是	~30ms	高	中英为主	自部署 GPU	中文场景首选
ColBERT	延迟交互	是	~100ms	很高	取决于基座	自部署	极致精度，学术场景
RankLLM	LLM 直接排序	是	~500ms-2s	最高	是	高 (GPU 需求大)	复杂查询、极端精度
Cross-Encoder (vanilla)	标准 CE	是	~20ms	高	取决于基座	自部署	通用，资源充足时
LLM-based Listwise	LLM 列表式	部分	~1s-5s	最高	是	很高	对精度要求极高的场景

选型建议

按语言

场景	推荐方案	理由
中文为主	bge-reranker-v2-m3	BAAI 出品，中文效果验证充分
英文为主	Cohere Rerank 3	效果好，API 成熟
多语言混合	Cohere Rerank 3 或 bge-reranker-v2-m3	两者都支持多语言
中日韩	bge-reranker-v2-m3	对东亚语言优化更好

按场景

场景	推荐方案	理由
快速原型	Cohere Rerank 3 API	一行代码，不用部署
生产环境、数据安全	bge-reranker-v2	开源，本地部署
学术研究、极致精度	ColBERT 或 RankLLM	精度最高
复杂推理查询	RankLLM	LLM 的理解能力覆盖复杂语义
低延迟要求	vanilla Cross-Encoder	模型小，推理快

什么时候需要重排序

情况	是否需要重排序	说明
初检 Top-3 就满足了需求	不需要	重排序不会带来明显增益
初检结果混乱，相关信息分散在 Top-20	需要	重排序把相关文档提到前面
多语言查询	需要	初检的 Embedding 可能不够精准
复杂查询，含多条件约束	需要	简单的向量相似度难以捕捉复杂意图
文档间区分度低	需要	Cross-Encoder 能捕捉细微差异
延迟预算 < 100ms	谨慎	重排序增加延迟，需权衡
候选数 > 1000	需要	先粗筛再精排，性价比最高

2026 年推荐策略

实用组合推荐：

初检: Embedding 模型 (bge-large 或 Cohere embed)
  → 召回 Top-100
  → 重排序: bge-reranker-v2 (中文) / Cohere Rerank 3 (英文)
  → 取 Top-5 送 LLM

这套组合在大多数 RAG 场景中能达到较高的精度-延迟平衡点。

前沿方向

LLM 直接重排序：利用 GPT-5.5、Claude Opus 4.8 等大模型直接对候选列表打分，精度最高但成本也最高。适合对答案质量要求极高的场景。
多目标重排序：同时优化相关性、多样性、时效性等多个目标
端到端训练：将初检和重排序联合训练，减少两阶段的信息损失
在线学习：根据用户点击反馈实时调整重排序参数

来源

Cohere Rerank 文档: https://docs.cohere.com/docs/rerank-2
BAAI bge-reranker GitHub: https://github.com/FlagOpen/FlagEmbedding
ColBERT 论文: “ColBERT: Efficient and Effective Passage Search via Contextualized Late Interaction over BERT” (SIGIR 2020)
ColBERT v2: https://github.com/stanford-futuredata/ColBERT
RankLLM: https://github.com/castorini/rank_llm
“Reranking in RAG” 系列文章 (Pinecone Blog, LlamaIndex Blog)