Test-time compute 这条赛道已经挤得差不多了。从 o1 的 "think longer" 到各种 self-consistency、majority voting，大家的核心假设都一样：让模型多想几次，取最好的那个。
但 "取最好的那个" 这一步，几乎所有人都偷懒了。
最常见的做法是：生成 N 个答案，用 LLM 给每个答案打个分，选最高分。听起来没问题？点式打分（pointwise judging）天生有位置偏见——模型对先看到的候选更宽容，打分标准在不同候选之间漂移。你以为你在做客观选择，其实是在掷骰子。
OpenDeepThink 这篇来自 UCSD 的论文，做了一件很实在的事：它承认 LLM 不擅长绝对打分，但承认 LLM 还算擅长比较——"A 和 B 哪个更好"。
怎么做：把投票变成赛马
OpenDeepThink 的核心流程像一场淘汰赛：
- 生成一批候选答案
- LLM 随机两两配对比较（"A 比 B 好吗？为什么？"）
- 用 Bradley-Terry 模型把所有配对结果聚合成全局排名
- 保留排名靠前的，淘汰尾部 1/4
- 用比较时 LLM 自己写的自然语言 critique 去修改（mutate）保留的候选
- 重复以上步骤
Bradley-Terry 模型来自 1952 年，本来是用来给棋手排名的。核心思想简单：如果 A 赢了 B 多次，A 的排名就高。关键是用成对比较替代绝对打分——模型说 "A 比 B 好" 的可信度，远高于说 "A 得 8 分，B 得 7 分"。
第五步才是真正的亮点。mutate 不是无脑重写，而是用 LLM 自己在比较过程中说出来的 具体 critique 来改进候选。相当于把判断信号和修改信号合二为一。
数据说话
- Gemini 3.1 Pro 在 Codeforces 上的有效 Elo +405 分。8 轮 LLM 调用，约 27 分钟。
- 这个 pipeline 可以跨模型迁移，不需要针对每个模型重新调参。
- 在多领域 HLE 基准上，收益集中在客观可验证的领域，主观领域反而倒退。
最后一条值得嚼一嚼。为什么主观领域会倒退？论文作者的解释是：当问题没有唯一正确答案时，LLM 在 pairwise 比较中会更倾向于 "看起来更有信心" 的答案，而非 "实际上更好" 的答案。这其实暴露了一个更深层的问题——test-time compute 不是万灵药，它的有效性取决于你能不能构造出可靠的评判信号。
CF-73：73 道带国际大师标注的 Codeforces 题目
论文还附带发布了一个 CF-73 数据集，73 道专家评级的 Codeforces 题目，带 International Grandmaster 标注，本地评估与官方判定的 agreement 达到 99%。这个数据集本身就有独立价值——编程竞赛评测一直缺这种高质量的带标注基准。
我的判断
OpenDeepThink 的贡献不在于 "Bradley-Terry 很新"（它 70 多岁了），而在于它精准定位了 test-time compute 的隐藏瓶颈：候选选择。
很多做 test-time compute 的工作把 90% 的精力放在生成上，选答案时随便取个 majority vote 就完事了。OpenDeepThink 告诉你：选答案这一步值得认真对待。
+405 Elo 不是小数。27 分钟的墙钟时间也不短。如果你的场景是实时交互，这个方法不适用；但如果你在做代码生成、数学解题、复杂推理这种 "慢工出细活" 的事，OpenDeepThink 提供了一条可验证的 compute 扩展路径。
下一步要看的是，这个思路能不能被集成进开源推理框架里，让普通开发者一行代码就能用。
主要来源：
- arXiv:2605.15177 OpenDeepThink: Parallel Reasoning via Bradley-Terry Aggregation
- UCSD 研究团队