什么是 RAG 中的 Rerank？从原理到实战的完整指南
Rerank 是 RAG 系统中连接检索与生成的关键桥梁——用更精细的语义分析，把真正相关的文档排到最前面。
引言
在 RAG（检索增强生成）系统中，有一个经常被忽视却至关重要的环节——Rerank（重排序）。简单来说，它就是在向量检索"粗筛"出一批候选文档后，再用一个更精细的模型对这些文档重新打分排序，把最相关的排到前面，喂给 LLM 生成高质量回答。
很多开发者搭建 RAG 系统时，只关注 Embedding 模型和向量数据库，却忽略了检索与生成之间这道"质检"工序。结果往往是：召回率看起来不错，但 LLM 的回答总是跑偏或产生幻觉。引入 Rerank 后，检索准确率通常能提升15%–30%，在生产环境里是非常显著的提升。
| 指标 | 数值 |
|---|---|
| 检索准确率提升 | 15–30% |
| 额外延迟成本 | 50–200ms |
| 精排后保留文档数 | Top-3 |
为什么向量检索不够用？
要理解 Rerank 的价值，首先要看清向量检索的局限性。
向量检索基于Bi-Encoder（双编码器）架构：Query 和 Document 分别通过同一个 Embedding 模型编码成向量，然后用余弦相似度计算匹配度。这种"各编各的"的方式，带来了三个核心问题：
- 语义鸿沟：Query 通常只有几个词，而 Document 可能有几百上千词，两者的语义空间天然不对齐。向量相似度高的文本片段，实际语义相关性可能并不强。
- 细粒度关系缺失：“不推荐这款手机"和"推荐这款手机”，Bi-Encoder 可能觉得语义相近，但意思截然相反。它无法捕捉否定词、时间限定等细节。
- 多义词消歧能力弱："苹果"是水果还是公司？Bi-Encoder 缺乏上下文，难以准确区分。
但 Bi-Encoder 的优势也很明显——快。Document 向量可以预计算存储，检索时只需编码一次 Query 再做相似度查找，适合在全量文档库中快速召回候选。
所以工业界的思路很清晰：用 Bi-Encoder 做快速粗筛，再用 Cross-Encoder 做精准重排，两阶段各取所长。
Rerank 的核心原理：Cross-Encoder
Rerank 之所以能做出比向量检索更精准的判断，关键在于它采用了Cross-Encoder（交叉编码器）架构。
Cross-Encoder 把 Query 和 Document 拼接在一起（[CLS] Query [SEP] Document），作为一个整体送入 Transformer 做联合编码。每一层注意力机制都让 Query 中的每个词和 Document 中的每个词充分交互，从而捕捉到 Bi-Encoder 根本看不到的细粒度匹配模式。
两阶段检索架构（文字描述）：
[Bi-Encoder 粗筛] Query + Doc1/Doc2/.../DocN → Encoder → 向量相似度 → Top-20 候选 ↓ [Cross-Encoder 精排] Query+Doc1, Query+Doc2, ..., Query+DocN → Cross-Encoder → 相关性分数 → Top-3 精排结果 ↓ [喂给 LLM]两种架构的对比用表格看得更清楚：
| 维度 | Bi-Encoder（粗筛） | Cross-Encoder（精排） |
|---|---|---|
| 速度 | 快（毫秒级） | 较慢（百毫秒级） |
| 精度 | 中等 | 高 |
| 处理范围 | 全量文档库（百万级） | 候选集（20–50 条） |
| 计算方式 | Query 和 Doc 分别编码 | Query 和 Doc 拼接联合编码 |
| 交互方式 | 无交互，各编各的 | Token 级深度交互 |
| 角色 | 召回（Recall） | 精排（Precision） |
关键洞察：Cross-Encoder 的优势在于 Attention——Query 的每个 Token 都能 attend to Document 的每个 Token。这意味着它能识别"这款手机不推荐"里的否定词，而 Bi-Encoder 很可能把这句话和"推荐这款手机"打成差不多的相似度。
Rerank 的工作流程
Rerank 在 RAG 流水线中的位置非常明确—
)
)