重排序（Reranking）
重排序是检索的最后一道精排——从初筛结果中挑出真正最相关的内容。它是 RAG 链路中性价比最高的优化步骤之一。
① 一句话定义
重排序（Reranking）是在初检索（如向量搜索返回Top-50）之后，用一个更精准但更慢的模型对这50个候选进行二次排序，最终选出Top-5或Top-10送给LLM。初检索追求"快"（从百万中筛50个），重排序追求"准"（从50个中挑最好的5个）。
② 为什么重要
向量检索的排序不一定是最优的——高维空间中的"最近邻"不一定等于"最相关"。重排序模型（通常是Cross-Encoder）会把查询和每个候选文档拼接后一起编码，做深度的语义匹配，比点积相似度准得多。在几乎所有RAG评测中，加Reranking比不加Reranking效果显著提升——而且成本不高（只对Top-50做Rerank，不是对全部文档）。
Reranking 可能是整个 RAG 链路中 ROI 最高的优化。它只需对几十个候选做一次重排，就能显著提升最终回答质量。
③ 核心机制
向量检索用 Bi-Encoder（查询和文档分别编码，通过向量点积算相似度）——速度快但匹配粗糙。重排序用 Cross-Encoder（查询和文档拼接后一起编码）——速度慢但匹配精准。常用的 Reranking 模型：Cohere Rerank、BGE-Reranker、Cross-Encoder。实现很简单——在检索和生成之间插入一个 Rerank 步骤，对检索返回的 Top-K 重新打分排序，取 Top-N 送给 LLM。
④ 典型应用场景
几乎所有需要精确检索的 RAG 场景都应该加 Reranking。典型配置：初检索返回20-50个候选 → Reranker精排 → 取Top-5送LLM。
⑤ 常见误区
误区：Reranker 能替代好的初检索——不能。初检索决定了候选池的上限，Reranker 只是从中择优。初检索漏掉的信息，Reranker 永远找不回来。两者是"海选"和"决赛"的关系，不是替代关系。
更多
招聘面试——HR 筛 50 份简历，部门经理精挑 5 份进面试。
初检索（向量搜索）= HR 每天收 1000 份简历，快速扫一遍，挑出 50 份"看起来相关"的——这个阶段追求速度，允许漏掉一些（反正后面没人能看到这 1000 份全部）。但 HR 的筛选是粗糙的——她可能看到简历里有"Python"就标记相关，不管这人是写了十年 Python 还是只在课程作业里用过一次。
重排序（Reranking）= 部门经理拿到这 50 份，花时间认真读每一份——分析项目经验和技术栈的匹配度、看具体贡献、评估文化契合度。最后挑出 5 份最合适的进入面试。部门经理的评估比 HR 精准得多（Cross-Encoder 做深度匹配），但他不可能把 1000 份全看一遍（速度慢）。HR 筛 + 经理精挑 = 快且准。这就是"初检索+重排序"的组合。
「重排序是 RAG 最后一道质量关口——用最小的成本（只多了一个 API 调用）换取最大的质量提升（从50个候选中挑出真正最好的5个）。不做 Reranking 的 RAG，是在用粗糙检索的排序直接喂给 LLM——等于让 LLM 自己在一堆半相关的信息里挑重点。
」