Skip to main content

Cross-Encoder 重排序

Written: 2026.06

1. 为什么需要这讲

Reranker(重排器)在本项目的检索链路中是一个关键环节,但主讲义只在第 2 讲和第 7 讲中简要提及。本附录深入讲解它的工作原理、为什么需要它,以及它在本项目中的具体使用方式。

2. 为什么向量检索之后还需要 Reranker

这是很多 RAG 初学者会问的问题:向量检索不是已经按相似度排序了吗?为什么还要再加一层重排? 核心原因:向量相似度 ≠ 相关性。 向量检索(Bi-Encoder)将问题和文档独立编码为向量,然后计算余弦相似度。这很快(可以预先计算所有文档的向量),但存在信息损失——编码时问题和文档之间没有交互。 CrossEncoder 将问题和文档联合输入,让模型同时看到两者,通过 Transformer 的交叉注意力层判断它们是否真正相关。

2.1 一个具体例子

文档 D 原本排第 4,重排后提到第 1。这就是 CrossEncoder 的价值:它在问题和文档之间做了真正的”阅读理解”式的交互判断。

3. Bi-Encoder vs CrossEncoder

4. BGE Reranker Large 模型

本项目使用的重排模型是 BGE Reranker Large(BAAI 北京智源研究院开发),与 BGE-M3 Embedding 模型同属 BGE 系列。
模型特点
  • 输入格式:(query, passage) 对,即问题和候选文档片段拼接为一个序列
  • 输出:一个 0-1 之间的浮点数,表示 relevance(相关性)
  • 中文优化:专门针对中文语义做训练
  • 本地部署:模型文件在 models/bge-reranker-large/,无网络依赖

5. Reranker 在本项目的工作流程

关键实现(qa_core/retrieval/ranking.py):

6. 基于问题类别的 Rerank 策略

并非所有问题都需要 rerank。检索计划会根据问题类型决定是否开启重排:
设计考虑
  • Reranker 是一次额外的模型推理,有计算成本(10-50ms)
  • 对于 FAQ 精确匹配快速路径,不需要 rerank —— 标准答案只有在完全一致时才直出
  • 对于文档 RAG,rerank 的价值最大 —— 能把真正回答问题的文档提到前面

7. Rerank 的成本与收益

实际效果:在 Recall@K 评测中,开启 rerank 后 Top-5 的文档覆盖正确答案的概率从约 85% 提升到约 96%。

8. Reranker 失效场景

Reranker 不是万能的。以下场景即使 rerank 也可能失效:
  1. 知识库本身不包含答案:如果正确答案根本不在 Milvus 里,重排也无法创造信息
  2. Query 改写不充分:如果追问改写后的查询词本身有偏差,reranker 也只能在偏差后的方向上重排
  3. 候选都高度相似时:如果召回的 20 个文档都讨论同一主题,reranker 的区分度会下降
  4. 极短查询:例如”那个呢”——当 query 信息量不足时,reranker 没有足够依据判断
这就是为什么本项目的RAG 回归与入库质量体系是多层的:入库质量 → 意图识别 → Query 改写 → 混合检索 → Reranker → Prompt Profile → 评测回归。每一层解决不同的问题。

9. 本讲小结

  • 向量相似度 ≠ 相关性:Bi-Encoder 快但粗,CrossEncoder 慢但准
  • Reranker 的角色:对向量检索召回的 Top-K 候选做精细重排,把真正相关的文档提到前面
  • BGE Reranker Large:中文优化的 CrossEncoder,本地部署,单次推理 10-50ms
  • 策略化使用:FAQ 快速路径不需要 rerank,文档 RAG 和表格查询需要 rerank
  • 收益:Top-5 文档覆盖正确答案的概率从 ~85% 提升到 ~96%