测试时强化学习的工具验证 Tool Verification for Test-Time Reinforcement Learning
T3RL通过测试时工具验证抑制虚假流行伪标签，实现数学推理模型的稳定自我进化
前置知识
Test-Time Reinforcement Learning (TTRL)
测试时强化学习是一种在无标签测试数据上进行模型参数更新的方法。TTRL通过多次采样生成多个候选推理轨迹，使用多数投票假设正确答案并作为伪标签，然后基于采样输出与共识输出的对齐度计算奖励信号，最后通过强化学习更新模型参数。这种方法模仿了人类学习的基本模式：通过生成候选解决方案来改进，选择最合理的方案，然后进行更新。TTRL的目标是在不依赖标注数据的情况下实现模型在测试时的在线适应和自我进化。
读懂本文需要理解TTRL，因为T3RL直接建立在TTRL框架之上，其核心问题就是针对TTRL中多数投票机制存在的虚假流行模式崩溃缺陷提出的解决方案。不理解TTRL的工作原理就无法理解T3RL的动机和改进方向。
Self-Consistency
自一致性是一种用于提高大语言模型推理性能的方法，通过生成多个推理路径（rollouts）并使用多数投票来选择最终答案。其基本假设是：正确的答案会从多个独立的推理路径中涌现出来，而错误的答案则更多是随机噪声，因此在多次采样中出现频率更高的答案更有可能是正确的。在TTRL中，自一致性被用作无监督奖励信号的来源，多数投票的结果被视为伪标签，用于指导强化学习训练。
自一致性是TTRL的基础机制，也是本文攻击的核心目标。论文指出的虚假流行模式崩溃问题正是自一致性假设失效的直接表现：当模型的内部推理存在系统性偏差时，共识与正确性不再相关，错误答案可能通过多数投票被选中。理解自一致性才能理解为什么需要引入外部验证机制。
Code Interpreter
代码解释器是一种能够执行Python代码并返回执行结果的外部工具。在T3RL中，代码解释器被用作验证工具，用于执行验证器生成的Python程序，从而对推理轨迹中的计算步骤进行可执行的检查。代码解释器提供的是确定性的、外部的、可执行的证据，与模型内部的不确定性推理形成互补。通过代码执行，验证器可以检查推理轨迹中声称的计算结果是否正确，例如验证某个代数运算或数值计算是否准确。
代码解释器是T3RL的核心组件之一，是工具验证的具体实现。理解代码解释器的作用和局限性对于评估T3RL方法的可行性和实际效果至关重要，特别是对于理解为什么工具验证能够提供比模型自验证更可靠的信号。
Verification Weight ω
验证权重是一个标量超参数ω≥1，用于量化工具验证轨迹相对于未验证轨迹的投票权重。在T3RL的验证感知多数投票机制中，每个rollout根据其验证状态v_i被分配权重w_i = (1-v_i)·1 + v_i·ω。当ω=1时，退化为标准多数投票；当ω→∞时，接近对所有未验证rollout的二元硬过滤。验证权重的引入使得验证通过的rollout能够获得更大的投票权重，从而将共识从最频繁的答案转向经过验证的答案。论文实验表明，适中的权重（如ω=5）能够达到最佳的性能平衡。
验证权重是T3RL方法的关键设计之一，理解其工作机制和调优策略对于掌握T3RL的核心创新至关重要。验证权重体现了T3RL如何平衡验证信号与多样性的权衡，也是T3RL区别于简单二元过滤的核心技术细节。
研究动机
测试时强化学习（TTRL）在无标签测试数据上进行模型自我进化时存在一个根本性缺陷：多数投票机制容易受到虚假流行模式崩溃的影响。当模型的内部推理存在系统性偏差时，共识与正确性不再相关，错误但高频的答案可能通过多数投票被选中为伪标签。例如在论文Figure 3的示例中，真实标签是C，但错误答案B通过多数投票被选中，导致错误rollout获得正奖励（Estimated Rewards中B为1，C为0）。更严重的是，这种偏差会在自我强化的反馈循环中被进一步放大：一旦伪标签设置为虚假流行的错误答案ñ，多数投票奖励就会奖励与错误信号一致的rollout，同时将真实rollout的奖励归零。强化学习更新会增加在后续rollout中采样到ñ的可能性，这进一步增加了其投票份额，使伪标签更加自信地错误。这种自我强化的动态会将TTRL推向不正确的模式崩溃，并且一旦模式崩溃发生，模型就更难自我纠正内部偏差。论文通过实验数据证实了这一问题：在TTRL训练过程中，模型会越来越自信于错误的估计，强化那些导致虚假流行模式崩溃的错误。
本文的目标是本文提出了T3RL（Tool Verification for Test-Time Reinforcement Learning），旨在通过引入测试时工具验证到奖励估计中，解决TTRL中虚假流行模式崩溃的问题。T3RL的具体目标是在无标签的自我进化框架下，利用外部工具（如代码解释器）提供的可执行证据，为验证通过的rollout赋予更高的投票权重，从而产生更可靠的伪标签和奖励信号。T3RL试图实现从频繁模式到验证模式的转变，通过验证感知的加权投票机制抑制虚假的伪标签奖励，实现更稳定和鲁棒的自我进化。论文通过在MATH-500、AMC和AIME 2024三个不同难度的数学基准测试上的实验，验证T3RL能够在各种backbone模型上实现一致的收益，特别是在更难的基准测试上获得更大的提升。
与已有工作不同的是，本文的独特切入角度在于首次将测试时验证引入到测试时强化学习框架中。现有研究主要集中在测试时扩展（Test-Time Scaling）中的验证机制，包括奖励模型、生成验证器、符号检查或多智能体系统，以及工具集成推理，但所有这些工作都聚焦于推理阶段的验证，用于评估额外计算的质量并从多个候选中选择最佳输出。相反，T3RL首次将验证应用于测试时训练，将采样rollouts通过验证转换为在线的、带有证据标签的训练实例，并通过验证来塑造训练过程。这种定位使T3RL本质上成为一个飞行的验证合成数据生成器，能够即时生成可靠的训练实例。与现有的测试时训练和测试时强化学习工作相比，T3RL是第一个提出测试时验证用于无标签自我进化的方法，特别是工具验证用于基于证据的自我进化。
核心方法
T3RL的整体思路是通过引入测试时工具验证来改善测试时强化学习中的奖励估计。其核心直觉是：当内省不可靠时，人类会通过与环境交互获取反馈来避免虚假假设的过滤，T3RL将这种人类学习机制引入到AI模型的自我进化中。T3RL在推理过程中评估LLMs推理路径的质量和合理性，通过外部验证打破自共识的闭环。具体技术路线是：在TTRL框架中集成三个核心组件——验证器、验证工具和验证权重，通过验证感知的加权投票来替代标准多数投票，将学习重心从频繁模式转移到验证模式。以数学问题为例，T3RL使用外部LLM作为验证器，将训练期间的rollouts转换为代码，并将推理轨迹中的计算卸载到代码解释器，从而减少虚假流行rollout主导奖励信号的可能性。
T3RL的核心创新点在于将工具验证集成到测试时强化学习的奖励估计中，通过验证加权的多数投票机制，将验证通过的rollout赋予更高的投票权重。这与TTRL使用标准多数投票（每个推理路径贡献相等权重）有本质区别。T3RL的关键创新体现在三个方面：第一，首次将测试时验证应用于测试时训练而非推理阶段，验证不再是为了选择最佳输出，而是为了塑造训练过程；第二，引入工具辅助验证，利用代码解释器提供确定性的、可执行的证据，而不仅仅依赖LLM的内部判断；第三，提出验证加权投票机制，通过超参数ω来控制验证rollout相对于未验证rollout的投票权重，实现从多数到验证的模式转变。这种设计使T3RL本质上成为验证的在线数据合成器，能够即时将采样rollouts转换为可靠的训练实例。
方法步骤详情
T3RL的方法步骤可以完整描述为以下四个阶段。首先，rollout采样阶段：给定输入提示x，从策略π_θ(·|x)中采样N个rollouts {y_i}_{i=1}^N，从每个rollout中提取候选最终答案â_i = Extract(y_i)。然后，验证阶段：验证器V评估每个rollout并返回一个三元组(a_i, v_i) = V(x, y_i)，其中a_i ∈ A是验证器派生的答案，v_i ∈ {0,1}表示rollout是否通过可执行检查。验证器执行三个任务：生成工具调用查询（将rollout推理转换为轻量级Python程序）、执行验证工具（代码解释器）、返回验证结果。接着，验证加权投票阶段：根据验证指示符v_i为每个派生答案a_i分配权重w_i = (1-v_i)·1 + v_i·ω，其中ω≥1是固定的标量超参数。验证感知的共识标签ỹ*通过最大化总加权投票质量获得：ỹ* = argmax_{a∈A} Σ_{i=1}^N w_i · 1[a_i = a]。最后，奖励计算和训练阶段：奖励信号保持二进制，但锚定到鲁棒的验证感知共识ỹ*，第i个rollout的奖励计算为r_{v_i} = 1[a_i = ỹ*]。训练目标保持TTRL形式不变，但使用验证感知的伪标签：max_θ E_{y∼π_θ(·|x)}[r_v(x, y)]，θ ← θ + η∇_θ E[r_v(x, y)]。
技术新颖性
T3RL的技术新颖性体现在多个方面。首先，T3RL首次将测试时验证框架应用于测试时训练而非推理，验证的目的是塑造训练过程而非选择最佳输出，这在自我进化人工智能时代是一个全新的研究方向。其次，T3RL引入了验证加权投票机制，通过超参数ω实现软偏好的奖励信号，避免了二元硬过滤的脆弱性，这是对传统多数投票机制的重要改进。第三，T3RL将工具验证整合到奖励估计中，利用代码解释器的可执行证据提供比模型自验证更可靠的信号，这开创了工具验证用于奖励塑造的新范式。第四，T3RL本质上是一个验证的在线数据合成器，能够即时将采样rollouts转换为可靠的训练实例，这为无监督学习提供了新的数据生成思路。最后，T3RL在数学推理任务上系统验证了验证对于更难基准测试和更大rollout预算的有效性，揭示了测试时计算在验证和扩展之间的最优分配策略。
![T3RL: Tool Verification for Test-Time Reinforcement Learning. Verifier: an LLM verifier parses each sampled rollout y_i into an answer â_i and examine the returned execution result a_i, yielding a validity flag v_i for each rollout. Tool verification: the verifier compiles the rollout's claimed computations into lightweight Python and queries a code interpreter to obtain executable evidence of a_i. Verification weighted majority voting: A verification-aware pseudo-label Ỹ* is formed that verified rollouts receive w_i vote mass and unverified rollouts receive a unit vote, and assign binary rewards r_{v_i} = 1[a_i = Ỹ*] for test-time RL updates.](/papers/2603.02203/images/figure_2..jpg)
实验结果
T3RL在三个数学推理基准测试和多种backbone模型上实现了相对于TTRL的一致性能提升。在MATH-500（最简单）、AMC（中等）、AIME 2024（最难）三个基准测试上，T3RL对Qwen-Math-1.5B的提升分别为：MATH-500从73.0到74.6（+2.2%），AMC从48.9到50.9（+4.1%），AIME 2024从15.8到20.8（+31.6%），平均提升为11.0%。更难的基准测试受益更多这一趋势在所有模型中一致：对Qwen-2.5-1.5B，T3RL在AIME 2024上的相对提升为+17.1%；对Llama-3.2-1B-Instruct，T3RL在AMC上的相对提升为+17.8%。数学专用backbone比通用模型受益更多：Qwen-Math-1.5B的平均提升为+6.3%，而Qwen-2.5-1.5B为+4.7%。消融研究表明：仅引入LLM验证器（无工具执行）就能改善TTRL，AIME和MATH都有提升；代码执行提供额外的可靠性提升，AIME从18.3提升到20.8（1.5B验证器）和从20.0提升到21.7（7B验证器）；验证权重ω=5达到最佳性能，欠权重（ω=2）和过权重（ω=10或∞）都会降低准确性。T3RL比TTRL更鲁棒：多次运行中，TTRL最佳准确率的标准差为2.638，方差为6.959，而T3RL分别为1.890和3.572。测试时计算分配分析显示，T3RL仅需N=16个rollouts就能超越TTRL@64，在N=32时饱和，匹配TTRL在AIME上的N=64性能。更强验证器提升性能：验证器从1.5B扩展到7B时，AIME 2024从20.8提升到21.7，AMC从50.9提升到51.5，MATH-500从74.4提升到74.9。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| MATH-500 | Accuracy | 74.6 (Qwen-Math-1.5B w/ T3RL) | 73.0 (Qwen-Math-1.5B w/ TTRL) | +2.2% |
| AMC | Accuracy | 50.9 (Qwen-Math-1.5B w/ T3RL) | 48.9 (Qwen-Math-1.5B w/ TTRL) | +4.1% |
| AIME 2024 | Accuracy | 20.8 (Qwen-Math-1.5B w/ T3RL) | 15.8 (Qwen-Math-1.5B w/ TTRL) | +31.6% |
| MATH-500 | Accuracy | 65.0 (Qwen-2.5-1.5B w/ T3RL) | 63.2 (Qwen-2.5-1.5B w/ TTRL) | +2.8% |
| AMC | Accuracy | 30.7 (Qwen-2.5-1.5B w/ T3RL) | 28.6 (Qwen-2.5-1.5B w/ TTRL) | +7.3% |
| AIME 2024 | Accuracy | 4.1 (Qwen-2.5-1.5B w/ T3RL) | 3.5 (Qwen-2.5-1.5B w/ TTRL) | +17.1% |
| MATH-500 | Accuracy | 42.2 (Llama-3.2-1B-Instruct w/ T3RL) | 40.0 (Llama-3.2-1B-Instruct w/ TTRL) | +5.5% |
| AMC | Accuracy | 19.9 (Llama-3.2-1B-Instruct w/ T3RL) | 16.9 (Llama-3.2-1B-Instruct w/ TTRL) | +17.8% |
| AIME 2024 | Accuracy | 8.3 (Llama-3.2-1B-Instruct w/ T3RL) | 7.5 (Llama-3.2-1B-Instruct w/ TTRL) | +10.7% |
局限与改进
T3RL存在几个重要的局限性。首先，T3RL依赖于验证器V提供有意义的正确性信号，当V能力不足时（如Qwen-Coder-0.5B），其工具调用会变得噪声很大。论文Table 4显示，使用0.5B验证器时，T3RL相对于TTRL的性能变化为：AIME 2024从0.4降到0.0（↓100.0%），AMC从12.0降到10.8（↓10.0%），MATH-500从34.6降到32.0（↓7.5%）。在这种情况下，验证感知投票可能会错误地加权rollouts（例如增加权重给虚假但自信预测的答案），实际上在自共识之上添加了另一个随机层。其次，在简单任务上，工具验证提供有限的边际收益。当任务足够简单以至于rollouts已经高度准确和一致时，自共识很少选择错误标签，在这种情况下，验证增加开销但不会显著改变伪标签分布，因此相对于TTRL的改进可能很小。第三，T3RL的计算开销来自于验证过程，包括验证器推理和代码执行，这会增加总的测试时计算成本。虽然论文显示T3RL可以通过减少rollout数量来部分抵消这一开销（T3RL@16超越TTRL@64），但在绝对计算量上仍然更高。最后，T3RL的验证机制可能继承其底层工具和数据源的偏差或漏洞，代码解释器的安全性也是一个潜在风险，恶意或构造的输入可能会触发安全问题。
独立分析的弱点
T3RL存在几个可以改进的弱点。首先，当前T3RL仅使用单一验证器，这可能导致验证器的系统偏差影响整个验证过程。改进方向是引入多验证器机制，类似多智能体验证，通过多个独立的验证器来交叉验证，减少单个验证器偏差的影响。其次，验证权重ω是一个全局固定超参数，但不同任务的验证可靠性差异很大。改进方向是自适应验证权重，根据验证器的置信度或rollout的难度动态调整ω值，更智能地平衡验证信号与多样性。第三，当前验证器仅使用代码解释器作为验证工具，限制了可验证任务的范围。改进方向是扩展验证工具的类型，例如引入符号验证器、形式化验证器或模拟器，使T3RL能够应用于更广泛的任务领域，如物理推理、代码生成或逻辑推理。第四，T3RL的验证过程是顺序的，每个rollout需要单独验证，这限制了并行化效率。改进方向是批处理验证和缓存机制，对于相似的推理路径可以复用验证结果，提高计算效率。最后，当前T3RL主要针对数学推理任务设计，在其他领域的适用性尚未充分验证。改进方向是探索T3RL在自然语言推理、代码生成、多模态推理等任务中的应用，并设计相应的验证工具。
未来方向
未来的研究方向可以从几个方面展开。首先，作者提出可以集成各种形式的测试时验证方法到无标签自我进化中，这包括探索更多的验证工具类型（如符号验证、形式化验证、模拟验证）和多验证器机制。其次，基于T3RL的成果，可以研究如何将验证机制应用于更广泛的自进化场景，例如在持续学习、在线学习或 lifelong learning 中的自我纠错和自我改进。第三，可以深入研究测试时计算在验证和扩展之间的最优分配策略，开发自适应计算分配算法，根据任务难度、验证器能力和rollouts质量动态调整采样数量和验证力度。第四，可以探索更强的验证器设计，包括如何训练专门用于验证的模型、如何设计更有效的验证提示词、如何结合检索增强验证等。第五，可以研究如何提高验证器对对抗性或噪声反馈的鲁棒性，包括检测和缓解验证器的偏差、设计更安全的验证工具、以及建立验证结果的置信度估计机制。第六，可以将T3RL与其他自进化方法结合，例如与课程学习、经验回放或元学习结合，实现更稳定和高效的自我进化。最后，从更广泛的角度，T3RL为智能系统的工具交互提供了新的视角，未来可以探索如何将验证机制应用于越来越依赖工具交互但需要可靠奖励信号的智能系统中。
复现评估
论文的复现性评估如下。作者承诺代码将在论文链接处发布，这提供了基本的复现基础。论文使用了公开可用的数学推理基准测试：AIME 2024、AMC和MATH-500，这些数据集都是公开可访问的。论文详细描述了实验设置：使用GRPO（Shao et al., 2024）实现T3RL，通过AdamW使用余弦调度训练（峰值学习率：5 × 10^{-7}），使用1B和1.5B验证器。遵循TTRL的vote-then-sample策略：使用64个响应进行标签估计（温度0.6），下采样到32个用于训练。最大token长度为2,560。验证器的最大生成长度为1,024 token，所有基准测试使用温度0.6。训练运行在8个NVIDIA A100 GPU上，根据数据集大小变化episode数量：10（MATH-500）、30（AMC）和80（AIME 2024）。论文提供了详细的验证器系统提示词（Figure 10），这对复现验证机制至关重要。论文还提供了验证器的失败案例分析（附录B），包括弱验证器的两种主要失败模式：盲目复制和硬编码输出、格式化和编译错误。总的来说，论文提供了足够的实现细节和资源描述，复现难度中等，主要挑战在于计算资源的可获得性（8个A100 GPU）和验证器的选择与配置。
论文图表
Figure 1展示了T3RL的核心概念。顶部部分说明了多数投票伪标签可能是虚假的：真实标签是C，但采样预测中B出现频率最高（B B B B），因此估计标签为B，这是一个错误的多数投票。底部部分展示了T3RL如何通过工具执行证据（如代码解释器）将测试时验证引入自我进化，使用验证的rollout来稳定训练。右侧部分展示了T3RL在不同模型上的性能提升：Qwen-Math-1.5B在AIME 2024上从15.8提升到20.8（+31.6%），Qwen-2.5-1.5B在AIME上从3.5提升到4.1（+17.1%），Llama-3.2-1B-Instruct在AMC上从16.9提升到19.9（+17.8%）。
这张图对理解论文至关重要，因为它直观地展示了T3RL要解决的核心问题（虚假流行伪标签）和解决方案（工具验证），同时提供了关键的性能数据。这张图在论文一开始就确立了T3RL的动机和有效性，为读者提供了清晰的整体概念。
Figure 3展示了TTRL中虚假奖励的自我强化循环。顶部部分显示真实标签是C，但虚假流行预测中B出现频率最高（B B B B），因此B被选为估计标签，估计奖励中B获得1而C获得0。底部部分显示在第N轮，采样预测中B的频率进一步增加（B B B B B B B B），形成自我强化的反馈循环，不正确的模式崩溃被不断强化。图中标注了'B is good!'和'B is really good!'，体现了模型对错误答案越来越自信。
这张图对理解论文要解决的核心问题至关重要，它直观地展示了虚假流行模式崩溃是如何在TTRL中形成和自我强化的。这张图帮助读者理解为什么需要引入外部验证机制来打破这个恶性循环。
Figure 8展示了工具位置和训练鲁棒性的消融实验。图(a)比较了工具调用与验证（相对于TTRL）：TTRL-AGENT（允许策略在rollouts期间直接调用工具）相对于TTRL性能下降，而T3RL通过将工具使用限制在验证器用于奖励塑造实现了一致的正收益，并且收益相对于基准测试难度增加。这表明在rollouts内部的工具调用混合了推理错误和工具使用错误，而T3RL将推理与工具执行解耦。图(b)的训练鲁棒性比较显示，TTRL在多次运行中表现出明显的运行间变异性，而T3RL的验证器重构投票产生了明显更低的峰值性能离散度。
这张图对理解T3RL的设计选择和鲁棒性至关重要。图(a)解释了为什么工具应该作为验证证据而不是策略动作，图(b)展示了T3RL比TTRL更鲁棒。这张图支撑了论文关于T3RL设计合理性和稳定性的主张。
Figure 9展示了改进T3RL的两个方向。图(a)显示增加rollout预算提高性能：T3RL随着rollout预算N的增加（N∈{16, 32, 64}）持续提升，因为更大的候选集增加了解决方案多样性，使验证感知投票更样本高效。图(b)显示缩放验证器在基准测试上增强性能：验证器从1.5B扩展到7B时，AIME 2024从20.8提升到21.7，AMC从50.9提升到51.5，MATH-500从74.4提升到74.9，这表明更强的验证器提供更可靠的答案标准化和置信度估计，加强了验证感知投票和奖励信号。
这张图对理解如何进一步提升T3RL性能至关重要。图(a)说明了rollout预算的影响，图(b)说明了验证器规模的影响。这张图为读者提供了改进T3RL的实际指导方向。
Table 4展示了使用弱（0.5B）验证器时的失败案例。对于Qwen-2.5-0.5B Vanilla，Baseline在AIME 2024、AMC、MATH-500上的准确率分别为0.0、4.8、7.9，TTRL为0.4、12.0、34.6，T3RL（0.5B验证器）为0.0、10.8、32.0。T3RL相对于TTRL的变化为：AIME 2024下降-0.4（↓100.0%），AMC下降-1.2（↓10.0%），MATH-500下降-2.6（↓7.5%）。这表明当验证器能力不足时，T3RL相对于TTRL的性能会下降。
这个表格对理解T3RL的局限性至关重要，它展示了弱验证器如何导致性能下降。这个表格支撑了论文关于T3RL需要最小阈值验证器容量才能有效工作的主张，帮助读者理解T3RL的适用条件和潜在风险。
Figure 10展示了验证器的系统提示词。提示词的关键设计选择包括：角色分配，指导模型扮演'专家数学家和Python程序员'，为生成严格、高质量的脚本公式化设定强先验；独立重新计算，通过明确说明'DO NOT assume the reasoning trace is correct'和'Prefer recomputing the answer directly'来缓解确认偏差，防止验证器盲目地将有缺陷的推理轨迹转换为代码；轨迹作为提示，允许验证器使用候选轨迹作为'提示'来帮助它导航复杂问题。提示词还规定了代码要求：使用单一Python块，格式为```python CODE```，允许的模块为math, sympy, numpy, fractions，代码必须只打印最终计算结果，如print(result)，不打印硬编码值。
这个图对理解如何实现验证器至关重要，它展示了验证器系统提示词的详细设计。这个提示词是T3RL验证机制的关键组件，帮助读者理解如何确保验证器的可靠性和独立性。
Figure 11展示了部署欠尺寸验证器时遇到的两种主要失败模式的定性示例。图(a)显示盲目复制和硬编码输出：尽管系统提示词中明确说明了'DO NOT assume the reasoning trace is correct'和严格输出硬编码值，但0.5B验证器经常表现出严重的指令遵循失败。模型通常完全倾向于提供的候选轨迹，在Python注释中产生伪推理，并绕过实际计算，产生一个仅仅执行轨迹最终答案的硬编码print语句的脚本。图(b)显示格式化和编译错误：0.5B验证器无法一致地遵循结构指南，难以维护有效的Python语法，导致编译和执行错误频率增加。
这个图对理解T3RL的局限性至关重要，它直观地展示了弱验证器如何失败。这个图支撑了论文关于T3RL需要最小阈值验证器容量的主张，帮助读者理解为什么过小的验证器会引入噪声而不是可靠证据。