什么是重排序模型？检索结果的质检员

用秘塔AI搜索查一个问题，排在前面的结果往往比后面贴题得多，这不是运气。检索系统内部有一道「终面」工序：海选出的候选结果，由重排序模型逐一细看、重新排座次。它是检索链路上最后一道质检，也是搜索体验好坏的分水岭。

类比招聘：HR 先用关键词从上千份简历里筛出 50 份（召回），业务面试官再对这 50 份逐份深谈，挑出真正合适的人选并排出顺序（精排）。面试官眼光准，但一个人一天面不了几千人，所以只能面筛过的那批。

类比失效的地方：面试官的经验可以跨行业迁移，重排序模型却只认它被训练过的那类「问题与文档的配对」，换一种语言或领域，表现可能明显下滑，选型时不能想当然。

两段式检索：先海选，再精排

主流检索系统分两步走。第一步用嵌入模型把查询和全部文档快速比对，从几十万条里捞出几十条候选，讲究快；第二步由重排序模型把查询和每条候选配对细算相关度，讲究准。前者解决「别漏」，后者解决「别排错」。

两步走的分工，落到工作量和成本上是这样。

能带走的判断：搜索结果质量差，原因可能在任何一段。候选都没捞到，是召回的问题；捞到了却排得很靠后，才轮到精排背锅。先分清是哪一段的问题，再谈改进。

它和嵌入模型的分工与配合

两者常被放在一起比较，其实是一条流水线上的前后工序。嵌入模型把文本压成向量，比对速度极快，但压缩必然丢信息，排序只能算粗排；重排序模型不走向量压缩，直接对「查询—文档」这一对文本做精细打分，更准也更慢。

所以它只被用在候选已经很少的阶段：几十条逐一打分可行，几十万条就撑不住了。想弄懂前一道工序怎么工作，看站内嵌入模型一文。

成本账：为什么只排前几十条

精排的计算量与「查询数 × 候选数」成正比。一次查询配 50 条候选是 50 次精细打分，配 5000 条就是 5000 次。工程上默认只对召回的前几十条精排，因为收益最大的头部结果已经覆盖，再往后排用户根本看不到，白花算力。

同样的账在自建知识库时也要算：数据量小、问答场景简单，先用向量检索往往就够；发现「文档明明在库里却总排不到前面」，再考虑加一道精排工序。

普通用户和自建者分别怎么用上它

普通用户感知不到它的存在，但选产品时可以留意：搜索类产品对「排后面的结果也相关」的处理能力，多半有精排的功劳。自建者的路径清晰得多：扣子这类编排平台里，可以把检索环节配成「召回加重排」两步，纳米AI等产品也在把这类能力产品化，具体支持以各自文档为准。

模型本身可以去模型仓库找，开源的重排序模型按语言和体积分档，社区还有给它做的轻量微调版本，几十兆的 LoRA 文件是怎么起作用的，见站内LoRA 模型文件一文。精排的思想也不只用于搜索，推荐和问答改写里同样能看到，思路相通。

召回与精排对照表

• 召回（嵌入模型）：快、粗、覆盖全，从海量文档里捞候选；
• 精排（本文主角）：慢、细、只看头部，给候选排出最终名次；
• 排错症状：捞不到，查召回；捞到排后面，查精排；
• 记一句：先海选后终面，两道工序各管一段，混着看只会白费算力。

读者对重排序模型的常见疑问

• 不用它，只靠向量检索行不行？：数据量小、要求不高时可以，排序的精细度会打折扣，加不加看你对头部结果准确度的要求。
• 它会让搜索明显变慢吗？：只对几十条候选打分时延迟很小，若把候选规模放开到成千上万，等待时间就能感知到了。
• 它和嵌入模型能互相替代吗？：不能，向量检索负责快速海选、它负责精细终面，一快一细，配合使用才兼顾速度和质量。