这周有两个人问我 reranker 要不要上，我的答案都是先别买。不是 reranker 没用——候选集够大的时候它确实能省一大截 token——而是多数人想上它的时候，召回那一层已经烂了。reranker 只是在给错误答案重新排队，排得还挺整齐。
召回烂的时候，reranker 在给错误答案排序
reranker 的输入是召回集，输出是同一个集合的重排。它不引入新文档。
所以如果正确答案压根不在你的候选集里，reranker 排完 top-5 还是没有。它做的是排序，不是召回。你在优化一个错误的目标。
麻烦的地方在于指标会骗人。NDCG、MRR 这类排序指标确实会涨——因为排序质量客观上变好了——但端到端答对率一动不动。你拿着涨了的离线指标上线，然后发现用户没感觉。这种"指标好但没用"的坑，比直接报错难查得多。
有人会说 reranker 也算召回的一部分。我不认。除非你的做法是把召回集从几十条扩到几百条再 rerank——那本质是扩大了召回池，钱花在召回上，只是顺带加了个筛选器。
先花一天，量出自己召回集的命中率
方法不复杂：抽一批真实 query，一两百条，人工标出正确答案在不在召回集里、排第几。然后看 recall@k，k 取你现在实际喂给模型的那个数。
如果相当一部分 query 的正确答案压根不在集合里，reranker 的天花板就被锁死了。你的上限是召回率，不是排序质量。这时候该干的是切块和 embedding。
标注成本真不高，一两个人一天能标完。比先接一个 reranker 服务、调两周参数、再发现没用，便宜太多。
标完还得按失败原因分类，因为修法完全不同：
- 切块把一句话或一个表格切断了 → 调 chunk size、overlap，或者按文档结构切
- 专有名词、内部代号、型号搜不到 → dense embedding 本来就不擅长，加 BM25 做混合检索
- 语义漂移，问 A 召回一堆讲 B 的 → embedding 模型的问题，或者 query 需要先改写
这三类的钱花在不同地方，别混着改。
reranker 真正值钱的地方：大候选集里挑少数几条
如果 recall@100 明显高于 recall@10，说明正确答案在集合里，只是排不上来——这才是 reranker 的主场。
它把一百条压到五条。喂给模型的 token 少一个量级，噪声也少。
反面观点就在这：召回够好的时候，reranker 不只是提精度，主要是省 token。上下文里塞三十条和塞五条，模型答得不一样，做过的人都清楚。长上下文不是免费的——中间那段容易被忽略，而且贵。省下的 prefill 时间，往往比 reranker 自己那点延迟多。
所以判断标准不是"要不要上 reranker"，是"我的正确答案通常排第几"。普遍落在 top-100 但掉出 top-10，上；压根不在 top-100，别上。
预算紧的话，先试不要钱的
混合检索加 RRF 融合，基本零成本，能解决一部分"在集合里但排不上来"的情况。先跑这个，看还差多少，再决定要不要请 cross-encoder 出场。
顺序别搞反。先接 reranker 再回头查召回，是最常见的浪费。
这周外部真没什么新料
说实话，这周的素材跟重排序基本不沾边。ArXiv 上一水儿是 agent 安全、agent 评测、机器人自进化；HN 上是 Docker Agent、Opus 5.5 找材料、韩国银行被 agent 打；OpenAI 那边全是客户案例。
唯一沾点边的是 Accurate but Not Humble，讲检索到的证据和 agent 先验冲突时它会不会改口。它不是在讲 reranking，但侧面说明一件事：喂进去的上下文质量，直接决定模型会不会死守错误结论。召回集里混着互相矛盾的片段，模型不会去分辨哪条新哪条旧，它挑一条顺手的就往下走。这算是给"先把召回修干净"多添一条论据。
还有 HN 上那篇 Why are coding agents so dumb?，光看标题就是要骂模型。我这两年碰到的同类抱怨，最后查下来不少是检索的问题——喂进去的上下文里压根没有能改对代码的那行。模型背了锅。
我的默认建议就一句：先花一天标一百条 query，算出 recall@k，再决定花不花这个钱。
也许过段时间 reranker 便宜到可以无脑开，那时候这个话题就没意义了。按我现在看，还没到。