重排序（Reranking）

一句话定义：检索的两段式第二步。先用一种快到能扫全库的方法做粗筛（Fast Search），把大量文档缩成一份候选短名单（Shortlist）；再让模型把查询与短名单里每一个候选逐对（Pairwise）判断，按分数重新排序，把真正对的顶到前面。

1. 核心要点

1.1 为什么要分两步

逐条把全库文档和查询比一遍，一行一个比较——百万文档就是每查询百万次比较。两段式的做法是：① 用快到能在全库跑的方法，把库缩成一份”可能有戏”的短名单；② 在这份短名单上跑一个更准的步骤，找出唯一正确的那个。

1.2 粗筛负责”召回”，重排负责”排序”

快速搜索（Fast Search）是任何能对全库快速返回带排名短名单的方法：关键词搜索（BM25）、稠密向量（Dense Embeddings），或两者结合。官方这一步只用 BM25，故意保持简单，好把注意力留给重排。

“Fast search is good at that, but it can’t tell you which candidate on the shortlist is correct. That’s where re-ranking comes in.” 译：快速搜索擅长缩小范围，但它分不清短名单里哪个候选才是对的。这正是重排序登场的地方。

“Re-ranking takes the shortlist fast search already produced and puts it in a better order. Instead of comparing the query against the whole corpus at once, it compares the query against each candidate on the shortlist individually, and sorts the shortlist by that score.” 译：重排序接过快速搜索已经产出的短名单，把它排成更好的顺序。它不是一次把查询和整个语料比，而是把查询和短名单上的每个候选单独比，再按这个分数给短名单排序。

关键性质：重排只能重排已经进入短名单的候选，加不进粗筛漏掉的东西。

1.3 官方 CLERC 法律检索示例

数据集：CLERC，3,565 条美国法庭意见段落，40 个查询（Query）；170 行文本池成一个共享语料，其中 130 行只作为候选出现，不参与评估。设置：BM25 为每个查询选 30 个候选（TOP_K = 30），Jev 负责重排。

重排问题是一道是非题（Noul）：“这段候选是否可能来自被引用的先例？“返回 0–1 的 noul 作为分数（示例：0.87 / 0.41 / 0.12），再按分数从高到低排序。

结果：

指标	仅快速搜索	+ Jev 重排
正确答案排第 1（Top-1）	5%	18%
进前 5（Top-5）	15%	35%
进前 10（Top-10）	38%	62%

一个关键细节：BM25 的短名单在 40 个查询上 100% 都包含正确答案，但正确答案排第一的只有 5%——粗筛的召回没问题，排序才是瓶颈。

成本：1,200 次调用（40 查询 × 30 候选），用了 1,536,002 个输入词元、25,200 个输出词元，共花 **$0.0645\ast \ast （模型‘jev-1.12‘，输入$0.042/百万词元）。

“That noul is the score the application sorts on.” 译：那个 noul 就是应用程序用来排序的分数。

官方还提醒：这里为了讲清楚，每个候选只问了一个问题；真实应用应该在一次调用里对同一个候选问好几个问题（见投机式扇出）。

1.4 第三方发现：分类准确率高 ≠ 排序有用

独立项目 jev-orderby-bench 专门检验”在 Jev 的概率上做 ORDER BY 是否站得住”，预先登记了一套门槛（配对反转、Score 序数性、校准、否定与改写的结构不变式），结论是分裂的：

• 在 20 Newsgroups 主题归类（Topic Membership） 上，jev-1.13.0 通过；
• 在 Amazon ESCI 人工评分的商品相关性（Product Relevance） 上，6 项检验有 4 项不通过。

另外两个尖锐发现：

• 请求形态会改变数字：把 40 行打包成一次批处理请求，会让”每行一次请求”时通过排序门槛的结果变为不通过。
• 两位小数的输出会造成并列：360 行里有 53 行在最上面并列，LIMIT k 会直接切进一组并列里。

社区精选清单的总结很直白：

“Classification accuracy alone does not establish that ORDER BY on a probability is useful.” 译：单凭分类准确率，并不能证明对概率做 ORDER BY（排序）是有用的。

2. 与 Jev 的关系

• 重排序是 Jev 的天然主场：它的 Noul 直接输出 0–1 的分数，不需要为一个通用 LLM 发明评分刻度，也不容易”同一对候选调两次得到两个分数”。
• 逐对判断把”哪个最相关”这种大问题拆成一堆原子是非判断，符合官方”大问题拆小、在代码里组合”的原则——见 模型与框架分责。
• 短名单把喂给模型的上下文压到最小，正好规避 上下文腐坏。
• 但排序必须当成排序来测：第三方结果说明，主题归类这种”分类题”通过，不代表商品相关性这种”排序题”也通过。这属于 评测污染 之外的另一类陷阱——测错了对象。

3. 相关来源

• 官方文档 cookbooks__rerank_typesafe.md —— CLERC 完整代码、Top-1/5/10 数字、1,200 次调用成本与 Noul 评分示例
• 社区精选 awesome-typesafe.md —— jev-orderby-bench 的检验结论与 “Classification accuracy alone…” 一句
• wiki/synthesis/Jev 知识.md 第 3.2 节 ⑦ —— 官方重排示例的中文概述