这项由英国剑桥大学与法国AI公司Mistral AI联合开展的研究，以预印本形式于2026年6月发布在arXiv平台，编号为arXiv:2606.09380。感兴趣的读者可以通过该编号检索完整论文。
一、先从一个让人头疼的训练困境说起
教一个AI学数学，最直觉的方法就是让它反复做题、对答案、改错误。这套思路听起来简单，背后却藏着一个几乎所有AI训练团队都会遇到的棘手问题——有时候，AI做的一批题要么全部答对，要么全部答错，没有一道题"部分正确"。
为什么这是个问题？因为当前最流行的AI强化训练方法（简单来说，就是"做对了就给奖励，做错了就扣分"）依靠的是同一批答案之间的差异来判断哪种思路更好。打个比方：一位厨师助理同时做了8道菜，如果这8道菜要么全都被食客称赞，要么全都被嫌弃，那主厨就完全不知道应该鼓励哪种烹饪手法、纠正哪种失误——奖惩系统彻底失灵。
这个困境在AI研究圈有个专门的名字，本文的研究团队称之为"非多样性奖励组"问题。现实中，这种情况出现的频率远比人们想象的高。根据研究团队的实际观测数据，在用一个名为Ministral-3-8B的AI模型进行训练时，全程有相当大比例的训练批次陷入了这种"要么全对、要么全错"的僵局——尤其在训练早期，模型太弱，题目太难，几乎全部答错；而训练进入后期，模型变强了，简单题目又几乎全部答对。两种极端情形加在一起，意味着大量的计算资源被白白耗费，那些已经生成的AI推理过程被直接丢弃，没有产生任何改进效果。
研究团队由此提出了一个核心问题：既然这些"全对"或"全错"的推理过程已经生成了，能不能想办法从中挖掘出有用的训练信号，而不是直接扔掉？
二、过去的解决思路：要么绕开，要么凑合
在这项研究之前，学术界对这个问题并非一无所知，已有几条应对思路。
第一条路是"绕开问题"——在训练前就把那些太难或太简单的题目过滤掉，只保留难度适中、能让AI产生参差结果的题目。这个思路的代表方法包括DAPO、DEPO、GRESO等。但这条路有个明显的代价：它本质上是在承认失败，主动放弃了对这些题目的学习机会，而且筛选本身也需要耗费大量的计算资源。
第二条路是"从模型自身找信号"——既然答案都一样，那就看看AI生成这些答案时的"心理状态"，也就是模型对自己输出的词汇的概率分布，通过分析这种内部状态来给不同的推理过程打分。这类方法的代表是RL-ZVP和ZAPO。然而这条路有个根本性的缺陷：模型内部的概率分布根本分不清"严谨的逻辑推导"和"自信满满的胡说八道"——两者在模型眼中可能呈现相同的概率特征。打个比方，一个学生无论是真正想清楚了解题思路，还是在凭感觉瞎蒙，写出来的字迹可能同样工整流利，光靠笔迹分析根本看不出区别。
这项研究提出的REASONING ARENA（可以理解为"推理擂台"）走了一条完全不同的路：引入一个外部评判者，直接看推理过程本身的质量，而不是绕开问题或者依赖模型的内部状态。
三、推理擂台的核心思想：让AI互相PK
REASONING ARENA的基本逻辑可以用一个竞技比赛的场景来理解。
当AI对同一道题生成了若干个推理过程，而这些推理过程的最终答案全部相同（要么全对要么全错）时，普通的评分方式就失去了区分能力。但是，这些推理过程的质量真的完全相同吗？未必。就像两个学生都答对了一道数学题，但一个写了清晰完整的推导步骤，另一个只写了关键跳跃，这两份答卷显然存在质量差异，只是标准答案核对系统看不出来。
REASONING ARENA的做法是：把这些推理过程两两配对，让一个更聪明的"裁判"AI来看这两段推理过程，判断哪一个更严谨、更有条理、更能体现正确的解题思路。裁判看完之后给出一个结论：A更好、B更好，或者打平。这个判断结果就转化为奖励信号，用来告诉被训练的AI模型："这种思路比那种好，你应该朝这个方向发展。"
关键在于，这套评判机制只在普通评分方式失灵的时候才启动。当一批题目的答案有对有错时，系统仍然使用原来可靠的对错评分；只有当所有答案都一样时，才把推理过程送进"擂台"进行PK。这种"按需切换"的设计既保留了精确评分在有效时候的权威性，又补上了它失效时候的空白。
四、评判者如何避免偏见：两个精心设计的细节
让AI充当裁判，本身就有很多潜在的问题。研究团队针对其中最常见的两个问题设计了专门的对策。
第一个问题是"位置偏见"——裁判AI往往倾向于偏爱出现在提示词前面的那个回答，就好像人在快速浏览时更容易注意到放在上方的内容一样。对策是随机打乱两段推理的出现顺序，让偏好随机化，这样系统性的位置偏见就变成了无规律的随机噪音，不会持续扭曲奖励信号。
第二个问题是判断结果如何量化。裁判给出的是"A胜"、"B胜"或"平局"这样的定性结论，但训练需要的是连续的数值奖励。研究团队引入了一个可调节的"软边距"参数：裁判判定A胜时，A获得一个高于0.5的分数；判定平局时，双方都得0.5；判定B胜时，A得低于0.5的分数。这个设计确保了奖励信号既有方向性，又不过于极端。
五、擂台PK面临的效率难题：从"全场赛"到"邀请赛"
如果每批生成了8个推理过程，要让它们两两对比，理论上需要进行28次比较（8×7÷2）。这对一次偶发的评判来说还可以接受，但如果训练全程有大量批次都需要这样处理，裁判AI需要处理的请求量就会变得极其庞大，严重拖慢整个训练流程。
研究团队针对这个效率问题设计了一套"动态锦标赛"机制，把成本从O(N?)（平方级增长）降低到O(N)（线性增长）。
具体做法是：不等所有推理过程都生成完再统一比较，而是每当一个新的推理过程生成完毕，立刻为它安排3个对手，这3个对手分别是当前已知的"最强选手"、"最弱选手"和"中间水平选手"。新来的推理过程与这三位参照点比较，就能大致确定自己在整个群体中的相对位置，而不需要跟每一个其他推理过程都正面交锋。这就像一个选手参加体育比赛，不需要跟所有人都打一遍，只要跟冠军、末位和中位选手各打一场，就基本能判断自己大概排在第几位。
但这种"不完整的比较图"会带来一个统计问题：每个推理过程的比较对象数量和强弱不一样，直接统计胜率会有失公平。为了解决这个问题，研究团队借用了一个来自体育统计学的经典工具——Bradley-Terry模型。这个模型的核心思想是：假设每个参赛者都有一个内在的"真实实力值"，每场比赛的结果都是这两个实力值的概率性体现。通过对所有比较结果进行统计拟合，就能反推出每个推理过程的"真实实力估计值"，而不受具体比赛对象和顺序的影响。最终，这个实力估计值被归一化到0到1之间，作为该推理过程的奖励分数。
六、实验结果：数字背后的真实含义
研究团队在竞赛数学和代码生成两大领域对REASONING ARENA进行了系统测试，基础模型是Ministral-3-8B-Instruct，测试题目包括AIME 2024、AIME 2025、AIME 2026（全美数学邀请赛历年真题）、Beyond AIME（更高难度的数学评测集）、GPQA-Diamond（研究生级别的跨学科问答）以及LiveCodeBench v6（代码能力基准测试）。
与只使用对错评分的基础方法相比，REASONING ARENA-Live（也就是加入了动态锦标赛和Bradley-Terry估计的完整版本）在6个测试集上的平均得分提升了7.6个百分点。其中提升最显著的是AIME 2026，足足高出了12.9个百分点。在通常意义上，这样的差距在竞赛数学这种极难任务上已经相当可观。
更有意思的是训练过程的动态变化。从训练曲线来看，REASONING ARENA的优势随着训练步数的增加不断扩大，尤其在训练后期差距拉得更明显。这个现象背后有清晰的逻辑：训练后期模型变强，简单题几乎都答对，普通评分方式能提供的有效信号越来越少，而REASONING ARENA此时却能源源不断地从这些"全对"批次中提取有用的训练信号，持续给模型指方向。
在代码生成和跨学科推理（GPQA-Diamond）上，REASONING ARENA同样保持了稳定的优势，这一点尤为重要，因为训练数据中并不包含代码任务，代码测试属于"未见过领域的泛化"测试。一般来说，过度依赖特定领域训练信号的方法往往会在泛化性上吃亏，但REASONING ARENA在这方面表现得相当稳健。
七、训练效率的意外收获：不只是更准，还更快
这项研究还带来了一个在提出方案时可能没有完全预料到的好处：训练速度加快了。
原因在于：在原来的方法中，一旦一批推理过程被判定为"全对"或"全错"，这8个已经生成的推理过程就被直接丢弃，系统需要重新生成足够多的有效批次才能继续训练。这意味着大量生成资源被浪费。而REASONING ARENA把这些原本要被丢弃的批次送进擂台评判，使它们也能产生有效的训练信号，从而减少了重新采样的次数。
具体数字是：采用完整动态锦标赛策略后，每个训练步骤的实际生成次数减少了将近50%，整体训练时间缩短了27%到41%。换句话说，用更少的算力达到了更好的效果。
与此同时，研究团队也仔细测算了引入裁判AI带来的额外开销。以8个推理过程为一组为例，完整的两两对比需要28次裁判调用；动态锦标赛版本最多需要18次（第1个推理生成时无法比较，第2个比较1次，第3个比较2次，第4到第8个每个比较3次，共1+2+3×5=18次）。而且由于只有非多样性批次才触发裁判机制，实际裁判调用次数还会被进一步折扣——实验中平均只有约43%到45%的批次被路由到擂台，所以实际额外开销远小于最坏情况估计。
八、不同裁判模型和不同评分方式的对比
研究团队还测试了几个关键的设计选择是否真的必要。
首先是"是否必须用PK对比"的问题。研究团队设计了一个对照方案，叫"Adaptive Pointwise"——同样只对非多样性批次启用裁判，但裁判只单独给每个推理过程打分（0分、0.5分或1分），而不是两两对比。测试结果显示，PK对比的平均得分为53.5，而单独打分只有51.3，差距明显。
为什么两两对比优于单独打分？研究团队给出的解释很直觉：单独打分要求裁判在没有参照的情况下给出绝对评价，这非常困难，容易受到回答长度、格式、用词习惯等表面特征的干扰；而两两对比让裁判在同一道题的两个解法之间做相对判断，比较基准已经被固定，裁判只需要专注于推理质量本身，判断结果更可靠。
其次是"裁判的能力大小是否重要"。研究团队分别测试了DeepSeekMath-V2（685B参数，专门针对数学优化）、Qwen3-235B-A22B（235B参数，通用能力强）和Qwen3.5-122B-A10B（122B参数，较小规模）三个裁判模型。三者都比基础RLVR方法有明显提升，但能力更强的裁判模型带来的提升更稳定、更一致，尤其在复杂的多步骤数学推理上，更大模型的裁判判断一致性更高。这说明REASONING ARENA的框架本身是稳健的，不过裁判的质量确实影响最终效果的上限。
九、擂台判决的真实案例：裁判到底在看什么
论文中提供了两个具体的判决案例，非常直观地展示了这套机制的实际工作方式。
第一个案例来自"全对"批次。题目是求满足条件的函数个数，正确答案是9。两个推理过程给出的最终答案都是9，从对错评分的角度完全相同。但裁判注意到，回答A在推导过程中明确指出了"定义域必须是某个特定集合的子集"这一前提条件，逻辑更加完整；回答B虽然结论正确，但省略了这一步关键论证，留有逻辑缺口。裁判的判决是A更好。
第二个案例来自"全错"批次。题目是关于答题得分的组合计数问题，正确答案是27。两个推理过程给出的答案都是错的（一个给出41，一个给出20），但质量差距很大。回答A几乎没有推导过程，直接凭感觉给出了41；回答B尝试从小规模情形中找规律，发现了"每增加一道题，得分种数增加2"的模式，虽然这个规律本身也有缺陷，但至少体现了系统性的思考过程，而且给出的20比41更接近正确答案27。裁判的判决是B更好。
这两个案例说明了擂台机制的核心价值：在最终答案无法区分高下的情况下，对推理过程的质量评估仍然能够捕捉到有意义的差异，并将这种差异转化为对模型的正向引导。
说到底，这项研究解决的是一个"好东西被浪费"的问题。AI在训练过程中生成了大量推理过程，其中有相当一部分因为答案碰巧全部相同而被整批丢弃，既浪费了生成这些推理过程所消耗的算力，也放弃了从中学习的机会。REASONING ARENA提供的方案是：别急着扔，先让裁判看看这些推理过程之间有没有质量差异，如果有，就把这个差异转化为训练信号。
这个思路的优雅之处在于它的"按需介入"：裁判只在普通评分方式失灵的时候才出场，不抢普通评分方式本来就能胜任的工作，也不放过普通评分方式无能为力的场景。两种机制各司其职，形成互补。
从实际效果来看，在竞赛数学这种对推理质量要求极高的领域，这套方法带来了7.6%的平均性能提升，同时还减少了近一半的计算开销。对于当前AI训练成本居高不下的大背景来说，"花更少的钱、训出更好的模型"是一个非常有吸引力的方向。
当然，这套方案也有其边界条件。裁判AI本身需要消耗额外的GPU资源，这形成了一个在训练速度、生成效率和总资源消耗之间的权衡。此外，当推理过程非常长时，把两段完整的推理都塞给裁判来评判，可能超出裁判模型的处理能力——这是研究团队自己也承认的现实局限。对于想深入了解这项研究的读者，完整论文可以通过arXiv编号2606.09380获取。
Q&A
Q1：REASONING ARENA只适用于数学题训练吗？
A：不局限于数学。论文实验中同时覆盖了代码生成任务（LiveCodeBench v6），且代码任务属于训练数据之外的领域，REASONING ARENA在上面同样有明显提升。研究团队还提到该框架理论上可以扩展到工具调用型AI智能体，只要中间的推理步骤可以被裁判评估，原理上都适用。
Q2：REASONING ARENA中的裁判AI会不会也犯错误，导致错误的奖励信号？
A：会，这是该方法固有的局限之一。论文中也提到，裁判的判断存在噪音，尤其对于非常复杂的多步骤推导，裁判可能判断失误。不过研究团队通过随机化比较顺序、使用Bradley-Terry模型综合多次比较结果等方式，降低了单次判断错误对最终奖励信号的影响。测试结果显示，即便使用较小规模的裁判模型，整体效果仍然显著优于不使用裁判的基础方法。
Q3：为什么REASONING ARENA训练速度反而比普通方法更快？
A：普通方法遇到"全对"或"全错"批次时会直接丢弃，然后重新生成新批次来填补空缺，这意味着大量生成算力被浪费在无效批次上。REASONING ARENA把这些批次引入擂台评判，使它们也能提供有效训练信号，减少了重新采样的次数。实验中每个训练步骤的实际生成次数减少了近50%，整体训练时间缩短27%到41%，这是"减少浪费"带来的效率红利，而非方法本身计算量更低。
