论文：OpenDeepThink: Parallel Reasoning via Bradley--Terry Aggregation
arXiv:2605.15177v1，提交时间：2026-05-14 17:57:40 UTC
作者：Shang Zhou、Wenhao Chai、Kaiyuan Liu、Huanzhi Mao、Qiuyang Mang、Jingbo Shang
来源：https://arxiv.org/abs/2605.15177
关键数据：Gemini 3.1 Pro 在 8 轮顺序 LLM 调用、约 27 分钟 wall-clock 下，Codeforces 有效 Elo 提升 405 点；论文发布 CF-73，包含 73 道专家标注 Codeforces 题，本地评测与官方 verdict 一致率 99%。
大模型的"深度思考"，可能太像一个人自言自语
过去一年，test-time compute 成了大模型推理能力提升的主线之一。
它的基本想法很简单：模型参数不变，但推理时多花一点算力。让模型想更久、写更长的 chain-of-thought、反复检查答案、调用 verifier、或者采样多个候选答案再选择。
这条路线之所以重要，是因为它绕开了一个现实约束：不是每个团队都能重新训练一个更大的模型，但很多应用可以接受推理时多花几秒、几十秒，甚至几分钟，只要答案质量明显变好。
问题在于，很多"深度思考"方法，本质上仍然是让模型沿着一条轨迹往下走。
这就像让一个人在白板前连续推导。推导得越久，确实可能更接近答案；但如果一开始方向错了，后面越努力，越可能把错误包装得更严密。模型的自我检查也有类似问题：它既是出题人、答题人，又是阅卷人，很容易把自己的偏见带进判断。
OpenDeepThink 的切入点不一样。它不把算力都押在一条更长的推理链上，而是把推理变成一个小型"候选群体"的演化过程：并行产生多个候选，让它们两两比较，用 Bradley-Terry 模型聚合比较结果，再保留、变异、淘汰。
这篇论文真正有意思的地方，不是又提出了一个让模型多想几轮的技巧，而是把"模型推理"从单人长跑，改造成了群体竞赛。
为什么多采样还不够
最直接的 breadth scaling 是多采样。
同一道题，让模型生成十个、二十个甚至更多答案。只要其中有一个是对的，理论上就有机会超过单次生成。
但这马上带来一个选择问题：你怎么知道哪个候选最好？
如果是数学题、代码题，最好有一个可靠 verifier。代码可以跑测试，数学可以检查最终数值或形式证明。但大量现实任务并没有一个廉价、确定、无偏的裁判。让另一个 LLM 给候选打分也不稳，因为 pointwise judging 容易受表达风格、答案长度、先验偏见影响。
OpenDeepThink 选择了更接近人类评审的方式：不让模型直接给每个候选打绝对分，而是随机抽两份候选做 pairwise comparison。比较时，模型不仅判断谁更好，还生成自然语言 critique。然后系统把一批 pairwise votes 用 Bradley-Terry 聚合成全局排名。
Bradley-Terry 模型常用于从两两胜负关系中估计选手强弱。放到这里，每个候选推理轨迹就是一个"选手"。它不要求裁判一次性给出绝对分，只需要回答 A 是否比 B 好。多个 noisy pairwise judgments 聚合后，比单次打分更稳。
这解决了多采样路线最关键的瓶颈：候选很多时，选择本身也要变成一个可扩展的推理过程。
OpenDeepThink 的循环
论文里的流程可以拆成四步。
第一步，生成一组候选推理。它们可以来自同一个模型的多次采样，也可以在后续轮次中由已有候选变异而来。
第二步，随机两两比较。LLM 作为 judge，阅读两个候选，判断哪一个更优，并写出 critique。这里的 critique 很关键，因为它不是只产生一个胜负标签，还给后续改写提供方向。
第三步，用 Bradley-Terry 聚合投票。系统不相信单次裁判结果，而是把多个 pairwise votes 放到一个统一排名里，估计每个候选的相对强度。
第四步，保留和变异。排名靠前的候选被保留；排名前四分之三的候选会基于 critique 做自然语言 mutation；底部四分之一直接淘汰。
这很像一个轻量级进化算法。不同的是，候选不是基因串，而是自然语言推理轨迹；适应度不是外部 reward，而是由 LLM pairwise judge 加 Bradley-Terry 聚合出来的相对质量。
它的工程吸引力也在这里：不需要训练新模型，不需要专门调参，不要求题目一定有 verifier。只要模型能生成、比较和按 critique 改写，就能跑这个框架。
405 Elo 这个数字说明了什么
论文最醒目的实验结果，是 Gemini 3.1 Pro 在 Codeforces 上有效 Elo 提升 405 点。
这个数字要谨慎理解。它不是说模型参数本身变强了 405 Elo，也不是说每个任务都能白拿同样提升。论文明确指出，收益集中在 objectively verifiable domains，在 subjective domains 甚至可能反转。
这点反而让结果更可信。
Codeforces 题有清晰对错，推理路径可以被最终答案或本地评测检验。并行候选、比较、变异在这种环境里容易积累优势。模型不是凭感觉写一篇更顺眼的文章，而是在一组可检验问题上逐步筛出更可能正确的解法。
但如果任务是审美判断、开放式写作、价值判断、策略建议，pairwise judge 的偏见可能被放大。多个候选之间的"胜负"不再有清晰外部标准，系统可能把某种表达风格误认为更好。
所以 OpenDeepThink 更适合被看作一种"可验证推理任务的 test-time optimizer"，而不是通用智能增强器。
它最自然的落地场景包括：算法题、代码修复、数学推导、结构化规划、配置诊断、数据分析、约束求解，以及那些最终可以跑测试或检查约束的任务。
为什么它比"让模型反思一下"更工程化
很多 agent 或 reasoning pipeline 里都有 self-reflection：先生成答案，再让模型评价，最后改写。
这类方法的问题是太线性。一个候选错了，反思也可能围着这个错误打转。模型经常会给出听起来合理的批评，但改完之后并没有真正跳出原来的路径。
OpenDeepThink 的差异在于群体多样性。
它同时保留多个候选轨迹。每一轮不是单个答案自我修补，而是多个答案竞争、继承和变异。错误路径会被淘汰，较强路径会被保留，critique 变成下一轮 mutation 的燃料。
这更像软件工程里的测试矩阵，而不是单次代码 review。你不会只跑一个 case，然后让程序解释为什么自己对；你会让多个实现、多个输入、多个断言一起暴露问题。
对 AI agent 来说，这种思想很重要。未来的复杂任务不一定靠一个模型一次性给出完美计划，而可能靠一组候选计划并行探索，再通过比较、约束检查和外部验证逐步收敛。
成本问题：27 分钟意味着什么
论文提到，8 轮顺序 LLM 调用约 27 分钟 wall-clock。
这说明 OpenDeepThink 不是面向普通聊天的。你不会希望用户问一个日常问题，系统先跑半小时候选演化。
但在高价值任务里，这个成本可以接受。比如修一个复杂生产 bug、生成一段关键算法、设计一个多步骤实验、优化一个金融模型、完成一次法律或医学前的辅助分析，几十分钟的推理时间并不荒谬。
更重要的是，这类流程天然适合并行化。候选生成、pairwise comparison、mutation 很多部分都可以横向展开。今天论文里的 wall-clock 是一个实验条件，不代表工程上没有优化空间。
未来真正的问题不是"要不要多花推理算力"，而是"哪些任务值得多花推理算力"。这会变成产品层面的路由问题：普通请求走低成本路径，高风险高价值请求走 OpenDeepThink 这类重推理路径。
对内容生产和代码 Agent 的启发
OpenDeepThink 对内容生产也有启发，但不能照搬。
如果要写一篇观点文章，多候选 + pairwise ranking 可能会强化流畅、保守、主流的答案，而不是产生更有洞察的文本。因为"哪个观点更好"没有确定裁判，LLM judge 容易奖励熟悉的表达。
但如果把它用于文章事实核查、结构设计、标题候选、论据排序，价值就更明确。比如生成多个大纲，让模型比较逻辑完整性；生成多个标题，让模型比较信息密度和误导风险；生成多个事实摘要，再用来源一致性做约束。
代码 Agent 的场景更直接。一个 agent 可以生成多个 patch，跑测试、静态检查、lint，再让 LLM pairwise 比较可维护性和风险。最后用测试结果和 Bradley-Terry ranking 一起决定保留哪个 patch。
这可能是未来 coding agent 的重要方向：不是一次生成一个 patch，而是生成一个 patch population。
我对这篇论文的判断
OpenDeepThink 值得关注，因为它把 test-time scaling 做得更像一个系统，而不是一个 prompt 技巧。
它承认单次 LLM 判断有噪声，所以用 pairwise comparison 降低绝对评分压力；它承认多候选选择困难，所以用 Bradley-Terry 聚合；它承认一次生成不够，所以引入 critique-driven mutation；它也承认领域差异，所以指出收益在客观可验证任务中更明显。
这类方法不会让每个应用都变快，甚至会让很多任务变慢。但它提供了一个重要范式：当任务足够重要时，我们可以把推理组织成可演化、可比较、可筛选的群体过程。
大模型的下一阶段能力提升，可能不只来自更大的模型，也来自更会调度模型的推理系统。
OpenDeepThink 正是在这个方向上迈出的一步。