测试时强化学习的工具验证

论文信息

标题: Tool Verification for Test-Time Reinforcement Learning

作者: Ruotong Liao, Nikolai Röhrich, Xiaohan Wang, et al.

发布日期: 2026-03-02

arXiv ID: 2603.02203v1

PDF 链接: 下载 PDF

3 分钟速览

研究问题：测试时强化学习（TTRL）通过多数投票生成伪标签来驱动模型自我进化，但虚假的高频共识会形成有偏奖励信号，导致模型向错误方向收敛。
核心方法：在奖励估计阶段引入外部工具验证（代码解释器），用验证感知的加权投票取代普通多数投票，让通过可执行性检查的推理轨迹获得更高投票权重。
关键结果：在最具挑战性的 AIME 2024 基准上，Qwen-Math-1.5B 模型相对 TTRL 基线获得 31.6% 的提升（见论文表 1）。
主要局限：当验证模型容量过小（如 0.5B）时，工具调用质量下降，反而向奖励信号注入噪声，导致性能劣于 TTRL（见论文附录表 4）。
适合读者：关注大模型推理能力增强、强化学习训练范式改进、以及工具集成方法的研究者和工程师。

论文背景和研究动机

大语言模型正在进入 “经验时代”（era of experience）。测试时扩展（Test-Time Scaling, TTS）已被证明能有效提升推理能力，而测试时训练（Test-Time Training, TTT）进一步允许模型在推理阶段利用自监督信号更新参数。

测试时强化学习（Test-Time Reinforcement Learning, TTRL）将这一思路推向极致：模型在未标注的测试输入上生成多条推理轨迹，通过多数投票选出共识答案作为伪标签，据此构造奖励信号进行在线强化学习更新。这一过程模拟了人类面对新问题时的自然应对策略：生成候选方案、选择最合理的一个、据此调整认知。

然而，这种完全依赖内部共识的机制存在根本性漏洞。当模型自身推理存在系统性偏差时，共识与非共识之间的相关性断裂——高频但错误的答案可能被多数投票选中，形成 “虚假流行模式坍缩”（false-popular mode collapse）。论文指出，一旦错误答案被选为伪标签，强化学习的自反馈循环将放大这一偏差：模型被迫增加错误答案的生成概率，进一步巩固其投票优势，进入恶性循环。

这就是论文提出的核心问题：能否在无标签条件下，使模型的自我进化对虚假共识具有鲁棒性？ 人类的做法是当内省不可靠时，转而寻求外部证据（如通过环境交互获取反馈）。论文认为，测试时强化学习缺失的正是这样一个外部验证机制。

核心方法和技术细节

T³RL（Tool-Verification for Test-Time Reinforcement Learning）在标准 TTRL 流程的奖励估计环节嵌入工具验证，核心由三个组件构成。

验证器（Verifier）

验证器 $\mathcal{V}$ 是一个独立的外部大语言模型。对于输入的提示词 $x$ 和生成的推理轨迹 $y_i$ ，验证器执行三项任务：第一，从推理轨迹中提取候选答案 $\hat{a}_i = \text{Extract}(y_i)$ ；第二，将推理轨迹转换为可执行的 Python 代码，涉及的计算步骤被编译为轻量级脚本；第三，根据代码执行结果判断轨迹的有效性，返回验证结果 $(a_i, v_i) = \mathcal{V}(x, y_i)$ ，其中 $a_i$ 是工具得出的答案， $v_i \in \{0,1\}$ 是有效性标志。

论文强调验证器的独立性：系统提示明确要求验证器 “不要假定推理轨迹是正确的”，应独立重新计算答案，仅将原轨迹作为提示参考。这避免验证器盲从原推理中的潜在错误。

验证工具（Verification Tool）

验证工具 $\mathcal{T}$ 是一个代码解释器，提供确定性的外部可执行证据。对于数学问题，许多推理故障表现为中间计算错误（如算术失误、代数滑动）。工具验证将这些计算卸载到解释器：

a_i = \mathcal{T}(\text{Code}(x, y_i))

验证器将工具返回的结果 $a_i$ 与轨迹原始答案 $\hat{a}_i$ 对比，生成有效性指标：

v_i = \mathbbm{1}[a_i = \hat{a}_i]

验证权重（Verification Weight）

这是 T³RL 区别于标准 TTRL 的关键设计。传统多数投票中每条推理路径权重相等，T³RL 引入验证权重 $\omega$ 放大通过工具验证的轨迹的投票影响力：

w_i = (1 - v_i) \cdot 1 + v_i \cdot \omega

未经验证的轨迹保留单位投票权，验证通过的轨迹贡献 $\omega$ 票。验证感知的共识标签通过最大化加权总票数获得：

\tilde{y}^* = \arg\max_{a \in \mathcal{A}} \sum_{i=1}^N w_i \cdot \mathbbm{1}[a_i = a]

论文将这种机制称为 “将学习从最频繁的模式转移到已验证的模式”。奖励计算保持与标准 TTRL 一致的二元形式，但锚定于验证感知共识：

r_i^\text{v} = \mathbbm{1}[a_i = \tilde{y}^*]

算法的整体流程可用以下伪代码清晰表达（见论文清单 1）：

python

def t3rl_reward_fn(x, policy, verifier, sandbox, N, omega):
    Y = policy.sample_rollouts(x, n=N)
    vote, A = defaultdict(float), []
    for y in Y:
        code = verifier.generate(x, y)
        evidence = sandbox.execute(code)
        a, v = verifier.judge(x, y, evidence)
        vote[a] += (1.0 if v == 0 else omega)
        A.append(a)
    y_star = max(vote, key=vote.get)
    rewards = [1.0 if a == y_star else 0.0 for a in A]
    return y_star, rewards

创新点和贡献

T³RL 的贡献可以从三个层面理解。

概念创新：将验证引入测试时训练。 此前验证机制仅用于推断阶段的最优输出选择（Test-Time Verification, TTV），T³RL 首次将验证嵌入训练循环，使采样的推理轨迹在工具证据支持下转化为在线标注数据。论文精辟地总结这一视角转换：“T³RL 将测试时强化学习定位为验证式在线数据合成”。

工程创新：解耦推理与工具执行。 对比实验中，允许策略模型在推理时直接调用工具的 TTRL-Agent 配置性能反降（见论文图 8(a)）。论文解释为工具调用将推理错误与工具使用错误混在一起，在更大的动作空间中奖励噪声被放大。T³RL 将工具执行限定在验证器侧，作为奖励塑形而非策略动作空间的一部分，推理与验证各司其职。

稳定性提升。 多次运行的对比显示，T³RL 降低了训练过程对采样噪声的敏感性。在 AIME 基准上，100 步后最佳准确率的标准差从 2.638 降至 1.890，方差从 6.959 降至 3.572（见论文第 6.1 节）。验证锚定的奖励结构产生了更一致的学习动态。

实验结果分析

实验覆盖三个数学推理基准（MATH-500、AMC、AIME 2024）和五类基础模型（普通模型、数学模型、指令微调模型），形成了对不同难度和模型类型的全面评估。

主要发现

表 1 显示 T³RL 在所有配置下均优于 TTRL。最突出的结果出现在最具挑战性的 AIME 2024 基准上：Qwen-Math-1.5B 模型获得 20.8%（TTRL 为 15.8%），相对提升 31.6%。跨所有模型平均，提升幅度随难度递增：MATH-500 上提升 3.5%，AMC 上提升 9.7%，AIME 2024 上提升 19.8%。

MATH-500 的难度分层分析（表 2）进一步验证这一趋势：最难的 L5 级问题相对 TTRL 提升 4.3%，而较简单的 L1 级仅提升 0.2%。论文解释为难题涉及更长的计算链，推理轨迹累积错误的概率更高，工具验证的确定性检查效益更明显。

消融实验洞察

权重选择。 验证权重 $\omega$ 的消融显示（图 6）， $\omega=5$ 取得最佳平衡。过低的权重（ $\omega=2$ ）无法有效抑制虚假共识；过高的权重（ $\omega=10$ 或 $\omega \to \infty$ ，等于硬过滤）将学习坍缩到少量验证通过的轨迹上，降低训练信号多样性。

工具执行的贡献。 仅使用语言模型验证（无代码执行）已带来改进，但加入工具执行后性能进一步跃升：AIME 上从 18.3% 升至 20.8%，7B 验证器下从 20.0% 升至 21.7%（图 5(b)）。可执行证据降低了验证器的不确定性，使验证信号更可靠。

计算预算分配。 T³RL 的样本效率表现出色：使用 16 条推理轨迹即可超越 TTRL 使用 64 条轨迹的效果（图 9(a)）。验证提高了每条轨迹的信息质量，使得在更少的测试时计算下获得更高准确率。更大的验证器（7B vs 1.5B）也持续改善性能，说明更强的验证能力可强化奖励信号（图 9(b)）。

失效模式

论文坦率分析了 T³RL 的可能失效情况。使用 0.5B 容量的极小验证器时，验证器频繁出现指令遵循失败，表现为盲从原始推理轨迹、输出硬编码答案、产生无法编译的 Python 代码（见论文附录图 11）。此时 T³RL 的性能劣于 TTRL：AIME 上从 0.4% 降至 0.0%，MATH-500 上从 34.6% 降至 32.0%（表 4）。这表明 T³RL 要求验证器具备最低限度的容量门槛，否则验证退化为额外的随机噪声源。

实践建议

对于计划在推理系统中部署类似机制的研究者和工程师，有几点可操作的建议。

验证器选型原则。 不要让验证器过小。论文实验表明 1.5B 参数是有效验证的最低门槛，0.5B 模型会导致性能倒退。作为一般性指导，验证器容量应不低于策略模型的容量。

验证权重调优。 $\omega=5$ 在论文实验中普遍表现良好，但这一数值可能随任务特性和模型配置变化。建议在目标场景中扫描 $\omega \in \{2, 3, 5, 8, 10\}$ ，寻找性能峰值。避免使用无穷权重（硬过滤），这会损失训练信号多样性。

测试时计算分配。 论文结果表明，将计算预算更多地分配给验证（而非单纯增加采样数量）是高性价比的选择。T³RL 用 16 条轨迹的少量采样即超越 TTRL 的 64 条轨迹，说明验证是比暴力扩展更高效的计算投资方向。在实践中，可优先部署验证机制，再逐步增加采样数量直至性能饱和。

任务适用性判断。 对于简单任务，T³RL 的边际收益有限（论文 MATH-500 L1 级别仅提升 0.2%）。验证机制的投资回报率在涉及长计算链、多步骤推理的任务中最高。数学竞赛类问题、代码生成、复杂逻辑推理是理想的切入点。

系统架构设计。 论文对比实验中 TTRL-Agent 的性能下降具有警示意义：将工具调用嵌入策略模型的动作空间会增加奖励信号的噪声。建议保持推理与工具执行的解耦架构——策略模型专注于生成推理轨迹，验证器独立承担工具调用与结果评估职责。