什么是 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-EncoderRerank 之所以能做出比向量检索更精准的判断，关键在于它采用了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 流水线中的位置非常明确—