重排序成本与收益估算器

重排序在管道里扮演什么角色

经典的两阶段检索：第一阶段用向量或关键词检索，从百万级文档里粗筛出 50–100 条候选——这一步追求「不漏」；第二阶段用交叉编码器（cross-encoder）把 query 和每条候选文档拼在一起逐条打分，重新精排——这一步追求「精准」。重排序模型比向量检索准得多，但每条候选都要过一次模型，所以只能用在候选集上，不能用在全库上。

成本结构的本质矛盾

这个管道的经济性来自一个反差：

• 重排序按「查询次数」计费，一次查询能给上千条文档打分，多条候选边际成本几乎为零。
• 大模型按「token」计费，每条塞进上下文的候选都要付钱，而且候选越多、越容易被无关内容干扰，答案质量反而下降。

所以这笔账通常非常划算：把 50 条压到 5 条，输入 token 直接砍掉 90%，而重排序只收一次查询的钱。这也是「上下文工程」里性价比最高的一步改造——不需要换模型、不需要重训，只是改了送进提示词的内容。

行业参考价与计费方式

关键细节：同一次查询里传 10 条文档和传 1000 条文档，按查询计费时价格一样。所以用按查询计费的方案时，务必把候选一次批量提交，而不是拆成多次调用——这是最容易浪费钱的地方。

候选数怎么定

业界经验是先粗筛 50–100 条再重排。低于 20 条容易漏掉真正相关的内容；高于 200 条则延迟与成本增加，但精度提升不再明显。本工具的最后一张表会把这个权衡直接算给你看——候选数越大，重排的收益越高，因为省下的 token 更多；但当候选数已经很小（比如 10 条压到 5 条）时，重排序的调用费可能超过省下的上下文费。

最后一个常见误区：有人以为重排序可以替代调优检索。如果第一阶段候选里根本没有正确答案，重排序再准也排不出来。先保证召回率，再谈重排精排——顺序不能反。

你可能还想问

重排序值得做吗？

在召回质量一般但重排模型强时收益明显，能把关键片段排到前面；若召回本身很差，重排也无力回天，应先优化召回。

成本怎么估？

按候选片段数与调用次数估算模型开销，再加上延迟带来的体验成本；候选越多成本越高，需要控制送入数量。

候选取多少合适？

常见先召回几十条再重排取前几条；候选太少覆盖不足，太多则成本与延迟上升，按效果与预算调整。

相关工具

相关内容