重排

它是什么

重排是在第一阶段快速召回一批候选之后，用一个更精细的模型重新计算「查询与每条候选的相关程度」，然后重新排序、并截取一个更小的结果集。

它是检索链路里的第二段，职责单一：在已经拿到的候选里，决定谁排前面、谁被丢掉。 它不生成内容，不改写候选，也不去别处找新的证据。

为什么需要它

因为第一阶段和最终需求之间有一处根本矛盾：第一阶段怕漏，所以要多要快；而上下文窗口很小，最终只能装几块。

第一阶段的检索为了速度和覆盖，通常用「查询向量 vs 文档向量」这种各自独立编码的方式——它快，但比较粗：查询里那些限定词、否定、多个条件的组合，很容易被压成一个平均印象。于是候选集里混进噪声是常态。

重排允许你只在这批候选上花大钱：一次比较查询和一条候选的内容，判断得更细。花销可控（候选就几十条），收益却很直接——上下文里装的几块，从『大概相关』变成『确实相关』。

它如何工作

流程是：检索器先返回较大的 Top-K → 重排模型对每条候选重新打分 → 按新分数排序 → 截取更小的 Top-N 送进上下文。

两种典型的打分方式（机制上代表两个方向）：

• 把排序变成一个生成/分类问题：让模型直接读「查询 + 候选」，输出一个相关性判定或分数。这条路线把预训练模型直接改造成排序器，实现简单、效果稳定。
• 延迟交互（late interaction）：查询和文档各自保留每个 Token 的向量，在最后一步才做细粒度的交互匹配。它的取舍是——比「各自压成一个向量」精确得多，又比「查询文档完全合并编码」便宜得多，落在两者的中间。

无论哪种，都有一个共同规律：越精细 → 延迟越高、成本越高。 所以重排天生是「在候选小集合上用贵模型」的活儿，把它用在第一阶段的位置上是错的。

必须澄清的误会

重排 ≠ 检索。 两段的分工是先宽后准：检索负责不漏，重排负责排准。这条分工带来一个必须记住的推论——第一阶段没召回到的东西，重排一条都补不回来。 所以「上线重排之后效果还是不好」时，第一件该查的事不是重排模型，而是第一阶段到底有没有把正确答案召回到候选里。这就是为什么要先看召回率，再看排名。

重排 ↔ Top-K 是一对要一起调的参数。 K 是第一阶段交出来的候选数量。K 太小时，重排手里没有可挑的东西——正确答案压根不在里面；K 太大时，延迟和成本按条数增长，而收益很快饱和。很多「重排没效果」其实是 K 给得太小，重排在为一个已经漏掉的候选集排序。

重排不能修正内容。 如果切片把「例外条款」切到了另一块里，重排会把这条残缺的规则排到第一位——它按「相关」排序，不按「正确」排序。上游问题必须在切片那一层解决。

重排不是必选项。 候选本来就少（比如就三五条）、或者第一阶段已经足够准的场景，加上它只是徒增延迟。它值得上的信号很具体：候选多、上下文紧、而且你观察到「正确的片段在候选里但排得很靠后」。

真实例子

用户问「取消订单后多久到账」。第一阶段的向量检索召回了三块：「取消订单流程」「退款到账时效」「账户注销说明」。

它们都含有「取消」或「退款」这类词，向量上都很接近——单靠向量相似度，三者难分高下，排序往往取决于谁的字面更巧。

重排器的优势在这里显现：它会把整句问题（尤其是「多久到账」这个真正的诉求）与每条候选细读比较，于是「退款到账时效」被排到第一位，而讲流程和讲注销的两块被压下去。

注意成功的条件：正确答案必须在第一阶段就已经在候选里。这个例子里它在了——如果第一阶段只召回了前两块，重排再强也只会从前两块里挑一个。

什么时候适合与不适合

适合：候选相似度高、上下文预算紧、答案质量值得多付一点延迟的任务。判断信号是「你在评测里看到：正确答案被召回了，但排位靠后」。

不适合：候选本来就很少；或者第一阶段就没召回正确答案（这时该改的是切片、嵌入或加上关键词路，不是加一个重排器）。也别忘了它是要花钱的：多一次模型推理，延迟和成本都涨——上线前应该拿评测数据回答「这多出来的延迟，换回了多少排名提升」。

一个实用的验收方式：重排前后各跑一遍评测集，比较的不只是准确率，还有延迟和单次成本。 只有准确率提升、成本翻倍的改动，未必值得上。

亲自试一下

把检索器返回的前 20 条候选存下来，人工标注每一条到底相不相关——这一步比调参更值得花时间，因为它是后面所有结论的基准。

然后跑一次重排，比较前后前三名的变化。

全程约 25 分钟。观察点是两件事：正确答案在不在前 20 里，以及它重排后排到了第几。 分三种情况读结果：

• 不在前 20 里 → 问题在第一阶段，重排帮不了你。
• 在前 20 但排在第 10 名左右、重排后进前三 → 这正是重排的适用场景。
• 本来就在前三 → 这个场景不需要重排，加它只是加延迟。

顺手记下新增的延迟和单次成本，这两个数字通常会决定它能不能上线。

接下来学什么

重排是第 3 站 给知识 · 怎么让它知道你家的资料 的第二段，也是候选进入上下文之前的最后一道筛选。

顺着这条链路往前：上游是 文档切片、嵌入、向量数据库 与 检索；重排之后，候选会连同来源一起进入 RAG 的生成阶段。要理解「重排取几块」这条边界，读 Top-K 与 上下文窗口。

判断「该不该上重排」，去第 7 站 给判断：没有评测集，你无法区分「排名变好了」和「只是顺序变了」。

来源与修订

「把预训练序列到序列模型改造成相关性排序器」这条路线参考 Document Ranking with a Pretrained Sequence-to-Sequence Model（arXiv 2003.06713）；「查询与文档各自保留 Token 级表示、最后再做细粒度交互」这条延迟交互路线参考 ColBERT（arXiv 2004.12832）。两篇分别代表「重新打分」和「细粒度交互」两个方向，是重排这个概念的原始来源。

一处边界要说明：具体用哪个重排模型不是定义的一部分。 本文只讲机制与取舍，是否采用、用哪一种，应由端到端评测（准确率 + 延迟 + 成本）决定——把它写死成某个模型名，是这个词条最容易过期的地方。

修订日期 2026-09-19：本条由生成模板改为决策页——补「必须澄清的误会」一节（对检索、对 Top-K），把「正确答案在不在候选里」写成可操作的三分支判断，去掉生成期的引用标记，补 boundaries 与 minAction。