这篇学完你能回答什么
- 「有了向量检索为什么还要 Rerank？」
- 「双塔（bi-encoder）和交叉编码器（cross-encoder）差在哪？为什么不直接用 cross-encoder 检索全库？」——这是最能筛掉背题选手的一问。
- 「Rerank 加在哪一步？top-k 怎么配？」
从一个真实故障讲起
你的知识库问答系统，用户问「售后维修返厂需要垫付运费吗」。你打日志一看：正确答案确实被检索到了，排在第 14 位。 而你的 prompt 只塞前 5 条——答案就在候选里，却被你自己扔掉了。
这类 badcase 有个共同特征：召回没问题，排序有问题。 加大 top-k 到 20 呢？上下文塞爆了，而且塞进去一堆噪音，模型反而更容易失焦（context rot，见 T1-3）。
于是问题变成：怎么在有限的名额里，把最相关的那几条准确地顶上来？ 这就是 Rerank 要干的活。
用户提问
「售后维修返厂需要垫付运费吗」
检索召回
打日志一看，正确答案确实被检索到了
它排在第 14 位断点
而 prompt 只塞前 5 条
答案被扔在名额外
「答案就在候选里，却被你自己扔掉了」
核心概念：召回要「全」，排序要「准」
这是检索系统的经典分工：
第一阶段（召回 / Retrieval）：从百万文档里快速捞出 50–100 个候选，目标是不漏（recall）。 第二阶段（精排 / Rerank）：对这几十个候选精细打分，选出最好的 5–10 条，目标是准（precision）。
一句话记住：召回负责别漏掉，精排负责别排错。 面试时用这个对仗句开场，比讲一堆模型名字有效。
先把可能有用的都捞上来
捞得再全，也不保证最相关的那条排在前面
Retrieval
从百万文档里快速捞出 50–100 个候选，目标是不漏
在捞上来的这几十条里排名次
只在候选里挑 —— 绝不对全库重排
Rerank
对这几十个候选精细打分，选出最好的 5–10 条，目标是准
原理拆解：双塔 vs 交叉编码器
- Bi-Encoder 双塔query / doc 各自编码 → 算余弦相似度
- ColBERT 后期交互doc 存一组 token 级向量，细粒度匹配
- Cross-Encoder 精排
[query + doc]→ 全交叉注意力 → 分数
| 阶段 | 谁来算 | 候选数 | 代价 |
|---|---|---|---|
| 第一阶段 · 召回 | 双塔，doc 向量已离线算好 | 百万 → 50~100 | 百万级语料上毫秒级 |
| 第二阶段 · 精排 | 交叉编码器，query 来了才能算 | 50~100 → 5~10 | 重排 50 条多几十到几百毫秒 |
| 假如全库跑精排 | 交叉编码器，无法离线预计算 | 100 万篇全打分 | 跑 100 万次模型推理，延迟与成本不可行 |
完整回答分三层：机制差异（独立编码 vs 联合编码）→ 工程后果（可预计算 vs 不可预计算）→ 架构结论（两阶段是成本约束下的必然）。能答到第三层的人不多。
双塔的代价说具体点：每篇文档被压成一个固定向量，压缩时丢掉的信息再也找不回来 —— 它只判断「这两段话大体上像不像」，判断不了「这段话到底回不回答得了这个问题」。
这是本篇的核心，也是追问必到之处。
双塔（Bi-Encoder）——你的 embedding 模型
query 和 document 各自独立编码成向量，再算余弦相似度：
query ──► [编码器] ──► 向量A ─┐
├──► 余弦相似度
doc ──► [编码器] ──► 向量B ─┘关键特性：doc 的向量可以离线预先算好存起来。查询时只需编码 query 一次，剩下的就是纯向量检索——所以能在百万级语料上做到毫秒级。
代价：query 和 doc 在编码时从未见过对方。每篇文档被压缩成一个固定向量，压缩过程中丢掉的信息再也找不回来。它只能判断「这两段话大体上像不像」，判断不了「这段话到底回不回答得了这个问题」。
交叉编码器（Cross-Encoder）——Rerank 模型
把 query 和 document 拼在一起送进模型，让注意力机制在两者之间充分交互，直接输出一个相关性分数：
[query + doc] ──► [编码器 + 全交叉注意力] ──► 相关性分数
关键特性：没有压缩、没有近似，模型能看到「问题里的『垫付』和文档里的『先行支付』是一回事」这种细粒度对应关系。精度显著高于双塔。
代价：没法预计算。因为分数依赖 query-doc 这一「对」，query 来了才能算。要给 100 万文档打分，就得跑 100 万次模型推理。
于是答案自明了
为什么不直接用 cross-encoder 检索全库？ 因为它的计算量正比于候选数量，且无法离线预计算。全库跑一遍在延迟和成本上完全不可行。所以工程上必须两阶段：用便宜的双塔把范围从百万缩到一百，再用昂贵的交叉编码器在这一百里精挑。
这个回答的完整版本包含三层：机制差异（独立编码 vs 联合编码）→ 工程后果（可预计算 vs 不可预计算）→ 架构结论（两阶段是成本约束下的必然）。能答到第三层的人不多。
第三条路：ColBERT 式后期交互
介于两者之间：文档预先编码成一组 token 级向量（不压成单个向量），查询时做细粒度的 token 匹配。精度接近 cross-encoder，又保留了部分预计算能力。代价是存储开销大得多。知道它的存在和定位即可，属于加分项。
工程实践（截至 2026-08）
标准配置：
query → 混合检索召回 top 50~100 → Rerank → top 5~10 → 组装 prompt → LLM
一条铁律：永远只对 top-k 候选重排，绝不对全库重排。 候选数超过一千，纯 cross-encoder 的延迟会急剧恶化。
模型选型（生态变化快，具体请以最新榜单和模型卡为准）：
| 场景 | 常见选择 | 备注 |
|---|---|---|
| 通用默认 / 自托管 | bge-reranker-v2-m3（约 567M，Apache 2.0） | 多语言、生态支持最广，性价比基准线 |
| 中文高精度 + 可商用 | Qwen3-Reranker 系列（0.6B–8B） | 精度高，部署成本也高 |
| 免运维 | Cohere Rerank / Voyage 等 API | 不想维护 GPU 时的省事选择 |
| token 级交互 | ColBERT v2 | 大候选集下比纯 cross-encoder 更扛延迟 |
| 大批量 | listwise 重排模型（一次给多篇打分） | 2026 年的新架构方向，成本更友好 |
两个能直接踩雷的点：
- 许可证：部分高分重排模型（如 Jina 的某些版本）是 CC-BY-NC-4.0，未经授权商用即侵权。企业项目优先选 Apache 2.0 的模型。这和 T2-3 里 embedding 的坑是同一个，面试时提一句显得很有工程意识。
- 别盲目追大参数：4B 模型精度高但部署成本可能是 567M 模型的数倍。通用中文 FAQ 场景，小模型往往就够——先用评测集确认精度差值，再决定值不值这个钱。
其他实践细节：
- query 和 doc 的顺序不能反。多数 cross-encoder 是非对称的，query 放前面，放反了掉点。
- 延迟预算要算清：重排 50 条会增加几十到几百毫秒（取决于模型和硬件）。对话式产品要评估用户能否接受，必要时降低候选数或换轻量模型。
- LLM 做 rerank 也可行（直接让大模型给文档打分排序），精度可能更高，但速度和成本明显劣于专用重排模型——适合质量优先、量不大的场景。
- 一定要 A/B 验证：Rerank 通常是 RAG 里投入产出比最高的单项升级，但收益幅度高度依赖你的语料。用自己的评测集测 NDCG@10 / Recall@5 的提升，别照搬博客里的数字。
top 50~100 → top 5~10；重排 50 条要多付几十到几百毫秒| 场景 | 常见选择 | 备注 |
|---|---|---|
| 通用默认 / 自托管 | bge-reranker-v2-m3（约 567M，Apache 2.0） | 多语言、生态支持最广，性价比基准线 |
| 中文高精度 + 可商用 | Qwen3-Reranker 系列（0.6B–8B） | 精度高，部署成本也高 |
| 免运维 | Cohere Rerank / Voyage 等 API | 不想维护 GPU 时的省事选择 |
| token 级交互 | ColBERT v2 | 大候选集下比纯 cross-encoder 更扛延迟 |
| 大批量 | listwise 重排模型（一次给多篇打分） | 2026 年的新架构方向，成本更友好 |
- 标准配置
query → 混合检索召回 top 50~100 → Rerank → top 5~10 → 组装 prompt → LLM- 一条铁律
- 只对 top-k 候选重排，绝不对全库重排；候选数超过一千，纯 cross-encoder 延迟急剧恶化
- 许可证
- 部分高分重排模型（如 Jina 的某些版本）是 CC-BY-NC-4.0，未经授权商用即侵权；企业项目优先 Apache 2.0
- 别盲目追大参数
- 4B 精度高，部署成本可能是 567M 的数倍；通用中文 FAQ 小模型往往就够，先用评测集确认精度差值
- 顺序不能反
- 多数 cross-encoder 是非对称的，query 放前面，放反了掉点
- 延迟预算
- 重排 50 条增加几十到几百毫秒（看模型和硬件）；扛不住就降候选数或换轻量模型
面试视角
- 对仗句开场「召回求全、精排求准」
- 讲机制差异独立编码 vs 联合编码
- 落点在预计算doc 向量能离线算好 vs query 来了才能算
- 给配置和数字
top 50~100→top 5~10 - 补代价与评测延迟多几十到几百毫秒，提升用评测集测
- 只说「rerank 能提升效果」，讲不出机制原因 —— 一追就穿
- 把两者的差别说成「一个快一个准」就结束了
- 答不出「为什么不全库跑 cross-encoder」，只会说「太慢」
- 报不出 top-k 数字，也不知道候选过千会发生什么
- 整个方案里只有精度一项，不提许可证也不提延迟
- 开口就是「召回求全、精排求准」，先把分工摆清楚
- 落点在能不能预计算：doc 向量离线算好，query-doc 对只能现算
- 算给面试官听：全库要跑 100 万次推理，所以先把百万缩到一百
- 给得出
top 50~100 → top 5~10，知道过千延迟急剧恶化 - 主动提 CC-BY-NC-4.0 不能商用、query 必须放前面这类细节
Q2-11、Q2-12；相关 Q2-10（融合）、Q2-15（评测）。小结与延伸
一句话总结：双塔快在能预计算，交叉编码器准在能全交互——一个不能又快又准，所以工程上用两阶段各取所长：先粗筛百万到百，再精排百到十。
下一篇 T2-7：用户的问法和文档的写法对不上怎么办——查询改写、扩展与路由。
继续深入
本篇归属第 2 章「RAG 工程化」，去做这一章的题。