Jiahong 的个人博客

凡事预则立,不预则废


  • Home

  • Tags

  • Archives

  • Navigation

  • Search

NLP——RLAnything

注:本文包含 AI 辅助创作

  • 参考链接:
    • 原始论文:RLAnything: Forge Environment, Policy, and Reward Model in Completely Dynamic RL System, Princeton, 20260202, Yinjie Wang

Paper Summary

  • 整体总结:
    • RLAnything 是一个针对任意 LLM 或 Agentic 场景都可以做 RL 训练的框架
    • RLAnything 使用整合的监督训练策略,并通过一致性反馈改进奖励模型,在整个训练过程中提供更强、更可靠的信号
    • RLAnything 包含了 策略 和 奖励模型 的同时学习
      • 奖励模型的训练是通过奖励信号学习的
    • 整合了 Step-wise 和 Outcome 的反馈信号
    • 号称通过本文方法优化 的奖励模型信号 优于 人工标注的结果信号(注:这一点其实存疑)
    • 本文还会动态调整训练环境:
      • 本文证明了一个结论:对于任何目标策略来说,过于简单或者过于复杂的环境都不适合做这个策略的 RL 训练
    • In Summary,RLAnything 使环境、策略和奖励模型能够相互提供反馈,从而增强学习信号并改进整个系统
  • 具体描述:
    • RLAnything 通过 Closed-loop Optimization 动态地优化环境 、策略 和奖励模型 ,放大学习信号并增强整个 RL 系统在任意 LLM 或智能体场景下的能力
    • 本文包含多个 Features,实验对各种做了详细的 Ablation
    • OSWorld 上, Qwen3-VL-8B-Thinking 的性能提升了 \(9.1%\)
    • AlfWorld 和 LiveBench 上,分别将 Qwen2.5-7B-Instruct 的性能提升了 \(18.7%\) 和 \(11.9%\)
  • 图 1:RLAnything 框架的总结性实验结果和关键 Insight
    • 1)联合优化奖励模型和环境,反过来有益于策略的学习曲线,从而获得更高的收敛精度
    • 2)来自优化后奖励模型的 Step-wise 信号优于人工标注的结果信号
      • 此外,还可以观察到整合后的反馈对于长轨迹任务至关重要
    • 3)RLAnything 在多种现实应用中的验证
    • 4)新的环境任务呈线性扩展,奖励模型在评估当前步骤的正确性和对结果的影响方面都变得更强大

Introduction and Discussion

  • 背景:
    • RLVR 效果不错,但在策略与环境进行长轨迹的迭代交互时,仅靠二元结果奖励提供的监督是不足的 (2023; 2025; 2024)
    • Step-wise 信号通常由生成式奖励模型提供,这些模型通过利用语言模型的推理能力,往往优于基于标量的模型 (2025; 2024)
      • 但训练这些模型通常需要收集高质量的、特定于任务的监督数据 (2025; 2025)
    • 结论:需要一个更自动化方法和可扩展的监督
  • 环境的质量对于扩展强化学习也很重要
    • 举例1:将任务难度与模型当前能力对齐已知能改善训练动态 (2025; 2025)
      • 在 RLVR 中,在优化过程中调整任务难度可以改善策略训练 (2025)
    • 举例2:在现实世界的环境中,探索的范围很大程度上由任务定义
      • 例如用于 GUI 智能体的计算机 (2025a; 2024) 或用于机器人的物理世界 (2013),
      • 通过增加任务多样性来扩展环境可以进一步促进策略在更广泛场景下的泛化能力 (2025; 2025; 2020; 2025; 2026; 2021)
  • 核心问题提出:是否存在一个可以联合优化环境、策略和奖励模型的 RL 系统,能用于放大学习信号并强化整个系统?
  • RLAnything 就是这样一个动态的 RL 框架,可以在闭环系统中 Forge 环境、策略和奖励模型
    • 每个组件持续接收来自其他组件的反馈,在各种复杂的 LLM 或智能体场景中放大学习信号
    • 策略训练:使用整合后的反馈进行训练
      • 该反馈结合了可验证的结果奖励和奖励模型提供的 Step-wise 信号
    • 奖励模型训练:通过基于结果和自洽性(self-consistency)的一致性反馈进行联合优化
      • 这样可产生可靠的 Step-wise 监督,这反过来又改善了策略学习
    • 奖励模型训练改进:
      • 基于理论结果分析得到结论:平衡任务难度不仅有益于策略训练,也有益于 RL 系统中的奖励模型训练
    • 环境任务调整:
      • 基于来自策略和奖励模型的 Critic 反馈来调整环境任务,实现精确和自动的任务调整
      • 将奖励模型总结出的、捕捉策略失败原因的信息输入到一个语言模型中,以扰动任务,为如何修改任务提供具体指导
  • RLAnything 是通用的,在多种场景中进行了验证:
    • Compute use (2024)
    • Text-based Interactive Games (2018; 2020)
    • Coding LLM 场景
  • 主要贡献总结:
    • (个人补充)作者通过大量实验观察到了一些关键 Insight
    • 作者提出了动态 RL 系统 RLAnything,通过闭环优化 Forge 环境、策略和奖励模型,以放大学习信号并强化整个系统
    • 作者多个场景(Compute-use Agent、Text-based LLM 智能体和 Coding LLM)实验中,展示了每个添加的动态组件都持续地有益于整个系统,并提升了 OOD 性能
    • 实验指标显著提升:
      • 在 OSWorld 上,Qwen3-VL-8B-Thinking 的性能提升了 \(9.1%\)
      • 在 AlfWorld 和 LiveBench 上,Qwen2.5-7B-Instruct 的性能分别提升了 \(18.7%\) 和 \(11.9%\)
    • 展示了广泛的适用性: Optimized RM 信号优于依赖人工标注的结果信号,使得从经验中主动学习(active learning)和环境扩展成为可能

RLAnything

  • RLAnything(参见算法 1)将策略模型、奖励模型和环境紧密结合,以实现联合优化
  • 具体方法:
    • 使用整合后的反馈(第 2.1 节中的公式 1)来训练策略
      • 反馈结合了来自奖励模型的 Step-wise 信号和 Trajectory-level 的结果信号
    • 通过将策略的轨迹视为环境任务,并通过公式 2 分配一致性反馈来训练奖励模型
      • 作者在第 2.3 节中证明,这个目标也能提高奖励模型预测最终结果的准确性
    • 随着奖励模型变得更准确,它反过来为策略提供了更强、更具信息量的学习信号
    • 调整环境任务的难度不仅有益于策略训练,也有益于奖励模型训练
  • 为了实现自动化和有针对性的调整,具体的任务修改由从奖励模型的评估响应中总结出的 Critic 反馈来指导(第 2.4 节)

Integration Feedback for Policy

  • 给定一个任务 \(q \in Q\) 和一个策略 \(\pi\),采样一个轨迹 \(\tau \sim \pi(\cdot | q)\) 并获得一个最终结果奖励
    $$ O_{\tau} \in \{- 1, 1\} $$
  • 对于第 \(i\) 步 \(\tau_{i}\),独立用奖励模型进行 \(m\) 次打分 ,得到
    $$S_{\tau_{i,j} } \in \{- 1, 1\}$$
    • 其中 \(j = 1, \ldots , m\),这里的 \(-1\) 表示未向最终目标推进或是一个 Step-wise 错误
  • 本文将步骤奖励定义为:
    $$R_{\tau_i} = O_{\tau} + \frac{\lambda}{m}\sum_{j = 1}^{m}S_{\tau_{i,j} } \tag {1}$$
    • 该公式将结果信号与细致的 Step-wise 反馈结合起来
    • 默认情况下设 \(\lambda = 1\)
    • 理解:当前设置下, Step-wise 的反馈奖励 和 Outcome 奖励各占一半融合(注,Step-wise 是 \(m\) 次采样得到的)
  • 通过在相同步骤索引 \(i\) 上的轨迹集合(即 \(\{R_{\tau_i}: \tau \sim \pi(\cdot | q)\}\))中对奖励进行标准化来计算优势(advantages)
    • 补充理解:这也是后来在 OpenClaw-RL 中使用的 Step-level 归一化方法(可能存在归一化时状态不一致的问题,理论上最优的归一化方式是在相同的 状态下才可以)
    • 注意:这里起始的状态是相同的(即 \(q\) 相同),但中间步骤的状态会不同
      • 若果 \(q\) 不同是不行的,状态差异太大了

Consistency Feedback for Reward Model

  • 对于轨迹的第 \(i\) 步 \(\tau_{i}\),奖励模型 \(r_{\phi}\) 的第 \(j\) 次打分(总共 \(m\) 次)为 Step-wise 标签 \(S_{\tau_{i,j} }\),并接收以下奖励信号:
    $$R_{\tau_{i,j} } = R_{\tau_{i} }\cdot S_{\tau_{i,j} } \tag {2}$$
    • 注:前一节中可以知道:
      • \(R_{\tau_i} = O_{\tau} + \frac{\lambda}{m}\sum_{j = 1}^{m}S_{\tau_{i,j} }\) 是包含了 Step-wise 和 Outcome 的融合奖励
      • \(S_{\tau_{i,j} } \in \{- 1, 1\}\) 是 Step \(i\) 下,奖励模型第 \(j\) 次打分得到的结果
    • \(R_{\tau_{i} }\in [- 1,1]\) ,反映了步骤 \(\tau_{i}\) 的整体质量
      • \(R_{\tau_{i} }< 0\) 表示质量差
      • \(R_{\tau_{i} } > 0\) 表示质量好
      • \(R_{\tau_{i} }\) 的值越接近 0,表示对该步骤的不确定性越大(可能好也可能坏,不好区分)
    • 这个 Step-wise 信号与第 \(j\) 次评估之间的一致性由 \(R_{\tau_{i} }\cdot S_{\tau_{i,j} }\) 捕获,本文将其用作该评估的监督信号
      • 问题:这里的表述不太清晰,如何理解这里的一致性?
  • 在策略优化过程中,策略的轨迹也充当奖励模型的训练环境(即 RM 也是动态更新优化的)
    • Refined 奖励模型为策略提供更强的奖励信号,并为指导环境任务调整提供更准确的反馈,这反过来又促进了策略和奖励模型的训练

Adaptation of Environment Benefits Both Policy and Reward Models,环境调整有益于策略和奖励模型

  • (本节中作者证明了优化上一节的这个目标可以提高奖励模型预测未来结果的准确性,并且本文的环境调整进一步促进了这种优化)
  • 本节目标:证明 对于任何目标策略来说,过于简单或者过于复杂的环境都不适合做这个策略的 RL 训练
  • 奖励模型信号的质量不仅取决于单个步骤的逻辑正确性,还取决于它预测该步骤未来影响的能力
  • 本文希望优化以下奖励精度:
    $$\mathcal{A} = P(S_{\tau_{i}^{+} } > S_{\tau_{i}^{-} }|O_{\tau^{+} } = 1,O_{\tau^{-} } = -1),$$
    • 其中 \(S_{\tau_{i} } = \frac{\sum_{j = 1}^{m} S_{\tau_{i,j} }}{m}\) 是由 \(r_{\phi}\) 分配的平均过程奖励
    • 理解:这个指标 \(\mathcal{A} > 0\) 的本质是:最终成功的轨迹的 Step-wise 奖励 大于 最终失败的轨迹的 Step-wise 奖励(这里使用概率来表达)
  • 定理 1 证明了这个奖励精度可以转化为一个可以通过本文的奖励设计来近似的目标:
    $$\mu \triangleq p_{+} + p_{- }$$
    • 其中 \(p_{+} = P(S_{\tau_{i}^{+},j} = 1)\) 和 \(p_{- } = P(S_{\tau_{i}^{-},j} = -1)\)
    • 注:这个精度是用于衡量环境是否合适的(不同策略下,需要用不同的环境训练,即最适配策略优化的环境应该是在训练过程中动态变化的)
  • Theorem 1
    • 当 \(m \rightarrow \infty\) 时,当且仅当 \(\mu > 1\) ,有 \(\mathcal{A} \rightarrow 1\)
    • 当 \(\mu > 1\) 时,\(\mathcal{A} \geq 1 - e^{- m(\mu - 1)^{2} / 4}\)
    • 目标 \(\mu = p_{+} + p_{- }\) 表明,用于估计 \(p_{+}\) 和 \(p_{- }\) 的采样密度应该平衡,而不是严重偏向某一侧;
      • 否则,估计器可能被单一类别主导,导致评估偏差
    • 然而,当由策略轨迹诱导的奖励模型训练环境在任务难度上不平衡时,这种平衡就可能被打破
  • Theorem 2
    • 目标如下:
      $$\mathbb{E}_{\tau \sim \pi_{\theta}(\cdot |q)}\mathbb{E}_{S_{\tau_{i,j} }\sim r_{\phi}(\cdot |\tau_{i})}[R_{S_{\tau_{i,j} } }] = 4\mathbb{E}_{q\sim Q}[\langle p_{+},f_{+}\rangle + \langle p_{-},f_{-}\rangle ] + C,$$
      • \(f_{+} \geq 0\) 和 \(f_{- } \geq 0\) 是 \(\tau\) 的重要性权重函数
      • \(\langle \cdot , \cdot \rangle\) 表示在 \(\tau \sim \pi_{\theta}(\cdot | q)\) 上的 \(L^{2}\) 内积
        • 问题:如何理解这里的内积含义?【这里写的晦涩难懂,符号也不太清晰,后续可以回来重新看看】
      • \(C\) 是与 \(\phi\) 无关的常数,且 \(| \cdot |\) 是 \(L^{2}\) 范数
    • 上式左边 :
      • 是奖励模型的 RL 目标
    • 上式右边 :
      • 【来自原文的奇怪描述】当 \(\lambda = 1\) 时,有右边的式子:
      • 理解:这里的 \(\lambda\) 是公式 1 中提到的 Step-wise 奖励与 Outcome-wise 奖励的加权系数
      • 当 \(P(O_{\tau} = - 1 | q, \pi_{\theta}) \rightarrow 1\):重要性权重的范数比 \(\frac{| f_{+} |}{| f_{- } |} \rightarrow 0\)
      • 当 \(P(O_{\tau} = 1 | q, \pi_{\theta}) \rightarrow 1\):\(\frac{| f_{+} |}{| f_{- } |} \rightarrow \infty\)
  • 这证明:
    • 当一个任务 \(q\) 对于策略模型来说过于困难(即 \(P(O_{\tau} = - 1 | q, \pi_{\theta}) \rightarrow 1\))或过于容易(即 \(P(O_{\tau} = 1 | q, \pi_{\theta}) \rightarrow 1\))时
      • \(p_{+}\) 和 \(p_{- }\) 之间的重要性采样变得极度不平衡,违反了定理 1 中建立的奖励精度目标 \(p_{+} + p_{- }\)
    • 基于这一 Insight,在本文的奖励系统中, 调节任务 \(q\) 的难度不仅可以促进策略训练,还可以改善过程奖励模型的训练

Critic Feedback for Environment Tasks

  • 本文使用策略的 Rollout 准确率来估计任务难度
    • 当准确率落在预设的阈值(\(\alpha_{\mathrm{low} }\) 和 \(\alpha_{\mathrm{high} }\))之外时
      • 会 Prompt 一个语言模型来修改任务,使其更难或更容易,同时保留原始任务的本质(参见附录 C.7 中的提示词)
    • 具体的修改由从奖励模型 \(r_{\tau_{i,j} }\) 总结出的评估痕迹(evaluative traces)来指导,这些痕迹是在获得 \(S_{\tau_{i,j} }\) 时生成的
  • 本文只总结那些表现出潜在失败的步骤 \(\tau_{i}\),即对于某些 \(j\) 满足 \(S_{\tau_{i,j} } = - 1\) 的步骤,以捕获策略可能的错误模式(附录 C.6)
    • 因此,任务调整依赖于准确的 Critic 反馈,并反过来产生更有效的调整,使策略和奖励模型都受益
  • 作者还对修改后的任务实施质量控制
    • 如果目标是使原始任务 \(q\) 更难,仅在 满足下面准确率 时接受修改后的任务 \(q^{\prime}\)
      $$ \alpha_{\mathrm{low} }< \mathrm{acc}(q^{\prime})< \mathrm{acc}(q) $$
    • 如果目标是使其更容易,仅在 满足下面准确率 时接受 \(q^{\prime}\)
      $$ \mathrm{acc}(q)< \mathrm{acc}(q^{\prime})< \alpha_{\mathrm{high} } $$
    • 这有助于确保新任务的有效性和调整的有效性(算法 1)
  • 然后将原始任务替换为任务集 \(Q\) 中被接受的任务 \(q^{\prime}\)

Experiments

  • 本节重点关注两种现实世界的智能体设置:
    • Compute use 代理和基于文本的交互式游戏,其中大型语言模型既用作策略也用作奖励模型,并且作者执行自动环境适应
  • 此外,还验证了 RLAnything 框架在 RLVR 编码任务上的有效性
    • 注:该任务中没有可用的交互环境

Experiment Settings

Models and Optimizations
  • 对于 OSWorld (2024) 上的 GUI 代理
    • 使用 Qwen3-VL-8B-Thinking 作为策略和奖励模型
    • 将评估的最大交互步数设置为 50,将 RL Rollout 的最大步数设置为 30
    • 在每个 RL 步骤中,采样 12 个任务,每个任务有 8 个独立的 Rollout 轨迹
    • 对于奖励模型,对每个策略 Response 执行 3 次评估
    • 使用 Qwen3-4B (2025) 进行任务适应
  • 对于 AlfWorld (2018; 2020) 上的 LLM 代理
    • 使用 Qwen2.5-7B-Instruct 作为策略模型
    • 使用 Qwen2.5-14B-Instruct 作为奖励模型 (2024a)
    • 使用 Qwen3-4B (2025) 进行任务适应
    • 将评估的最大步数设置为 60,将 RL Rollout 的最大步数设置为 40
    • 在每个 RL 步骤中,采样 16 个任务,每个任务有 8 个独立的 Rollout
  • 对于 Coding LLM
    • 使用与 AlfWorld 设置中相同的模型组合
    • 在每个 RL 步骤中,采样 64 个任务,每个任务有 32 个独立的代码解决方案生成和 32 个独立的单元测试生成
Training and Evaluation Datasets
  • 在每个设置中,使用单独的训练和测试数据集
  • 对于 GUI 代理,划分 OSWorld-verified 数据集,使得训练集排除 “Multiple Apps” 和 “Chrome” 任务类别,将其视为最终评估中的 OOD 任务
    • 在 230 个域内任务和 139 个 OOD 任务上进行评估
  • 对于 AlfWorld,遵循官方设置:
    • 任务被划分为 3.5k 个训练任务、140 个域内评估任务和 134 个 OOD 评估任务
  • 对于 Coding LLM ,使用 LiveCodeBench-V2 (2024)、CodeContests (2022) 和 LiveBench (2024) 进行评估,并使用 CodeContests (2022) 进行训练
    • Specificlly 对于 CodeContests,提取难度级别 \(\le 2\) 的任务,并将其随机划分为包含 4.5k 个样本的训练集和包含 200 个样本的评估集
Reward Modeling
  • 对于奖励建模,使用 LLM 作为生成式奖励模型:
    • Prompt LLM 评估每个步骤的质量及其对最终结果的潜在影响,然后在推理后输出 1 或 -1(附录 C.5)
  • 对于 GUI 代理,提供先前操作的摘要、最近的两张图像以及要评估的这两张图像之间的操作作为上下文
  • 对于 AlfWorld,总结了先前的操作及其观察到的结果
  • 在 Coding-LLM 设置中,使用单元测试生成器作为奖励模型,其中每个新生成的测试评估代码的一个方面
  • 在本文所有的实验中,奖励模型为每个策略步骤生成 3 个独立的评估(即 \(m = 3\))
Environment Task Adaptation
  • 在环境适应之前
    • 首先总结奖励模型的输出,这些输出针对被标记为潜在错误的步骤,定义为至少有一个最终得分为 -1 的步骤(附录 C.6)
    • 然后将此 Critic 反馈输入到语言模型中,以根据目标扰动重写任务,使其更容易或更难(附录 C.7)
  • 在 Coding-LLM 设置中,Critic 反馈仅仅是代码在生成的单元测试上的评估结果
  • 在 AlfWorld 设置中,环境模型使用 Critic 反馈和对当前环境的结构化摘要(包括对象位置和属性)重写任务
  • 在编码设置中,环境模型生成一个新任务以及相应的单元测试
  • 在 GUI 设置中,除了使用 Critic 反馈添加或移除提示来调整难度外,适应不同的目标需要创建新的验证文件
  • 本文为 230 个训练任务中的 47 个预先创建了额外的扰动版本(附录 C.8)
    • 每个扰动版本都包含其对应的评估器和验证器文件
  • 这些任务被包含在本文实验中所有训练设置中,以确保公平比较

Results and Insights

RLAnything Facilitates Policy Training,RLAnything 能促进策略训练
  • 图 4 中报告了三个训练曲线,其中每个方法都添加了一个额外的动态组件
    • 图 4 展示了每个动态组件都能持续改进策略优化
  • 对于曲线上的中间评估,将 OSWorld 的最大交互步数设置为 30,将 AlfWorld 的最大交互步数设置为 60
  • 可以发现,使奖励模型和环境都保持动态能产生更强的优化和更高的收敛点
    • 具体来说,联合优化奖励模型改善了监督信号,这反过来又有利于策略训练
  • 此外,环境适应不仅有利于策略,也有利于奖励模型(第 3.2.2 节),从而为策略训练带来三倍的增益
    • 表 1 中报告了域内和 OOD 任务的最终评估结果
    • 在 OOD 任务上的显著改进突显了作者优化框架更强的泛化能力
RLAnything Produces a Stronger Reward Model,产生更强的奖励模型
  • 从表 1 中可得出两个结论
    • 第一,本文的奖励设计(公式 2)有效地改进了奖励模型
    • 第二,适应环境任务进一步促进了奖励模型的训练,支持了本文的理论结果
  • 为了评估奖励模型的改进,本文考虑两个方面:
    • (i) 其评估步骤质量的能力(过程准确性)
    • (ii) 其预测步骤对最终结果影响的能力(结果准确性)
  • 标签来源:
    • 结果准确性的真实标签来自可验证的结果
    • 步骤质量标签是通过对提示评估步骤质量的更强推理模型进行多数投票获得的
    • 详情见附录 C.2
  • 从表 1 中,可以发现这两个准确性指标在所有设置优化后都有所提高,并且环境适应进一步提升了它们
  • 此外,本文还使用不同的监督模型进行了消融研究,结果见附录 B.1,显示了类似的结果
Adaptation of Environments Enables Active Learning from Experience,环境 Adaptation 允许从经验中 主动学习
  • 作者的环境适应是自动化的,并明确由奖励模型的 Critic 反馈指导,该反馈诊断策略在给定任务上可能出现的错误
  • 本节提供示例,展示这种有针对性的适应如何促进更主动的策略学习
  • 在图 3 的示例中
    • GUI 代理在独立的 Rollout 中未能获得任何成功的轨迹
      • 奖励模型指出了策略在此任务上犯的两个具体错误,其输出作为重写任务的诊断反馈
      • 修改后的提示添加了有针对性的提示,使策略能够实现成功的 Rollout 并更有效地学习,而不是依赖随机探索
      • 注:任务也可以向相反方向调整,以鼓励更具挑战性的探索
    • 在交互式文本游戏示例中,策略在所有轨迹中都成功了,但花费了大部分步骤来搜索对象
      • 模型通过用出现频率较低的目标对象替换当前对象来增加难度
      • 参见附录 B.2 中的其他示例
State-of-the-Art Performance of the Optimized Multimodal GUI Agent,优化后的多模态 GUI Agent 到达 SOTA 性能
  • 本文进一步扩展了 GUI 代理的 RLAnything 优化(图 8,左),并将其与开源基线进行比较,包括 UI-TARS1.5-7B (2025)、OpenCUA-7B (2025b) 和 Qwen3-VL-8B-Thinking (2025)
    • 注:图 8 左给出的是训练 ACC 曲线,可以看到训练过程中 ACC 指标是一直在涨的
  • 如图 5 所示,优化后的模型在所有 OSWorld 任务类别中都取得了显著性能,突显了作者优化框架的有效性
    • 优化后的模型在 OSWorld 上的准确率提高了 9.1%
    • 在分布外任务上,模型也提高了 5.2%
Advantages of Integrating Step-wise and Outcome Rewards for Policy Training,整合 Step-wise 和 Outcome 奖励
  • 在复杂的现实世界环境中,策略必须与环境交互,在长轨迹上进行充分探索(见图 6(b)), Outcome Reward 过于稀疏,无法提供有效的训练信号
  • 将常用的 Outcome-only Reward 与本文的整合奖励设计(公式 1)在 LLM 代理和 GUI 代理设置的 RL 训练曲线(图 6(a))上进行了比较
    • 问题:这里最优的方案是 Optimized Step-wise Reward Only,但是没有非常明确给出这个奖励的定义,是 Step-wise 标准化以后得到的奖励吗?
  • 结果突显了整合奖励的必要性,它将细微的逐步信号与可验证的最终结果的忠实监督相结合
Optimized Reward Model Supervision Outperforms Human-Labeled Outcome Supervision,Optimized RM 超过人工打标的 Outcome 监督
  • 在 Compute use 任务等复杂的现实世界环境中,定义可验证的结果通常需要人工努力
  • 特别是,GUI 评估器通常实现为人工编写的评估脚本,这限制了用于探索和训练的环境扩展
  • 本文提议仅使用 Optimized RM 提供的逐步信号,该模型可以评估当前操作及其未来影响
    • 具体来说,仅使用本文的 Optimized RM 进行逐步监督来训练策略,而不使用来自评估器脚本的任何 Outcome Reward
    • 令人惊讶的是,这种设置甚至优于使用可验证 Outcome Reward 的训练(见图 6(a)),展示了本文的框架在改进奖励模型方面的有效性,以及其在计算机等现实世界环境中实现大规模、自我进化代理的潜力
Also Works for Single-Turn Coding Tasks,单轮 Coding 任务也 Work
  • 除了交互式设置外,RLAnything 也适用于 RLVR 风格的编码任务:
    • 策略奖励是代码在单元测试上的通过率
  • 按如下方式为每个生成的单元测试分配奖励
    • 如果一个生成的代码通过了数据集提供的所有真实单元测试,作者将其标记为真实代码
    • 如果一个生成的单元测试在所有真实代码上都能通过,将其标记为真实单元测试
      • 一个真实单元测试获得的奖励等于它导致失败的非真实代码的数量
      • 否则,它获得的奖励等于它错误地让其通过的非真实代码的数量的负数
  • 本文附录 A.2 中展示了这与本文通用框架的等价性
  • 为了评估奖励模型,本文作者测量了生成的单元测试的正确性及其在检测代码正确性方面的准确性(附录 C.2)
  • 总体而言,表 1 显示,通过联合单元测试训练和环境适应,编码性能和单元测试生成质量都得到了提高
Trade-off Between Outcome and Self-consistency Supervision in Optimization
  • 在整合奖励设计 \(R_{\tau_i}\) 中,来自最终结果 \(O_{\tau}\) 的监督与聚合的逐步信号 \(\lambda \sum_{j = 1}^{m}S_{\tau_{i,j} } / m\) 由超参数 \(\lambda\) 平衡
  • 除了对策略的影响外,\(\lambda\) 也影响奖励模型的监督:
    • 较大的 \(\lambda\) 更强调 Step-wise 质量,而较少强调预测结果影响
  • 本文在 AlfWorld 设置中对 \(\lambda\) 进行了消融研究,进行了 100 个 RL 训练步骤,评估了策略和奖励模型
    • 为了研究对奖励模型的影响,本文在 \(R_{\tau_i}\) 中固定 \(\lambda = 1\),并在 \(R_{\tau_i}\) 中改变 \(\lambda\)
    • 为了研究对策略的影响,本文在 \(R_{\tau_i}\) 中固定 \(\lambda = 1\),并在 \(R_{\tau_i}\) 中改变 \(\lambda\)
  • 如表 2 所示,\(\lambda\) 确实在基于结果和基于自洽性的监督之间进行了权衡,策略优化在 \(\lambda = 1\) 时表现最佳,这是本文默认使用的
  • 报告的数字是训练曲线上最后三次评估的平均值,每次评估都是三次独立运行的平均值
  • 本文附录 A.2 中讨论了 \(\lambda\) 如何影响理论结果
Dynamics of Accepted New Tasks
  • 本节分析了优化过程中接受的任务(见图 7(a))
    • 1)接受的任务数量随训练步数近似线性增长,表明了环境扩展的潜力
    • 2)本文使用 策略在这些接受任务上的准确率 来表征任务难度
      • 由于初始样本有限,准确率早期有所波动,但很快稳定在中等水平
        • 也就是说训练过程中,任务难度始终保持在中间水位
      • 收敛值低于 0.5,因为原始任务对策略来说大多具有挑战性
    • 3)本文使用更强的推理模型(GUI 设置使用 Qwen3-VL-32B-Thinking,AlfWorld 和编码设置使用 Qwen3-32B)评估接受任务的质量,每个任务运行 16 次独立试验,并报告至少一次成功运行的比率
    • 得到的至少一次通过率分别为 96.0%、96.7% 和 94.2%
  • 这些结果证明了作者接受机制在过滤错误合成任务方面的有效性
Application on Agentic Coding
  • 本文在多种代理编码方法下评估了优化后的编码模型,包括 MPSC (2024)、AlphaCodium (2024)、\(S^{\star}\) (2025a) 和 Best of N 方法(附录 C.3)
  • 从图 8(右)中,可以发现优化后的模型显著提高了各种方法下的代理编码性能
Response Length on AlfWorld
  • 作者还研究了 AlfWorld 设置中的响应长度和推理模式(图 7(b))
    • 优化前,策略模型 (Qwen2.5-7B-Instruct) 在采取行动前通常无法产生足够的推理
    • 优化后,其思维链长度迅速增加,到训练结束时,响应变得更加稳定和高效,同时仍保持足够的推理能力

Related Works

Reinforcement Learning of Large Language Models

  • RL 已被用于增强语言模型的推理能力,并已应用于包括编码任务 和 RAG 任务 等场景
  • 随着 Agentic AI 的广泛采用,RL 也已扩展到多轮设置,策略模型在长轨迹上与环境交互
  • 但奖励稀疏性 (2023; 2024) 和现有环境的有限规模 仍然是关键挑战

Reward Modeling and Environments

  • RM(尤其是 GRM),在使 RL 变得实用方面发挥着重要作用
  • RLVR Setting 中,单一的 Outcome Reward 可以联合优化奖励模型和策略,但由于缺乏逐步监督,这并不能直接扩展到多轮设置
  • 环境质量对于有效的 RL 也至关重要 (2024; 2022; 2023)
  • 先前的工作表明,调整任务难度可以改善策略训练 (2025; 2025),这激发了生成或修改任务以增强学习信号的方法 (2025b; 2025a; 2025; 2024)
    • 例如,Zeng 等人 (2025) 构建了一个 RLVR 引擎,其中每个任务都有多个难度级别
    • Xue 等人 (2026) 通过可验证的自动化任务合成扩展了这一方向
    • 但这些系统缺乏长时程交互任务所需的逐步信号
  • 相比之下,本文作者证明了环境、策略和奖励模型的耦合优化能为整个系统产生更强的信号

附录 A:Proof of Theorems

  • 详情暂见原文(待补充)
    • 包含对 Theorem 1 和 Theorem 2 的证明

附录 B:Additional Experimental Results

B.1. Ablation Studies on Using Different Models for Reward Model Evaluation,不同模型进行奖励模型评估的消融研究

  • 本节展示了使用不同的监督模型来评估分配步骤奖励的准确性会得出相同的结论
    • 在附录 C.2 中提供了这种评估方法的细节
  • 在 GUI 设置中使用 OpenCUA-72B,在 LLM 智能体设置中使用 gpt-oss-20b (OpenAI, 2025) 进行了消融研究
  • 此外,本文作者还改变了用于生成奖励模型评估的轨迹的模型:
    • 在 GUI 设置中使用 OpenCUA-7B,在 LLM 智能体设置中使用 LLaMA-3.1-8B-Instruct (2024)
  • 结果(表 3 和表 4)与表 1 中的主要结果一致,验证了本文使用 LLM-as-a-judge 进行评估的方法

B.2. Examples of Environment Adaptation,Environment Adaptation 的示例和分析

  • 下面的 GUI 智能体示例说明了环境模型如何使用总结的错误模式向任务 Prompt 中添加 Tips,从而使策略更容易完成任务

    • 策略在此任务上的准确率从 0 提高到 0.125
  • 原始任务对于策略来说太难了,没有产生任何成功的轨迹,因此无法从成功案例中获得训练信号

  • 添加 Tips 简化任务后,策略偶尔会成功,提供学习信号,使其能够逐渐解决任务

  • GUI Task Adaptation Example 1 (Target: Easier)

    1
    2
    3
    4
    **template**: Using the Pivot Table feature, summarize the total revenue for each promotion type in a new sheet (’Sheet2’), with the promotion names as the column headers.
    **old task prompt**: Summarize the total revenue for each promotion type in a new sheet (Sheet2) with the promotion names as the column headers using the Pivot Table feature.
    **new task prompt**: Using the Pivot Table feature, summarize the total revenue for each promotion type in a new sheet (’Sheet2’), with the promotion names as column headers. Ensure ’Promotion’ is in Column Fields and use ’Insert’, ’PivotTable’ for correct setup. Verify field names to avoid confusion between ’Date’ and ’Promotion’.
    **policy accuracy change**: 0 → 0.125 (easier for the policy)
    • 中文版:
      1
      2
      3
      4
      * **模板** : 使用数据透视表功能,在一个新工作表('Sheet2')中汇总每种促销类型的总收入,促销名称作为列标题
      * **旧任务提示** : 使用数据透视表功能,在一个新工作表(Sheet2)中汇总每种促销类型的总收入,促销名称作为列标题
      * **新任务提示** : 使用数据透视表功能,在一个新工作表('Sheet2')中汇总每种促销类型的总收入,促销名称作为列标题。确保将“促销”放在列字段中,并使用“插入”、“数据透视表”进行正确设置。验证字段名称以避免“日期”和“促销”混淆
      * **策略准确率变化** : \\(0 \rightarrow 0.125\\) (对策略来说更容易)
  • 下面的示例展示了 GUI 任务对策略模型来说太容易的情况,因此扰动通过切换到更具挑战性的任务模板使任务更难

  • GUI Task Adaptation Example 2 (Target: Harder)

    1
    2
    3
    4
    5
    6
    **template candidates**:
    • template1: Copy the “Revenue” column along with the header to a new sheet named “Sheet2”.
    • template2: Copy the “Revenue” column along with the header to a new sheet named “Sheet2”. Then rename this “Revenue” column in “Sheet2” to “Profit”.
    **old task prompt**: Copy the “Revenue” column along with the header to a new sheet named “Sheet2”.
    **new task prompt**: Copy the “Revenue” column along with the header to a new sheet named “Sheet2”. Then rename this “Revenue” column in “Sheet2” to “Profit”.
    **policy accuracy change**: 1.0 → 0.625 (harder for the policy)
    • 中文版:
      1
      2
      3
      4
      5
      6
      * **模板候选** :
      - 模板 1: 将“收入”列及其标题复制到名为“Sheet2”的新工作表中
      - 模板 2: 将“收入”列及其标题复制到名为“Sheet2”的新工作表中,然后将“Sheet2”中的此“收入”列重命名为“利润”
      * **旧任务提示** : 将“收入”列及其标题复制到名为“Sheet2”的新工作表中
      * **新任务提示** : 将“收入”列及其标题复制到名为“Sheet2”的新工作表中,然后将“Sheet2”中的此“收入”列重命名为“利润”
      * **策略准确率变化** : \\(1.0 \rightarrow 0.625\\) (对策略来说更难)
  • 以下两个示例通过改变涉及的对象数量来调整任务难度

  • ALFWorld Task Adaptation Example 1 (Target: Easier)

    • 英文版见原论文
    • 中文版:
      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      13
      14
      * **任务** : 修改目标词元 (对象类型,容器类型) 以使任务更容易,同时保留原始目标框架
      * **响应** : 我需要找到一对满足约束且更有可能在当前状态下成功完成的对象和容器类型。查看“可清洁”列表,许多对象都是可清洁的。“可容纳”列表显示,许多容器可以容纳许多对象
      原始目标是清洁马铃薯类型并将其放入微波炉类型。虽然有效,但成功可能性较低,因为:
      1. 马铃薯类型只有 2 个实例 (potato1, potato2)
      2. 微波炉类型只能容纳某些对象 (AppleType, BowlType, BreadType, CupType, EggType, MugType, PlateType, PotatoType, TomatoType)
      3. 智能体在 loc32,这可能不在微波炉附近
      一个更好的选择是具有更多实例的对象和可以容纳它的容器。查看“可清洁”列表,“CupType”有 3 个实例 (cup1, cup2, cup3),并且可以放置在包括微波炉类型在内的许多容器中
      目标“清洁 CupType 然后放入 MicrowaveType”将:
      - 由于实例更多,更有可能成功
      - 有效,因为 CupType 是可清洁的,并且 MicrowaveType 可以容纳它
      - 遵循清洁对象并将其放入容器中的框架
      **最终答案**
      CupType, MicrowaveType
      * **策略准确率变化** : 0.125 \\(\rightarrow\\) 0.5
  • ALFWorld Task Adaptation Example 2 (Target: Harder)

    • 英文版见原轮文
    • 中文版:
      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      13
      14
      15
      16
      17
      18
      19
      20
      21
      22
      23
      24
      25
      26
      27
      28
      29
      * **任务** : 修改目标词元 (对象类型,容器类型) 以使任务更难,同时保留原始目标框架
      * **响应** : 让我分析创建更难目标的要求
      原始目标是将 RemoteControlType 放入 ArmChairType。这是可行的,因为 (ArmChairType, RemoteControlType) 在 canContain 列表中
      为了使其更难,我需要:
      1. 选择实例更少的对象类型
      2. 选择可以容纳它但实例更少的容器类型
      3. 确保该对是有效的 (满足 canContain)
      查看对象类型:
      - WatchType 有 3 个实例 (watch1, watch2, watch3)
      - KeyChainType 有 3 个实例 (keychain1, keychain2, keychain3)
      - CreditCardType 有 1 个实例 (creditcard1)
      查看容器类型:
      - ArmChairType 有 2 个实例 (armchair1, armchair2)
      - CoffeeTableType 有 2 个实例 (coffeetable1, coffeetable2)
      - DiningTableType 有 1 个实例 (diningtable1)
      - SofaType 有 1 个实例 (sofa1)
      对 (KeyChainType, ArmChairType) 是有效的 (在 canContain 中),并且:
      - KeyChainType 有 3 个实例
      - ArmChairType 有 2 个实例
      这是一个有效的对,但它并不比原始目标更难
      让作者试试 (CreditCardType, ArmChairType):
      - CreditCardType 有 1 个实例
      - ArmChairType 有 2 个实例
      - (ArmChairType, CreditCardType) 在 canContain 中
      这对是有效的,并且实例更少,使其更难
      所以更难的目标将是:
      **最终答案**
      CreditCardType, ArmChairType
      * **策略准确率变化** : 1.0 \\(\rightarrow\\) 0.25

附录 C:Experimental Details

C.1. Models and Settings

  • 对于应用于 OSWorld (2024) 的 GUI 智能体
    • 本文在实验中使用了 Qwen3-VL-8B-Thinking (2025)、UI-TARS1.5-7B (2025) 和 OpenCUA-7B (2025b)
    • 在最终评估中,本文将最大步数设置为 50,温度设置为 0,并报告 3 次独立运行的平均准确率
    • 在 RL 优化期间,将最大步数设置为 30,并对策略模型使用温度 1.0,对过程奖励模型使用温度 0.8
    • 对于策略模型,在每个 RL 步骤中,作者采样 12 个任务,每个任务有 8 条独立的 Rollout 轨迹
    • 上下文管理遵循标准的 OSWorld 流程 (2024),包括最近的三张图像 ,并将所有先前的操作总结为上下文
    • 当使用 OpenCUA 时,将其 CoT 级别设置为 2,遵循其默认设置
      • 对于奖励模型,使用 Qwen3-VL-8B-Thinking 作为基座模型,并对每个策略 Response 进行 3 次评估
      • 奖励上下文通过总结所有先前的操作、包含最近的两张图像以及这两张图像之间作者要求奖励模型评估的操作来构建
      • 本文使用 Qwen3-4B (2025) 来调整任务
    • 在优化期间,本文将执行后等待时间(截图前)设置为 0 以保持训练效率,而在评估期间则设置为 5 秒
      • 本文使用 12 个节点进行训练
  • 对于应用于 AlfWorld (2018; 2020) 的 LLM 智能体
    • 使用 Qwen2.5-7B-Instruct 作为策略模型,Qwen2.5-14B-Instruct 作为奖励模型 (2024a),并使用 Qwen3-4B (2025) 来调整任务
    • 在最终评估中,本文将最大步数设置为 60,温度设置为 0.8,并报告 3 次独立运行的平均准确率
    • 在 RL 优化期间,本文将最大步数设置为 40,并对策略模型和过程奖励模型使用温度 0.8
    • 在每个 RL 步骤中,采样 16 个任务,每个任务有 8 条独立的 Rollout
    • 通过总结所有先前的操作及其相应的观察,并包含最近要选择的动作来构建策略模型上下文
    • 使用 8 个节点进行训练
  • 对于 Coding LLM ,使用与上述 LLM 智能体设置中相同的模型组合
    • 在每个 RL 步骤中,采样 64 个任务,每个任务有 32 次独立的代码解决方案生成和 32 次独立的单元测试生成
    • 使用 4 个节点进行训练
  • 在所有 RL 训练过程中
    • 在策略目标中使用以下标准超参数:裁剪阈值 \(\epsilon = 0.2\) (2017),KL 散度权重 \(\beta = 0.01\) ,学习率为 \(1 \times 10^{-6}\)
    • 使用 k3 KL 估计器,并使用 AdamW (2017) 进行优化
    • 为 GUI 智能体训练 240 步,为 LLM 智能体训练 200 步,为 Coding LLM 训练 300 步,以获得表 1 中报告的最终模型

C.2. Evaluation for Reward Models

  • 对于 OSWorld 和 AlfWorld 设置,本文评估了 Step-level 质量(过程准确率)和预测某一步骤对最终结果影响的能力(结果准确率)
    • 对于结果准确率,其 Ground Truth 标签就是可验证的结果
    • 对于过程准确率,标签由一个 比所使用的奖励模型更强的推理模型提供(这不够准确吧?)
  • 在 OSWorld 设置中
    • 使用 Qwen3-VL-32B-Thinking 对每个策略 Response 提供八次独立的评估,使用的 Prompt 见 C.5 节,并将多数投票结果(1 或 \(-1\))作为 Ground Truth 标签
    • 策略 Response 由 Qwen3-VL-8B-Thinking 在 OSWorld 的多个应用任务上生成:
      • 对于每个任务,策略采样 16 条独立的 Rollout,每个任务产生 16 条轨迹
  • 在 AlfWorld 设置中
    • 使用 Qwen3-32B 进行评估,并使用 Qwen2.5-7B-Instruct 在 AlfWorld OOD 评估集(第 3.1.2 节)上生成轨迹,使用与 OSWorld 设置相同的协议和超参数
  • 在编码 Setting 中
    • 使用 Qwen2.5-7B-Instruct 作为策略模型,为评估数据集(LiveCodeBench、CodeContests 或 LiveBench)中的每个任务生成 16 个独立的代码解决方案,并使用 Qwen2.5-14B-Instruct 作为奖励模型,为每个任务生成 32 个独立的单元测试
    • 如果一个生成的解决方案通过了所有数据集提供的单元测试,则被标记为 Ground Truth 正确
    • 如果一个生成的单元测试通过了所有 Ground Truth 正确的解决方案,则该单元测试是正确的
      • 如果它是正确的,并且能拒绝所有非 Ground Truth 的解决方案(即导致它们失败),那么它是完美的
      • 本文使用正确率和完美率来评估奖励模型,其中完美率对应表 1 中报告的检测准确率

C.3. Agentic Coding Applications

  • 在多种智能体编码方法下评估优化后的编码模型,包括 MPSC (2024)、AlphaCodium (2024) 和 \(S^{\star}\) (2025a)
  • 在 MPSC 中
    • 为每个任务生成 8 个代码、单元测试和规范样本
    • 一个规范是一对函数(前置条件和后置条件),它定义了程序的有效输入空间和预期的输入输出行为,作为其预期功能的形式化描述
    • 然后遵循迭代优化过程计算一致性分数,用于识别最佳的代码解决方案
  • 在 AlphaCodium 中
    • 为每个任务使用对公开测试的推理生成 8 个代码解决方案,以及 8 个对应的单元测试
    • 每个解决方案根据在公开测试上的执行结果进行两次优化迭代,然后根据在生成的单元测试上的执行结果再进行两次迭代
    • 具体来说,每个优化步骤都以单元测试、当前代码和执行日志为条件,并决定是否以及如何更新解决方案
  • 在 \(S^{\star}\) 中
    • 生成 8 个代码解决方案,并应用四轮使用公开测试的自调试,以获得 8 个优化版本
    • 由于调试依赖于 Ground Truth 单元测试的执行结果,本文直接在测试失败时提示模型修改代码
    • 最终的解决方案使用它们的成对比较方法选择,以生成的单元测试作为评估信号
  • 本文作者还考虑了最简单的测试时扩展方法,即最佳 N 选一
    • 具体来说,独立生成 8 个代码和 8 个单元测试,并选择通过最多生成单元测试的代码作为最终解决方案

C.4. Policy Prompt Templates

  • 在 RL 采样和最终评估中都使用这些模板进行上下文管理

  • 对于 OpenCUA 和 UI-TARS,遵循标准的 OSWorld 流程,该流程总结先前的操作,同时保留最近的三张图像作为上下文

  • GUI Agent Prompt Templates (Qwen3-VL-8B-Thinking)

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    **Tool-Calling; System Prompt**
    ’’’<|im_start|>system
    # Tools
    You may call one or more functions to assist with the user query.
    You are provided with function signatures within <tools></tools> XML tags:
    <tools>
    {{tools_def}}
    </tools>
    For each function call, return a json object with function name and arguments within <tool_call></tool_call> XML tags:
    <tool_call>
    {"name": <function-name>, "arguments": <args-json-object>}
    </tool_call>
    # Response format
    Response format for every step:
    1) Action: a short imperative describing what to do in the UI.
    2) A single <tool_call>...</tool_call> block containing only the JSON:
    {"name": <function-name>, "arguments": <args-json-object>}.
    Rules:
    - Output exactly in the order: Action, <tool_call>.
    - Be brief: one sentence for Action.
    - Do not output anything else outside those parts.
    - If finishing, use action=terminate in the tool call.
    <|im_end|>
    ’’’
    Message Construction
    # We construct a multimodal message list as follows:
    # 1) A system message containing the tool-calling specification and the tool schema.
    # 2) For historical context, we keep:
    # - All past actions as a text-only history (Step 1: ..., Step 2: ..., ...).
    # - At most the most recent 3 screenshots (image-only history).
    # 3) For each retained past step i:
    # - Append a user message with the screenshot i.
    # - Append an assistant message with the model’s response at step i (Action + < tool_call>).
    # 4) For the current step:
    # - Append a user message containing the current screenshot + the instruction prompt
    # (which includes the instruction and the full action history).
    # Variables used in the paper template:
    # - tools_def: JSON string of tool definitions (i.e., json.dumps(tools_def))
    # - step_index: current step id (0-based)
    # - screenshots[i]: base64-encoded PNG screenshot at step i (string without the data: prefix)
    # - responses[i]: assistant response text at step i (Action + <tool_call>)
    # - actions: list of action strings taken so far (for the text-only action history)
    # - instruction: the current task instruction (string)

    messages = [{"role": "system", "content": [{"type": "text", "text": "system_prompt"}]}]

    # Keep at most the last 3 screenshots
    start_i = max(0, step_index - 3 + 1)
    for i in range(start_i, step_index):
    # 历史截图 i
    img_url_i = f"data:image/png;base64,{screenshots[i]}"
    messages.append({"role": "user", "content": [{"type": "image_url", "image_url": {"url": img_url_i} }]})
    # 历史助手响应 i (Action + <tool_call>)
    messages.append({"role": "assistant", "content": [{"type": "text", "text": responses[i]}]})

    # Text-only full action history
    previous_actions_str = "None" if len(actions) == 0 else "\n".join([f"Step {k+1}: {a}" for k, a in enumerate(actions)])
    instruction_prompt = f"""
    请根据UI截图、指令和之前的操作,生成下一步
    指令:{instruction}
    之前的操作:{previous_actions_str}
    """
    # Current screenshot + instruction prompt
    curr_img_url = f"data:image/png;base64,{screenshots[step_index]}"
    messages.append(
    {"role": "user", "content": [
    {"type": "image_url", "image_url": {"url": curr_img_url} },
    {"type": "text", "text": instruction_prompt},
    ]}
    )
  • LLM Agent Prompt Templates (ALFWorld)

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    **Guide Prompt)**
    guide = {
    "You are playing a text game. Your objective is to complete the task as soon as possible.\n"
    "Below is your trajectory so far and current candidate actions.\n"
    "You need to think step by step then put the integer (the index of your chosen action) in \\boxed{}. \n"
    }

    **Trajectory Rendering; summarized history**

    # The trajectory is summarized into alternating observation/action lines

    def_render_traj(traj):
    lines = []
    for t in traj:
    if "obs" in t and t["obs"] is not None:
    lines.append(f"observation: {t['obs']}")
    if t.get("act") is not None:
    lines.append(f"you took action: {t['act']}")
    return "\n".join(lines)

    trajectory_history =_render_traj(traj)

    **Full Prompt Template**

    '''<|im_start|>system
    You are a helpful assistant.<|im_end|>
    <|im_start|>user
    { {guide} }<|im_start|>system
    You need to think step by step then choose one action by number:<|action_options|><|im_end|>
    <|im_start|>assistant
    '''
    { {trajectory_history} }

    You need to think step by step then choose one action by number: { {action_options} }<|im_end|>
    <|im_start|>assistant
    '''

    ** Coding LLM Prompt 模板**

    ```python
    '''<|im_start|>system
    You are a helpful assistant that helps the user solve programming problems.<|im_end|>
    <|im_start|>user
    You need to think first then write a Python script.
    You should use input() to read input and print() to produce output in your script.
    This is the problem:
    <|prom|><|prom|><|prom|><|prom|><|prom|><|prom|>
    You should put your code in "python ".
    <|im_end|>
    <|im_start|>assistant
    '''

C.5. Process Reward Model Prompt Templates,PRM Prompt 模板

  • 对于 GUI 智能体 Setting

    • 本文使用 Qwen3-VL-8B-Thinking 作为过程奖励模型来评估每个策略 Response
    • 奖励模型上下文由以下部分组成
      • 所有先前操作的摘要
      • 最近的两张图像
      • 评估的这两张图像之间的操作
  • 对于 AlfWorld 设置

    • 本文提供策略 Prompt 和 Response,并要求 LLM 评判该 Response
  • 在这两种 Setting 中,Prompt 旨在评估 Step-level 质量以及该步骤对最终结果的潜在影响

  • 最终输出的奖励只能是 1 或 -1

    • 对于 Coding LLM 设置,提示 LLM 生成单元测试
    • 这些单元测试的质量可作为对生成代码某些方面的评估信号,并可用作过程奖励的一种特殊形式
  • GUI Agent Rewarding Prompt Templates

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    # We build reward_messages as a multimodal user content list.
    # The reward prompt includes:
    # - A text-only prefix containing "Previous Actions" (older action history).
    # - A short window of recent steps: for each step i in the window,
    # (a) the environment screenshot at step i,
    # (b) the agent action taken at step i.
    # - The current observation screenshot (the state after the most recent action).
    # - A strict evaluation instruction describing the agent objective and the most recent response.
    # Variables used in the paper template:
    # - step_index: current step id (0-based, the "most recent step" is step_index)
    # - actions[i]: action text taken at step i
    # - instruction: task instruction / objective string
    # - response: the agent’s most recent response (reasoning + action/tool call)
    # - reward_messages: chat message list for the reward model
    # - reward_user_content: multimodal user content list (text/image blocks)

    reward_user_content = []

    # 最多为奖励上下文保留最近 2 步(不包括当前 Observation)
    rstart_i = max(0, step_index - 2 + 1)

    # (1) 之前的操作:rstart_i 之前的所有操作
    prev_lines = []
    for i in range(rstart_i):
    prev_lines.append(f"Step {i+1}: {actions[i]}")
    previous_reward_actions_str = "\n".join(prev_lines) if prev_lines else "None"
    reward_user_content.append({"type": "text", "text": f"Previous Actions:\n{previous_reward_actions_str}"})

    # (2) 最近的步骤窗口:对于 [rstart_i, step_index) 范围内的每个步骤 i
    for i in range(rstart_i, step_index):
    reward_user_content.append({"type": "text", "text": "Image of environment:\n"})
    reward_user_content.append({"type": "image", "image": "image"})
    reward_user_content.append({"type": "text", "text": f"\nAction of agent:\nStep {i+1}:\n{actions[i]}\n"})

    # (3) 当前观察图像(执行最近操作后)
    reward_user_content.append({"type": "text", "text": "Agent's current observation:\n"})
    reward_user_content.append({"type": "image", "image": "image"})

    # (4) 评估指令(目标 + 最近响应)
    REWARD_INSTRUCTION_TEMPLATE = r"""
    You are a strict evaluator to evaluate the most recent step of the agent in the following.

    Objective of Agent: {instruction}

    Agent's most recent step (reasoning + action): {response}
    """
    reward_user_content.append({
    "type": "text",
    "text": "\n" + REWARD_INSTRUCTION_TEMPLATE.format(instruction=instruction, response=response)
    })
    reward_messages.append({"role": "user", "content": reward_user_content})
  • 在评估奖励模型预测的 Step-level 质量时,使用以下奖励指令模板并要求 Qwen3-VL-32B-Thinking 提供标签:

  • REWARD_INSTRUCTION_TEMPLATE for evaluating reward model’s step-wise accuracy (OSWorld)

    1
    2
    3
    4
    5
    6
    7
    REWARD_INSTRUCTION_TEMPLATE = r"""
    You are a strict evaluator to evaluate the most recent step of the agent in the following. Focus on the quality of this step.

    Objective of Agent: {instruction}

    Agent's most recent step (reasoning + action): {response}
    """
    • 问题:这里不应该是一个 Meta Evaluator 吗?
  • LLM Agent Rewarding Prompt Templates (ALFWorld)

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    '''<|im_start|>system
    You are a helpful assistant.
    <|im_end|>
    <|im_start|>user
    You are a judge for an agent acting in a text-based environment.
    Evaluate ONE step using:
    - the agent's prompt (observation + candidate actions),
    - its response (reasoning + chosen index), and
    - the environment's next observation after executing that action.

    Scoring (binary):
    Score 1 if ALL are true:
    (a) The selected action is appropriate for the current observation and task goal (it reasonably explores, progresses or completes the task);
    (b) The reasoning is present, relevant, and not self-contradictory (no hallucinated objects/locations);
    (c) The chosen index exists in the candidate list, and the resulting next observation is consistent with the described action.
    Otherwise score -1. Cases include: no reasoning provided; index out of range; clearly irrelevant; undoes progress; self-contradictory/hallucinated reasoning; or next observation contradicts the action.

    Important: think first then put the final score in \\boxed{}.

    Agent's prompt:
    { {policy_prompt} }

    Agent's response:
    { {policy_response} }

    Next observation after this action:
    { {next_obs} }
    <|im_end|>
    <|im_start|>assistant
    '''
  • 在评估奖励模型预测的 Step-level 质量(AlfWorld Setting)时,使用以下奖励指令模板并要求 Qwen3-32B 提供标签:

  • Prompt Template for evaluating reward model’s step-wise accuracy (Alf World)

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    '''<|im_start|>system
    You are a helpful assistant.
    <|im_end|>
    <|im_start|>user
    You are a judge for an agent acting in a text-based environment.
    Evaluate ONE step using:
    - the agent's prompt (observation + candidate actions),
    - its response (reasoning + chosen index), and
    - the environment's next observation after executing that action.

    Scoring (binary):
    Score 1 if ALL are true:
    (a) The selected action is appropriate for the current observation;
    (b) The reasoning is present, relevant, and not self-contradictory (no hallucinated objects/locations);
    (c) The chosen index exists in the candidate list, and the resulting next observation is consistent with the described action.
    Otherwise score -1. Cases include: no reasoning provided; index out of range; clearly irrelevant; undoes progress; self-contradictory/hallucinated reasoning; or next observation contradicts the action.

    Important: think first then put the final score in \\boxed{}.

    Agent's prompt:
    { {policy_prompt} }

    Agent's response:
    { {policy_response} }

    Next observation after this action:
    { {next_obs} }
    <|im_end|>
    <|im_start|>assistant
    '''
  • Coding LLM Reward Prompt Template

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    REWARD_TEST_PROMPT = r"""<|im_start|>system
    You are a rigorous unit-test designer for coding problems.
    You must produce exactly ONE new test example that is correct and discriminative.
    <|im_end|>
    <|im_start|>user
    You need to provide a new test example. A good test example should be completely
    - accurate and conform to the problem's format requirements, while also
    - possessing enough discriminative power to distinguish correct code from
    - incorrect code.

    Before providing a test example, you must think carefully and reason step by step to
    - derive an input and output you are very confident are correct. For example,
    - start by designing an input you can reliably handle, then compute the output
    - step by step. If you're unsure about the output, revise or re-design the input
    - to ensure accuracy. Directly providing input/output pairs without this
    - process is discouraged, as it often results in low accuracy.

    Finally, after completing these previous thinking and derivation steps (you should
    - not write the final test example unless you have gone through these steps very
    - thoroughly), you MUST put your final test example in the following format:

    **Test Input:**
    '''
    <put the EXACT stdin content here>
    '''
    **Test Output:**
    '''
    <put the EXACT stdout content here>
    '''
    **Explanation:** <brief explanation here>

    IMPORTANT:
    - Output must contain exactly one **Test Input:** block and one **Test Output:** block.
    - Use triple backticks exactly as shown.
    - The test must be self-contained and match the problem format.

    Problem: { {problem} }
    <|im_end|>
    <|im_start|>assistant
    """

C.6. Error Pattern Summarization and Prompt Templates,错误 Pattern 总结

  • 通过总结过程奖励模型输出的思考部分来识别策略可能出错的地方

  • 对于每个任务,获得几个句子来描述策略在解决任务时所犯的错误

  • 对于 GUI 智能体

    • 首先通过聚合至少一个评估分数为 \(-1\)(表示潜在错误)的步骤上的独立评估来进行 Step-level 总结,生成 Step-level 摘要
    • 然后进行 Trajectory-level 总结:
      • 对于每条轨迹,使用 Step-level 摘要作为上下文,并要求模型总结整个轨迹中发生的错误
      • 对于每个任务的每条策略轨迹,获得一个关于策略错误模式的简洁摘要
  • 对于 AlfWorld 上的 LLM 智能体

    • 直接使用完整轨迹(智能体的操作和相应的观察),并突出显示所有评估分数均为 \(-1\) 的步骤作为总结上下文
    • 由于这里的上下文短得多且直接,本文未使用 GUI 智能体设置中采用的两阶段 Step-level 后接 Trajectory-level 总结
  • 本文为 OSWorld 设置使用 Qwen3-VL-8B-Thinking,为 AlfWorld 设置使用 Qwen3-4B

    • 对于 Coding Thinking,诊断信息包括生成的代码未能通过的单元测试
  • OSWorld (GUI Agent) Error Summarization Prompt Templates

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    **Step-wise Summarization (OSWorld GUI)**

    STEP_ERROR_SUMMARY_PROMPT = (
    "you are analyzing one step in a trajectory for an OSWorld/desktop task.\n\n"
    f"step_index: {step_index}\n\n"
    "You are given:\n"
    "- reward_model_responses (multiple candidates)\n"
    "- extracted_reward aligned with responses (+1/-1/0)\n\n"
    "Task:\n"
    "Write ONE high-density summary (<= 2 sentences) explaining why this step was judged negative.\n"
    "Be specific about the failure mode (e.g., wrong assumption, misread UI, inconsistent with instruction, hallucinated value, skipped constraint).\n\n"
    "Rules:\n"
    "- Do NOT repeat the prompt verbatim.\n"
    "- Final answer MUST be in \\boxed{...} ONLY.\n\n"
    "reward_model_responses:\n"
    f"{json.dumps(reward_model_responses, ensure_ascii=False)}\n\n"
    "extracted_reward:\n"
    f"{json.dumps(extracted_reward, ensure_ascii=False)}\n"
    )

    **Trajectory-wise Summarization (OSWorld GUI)**

    TRAJECTORY_ERROR_SUMMARY_PROMPT = (
    "You are given step-level error summaries for ONE trajectory.\n\n"
    "Task:\n"
    "Produce ONE trajectory-level error summary (<= 2 sentences) capturing the main recurring failure modes.\n\n"
    "CRITICAL anti-redundancy rule:\n"
    "- Do NOT repeat the same error across different steps.\n"
    "- If multiple steps share the same failure type, mention it ONCE and, if helpful, note it as recurring.\n"
    "- Keep language concise but high information density.\n\n"
    "- Do reasoning first, then put Final Answer in \\boxed{...} ONLY.\n\n"
    "step_error_summaries (JSON):\n"
    f"{json.dumps(step_summaries, ensure_ascii=False)}\n"
    )
  • Alf World (LLM Agent) Error Summarization Prompt Template

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    ALFWORLD_ERROR_SUMMARY_PROMPT = (
    "<|im_start|>You are a helpful assistant. <|im_end|>\n"
    "<|im_start|>user\n"
    "You are analyzing a failed rollout of a policy in a text-based environment.\n"
    f"The rollout did NOT finish the task within {max_steps} interaction steps.\n"
    f"Task (natural language): {task}\n\n"
    "Full trajectory (observation/action sequence):\n"
    f"{traj_text}\n\n"
    f"Some steps that are marked by reward model to be highly possible incorrect: {steps_information}\n\n"
    "In at most TWO sentences, explain the most likely reasons the policy failed to finish in time.\n"
    "Be concrete (e.g., wrong exploration, looping, wrong target/location, inconsistent reasoning, hallucination, etc.).\n"
    "Put the final \\(<= 2\\) sentence summary in \\boxed{ and output NOTHING else.\n"
    "<|im_end|>\n"
    "<|im_start|>assistant"
    )

C.7. Environment Modification and Prompt Templates,环境修改和 Prompt 模板

  • 为了获得能更好地匹配策略当前能力的新任务 ,同时保留原始任务的本质 (以防止任务集偏离原始分布太远)

  • 本文设计以下 Prompt 模板供推理模型使用,以基于关于策略准确率及其在每个任务上具体错误的总结信息来调整任务

  • 对于 GUI 智能体

    • 为每个任务提供一组任务模板 :原始任务始终包含在内,偶尔会添加新的但高度相关的模板
    • 为 230 个训练任务中的 47 个预先创建了额外的任务模板,总共得到 295 个任务模板(示例见附录 C.8)
      • 在本文的消融研究中,所有这些任务都包含在训练集中
    • 本文提供策略在原始任务上可能出错的位置的信息,并要求模型(如果适用)选择一个新任务模板,并根据该模板编写一个新的任务 Prompt
      • 当目标是让任务更容易时,模型可以根据总结的错误模式在 Prompt 中添加 Tips,从而对策略难以处理的任务实现更主动的调整
      • 当目标是让任务更难时,模型可以移除此类 Tips 并使指令更模糊
      • 任务模板的选择也可以取决于目标难度和扰动类型
  • 对于 AlfWorld 上的 LLM 智能体

    • 本文向模型提供策略在任务上的表现,以及基本环境信息(例如,环境包含哪些对象、它们的属性以及它们的位置),以帮助模型决定如何修改任务
    • 例如:
      • 如果子类别“拾取和放置”中的原始任务对于策略来说太难,因为它找不到目标对象,则环境模型将目标替换为更容易找到的对象
      • 如果任务对策略来说太容易,环境模型会使目标对象更难找到
  • GUI Agent Task-Difficulty Adaptation Prompt Template (OSWorld)

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    # Variables:
    # - goal: str, target difficulty direction, e.g., "easier" or "harder"
    # - current_task_json: str, JSON string of the current task object
    # - task_template_json: str, JSON string of a mapping evaluator_name -> canonical instruction
    # - traj_summaries_json: str, JSON string of OPTIONAL historical trajectory-level error summaries
    # (each trajectory_summary is already deduplicated across steps)
    SYSTEM_PROMPT = """<|im_start|>You are a helpful assistant. <|im_end|>
    <|im_start|>user
    You will help me adjust the difficulty of an OSWorld/desktop task.
    You are given:
    (1) current_task (JSON)
    (2) task_template: a JSON object mapping evaluator_name -> a canonical instruction for that evaluator.
    (3) previous_rollout_trajectory_summaries: OPTIONAL historical error analyses from earlier rollouts.
    - A task may have multiple trajectories (runs).
    - Each trajectory_summary is already deduplicated across steps (no repeated same error across steps).
    Goal: make the task {{goal}}.
    Rules:
    - You MAY switch to a different evaluator from task_template (by changing the key), OR keep the same evaluator.
    - You MAY rewrite the instruction to increase/decrease hint strength (add hints to make easier, remove hints to make harder).
    - The instruction can NOT be too long.
    - You MUST NOT change the essential task meaning compared to the chosen evaluator’s template. Do NOT invent a new task.
    - Do NOT invent new evaluator names. The output key must be one of the keys in task_template.
    - You SHOULD use previous_rollout_trajectory_summaries to guide how you adjust difficulty:
    - If goal is EASIER: add minimal, targeted clarifying hints addressing recurring failure modes.
    - If goal is HARDER: remove such hints, but still keep the same essential task and stay within the chosen evaluator template.
    - Output MUST be valid JSON ONLY (no markdown, no extra text).
    - Output format MUST be the new current_task JSON object with EXACTLY ONE key:
    {"evaluatorX": "your rewritten instruction"}
    - If you accidentally output other text, ensure the FINAL output segment is the JSON object.
    current_task:
    {{current_task_json}}
    task_template:
    {{task_template_json}}
    previous_rollout_trajectory_summaries:
    {{traj_summaries_json}}
    <|im_end|>
    <|im_start|>assistant
    """
  • Alf World (LLM Agent) Task-Difficulty Adaptation Prompt Template

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
    76
    77
    78
    79
    80
    81
    82
    83
    84
    85
    86
    87
    88
    89
    90
    91
    92
    93
    94
    95
    96
    97
    98
    99
    100
    101
    102
    103
    104
    105
    106
    107
    **Environment Summary from INIT**
    # summarize_init_english(problem_text) 返回:
    # (1) summary_text: 一个人类可读的 INIT 事实的英文摘要,包括:
    # - 对象/容器类型 -> 具体实例
    # - 位置
    # - cancontain(type -> type) 约束
    # - 按谓词名称分组的其他实例化谓词
    # (2) S: 一个结构化的已解析事实字典,用于下游约束,包括:
    # - obj2type, rec2type
    # - otype2obj, rtype2recs
    # - cancontain
    # - caps (能力集,如 pickable/toggleable/cleanable/hearable/coolable/sliceable)

    summary_text, S = summarize_init_english(problem_text)

    **Prompt Construction (environment info + failure summaries + goal editing instruction)**

    prompt_text = (
    "|<im_start|>You are a helpful assistant. <|im_end|>\n"
    "<|im_start|>user\n"
    "Review the following details about an interactive environment. A related task will follow.\n"
    + summary_text
    )

    prompt_text += "\n\n--\n"

    fails = item.get("failed_rollout_summaries", [])
    if fails:
    prompt_text += "### Failure summaries from recent rollouts (failed rollouts only)\n"
    for rec in sorted(fails, key=lambda x: int(x.get("rollout_idx", 0))):
    rj = rec.get("rollout_idx", 0)
    ss = str(rec.get("summary", "").strip())
    prompt_text += f"- Rollout {rj}: {ss}\n"
    prompt_text += "\n"

    prompt_text += f"### Your job is to propose a new goal that makes the task \*\*{goal.upper()}\*\*.\n"
    prompt_text += f"- The parent rollout accuracy (prev_acc) is {acc_before}.\n"
    prompt_text += "- The new goal must be different from the original and follow the instructions.\n"
    prompt_text += "- The overall framework of the goal cannot be changed; you may only modify two tokens within this framework.\n"
    prompt_text += "Represent the new goal by outputting two tokens, placed inside \n boxed{ and separated by a comma, e.g., \\boxed{TOKEN_A,TOKEN_B}.\n"
    prompt_text += "You need to think step by step then provide final result in \\boxed {}. \n"
    prompt_text += "\n" + goal_brief_and_instruction(
    task, goal_obj_types, goal_rec_types, S, direction=goal, prev_acc=acc_before
    )
    prompt_text += "\n<|im_end|>\n<|im_start|>assistant"

    **Task-Specific Editing Rubric (goal_brief_and_instruction)**

    def goal_brief_and_instruction(task, goal_obj_types, goal_rec_types, S, direction: Optional[str] = None, prev_acc: Optional[float] = None):
    lines = []
    if direction in ("harder", "easier"):
    lines.append(f"### Difficulty goal: \*{direction.upper()}\* (prev_acc={prev_acc})")
    if direction == "harder":
    lines.append("- Prefer types with \*fewer\* available instances (rarer) while keeping constraints satisfied.")
    lines.append("- Prefer combinations likely requiring more search/steps, but still solvable in this environment.")
    else:
    lines.append("- Prefer types with \*more\* available instances (more common) while keeping constraints satisfied.")
    lines.append("- Prefer combinations likely easier to find/complete, but still valid.")

    if task == "pick_and_place_simple":
    g = (goal_obj_types[0] if goal_obj_types else "<?>", goal_rec_types[0] if goal_rec_types else "<?>")
    lines.append("\*Overall Framework\*: place an object type into/on a receptacle type.")
    lines.append(f"\*Original goal\*: place an object of type \*\*[g[0]]\* into/on a receptacle of type \*\*{g[1]}\*.")
    lines.append(f"The final output example is \\boxed{ {g[0]}, {g[1]} }")
    lines.append("\*Design instructions\*: Output exactly \*two tokens\* - < OBJ_TYPE> <REC_TYPE>.")
    lines.append("- Constraints: pair must satisfy 'canContain(REC_TYPE, OBJ_TYPE)'.")

    elif task == "look_at_obj_in_light":
    g = (goal_obj_types[0] if goal_obj_types else "<?>", goal_obj_types[1] if len(goal_obj_types) > 1 else "<?>")
    lines.append("\*Overall Framework\*: a light object type is present at the agent's location; the agent \*holds\* an object type.")
    lines.append(f"\*Original goal (Example)\*: a \*toggleable and toggled\* light object of type \*{g[0]}\* is present; agent \*holds\* type \*{g[1]}\*.")
    lines.append(f"The final output example is \\boxed{ {g[0]}, {g[1]} }")
    lines.append("\*Design instructions\*: Output exactly \*two tokens\* - < LIGHT_OBJ_TYPE> <HOLD_OBJ_TYPE>'.")
    lines.append("- Constraints: LIGHT must have 'toggleable'; HOLD should have a 'pickupable' instance in INIT.")

    elif task == "pick_clean_then_place_in_recep":
    g = (goal_obj_types[0] if goal_obj_types else "<?>", goal_rec_types[0] if goal_rec_types else "<?>")
    lines.append("**Overall Framework** : **clean** an object type and place it into/on a receptacle type.")
    lines.append(f"**Original goal** : clean type **{g[0]}** then place into/on type **{g[1]}**.")
    lines.append(f"The final output example is \\boxed{ {g[0]}, {g[1]} }")
    lines.append("- Constraints: OBJ must be cleanable; canContain(REC,OBJ).")

    elif task == "pick_heat_then_place_in_recep":
    g = (goal_obj_types[0] if goal_obj_types else "<?>", goal_rec_types[0] if goal_rec_types else "<?>")
    lines.append("**Overall Framework** : **heat** an object type and place it into/on a receptacle type.")
    lines.append(f"**Original goal** : heat type **{g[0]}** then place into/on type **{g[1]}**.")
    lines.append(f"The final output example is \\boxed{ {g[0]}, {g[1]} }")
    lines.append("- Constraints: OBJ must be heatable; canContain(REC,OBJ).")

    elif task == "pick_cool_then_place_in_recep":
    g = (goal_obj_types[0] if goal_obj_types else "<?>", goal_rec_types[0] if goal_rec_types else "<?>")
    lines.append("**Overall Framework** : **cool** an object type and place it into/on a receptacle type.")
    lines.append(f"**Original goal** : cool type **{g[0]}** then place into/on type **{g[1]}**.")
    lines.append(f"The final output example is \\boxed{ {g[0]}, {g[1]} }")
    lines.append("- Constraints: OBJ must be coolable; canContain(REC,OBJ).")

    elif task == "pick_two_obj_and_place":
    g = (goal_obj_types[0] if goal_obj_types else "<?>", goal_rec_types[0] if goal_rec_types else "<?>")
    lines.append("**Overall Framework** : place **two distinct objects** (same type) into/on a receptacle type.")
    lines.append(f"**Original goal** : place two objects of type **{g[0]}** into/on type **{g[1]}**.")
    lines.append(f"The final output example is \\boxed{ {g[0]}, {g[1]} }")
    lines.append("- Constraints: >=2 instances of OBJ_TYPE; canContain(REC,OBJ).")

    else:
    lines.append("**Original goal** : (unknown task type).")

    return "\n".join(lines)

C.8. Examples of Task Templates in GUI data

  • 正如附录 C.7 中讨论的,本文在 GUI 训练数据中为某些任务添加了新的任务模板
  • 本文提供的示例如下,每个任务模板都配有一个评估器及其对应的可验证结果文件
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    TASK_TEMPLATE_EXAMPLES = r"

    Example 1:
    "task_template":{
    "evaluator1": "Work out the monthly total sales in a new row called 'Total', and then create a line chart to show the results (with Months on the x-axis).",
    "evaluator2": "Work out the monthly total sales in a new row called 'Total'.",
    "evaluator3": "Work out January's total sales in a new row called 'Total'.",
    "evaluator4": "Work out the monthly total sales in a new row called 'Total', and then create a line chart to show the results (with Months on the x-axis, for January, February, and March only)."
    }

    Example 2:
    "task_template":{
    "evaluator1": "Fill all blank cells in B1:E30 with the value from the cell directly above. Finish the task and do not modify irrelevant regions, even if they are blank.",
    "evaluator2": "Fill all blank cells in B1:B30 with the value from the cell directly above. Finish the task and do not modify irrelevant regions, even if they are blank.",
    "evaluator3": "Fill all blank cells in E1:E30 with the value from the cell directly above. Finish the task and do not modify irrelevant regions, even if they are blank.",
    "evaluator4": "Fill all blank cells in E1:E24 with the value from the cell directly above. Finish the task and do not modify irrelevant regions, even if they are blank."
    }

C.9. Task Specific Algorithm

  • Algorithm2:

NLP——LLM对齐微调-GR3

注:本文包含 AI 辅助创作

  • 参考链接:
    • 原始论文:(GR3,\(\text{GR}^3\))Tackling Length Inflation Without Trade-offs: Group Relative Reward Rescaling for Reinforcement Learning, 20260311, ISCAS & XHS

Paper Summary

  • 整体总结和说明:
    • 作者定义并提出了 长度膨胀(length inflation) 现象:模型倾向于产生不必要的冗长或过度思考
    • 长度膨胀(length inflation) 是 LLM RL 训练中一个根本性的效率问题
    • 为解决 长度膨胀问题,作者提出了一个无损长度控制的通用框架 组相对奖励重缩放(Group Relative Reward Rescaling, \(\mathbf{GR}^3\))
      • \(\text{GR}^{3}\) 通过一个乘法的、组相对的形式,并结合优势感知校准来调控推理长度
    • 在 RLVR 和 RLHF 两种 Setting 下,\(\text{GR}^{3}\) 均能将 性能-成本帕累托前沿 向外推移
      • 观测效果:保持与标准 GRPO 相当的训练动态和下游性能,同时显著缓解了长度膨胀问题
      • 在保持(甚至提升)模型能力的同时减少 Token 使用
    • 理解:本文的核心思路创新是将加性的长度惩罚方式转变成 乘性的长度惩罚方式
  • 当前 LLM RL 面临问题:模型采用冗长或低效的推理来最大化奖励(长度膨胀)
  • 先前的方法:难以以一种通用且无损的方式解决这一挑战,主要是因为:
    • 加性惩罚 :引入了一种补偿效应 ,从而创造了优化捷径
    • 启发式门控策略 :在二元反馈之外缺乏通用性
  • 本文方法:组相对奖励重缩放(Group Relative Reward Rescaling, \(\mathbf{GR}^3\))
    • 将长度控制重新构建为一种乘法重缩放范式
    • 建立了一个通用的、连续的、且依赖于奖励的门控机制
  • 其他创新:在 \(\mathbf{GR}^3\) 的基础上,结合了 组相对正则化(group-relative regularization) 和 优势感知校准(advantage-aware calibration)
    • 能根据实例难度动态调整长度预算,并保留高质量轨迹的优势信号

Introduction and Discussion

  • LLM 上的 RL 表现出一个持续的缺陷,本文称之为长度膨胀(length inflation):
    • 长度膨胀的定义:经过 RL 训练的模型倾向于产生不必要的冗长轨迹,导致推理成本增加,而质量却没有成比例地提升
  • 长度膨胀现象在主要的 RL 范式中都有出现
    • 在 RLHF(2022)中,模型利用奖励模型对冗长的偏好,导致 Reward Hacking(2023)
    • 在 RLVR(2024)中,长度膨胀则源于推理效率低下(2025),模型生成不必要的长思维链以略微提高正确解的可能性
  • 之前的工作:
    • 路线一:训练对 Response 长度不变的奖励模型(2024a;2024)
      • RLHF 中有效,无法扩展到 RLVR,因为 RLVR 的奖励来自真实值验证器,而非可以被去偏的学习代理
    • 路线二(更通用):在奖励中引入显式的长度惩罚(2025a;2025c;2025)
      • 大多数现有方法依赖于粗略的正则化,导致了次优的优化动态
        • 一种常见的设计:采用加性塑形(additive shaping)(2025;2025)
          • 用一个显式的长度项(例如,\(R’ = R - \lambda \ell\))修改目标函数
          • 这引入了解耦的激励,创造了一个与任务成功无关的、使极端简洁成为有吸引力的捷径的、由长度驱动的组成部分
        • For 更好地使惩罚与结果对齐,一些工作提出了启发式门控(heuristic gating)(2025;2025),仅在 \(R = 1\) 时应用惩罚
          • 这种设计本质上局限于二元反馈,不能自然地扩展到像 RLHF 这样的连续奖励 Setting
          • 许多方法依赖粗略的控制机制,如静态截断阈值或未校准的惩罚强度(2025b;2025),导致固有的效率-性能权衡,如图 1 所示
  • 核心问题提出:能否在不损害 RL 能力增益的情况下,以一种通用的方式解决长度膨胀?
  • 本工作提出了一个用于无损效率优化的 Principled 框架 GR\(^3\))
    • 特点:GR\(^3\) 不使用加性惩罚 ,而是通过乘法重缩放 来正则化长度
      • 作为一个广义的门控机制,消除了加性方案固有的补偿捷径
    • 为了进一步确保无损优化,作者引入了两个细粒度机制
      • 采用 Group-relative Regularization
        • 根据 On-policy 统计量而非刚性阈值来归一化长度,从而动态地将长度预算调整到每个 Prompt 固有的难度
      • 补充引入 Advantage-aware Calibration,显式控制惩罚强度
        • 这确保了长度正则化不会推翻代表性高质量轨迹的优势信号,从而保障了向能力提升的稳定优化
  • 实验显示:GR\(^3\) 解决了先前方法中固有的效率-性能权衡
    • 如图 1 所示,GR\(^3\) 显著减少了 Token 使用量(在 AIME-25 上超过 \(40%\)),同时提高了准确性(\(+8\) points)
      • 这证明冗长并非智能的先决条件
    • 在 RLHF 设置中,GR\(^3\) 表现出自适应的长度动态:
      • 当计算有益时,它允许适度增长,但随着策略成熟,它会自动抑制生成长度(图 2)
      • 这种机制有效地通过冗长来缓解 Reward Hacking ,而不牺牲性能
  • 本文贡献总结:
    • 提出无损长度控制框架 \(\text{GR}^3\),用乘法奖励重缩放替代了加性惩罚
      • 这种设计消除了补偿性优化捷径,并为二元奖励和连续奖励提供了统一的机制
    • 开发了一种优化保持策略,将组相对正则化与优势感知校准相结合,使约束适应于 On-policy 统计量,同时保留学习信号
    • 在数学推理、代码生成和 RLHF 对齐任务中,GR\(^3\) 在匹配标准 GRPO 性能的同时产生了简洁的生成,推动了效率-性能帕累托前沿的迁移

Preliminary

Group Relative Policy Optimization(GRPO)

  • LLM 生成可以被形式化为一个 Token 级别的 MDP
    • 给定一个 Prompt \(x \sim \mathcal{D}\) ,一个自回归策略 \(\pi_{\theta}\) 通过从 \(\pi_{\theta}(y_t\mid x,y_{< t})\) 中采样 Token 来生成长度为 \(\ell := |y|\) 的 Response \(y = (y_1, \ldots , y_\ell)\)
    • 一个标量奖励 \(R(x,y)\) 定义在完整 Response 上,强化学习旨在最大化期望奖励:
      $$\max_{\pi_{\theta} }\mathbb{E}_{x\sim \mathcal{D},y\sim \pi_{\theta}(\cdot |x)}\big[R(x,y)\big]. \tag {1}$$
  • 随着像 DeepSeek-R1 这样的推理模型的出现,组式 RL 在 LLM 后训练中变得普遍
    • 其中的 GRPO(2024)因其可扩展性和无需单独的价值模型而被广泛采用
  • 对于每个 Prompt \(x\) ,GRPO 从一个旧策略 \(\pi_{\theta_{\text{old} } }(\cdot |x)\) 中采样一组 \(G\) 个 Response \(\{y^{(i)}\}_{i = 1}^{G}\),并通过 \(R(x,y^{(i)})\) 评估每个 Response
    • 通过组内归一化构建一个组相对优势(group-relative advantage):
      $$\begin{array}{c}{\hat{A}^{(i)} = \frac{R(x,y^{(i)}) - \mu_R}{\sigma_R} }\\ {\mu_R:= \frac{1}{G}\sum_{j = 1}^{G}R(x,y^{(j)}), \quad \sigma_R:= \text{std}\Big(\{R(x,y^{(j)})\}_{j = 1}^{G}\Big)} \end{array} \tag {2}$$
  • 策略优化时,使用一个 PPO 风格的、在组归一化优势上的裁剪目标进行优化:
    $$\begin{array}{rl} & {\mathcal{J}_{\text{GRPO} }(\theta) = \mathbb{E}_{x\sim \mathcal{D},\{y^{(i)}\}_{i = 1}^{G} }\left[\frac{1}{G}\sum_{i = 1}^{G}\sum_{t = 1}^{|y^{(i)}|}\right.} {\left.\left(\min \left(r_{i,t}(\theta)\hat{A}^{(i)},\text{clip}(r_{i,t}(\theta),1 - \epsilon ,1 + \epsilon)\hat{A}^{(i)}\right)\right.\right.} {\left.\left. - \beta D_{\text{KL} }(\pi_{\theta}| \pi_{\text{ref} })\right)\right],} \end{array} \tag {3}$$
    • 重要性采样比率定义为
      $$r_{i,t}(\theta) = \frac{\pi_{\theta}(y_t^{(i)}\mid x,y_{< t}^{(i)})}{\pi_{\theta_{\text{old} } }(y_t^{(i)}\mid x,y_{< t}^{(i)})}. \tag {4}$$
  • GRPO 基于组内统计量估计优势
    • 后面,本文作者会利用这一结构特性来构建一个更符合 On-policy 的长度正则化方案,并制定优势感知校准,以更好地尊重底层的优化信号,详见第 3 节

Length-Regularized Reinforcement Learning

  • RL 带来了实质性的性能提升,但 RL 的一个关键的失败模式变得越来越明显(本文称为长度膨胀)
    • 长思维链(Long-CoT)模型特别容易受到过度思考的影响(2024b;2025a)
    • RLHF 中的 Reward Hacking(2023;2023)也可能导致 Response 长度的爆炸性增长
  • 缓解 RL 中长度膨胀的一个常见策略是通过 Reward Shaping 显式地正则化 Response 长度
    • 从一个统一的视角来看(2025c),大多数现有方法可以被实例化为加性塑形 :
      $$\text{Additive:}\hat{R}^{(+)} = R + \lambda \cdot S,\lambda >0 \tag {5}$$
      • \(R\) 是任务奖励
      • \(S\) 是一个依赖于长度的塑形信号
      • \(\lambda\) 控制长度正则化的强度
      • \(\hat{R}^{(+)}\) 表示用于策略优化的塑形后奖励
      • 表 1 中展示了一些代表性的 加性塑形 的例子
    • 在这个公式下,现有方法主要在长度正则器 \(S\) 的实例化方式上有所不同
      • 最基本的策略通常依赖于一个固定的阈值(例如, \(\ell_{T} = 4K\) ):
        • 一旦 Response 长度超过这个限制,模型就会招致一个恒定的惩罚(2025b)或一个逐渐增加的惩罚(2025)
      • 一个更 Principled 范式则利用组级统计量(2025)来确定惩罚的强度
      • 一些方法引入了门控机制(例如, \(\mathbb{I}(R = 1)\) )(2025), 仅对成功的轨迹激活长度正则化,以防止模型过度优化简洁性
    • 这些方法在具体实例上有所不同,但共享一个共同的目标:
      • 在 RL 训练期间压缩 Response 长度
      • 但实践发现,这种正则化常常导致性能下降,这促使本文作者更仔细地审视 Reward Shaping 设计

Group Relative Reward Rescaling(GR3, GR\(^3\))

  • \(\mathbf{GR}^3\) 是一个旨在无损能力的情况下缓解长度膨胀的 Principled 框架
  • 对于一个在一组 \(G\) 个样本中的、长度为 \(\ell^{(i)} = |y^{(i)}|\) 的 Response \(y^{(i)}\), \(\mathbf{GR}^3\) 将重缩放后的奖励定义为:
    $$\hat{R} (x,y^{(i)}) = R(x,y^{(i)}) \cdot \underbrace{\frac{1}{1 + \alpha \cdot \frac{\ell^{(i)} }{\bar{\ell} } } }_{S^{(i)} } \tag {6}$$
    • \(S^{(i)}\) 表示长度缩放因子
    • \(\bar{\ell}\) 表示组内的平均 Response 长度
  • 这个公式反映了三个维度的统一设计
    • 采用乘法奖励重缩放(第 3.1 节)作为一种依赖于奖励的门控,减轻了补偿效应,同时仍适用于一般的连续奖励分布
    • 通过组相对正则化(第 3.2 节)实例化缩放因子,利用 On-policy 平均值 \(\bar{\ell}\) 来动态地将长度预算调整到 Prompt 的固有难度
    • 为了维持稳定的优化,优势感知校准(第 3.3 节)进一步控制惩罚强度,防止对高优势轨迹的不当抑制

Multiplicative Reward Rescaling

Motivation and Formulation
  • 最朴素的长度控制方法依赖于如公式 5 所示的加性 Reward Shaping ,其中 \(\lambda\) 控制长度惩罚的强度
    • 但加性塑形引入了一个固有的补偿效应:塑形项 \(S\) 形成了一个可以独立于任务性能被利用的辅助优化目标
    • 一些工作通过门控机制缓解了这个问题,例如,将 \(I(R = 1)\) 纳入 \(S\)
      • 但这种设计仅限于二元奖励,不能扩展到连续奖励设置
  • 区别于这些加性公式,作者提出了一个更通用的乘法塑形范式:
    $$\mathbf{Multiplicative:}\quad \hat{R}^{(\times)} = R\cdot S, \tag {7}$$
    • 这可以解释为启发式门控的连续扩展,消除了权衡系数 \(\lambda\),并自然地推广到任意奖励尺度 1
    • 重点:乘法公式消除了加性塑形的补偿特性,要求策略联合优化任务性能和长度控制
  • 如图 3 所示,加性塑形表现出一个系统性的失败模式:
    • 对于任何 \(\lambda\) 的选择,优化都被快速的长度缩减所主导,导致严重的性能下降
    • 乘法塑形不允许这样的捷径,因此避免了这种崩溃
  • 直观地说,乘法塑形通过下式将长度控制的影响与任务奖励耦合起来:
    $$\frac{\partial\hat{R}^{(\times)} }{\partial S} = R. \tag {8}$$
    • 因此,长度正则化随着任务成功而自动增强,使塑形内在地具有奖励感知性
Analysis Under Group-Normalized Advantage
  • 在 GRPO 采用的组归一化优势下进一步提炼上述直觉
    • 固定一个 Prompt \(x\),并考虑由采样 Response \(y \sim \pi_{\theta_{\text{old} } }(\cdot |x)\) 引起的 \((R,S)\) 的组内分布
      • 其中 \(R \in [0,1]\) 表示任务奖励, \(S \in [0,1]\) 表示一个与长度相关的分数(例如,公式 6)
  • 比较加性塑形 \(\hat{R}^{(+)}\)(公式 5)和乘性塑形 \(\hat{R}^{(\times)}\)(公式 7)
    • 令 \(\mu\) 和 \(\sigma\) 表示组内均值和标准差
    • 结果使用 Population Moments 陈述,经验版本通过 Substituting 样本均值得到
Proposition 3.1 (Additive shaping: linear injection of the length signal)
  • 命题 3.1 (加性塑形:长度信号的线性注入)
  • 令 \((R,S)\) 具有有限二阶矩,并定义
    • \(\mu_{R} = \mathbb{E}[R]\)
    • \(\mu_{S} = \mathbb{E}[S]\)
    • \(\sigma_{R}^{2} = \text{Var}(R)\)
    • \(\sigma_{S}^{2} = \text{Var}(S)\)
    • \(\sigma_{RS} = \text{Cov}(R,S)\)
  • 对于
    $$\hat{R}^{(+)} = R + \lambda S, \quad where \lambda >0 $$
    • 有:
      $$ \begin{align}
      \hat{R}^{(+)} - \mathbb{E}[\hat{R}^{(+)}] &= (R - \mu_R) + \lambda (S - \mu_S), \tag {9} \\ \text{Var}(\hat{R}^{(+)}) &:= \sigma_{R}^{2} + \lambda^{2}\sigma_{S}^{2} + 2\lambda \sigma_{RS}, \tag {10}
      \end{align}$$
  • 因此
    $$A\left(\hat{R}^{(+)}\right) = \frac{(R - \mu_R) + \lambda(S - \mu_S)}{\sqrt{\sigma_R^2 + \lambda^2\sigma_S^2 + 2\lambda\sigma_{RS} } }. \tag {11}$$
  • 因此,与长度相关的信号 \((S - \mu_S)\) 以固定权重 \(\lambda\) 线性地注入到优势中,并且即使在组内 \(R\) 提供很少的判别信号时也能起作用
  • Proof :
    • 公式 (9) 由下式给出:
      $$\mathbb{E}[\hat{R}^{(+)}] = \mu_R + \lambda \mu_S$$
    • 公式 (10) 由下式导出:
      $$\text{Var}(X + Y) = \text{Var}(X) + \text{Var}(Y) + 2\text{Cov}(X,Y)$$
      • 其中 \(X = R\) 和 \(Y = \lambda S\)
    • 公式 (11) 通过将公式 (2) 中的 \(R\) 替换为 \(\hat{R}^{(+)}\) 得到
Proposition 3.2 (Multiplicative shaping: reward-weighted length signal)
  • 命题 3.2 (乘性塑形:奖励加权的长度信号)
  • 令 \((R,S)\) 具有有限二阶矩,并定义
    • \(\mu_R = \mathbb{E}[R]\)
    • \(\mu_S = \mathbb{E}[S]\),
    • \(\sigma_R^2 = \text{Var}(R)\),
    • \(\sigma_S^2 = \text{Var}(S)\),
    • \(\sigma_{RS} = \text{Cov}(R,S)\)
  • 对于乘性塑形 \(\hat{R}^{(\times)} = RS\),有:
    $$\mathbb{E}[\hat{R}^{(\times)}] = \mathbb{E}[RS] = \mu_R\mu_S + \sigma_{RS}. \tag {12}$$
  • 此外,中心化后的塑形奖励允许分解为:
    $$RS - \mathbb{E}[RS] = R(S - \mu_S) + \mu_S(R - \mu_R) - \sigma_{RS}. \tag {13}$$
  • 因此,组归一化后的优势可以写为:
    $$A\left(\hat{R}^{(\times)}\right) = \frac{R(S - \mu_S) + \mu_S(R - \mu_R) - \sigma_{RS} }{\sqrt{\text{Var}(RS)} }. \tag {14}$$
  • Proof :
    • 公式 (12) 由下面的公式得到:
      $$\mathbb{E}[RS] = \mathbb{E}[R]\mathbb{E}[S] + \text{Cov}(R,S)$$
    • 对于公式 (13)
      • 重写为
        $$RS = R\mu_S + R(S - \mu_S) = \mu_R\mu_S + \mu_S(R - \mu_R) + R(S - \mu_S)$$
      • 并减去
        $$\mathbb{E}[RS] = \mu_R\mu_S + \sigma_{RS}$$
    • 公式 (14) 是将公式 (2) 应用于 \(\hat{R}^{(\times)}\) 的结果
Remark 3.3 (为什么乘性塑形在组归一化下具有奖励感知性)
  • 在加性塑形下,命题 3.1 表明长度偏差 \((S - \mu_S)\) 以固定系数 \(\lambda\) 注入中心化后的塑形奖励
    • 这创造了一个补偿性的自由度:即使当 \(R\) 提供很少的学习信号时,策略也可以通过操纵 \(S\) 来改善塑形奖励
  • 相比之下,命题 3.2 给出了分解式
    $$RS - \mathbb{E}[RS] = R(S - \mu_S) + \mu_S(R - \mu_R) - \sigma_{RS}$$
    • 其中长度偏差的影响被 \(R\) 本身缩放
    • 因此,当奖励低时长度控制较弱,并随着任务性能提高而增强,使得乘性塑形内在地具有奖励感知性
      • 问题:为什么奖励低时应该用耿荣的长度控制?奖励高时应该用更强的长度控制?

Group Relative Length Regularization

  • 之前工作的问题:
    • 许多先前的工作通过施加绝对长度阈值(2025;2025c)来解决长度膨胀问题,惩罚超过固定预算的轨迹
      • 这种设计可能会抑制困难实例上的必要推理,使策略对任务难度不敏感,从而降低性能
    • 更重要的是,固定的阈值不可避免地会导致 Off-policy 偏差:
      • 最优推理长度随任务变化,并在训练过程中发生改变,这是单一的全局常数无法捕捉的
  • 解法:组相对长度正则化策略,它能够适应 On-policy 行为
    • 根据公式 6,使用组内统计量定义一个界于 \((0,1)\) 的有界长度塑形项 \(S^{(i)}\):
      $$S^{(i)} = \frac{1}{1 + \alpha \cdot \frac{\ell^{(i)} }{\bar{\ell} } }, \quad \alpha >0. \tag {15}$$
      • \(\ell^{(i)}\) 是 Response 长度
      • \(\bar{\ell}\) 是组均值
    • 这个惩罚随着长度增加而平滑下降,同时通过 \(\bar{\ell}\) 归一化避免了任意的全局阈值,并使惩罚适应模型当前的生成行为
  • 如表 2 所示,将固定阈值截断方法(2025)作为一个极简基线
    • 可以发现,基于阈值的截断即使在困难的基准测试上也强加了统一的最大 Response 长度,这会损害在挑战性问题上的推理性能
    • 与其他组相对方法进行比较,发现某些塑形策略(2025)引入了偏向于在简单基准上进行浅层推理的偏差(分析见附录 B)
    • 作者还评估了另一种组相对方法 Kimi-1.5(2025),但它表现出训练崩溃;
      • 因此,作者省略了其结果
      • 作者将此失败归因于没有门控的加性塑形范式,如第 3.1 节所述

Advantage-Aware Calibration

  • 在组相对策略优化的框架内,长度惩罚项 \(S\) 充当了优势格局的强大塑造者
  • 惩罚强度与组归一化之间的相互作用 is non-trivial:\(S\) 的微小变化都可能显著改变优化轨迹
    • 在实践中,无约束或过强的惩罚可能会严重惩罚高质量 Response ,以至于产生一个矛盾的信号,阻止模型生成其最佳 Response
  • 一个自然但过于严格的目标是要求所有高质量轨迹都保持正优势
    • 在高奖励密度下,当组内大多数 Response 都达到最大奖励 \(R_{\text{max} }\) 时(例如,16 个中有 15 个是正确的),这会变得难以实现
    • 由于组归一化的零和结构,正确但长度高于平均水平的 Response 可能不可避免地获得负优势
    • 作者在附录 C.1 中对此限制提供了正式分析
  • 理解:GRPO 中,优势为负的 Response 会被打压(降低生成概率),优势为正的 Response 会被提升(提升生成概率)
    • 所以这里主要想强调高质量的 Response 不应该 优势为负
    • 问题:实际上,从 PG 方法来看,即使所有的梯度系数(比如可以为累计收益)都为正,或者都为负,也总会收敛到最优策略(至少从数学上来看是这样的,所有动作的概率都在被提升的时候,因为总的概率和为 1,所以提升最大的动作肯定是概率提升的,提升最小的动作概率肯定是下降的),所以推测,GRPO 这里理论上也不一定需要这个优质样本优势为正的强假设
Average-Case Advantage Preservation,平均情况优势保持
  • 我们不是要保护最长的异常轨迹,而是旨在保持一个有代表性的高质量 Response 的优势
    • 考虑一个 Response ,它达到了组内最大奖励 \(R_{\text{max} }\),并具有组平均长度 \(\bar{\ell}\),并要求其优势保持非负
    • 令 \(\mu_{\bar{R} }\) 表示组内正则化后奖励的均值,这产生了条件:
      $$\frac{R_{\text{max} } }{1 + \alpha\cdot\frac{\bar{\ell} }{\bar{\ell} } }\geq \mu_{\bar{R} }\Rightarrow \frac{R_{\text{max} } }{1 + \alpha}\geq \mu_{\bar{R} } \tag {16}$$
      • 这确保了惩罚 \(\alpha\) 不会推翻一个典型高质量 Response 的优势
      • 在组内所有轨迹都达到 \(R_{\text{max} }\) 的极限情况下,平均情况约束仍然可能无法满足
        • 因此,本文过滤掉此类组 (见附录 C.2)
  • 在实践中,由于 On-policy 采样的随机性,公式 (16) 并非作为每次更新的硬约束来执行
    • 可将其视为选择惩罚系数 \(\alpha\) 的校准标准
  • 在 GRPO 训练开始时运行一个短暂的校准阶段,并测量候选 \(\alpha\) 值上的约束满足率(Constraint Satisfaction Rate, CSR)
    • 然后选择 CSR 保持持续高值(例如,\(\geq 99.9%\))的最大 \(\alpha\),以确保高概率的约束满足,同时保持强大的长度正则化
  • 经验上,通过此协议选择的 \(\alpha\) 在整个训练过程中保持了近乎完美的 CSR(见图 4)
    • 这一点有效地标志了一个实际边界:相对于 GRPO 基线的奖励差距已经是正的,表明任务能力得到保留
    • 进一步降低惩罚强度(即减小 \(\alpha\))不会带来一致的性能提升,反而会导致与训练方差一致的波动

Experiments

Setup

Efficient Reasoning for RLVR
  • 遵循先前的工作,采用 DeepSeek-R1-Distill-1.5B 和 DeepSeek-R1-Distill-7B (2025) 作为基础模型
  • 对于数学推理,使用 DeepScaleR-Preview-Dataset (2025b) 作为训练数据
    • 将现有高效推理方法的开源检查点作为基线,如 LC-R1 (2025)、Laser (2025c)、AdaptThink (2025) 和 DLER (2025b)
  • For 通用性,进一步将其扩展到代码生成任务,使用来自 DeepDistill (2025) 的 Prompt
Mitigating Length Bias in RLHF
  • 对于 RLHF 设置,使用非推理版本的 Qwen3-4B 和 Qwen3-8B (2025) 作为基础模型
  • 从 arena-human-preference-140k 构建 RL Prompt,并采用 Skywork-Reward-V2-Llama-3.1-8B (2025a) 作为奖励模型
  • 为了提高训练稳定性,应用了基于参考的 Sigmoid 塑形 (2025) 方案(原始论文见:(PAR)Reward Shaping to Mitigate Reward Hacking in RLHF, 20250226-20260121, Fudan & UC Berkeley & StepFun):
    $$R(x,y^{(i)}) = s\Big(R_{\text{origin} }(x,y^{(i)}) - R_{\text{origin} }(x,y^{\text{ref} })\Big). \tag {17}$$
    • \(R_{\text{origin} }(\cdot)\) 表示原始奖励模型分数
    • \(s(\cdot)\) 是 sigmoid 函数
    • 注:原始论文中,可能会有多个 参考回复 \(y^{\text{ref}}\)
  • 详细的实验设置在附录 D 中提供

Main Results

Efficient Reasoning for RLVR
  • 7B 模型的实验结果如表 3 所示,1.5B 模型的结果见附录 E.1
  • \(\mathbf{GR}^3\) 在减少生成长度的同时提高了推理性能,这表明其实现了真正的效率提升,而非一种权衡
  • 在数学推理中,与标准 GRPO 相比,\(\mathbf{GR}^3\) 在保持甚至提升性能的同时,生成了更短的文本
    • 在 7B 规模的 AIME24 上
      • \(\mathbf{GR}^3\) 平均长度:13,213 Token -> 7,923 Token(GRPO 为 11079)
      • Avg@32:52.4 -> 60.1(GRPO 为 57.1)
  • 在数学推理中,与现有的面向长度的基线相比,\(\mathbf{GR}^3\) 没有以牺牲准确性为代价过度压缩推理长度
    • GR3 能优先在保持性能的同时去除冗余推理
    • 在 AIME25(7B)上,没有一个面向长度的基线能够超越初始检查点的性能(39.4),而 \(\mathbf{GR}^3\) 则用更少的 Token(14,032 -> 8,582)将其性能提升至 46.9
    • 这表明 \(\mathbf{GR}^3\) 鼓励更高效的推理轨迹,而不仅仅是截断推理,从而在不同规模上都能带来持续的增益
  • 表 4 展示了在代码 Setting 下的结果,与数学推理结论一致,\(\mathbf{GR}^3\) 在保持任务性能的同时实现了显著的效率提升
Mitigating Length Bias in RLHF
  • 对齐基准上的结果如表 5 所示
    • 与初始模型相比,RLHF 训练在聊天质量上带来了显著的改进
    • 标准 GRPO:
      • 在长度偏置下遭受严重的 Reward Hacking,即模型可以通过生成不必要地长 Response 来人为地增加奖励,导致爆炸性的长度膨胀
      • 例如,在 Qwen3-8B 上,Arena-Hard-Auto 的平均 Response 长度从 1,171 个 Token 增加到 2,343 个 Token
    • \(\mathbf{GR}^3\)
      • 在保持 Response 长度几乎不变的同时,取得了相当甚至更强的对齐增益,有效地将性能提升与冗长性解耦
      • 例如,在 Qwen3-8B 上,\(\text{GR}^{3}\) 将 Arena-Hard-Auto 分数从 77.2 提高到 92.8,而 Token 成本仅略微增加 (1,171 -> 1,178)
  • 图 2 中进一步可视化了 RLHF 设置下的训练动态
    • 在 GRPO 下,Response 长度在整个训练过程中单调且不可控地增长
    • 相比之下,\(\text{GR}^{3}\) 呈现出清晰的“先增后减”模式 :模型最初扩展其推理以确保对齐改进,然后在性能稳定后压缩冗余生成
    • 这种动态行为符合作者的设计直觉:\(\text{GR}^{3}\) 优先实现可靠的对齐增益,然后通过抑制基于长度的利用来逐步提高 Response 效率

Analysis and Discussion

Ablation on Penalty Strength \(\alpha\)
  • 通过在其值范围内进行扫描来研究惩罚系数 \(\alpha\) 的影响,同时保持所有其他设置不变
    • 注:详细的结果和分析见附录 E.2,这里作者仅总结关键发现
  • 当 \(\alpha\) 过大时(例如,1.0):\(\text{GR}^{3}\) 退化为一种朴素的长度正则化方法:Response 变得更短,但相较于基础模型的性能增益有限,因为优化过程主要由压缩主导,而非能力提升
  • 随着 \(\alpha\) 减小:Response 长度平滑增长,而任务性能先提高后趋于平稳
    • 这一趋势与第 3.3 节的分析一致:
      • 当具有代表性的高质量轨迹的优势得以保留后,进一步减小惩罚主要会放宽长度控制,而不会产生更强的学习信号
      • 问题:如何理解这里的 不会产生更强的学习信号?
    • 所选值 \(\alpha = 0.33\) 接近这个过渡区域,在保留大部分性能增益的同时实现了显著的长度缩减
Why Does \(\text{GR}^{3}\) Outperform GRPO?
  • 作者观察到一个反直觉的现象:在许多 Setting 中,\(\text{GR}^{3}\) 不仅缩短了 Response,而且取得了比标准 GRPO 更强的下游性能,同时相对于 GRPO 基线保持正向的奖励差距
    • 作者将此归因于优化信号结构方式的不同
  • 在无约束的 RL(如 GRPO)下,策略往往会漂移到过度扩展的推理轨迹上
    • 尽管这些轨迹最终可能达到正确答案,但它们往往包含许多贡献较低的 Token
    • 从优化的角度来看,这会使得学习信号在长 Response 中被稀释,降低了奖励对最重要推理步骤的有效影响
    • 通过抑制不必要的冗长,\(\text{GR}^{3}\) 在保留关键步骤的同时压缩了推理痕迹
      • 这增加了奖励相对于 Token 的信号密度,使得优化能够更强烈地聚焦于因果上重要的推理模式 ,而不是将梯度分散在冗长但相关性弱的 Token 上
    • 附录 F 中提供了定性的生成示例

Related Work

  • RL (1996; 2022; 2025) 存在推理成本高和生成长度不断增长的问题,作者将这一瓶颈称为 长度膨胀 (length inflation)
  • 一系列工作研究高效推理 (2025; 2025),旨在改进长思维链模型的准确率-成本权衡
    • 早期方法依赖于 Prompt 工程或有监督微调来鼓励更短的推理痕迹 (2025a; 2025; 2025b)
    • 最近更多的方法应用 RL,通过长度感知的目标直接优化效率 (2025; 2025c; 2025)
      • 虽然这些方法在减少 Token 使用方面很有效,但由于惩罚校准不佳或存在捷径解 (2025),它们可能会降低性能或引入不稳定的优化动态
  • 另一系列工作将 RLHF 中的长度膨胀归因于 Reward Hacking 和长度偏置 (2022; 2023; 2023)
    • 由于奖励模型可能隐式地偏爱较长的 Response,冗长可能源于利用奖励的假象而非真正的能力提升 (2023)
    • 先前的工作通过改进奖励建模和校准 (2024a; 2025) 或应用事后奖励修正 (2024) 来缓解这一问题,尽管许多这些解决方案是针对特定训练环境定制的
  • \(\text{GR}^{3}\) 与基于 RL 的高效推理最为相关,并且在由长度偏置驱动的 Reward Hacking 情况下仍然有效
    • \(\text{GR}^{3}\) 是一个通用的长度正则化框架,在保持性能的同时改善了性能-成本帕累托前沿

附录 A:Connection to Heuristic Gating Mechanisms,分析 GR3 与启发式门控机制的联系

  • 第 3.1 节中主要从消除加法塑形固有的补偿性优化捷径的角度来激励乘法塑形
  • 本节通过分析 \(\text{GR}^{3}\) 与启发式门控机制 (2025; 2025) 之间的关系,提供另一种视角
  • 作者证明,乘法塑形可以被视为启发式门控的一个 Principled 泛化:
    • 在二元奖励设置中数学上简化为门控,同时在硬指示器失效的连续奖励场景中提供了一个鲁棒的、”软性”的门控机制

Equivalence in Binary Reward Settings,二元奖励中两者是等价的

  • 启发式门控是对高效推理 (RLVR) 中加法塑形的一种常见改进,可防止模型以牺牲准确性为代价来优化长度
    • 启发式门控通常采用一个指示函数 \(\mathbb{I}(R = 1)\),仅在 Response 正确时应用长度惩罚
  • 设 \(P\) 表示一个通用的基于长度的惩罚项(例如,一个长度的负函数)
    • 标准的门控加法塑形将等式 5 中的塑形项 \(S\) 修改为依赖于任务成功与否的条件形式:
      $$\text{Gated Additive: }\hat{R}^{(+g)} = R + \lambda \cdot S_{\text{gate} }$$ $$\text{where }S_{\text{gate} } = \mathbb{I}(R = 1)\cdot P.$$
      • \(\mathbb{I}(R = 1)\) 是一个硬门控
      • \(R\in \{0,1\}\) 是二元任务结果
  • 考虑在等式 7 中定义的乘法塑形:
    $$\text{Multiplicative: }\hat{R}^{(\times)} = R\cdot S_{\text{mult} }.$$
  • 为了便于比较,将缩放因子 \(S_{\text{mult} }\) 分解为一个基线和偏差项
    • 将 \(S_{\text{mult} } = 1 + (S_{\text{mult} } - 1)\) 重写,其中偏差对应于缩放机制应用的隐式惩罚:
      $$\lambda P:= S_{\text{mult} } - 1\quad \Longrightarrow \quad S_{\text{mult} } = 1 + \lambda P.$$
  • 分析两种二元状态下的行为:
    • 情况 \(R = 0\) (失败):
      $$\hat{R}^{(+g)} = 0 + \lambda \cdot (0\cdot P) = 0$$ $$\hat{R}^{(\times)} = 0\cdot (1 + \lambda P) = 0$$
      • 两种方法都会停用惩罚,防止在困难实例上过早终止
    • 情况 \(R = 1\) (成功):
      $$\hat{R}^{(+g)} = 1 + \lambda \cdot (1\cdot P) = 1 + \lambda P$$ $$\hat{R}^{(\times)} = 1\cdot (1 + \lambda P) = 1 + \lambda P$$
      • 两种方法都应用完整的惩罚,以激励正确解决方案中的效率
  • 结论:在典型的 RLVR 的严格二元奖励设置中,乘法塑形在数学上等价于启发式门控
    • 继承了在不正确的推理路径上保护策略免受惩罚的理想特性

Generalization to Continuous Rewards,泛化到连续奖励

  • 当过渡到连续奖励设置时,启发式门控的局限性变得明显,例如 RLHF(其中奖励通常由奖励模型给出)或具有部分分数的推理任务
  • 在这些场景中,硬指示器 \(\mathbb{I}(R = 1)\) 是难以定义的
    • 简单地将它替换为一个阈值 \(\mathbb{I}(R > \tau)\) 会引入超参数和优化不连续性
    • 相反,完全移除门控(回到纯粹的加法塑形)会重新引入命题 3.1 中讨论的权衡问题,即模型可以通过缩短长度来改进 \(\hat{R}^{(+)}\),即使 \(R\) 略有下降
  • 乘法塑形通过充当软门控机制解决了这个问题
    • 正如命题 3.2 推导的那样,在乘法塑形下,组归一化优势包含以下控制长度信号的项:
      $$A(\hat{R}^{(\times)})\propto R\cdot (S - \mu_S) + \ldots$$
    • 这个分解表明,长度变化 \((S - \mu_S)\) 对优势的影响明确地由任务奖励 \(R\) 缩放
    • 这创建了学习信号的动态重加权:
      • 低质量 \((R \approx 0)\): 长度信号被抑制 \((R \cdot (S - \mu_S) \approx 0)\)
        • 优势主要由改进任务正确性的需求决定,策略几乎收不到关于长度的信号。这模仿了非激活的门控,防止模型坍缩到短但不正确的 Response
      • 高质量 \((R \approx 1)\): 长度信号完全激活 \((R \cdot (S - \mu_S) \approx S - \mu_S)\)
        • 优势显著地倾向于成功组内较短的轨迹
        • 这模仿了激活的门控,能力得到保证后,就有效地优先考虑效率
  • 这个特性有效地根据 Response 质量在”无惩罚”和”完全惩罚”之间进行插值
    • 因此,\(\mathbf{GR}^3\) 允许作者在 RLHF 中应用强长度正则化,而不会有模型坍缩到短、低质量 Response 的风险,如图 2 中的动态所示

Empirical Observation

  • 作者进一步进行了一项分析实验,如图 5 所示
    • 通过定义 \(\lambda P := S_{\text{mult} } - 1\),将乘法塑形项转换为门控加法塑形中使用的惩罚形式
    • 然后引入不同的阈值 \(\mathbb{I}(R > \tau)\) 来将门控加法塑形扩展到连续奖励的 RLHF 设置
    • 可观察到
      • 由于优化不连续性,所有 \(\tau\) 的选择都导致性能低于标准 GRPO
      • 同时,生成长度被更激进地减少,降至基础策略模型的典型水平以下

附录 B:Analysis of the Difficulty Over-Adaptation Phenomenon,难度过适应现象分析

  • 第 3.2 节中讨论了组相对长度正则化如何使长度预算适应于 on-policy 统计量
  • 虽然这消除了全局阈值的刚性,但在某些塑形策略中观察到了一个意想不到的副作用(例如,Efficiently (2025)):
    • 策略可能变得对感知到的任务难度过度适应(over-adaptive) ,作者将此现象称为难度过适应(Difficulty Over-Adaptation)
    • 具体解释:模型倾向于在简单 Prompt 上激进地压缩推理,而在困难 Prompt 上未能有效约束过长的长度
      • 理解:可能是因为
        • 简单的 Prompt 上,大家的奖励都收敛为 1 左右了,从而学习的重点是长度(缩短)
        • 困难的 Prompt 上,偶尔有一个正确的 Response,此时的长度惩罚可能不占主体,主要以优化 Response 为主
          • 因为乘法情况下,想要获得高的 Final Reward,高质量(Reward Score 为正)的回复是必须的前提
    • 如表 2 所示,并通过表 6 中的示例加以说明
    • 换句话说,正则化器扭曲了推理 effort 在不同难度级别上的分配
  • 为了理解这种偏差背后的机制,作者分析奖励函数对长度变化的敏感性
    • 考虑 Efficiently (2025) 的公式:
      $$\hat{R} (x,y^{(i)}) = R(x,y^{(i)}) - \lambda \cdot \mathbb{I}(R(x,y^{(i)}) = 1)\cdot s\left(\frac{\ell^{(i)} - \bar{\ell} }{\sigma_{\ell} }\right).$$
      • 在这个公式中,sigmoid 函数 \(s(\cdot)\) 的输入被因子 \(1 / \sigma_{\ell}\) 放大
      • 这意味着增加 Response 长度的边际惩罚与该组的统计离散度 \((\sigma_{\ell})\) 成反比
    • 这种依赖性在不同难度区间内造成了不稳定性
      • 在较简单的 Prompt 上,策略通常很自信,并收敛到一致的 Response ,导致长度标准差坍缩(即,\(\sigma_{\ell} \rightarrow 0\))
        • 因此,缩放因子 \(1 / \sigma_{\ell}\) 变得极大
        • 在这个低方差区间内,即使是一个 token 的偏差也会被视为巨大的统计异常值,触发奖励的严重下降
        • 这种 hypersensitivity 迫使模型过度压缩简单 Response 以避免严厉的惩罚
      • 在困难的 Prompt 上,策略通常会探索多样化的推理路径,导致更大的 \(\sigma_{\ell}\)
        • 这会减弱惩罚信号,使得较长的生成能够以相对较小的代价持续存在
  • 相比之下,\(\text{GR}^{3}\) 基于特征尺度(平均长度 \(\bar{\ell}\))而非离散度来归一化惩罚:
    $$\hat{R} (x,y^{(i)}) = R(x,y^{(i)})\cdot \frac{1}{1 + \alpha\cdot\frac{\ell^{(i)} }{\ell} }.$$
    • 惩罚的敏感性取决于相对于 \(\bar{\ell}\) 的比率
    • 平均长度 \(\bar{\ell}\) 对于较简单的任务自然更小(适当地使预算更紧张)
      • 但它代表了 Response 的物理尺度,并且不会随着模型变得自信而坍缩到接近零的值
    • \(\text{GR}^{3}\) 使用基于尺度而非方差进行归一化,提供了一个稳定的正则化信号
      • 该信号对模型的收敛状态保持鲁棒,有效地缓解了不同难度级别间压缩压力的不平衡

附录 C:The Dilemma of High Reward Density,高奖励密度的困境

  • 本节分析了将长度正则化与组归一化优势相结合时出现的一个基本结构张力
  • 作者证明,在高奖励密度下,一个看似理想化的严格条件(确保所有最高奖励轨迹都保持正优势)通常在数学上是不可行的
  • 然后作者证明,即使是一个宽松的平均情况标准,在所有采样轨迹都达到 \(R_{\text{max} }\) 的极限情况下也会退化,这是由于乘法长度重缩放的凸性所致
  • 这些观察结果证明了第 3.3 节中采用的基于松弛的校准策略和在线过滤策略的合理性

C.1 Impossibility of the Strict Advantage-Preservation Objective,严格优势保持目标是不可行的

A Strict but Natural Objective
  • 长度感知强化学习的一个自然目标是保留最佳解决方案的优化信号
  • 具体来说,考虑以下严格条件:在一个采样组内,所有达到最大任务奖励 \(R_{\text{max} }\) 的轨迹,在长度正则化后应获得正的优势
  • 直观上,这些轨迹代表了最高质量的 Response ,给它们分配负的优势可能会阻碍正确的推理行为
  • 在 GRPO 风格的归一化下,严格的目标因此等价于要求
    $$\hat{R} (x,y^{(j)}) > \mu_{\hat{R} },\quad \forall j\in \mathcal{H}$$
    • \(\mathcal{H}:= \{j:R(x,y^{(j)}) = R_{\text{max} }\}\) 表示最高奖励轨迹的集合
    • \(\hat{R} (x,y^{(j)})\) 是正则化后的奖励,而 \(\mu_{\hat{R} }\) 是组内正则化奖励的平均值
Impracticality Under High Reward Density,在高奖励密度下,上述目标不切实际
  • 在高奖励密度下,为所有最高奖励轨迹保留正优势的严格目标在数学上是不可行的,无论长度惩罚系数 \(\alpha\) 有多小
  • 在 \(\mathbf{GR}^3\) 下,正则化奖励为
    $$\hat{R} (x,y^{(j)}) = \frac{R(x,y^{(j)})}{1 + \alpha \cdot \frac{\ell^{(j)} }{\ell} }.$$
  • 对于所有 \(j\in \mathcal{H}\),有 \(R(x,y^{(j)}) = R_{\text{max} }\),因此 \(\hat{R}\) 的变化仅取决于长度
  • 由于正则化项在 \(\ell^{(j)}\) 上是单调递减的,\(\mathcal{H}\) 中最长的轨迹
    $$\ell_{\text{max} } = \max_{j\in \mathcal{H} }\ell^{(j)}$$
  • 获得最小的正则化奖励
    $$\hat{R}_{\text{min} } = \frac{R_{\text{max} } }{1 + \alpha \cdot \frac{\ell_{\text{max} } }{\ell} }.$$
  • 当奖励密度高时,组均值 \(\mu_{\hat{R} }\) 主要由 \(\mathcal{H}\) 中的轨迹决定,因此近似于它们的平均值
  • 由于一个集合的最小值不能超过其均值,作者必须有 \(\hat{R}_{\text{min} }\leq \mu_{\hat{R} }\)
  • 因此,至少有一个最高奖励轨迹在组归一化后获得非正的优势
    • 这表明,在高奖励密度下,所有最高奖励轨迹在组归一化后都保持正优势是不可能的
    • 这种冲突是结构性的,而非超参数选择的结果
  • 即使在极限 \(\alpha \rightarrow 0\) 下,这种不可能性仍然存在
    • 使用一阶展开,
      $$\hat{R} (x,y^{(j)})\approx R_{\text{max} }\cdot \left(1 - \alpha \cdot \frac{\ell^{(j)} }{\ell}\right)$$
    • 并记
      $$\bar{\ell}_{\mathcal{H} } = \frac{1}{k}\sum_{j\in \mathcal{H} }\ell^{(j)}$$
    • 为最高奖励轨迹中的平均长度,得到
      $$\hat{R} (x,y^{(j)}) - \mu_{\hat{R} }\approx -R_{\text{max} }\cdot \alpha \cdot \frac{\ell^{(j)} - \bar{\ell}_{\mathcal{H} } }{\bar{\ell} }.$$
    • 因此
      $$\hat{A}^{(j)}\propto -(\ell^{(j)} - \bar{\ell}_{\mathcal{H} }).$$
    • 所以任何长度超过 \(\mathcal{H}\) 平均长度的最高奖励轨迹都必须获得负优势,无论 \(\alpha\) 有多小
    • 组归一化强制实行零均值约束,这不可避免地导致在具有不同长度的同等正确的轨迹中产生符号翻转
Empirical Observation
  • 图 6 凭经验说明了这一现象
    • 横轴显示组中达到 \(R_{\text{max} }\) 的轨迹比例(奖励密度),纵轴显示满足严格条件 \(A_{i} > 0\) 的最高奖励轨迹的比例
    • 即使使用非常小的惩罚强度(图 6(a), \(\alpha = 0.05\)),满足率也随着奖励密度的增加而下降
    • 使用较大的 \(\alpha\)(图 6(b), \(\alpha = 5.0\)),下降变得更加明显
    • 这些结果证实,严格条件的违反源于固有的结构冲突,而不是糟糕的超参数调整
  • 这个不可能性结果直接激发了第 3.3 节中宽松校准策略的提出(在组内所有轨迹都达到 \(R_{\text{max}}\) 的极限情况下, 过滤掉此类组)
    • 作者不是试图保护最长的高奖励轨迹(这通常是不可行的),而是采用一个平均情况标准,确保一个典型的、长度接近组均值的高质量轨迹保持在组平均正则化奖励之上
    • 这自然导致了等式 16 中的实际约束

C.2. Degeneracy of the Average-Case Criterion in the All-\(R_{\text{max} }\) Limit,全 \(R_{\text{max} }\) 极限下平均情况标准的退化

  • 回顾平均情况校准标准(等式 16),它要求一个代表性的高质量轨迹(奖励 \(R_{\text{max} }\) 和平均长度 \(\bar{\ell}\))保持非负优势:
    $$\frac{R_{\text{max} } }{1 + \alpha}\geq \mu_{\hat{R} }$$
    • \(\mu_{\hat{R} }\) 表示正则化奖励的组内均值
  • 如第 3.3 节所述,在组中所有轨迹都达到 \(R_{\text{max} }\) 的极限情况下,这个约束可能会失败,这激发了在线过滤的动机
All-\(R_{\text{max} }\) case reduces the condition to a Jensen inequality,全为 \(R_{\text{max} }\) 将条件简化为 Jensen 不等式
  • 假设一个采样组满足所有 \(i \in \{1, \ldots , G\}\) 有 \(R(x,y^{(i)}) = R_{\text{max} }\)
  • 在 \(\text{GR}^{3}\) 下,正则化奖励为
    $$\hat{R}^{(i)} = R_{\text{max} }\cdot \frac{1}{1 + \alpha\cdot\frac{\ell^{(i)} }{\bar{\ell} } }.$$
  • 定义归一化长度比率 \(z_{i} := \ell^{(i)} / \bar{\ell}\),它满足 \(\frac{1}{G} \sum_{i = 1}^{G} z_{i} = 1\)
  • 设
    $$f(z):= \frac{1}{1 + \alpha z},\qquad z\geq 0.$$
  • 那么 \(\mu_{\hat{R} } = R_{\text{max} } \cdot \frac{1}{G} \sum_{i = 1}^{G} f(z_{i})\),并且等式 16 变为
    $$f(1)\geq \frac{1}{G}\sum_{i = 1}^{G}f(z_{i}).$$
Convexity flips the inequality,凸性翻转了不等式
  • 直接计算给出
    $$f^{\prime \prime}(z) = \frac{2\alpha^{2} }{(1 + \alpha z)^{3} } >0$$
  • 所以 \(f\) 在 \([0,\infty)\) 上是凸函数
  • 根据 Jensen 不等式,
    $$f\left(\frac{1}{G}\sum_{i = 1}^{G}z_{i}\right)\leq \frac{1}{G}\sum_{i = 1}^{G}f(z_{i}).$$
  • 利用 \(\frac{1}{G}\sum_{i}z_{i} = 1\),可以得到
    $$f(1)\leq \frac{1}{G}\sum_{i = 1}^{G}f(z_{i})$$
    • 这与期望的条件相反
  • 而且,只要长度不全相同(即,当 \(z_{i}\) 不是常数时),这个不等式就是严格的
    • 因此,在一个全 \(R_{\text{max} }\) 组中,等式 16 中的平均情况约束只有在退化情况 \(\ell^{(1)} = \dots = \ell^{(G)}\) 下才能成立;否则它必然失败
    • 这解释了为什么作者在实践中通过在线过滤排除这样的组
  • 理解:
    • 这里这种组下,都是正确的回复,我们希望模型选择更短的 Response,似乎也不是什么问题吧?为什么在作者的眼里是一个问题呢?

附录 D:Detailed Experimental Settings

  • 在跨越 RLVR 和 RLHF 的代表性后训练场景中评估 \(\text{GR}^{3}\)
  • 在 RLVR 设置中,研究模型是否能在保持任务性能提升的同时,减少不必要的长 CoT 推理
  • 在 RLHF 设置中,检验 GR3 是否减轻了 Reward Hacking (2016) 并产生具有自然 Response 长度的良好对齐的 Response
  • 本节提供实验中使用的详细超参数和配置
    • 所有实验均使用 veRL (2024) 作为训练框架进行,基于标准的 GRPO 优势估计器
    • 实验的详细实现设置如表 7 所示
  • 作者还做了如下验证:
    • 在 AIME-24 (MAA, 2024)、AIME-25 (MAA, 2025)、AMC-23 (MAA, 2023) 和 MATH500 (2023) 上评估数学推理能力
    • 在 LiveCodeBench v6 (2024) 和 MultiPL-E (2022) 上评估代码生成能力
    • 在 Arena-Hard-Auto (2024) 和 AlpacaEval (2024) 上评估对话能力
  • 遵循标准做法,报告 AlpacaEval 的长度控制 (LC) 胜率
    • 对于 Arena-Hard-Auto,不应用长度控制,而是使用直接从原始成对评判器得出的分数

附录 E:Additional Experimental Results

E.1. Mathematical Reasoning Results on 1.5B Models

  • 本节展示使用 DeepSeek-R1-Distill-1.5B 作为基础模型的数学推理任务实验结果
  • 如表 8 所示,结果与 DeepSeek-R1-Distill-7B 的实验结果一致:
    • \(\text{GR}^3\) 不仅显著增强了模型的推理能力,而且在 token 数量方面大幅减少了生成输出的长度,展示了在不同规模上的良好性能

E.2. Ablation Results on Penalty Strength \(\alpha\),关于 \(\alpha\) 的消融结果

  • 本节通过在相同训练设置下改变其值,分析 \(\text{GR}^3\) 对长度惩罚系数 \(\alpha\) 的敏感性
  • 1.5B 模型的详细结果如表 9 所示
    • 当 \(\alpha\) 较大时(例如, \(\alpha = 1.0\)),乘法重缩放项会严重惩罚长轨迹,很大程度上独立于它们的奖励水平
      • 在这种 regime 下,\(\text{GR}^3\) 的行为类似于传统的长度惩罚 RL,其中优化主要由缩短 Response 而非提高解决方案质量驱动
      • 尽管 token 使用量显著减少,但相对于初始模型的性能增益变得明显较小,表明过于激进的正则化抑制了有用的长形式推理
    • 随着 \(\alpha\) 减小, Response 长度以逐渐且良好的方式增加,而任务性能首先提高,然后趋于饱和
      • 特别是,从 \(\alpha = 0.33\) 移动到更小的值(例如,0.2 和 0.1)会产生更长的生成,但准确率提升微乎其微或不一致
        • 这一经验趋势与第 3.3 节中的分析紧密吻合
      • 一旦惩罚足够弱,以至于代表性的高质量轨迹的优势得以保留,进一步降低 \(\alpha\) 主要会放宽长度约束,而不会引入更强的优化信号
        • 换句话说,训练已经越过了优势保持边界,在此之后,额外的推理长度不再转化为有意义的性能增益
  • 总体而言,\(\alpha\) 控制着不同的行为区间,而 \(\text{GR}^3\) 提供了一种 Principled 方法,使其在长度控制和能力增益之间的优势保持过渡点附近进行选择

附录 F:Qualitative Analysis of Rollout Trajectories,Rollout 轨迹的定性分析

  • 为了更好地理解两种训练目标所导致的行为差异,本节在相同的推理 Prompt 上,展示了 \(\text{GR}^3\) 训练模型和 GRPO 训练基线的代表性 rollout 示例
  • 表 10 和 11 显示了生成轨迹

\(\text{GR}^3\): concise reasoning with preserved structure,简洁的推理与保留的结构

  • 如表 10 所示,\(\text{GR}^3\) 训练的模型产生了一个既结构化又经济的推理轨迹
  • 解决方案遵循清晰的进展:
    • (i) 重述任务
    • (ii) 识别完整旋转下方向的周期性
    • (iii) 将角度约简为 \(360^{\circ}\) 的余数
    • (iv) 将剩余旋转映射到罗盘方向
    • 每一步都直接有助于推进解决方案,中间检查用于确认而非重新推导早期的结果
  • 重要的是,轨迹以正确格式化的 boxed 答案果断终止
    • 推理链既没有人为缩短,也没有过于冗长
    • 冗余的重新计算和自我怀疑循环基本不存在
    • 这反映了一个策略,它已经学会主要将 token 分配给因果相关的步骤

GRPO: verbose loops and diluted signal,冗长的循环和稀释的信号

  • GRPO 训练的 baseline(表 11)表现出显著不同的行为
    • 尽管它反复识别出正确的中间事实(例如 \(360^{\circ}\) 周期性和 \(2250 \mod 360 = 90^{\circ}\) 的约简)
    • 但它经常重新推导这些事实,质疑先前已建立的结论,并在等效的公式之间振荡(例如,完整旋转与分数旋转)
    • 轨迹包含多次自我修正,但这些修正并未引入新信息
  • 这种模式导致冗长的推理痕迹,其中许多 token 仅与进展 weakly 相关
    • 从优化的角度来看,这样的轨迹将奖励信号分散到大量低影响的 token 上,减少了对决定性推理步骤的有效学习压力
    • 此外,尽管最终绕回正确的方向,但模型未能以所需的 boxed 格式呈现清晰的最终答案,使解决方案没有结论

Implications for optimization dynamics

  • 这些定性差异与第 4.3.2 节讨论的机制一致
  • 通过降低不必要长轨迹的优势,\(\text{GR}^3\) 隐式地偏好具有更高 Per Token 信息密度的推理路径
  • 这鼓励策略保留基本的逻辑结构,同时避免非鲁棒的推理模式,例如重复或自我怀疑的循环
  • 结论:奖励信号更加集中在对应于有意义的推理转换的 token 上,而不是被稀释到冗长但贡献低的片段中

NLP——LLM对齐微调-OAPL

注:本文包含 AI 辅助创作

  • 参考链接:
    • 原始论文:(OAPL)LLMs Can Learn to Reason Via Off-Policy RL, 20260222 & 20260227, Cornell University & Databricks & Harvard
    • 作者的前一篇论文:(A*-PO,A*PO)Accelerating rl for llm reasoning with optimal advantage regression, 20250527, Harvard
      • 是这篇文章思想来源,但是 A*PO 中是基于 \(\pi_\text{ref}\) 的采样样本来估计 \(V^{\star}\) 的,策略的更新则是 On-policy 的
      • 根源是两者的推导目标不一致:
        • A*PO 目标中的 KL 散度约束是当前策略与 \(\pi_\text{ref}\)(参考策略) 的 KL 散度
        • 本文 OAPL 目标中的 KL 散度约束是当前策略与 \(\pi_\text{vllm}\)(采样策略)的 KL 散度

Paper Summary

  • 整体说明:
    • 严格来说,本文是第一篇直视 LLM 中 Off-policy 方法的论文(忽略 PPO 中可能存在的微小 Off-policy 更新)
    • 本文提出的 OAPL(Optimal Advantage-based Policy Optimization with Lagged Inference policy)方法完全接受了 Off-policy 训练,无需任何重要性加权比率
    • 亮点:
      • 在代码生成实验中,策略滞后(Off-policy 程度)可能高达 400 次梯度更新 ,而无需任何重要性采样
      • 稳定地改进了 Pass@k 测试时扩展指标
    • 本文证明了一个简单的 off-policy RL 方法可以比用于 LLM 后训练的 on-policy RL 方法 GRPO 更有效
      • 需要确认的点:是否是因为 \(\pi_\text{ref}\) 被不断向前更新导致的?
    • 使用 Off-policy 方法,本文可以实现完全异步训练,并允许算法重用先前采样的数据,带来极高的样本效率
    • 实验用的模型较小(数学仅 4B,代码仅 14B),在更大的模型上是否有提升还需要进一步验证
    • 本文的最核心思路理解:
      • OAPL 的梯度推动策略 \(\pi\) 向着 使对数比值 \(\beta \ln(\pi/\pi_{\mathrm{vllm} })\) 逼近最优优势函数 \(A^{*}\) 的方向更新
        • 这是一种 回归到最优策略 的过程(其中最优策略由带 KL 正则化的最大化奖励目标定义)
      • 由于 \(A^{*}\) 是通过 \(\pi_{\mathrm{vllm} }\) 采样估计的,因此这个更新是 完全 off-policy 的,不需要重要性采样,也不需要 on-policy 数据
  • 背景 & 问题提出
    • LLM 的 RL 方法常使用 On-policy 算法(例如 PPO 或 GRPO)
    • 分布式训练架构带来的策略滞后以及训练策略与推理策略之间的差异导致数据在设计上就是 Off-policy 的,这破坏了 On-policy 假设
      • 理解:实际上这些 Off-policy 本身是可以解决的,只是说需要一些时间成本
  • 之前工作的解法:
    • 核心思路主要集中于使这些 Off-policy 数据看起来更符合 On-policy 数据
    • 方案一:通过重要性采样
    • 方案二:通过显式修改 Inference Engine 来更紧密地对齐训练策略和推理策略
  • 本文接受了 Off-policy 特性,并提出了一种新颖的、不需要这些修改的 Off-policy 强化学习算法 OAPL :
    • 基于最优优势的带滞后推理策略策略优化(Optimal Advantage-based Policy Optimization with Lagged Inference policy, OAPL)
  • OAPL 在竞赛数学基准测试上优于使用重要性采样的 GRPO
    • 在 LiveCodeBench 上匹配公开可用的代码模型 DeepCoder 的性能
    • 而且:训练中使用的生成次数减少了 3 倍
      • 如果能严格说明不是学习率导致,那么这个算是非常大的提升了(当前 LLM RL 训练的耗时大头基本都在 Rollout 上)
  • 实验证明,经 OAPL 训练的模型在 Pass@k 指标下具有改进的测试时扩展能力
  • 即使训练策略和推理策略之间的滞后超过 400 个梯度步 (比先前方法的 Off-policy 程度高 100 倍),OAPL 也能实现高效、有效的后训练
    • 注:之前一般异步不会超过 10,大部分时候是 4 以内

Introduction and Discussion

  • 自 DeepSeek-R1 以来,研究主要集中于改进 GRPO 的训练稳定性 , 训练稳定性 难以实现的一个核心原因是:
    • 现代的 RL 后训练基础设施通常并非真正的 On-policy
    • 特别是, Trainer (例如 HuggingFace 模型)和 Inference Engine (例如 vLLM 模型)可能对相同的序列产生不同的对数概率,即使两个模型具有相同的权重
      • 这种不匹配可能源于 Trainer 和 Inference Engine 内核实现的差异(2025),或者源于异步训练流程,其中 Inference Engine 可能包含一个较旧版本的 Trainer 权重 (2025)
  • 这种对数概率的差异使得实际的策略梯度训练有效地变成了 Off-policy 的:
    • 即用于优化当前策略的数据并非由该策略生成
  • 而经典的策略梯度方法(REINFORCE 等),以及现代的策略优化方法如 GRPO、PPO ,都是在 On-policy 的假设下工作的:
    • 即假定数据由待优化的当前策略生成
  • 大多数对 GRPO 的改进都集中在尽管 Trainer 和 Inference Engine 之间存在差距,也要使其尽可能地保持 On-policy
    • 通常有两个工作系列来解决这个问题:
      • (1)引入额外的重要性权重 (2025)
      • (2)通过修改 Inference Engine 来缩小 Trainer 和 Inference Engine 之间的差距 (2025)
  • 作者认为两者都不是理想
    • 第一种方法(IS):向 GRPO 目标添加重要性权重会给强化学习损失函数引入额外的方差
    • 第二种方法:会使 Inference Engine 变慢,并且在异步强化学习训练中并不能完全消除 Inference Engine 和 Trainer 之间的差距(这里的差距来源于异步训练时,参数本身不是完全对齐的)
  • 本文要解决的核心问题:On-policy 算法对于强化学习后训练是必要的吗?能否开发出简单且可扩展的 Off-policy 强化学习算法?
    • 作者观点:保持 On-policy 对于强化学习后训练并非必要
    • 作者提出了提出了一种易于实现且有效的 Off-policy 后训练算法:
      • 基于最优优势的带滞后推理策略策略优化,缩写为 OAPL
      • 将 Trainer 和 Inference Engine 策略之间的不匹配视为一个 KL 正则化的强化学习问题,其中 KL 项明确地防止训练策略偏离推理策略太远
        • 利用 KL 正则化强化学习的闭式解,推导出一个平方回归目标 ,该目标在来自滞后推理策略的 Rollout 上进行训练,从而消除了对 On-policy 采样的需求
  • OAPL 在一个迭代过程中使用上述推导目标,以很大的间隔同步 Trainer 和推理策略,从而实现比其他方法显著更 Off-policy 的训练
    • 亮点:OAPL 完全接受了 Off-policy 训练,无需任何重要性加权比率
  • 注:作者的观点与经典的强化学习结果一致,即 On-policy 学习对于强化学习后训练并非必要
    • 在经典的强化学习结果中,诸如 PPO 和 REINFORCE 之类的 On-policy 策略梯度方法在传统的机器人控制和视频游戏基准测试上通常不如 DDPG 和 SAC 等 Off-policy 算法高效 (2015; 2018)
  • 实验表明,OAPL 在多个 Pass@k 指标上可以在三个数学竞赛基准测试(AIME 25,HMMT 25 Feb 和 Nov,BRUMO 25)上胜过基于 GRPO 的基线(见图 1)
    • 在 LiveCodeBench v5 上,在各种 Pass@k 指标上,作者的方法可以匹配或胜过 DeepCoder (2025a)
      • DeepCoder 是通过 GRPO 并辅以额外的启发式方法(包括 clip-high、超长过滤等)训练的,同时训练使用的生成次数大约是其三分之一
  • 作者还观察到 OAPL 不仅仅是进行基模型分布锐化
    • OAPL 不会导致熵崩溃,并且稳定地改进了 Pass@k 测试时扩展指标,其中 k 的范围从 1 到 256
  • In Summary,作者证明了保持 On-policy 并非必要,接受 Off-policy 学习可以实现对推理型 LLMs 稳定、有效且高效的训练

Background

  • 现代强化学习后训练中,通常有两种类型的策略: Trainer \(\pi\) 和 Inference Engine \(\pi_{\text{vllm} }\)
    • Trainer \(\pi\) 用于根据生成的序列计算梯度更新
    • Inference Engine \(\pi_{\text{vllm} }\) 用于快速生成
  • 即使当 \(\pi\) 和 \(\pi_{\text{vllm} }\) 共享相同的权重,对于相同的 Token 序列,它们也可能输出不同的对数概率
    • 这种来自 \(\pi\) 和 \(\pi_{\text{vllm} }\) 的对数概率的固有差异,破坏了基于策略梯度的方法的 On-policy 假设
    • Liu 等人 (2025b) 测量了 Inference Engine 和 Trainer 之间的 KL 散度,并发现该散度的突然增加导致了 GRPO 训练的不稳定性和策略崩溃
    • Inference Engine 和 Trainer 之间的差距在异步强化学习训练框架中可能会进一步扩大
      • 比如:\(\pi_{\text{vllm} }\) 可能落后 Trainer \(\pi\) 多个梯度步
  • 处理 LLM 后训练中 Off-policy Rollout 的一种常见方法(Baseline)是标准的重要性采样
    • IS 在 Token-level 应用 (2025),也可以在 Sequence-level 应用 (2025a)
    • 给定从 \(\pi_{\text{vllm} }(\cdot |x)\) 采样的任意前缀 \(x\) 和下一个动作 \(a\),重要性采样计算似然比:
      $$\frac{\pi(a|x)}{\pi_{\text{vllm} }(a|x)}$$
    • 用它对 GRPO 损失函数进行重新加权,然后在一个批次样本上取平均
    • 这些似然比旨在纠正因动作 \(a\) 由 \(\pi_{\text{vllm} }\) 而非 \(\pi\) 生成所导致的不匹配
  • 可以将 GRPO 表述为一个带有重要性权重的损失函数:
    $$\mathbb{E}_{\{y_i\}_{i = 1}^c\sim \pi_{\text{vllm} }(\cdot |x)}\left[\frac{1}{G}\sum_{y\in \mathcal{G} }\frac{1}{|y|}\sum_{t = 1}^{|y|}\frac{\pi_{\text{old} }(y_t|x,y_{< t})}{\pi_{\text{vllm} }(y_t|x,y_{< t})}\cdot \min \{r_tA_t,\text{clip}(r_t,1 - \epsilon ,1 + \epsilon)A_t\} \right]$$
    • \(\pi_{\text{old} }\) 是 Trainer 前一次迭代的版本
    • \(r_t = \frac{\pi(y_t|x,y_{< t})}{\pi_{\text{old} }(y_t|x,y_{< t})}\) 是 PPO 风格的似然比
    • \(A_t\) 是归一化的优势
  • Fu 等人 (2025) 为其异步强化学习训练框架引入了上面这个损失函数
    • 在该框架中,数据生成策略 \(\pi_{\text{vllm} }\) 可能落后于当前的训练策略 \(\pi\)
    • 额外的 Token-level 比率 \(\frac{\pi_{\text{old} }(y_t|x,y_{< t})}{\pi_{\text{vllm} }(y_t|x,y_{< t})}\) 对从 \(\pi_{\text{vllm} }\) 采样的 Token \(y_t\) 进行重新加权,就好像它们是由 \(\pi_{\text{old} }\) 生成的一样
    • 但当行为策略和目标策略差异很大时,重要性采样可能变得不可靠,这促使先前的大量工作致力于方差缩减技术 (2016; 2015; 2013)
  • 根据实验,先前的工作尝试了许多额外的启发式方法
    • 例如裁剪重要性采样比率 :明确从 GRPO 目标中删除那些重要性采样比率过大或过小的 Token,或者丢弃那些过于 Off-policy 的整个 Rollout
    • 虽然这些启发式方法专门针对 GRPO 训练并经过测试,使 GRPO 训练稳定,但它们越来越偏离经典策略梯度理论背后的原理
    • 由于这些启发式方法是专门为 GRPO 损失函数设计并在其下测试的,目前尚不清楚它们如何在非常具体的 GRPO 损失函数之外推广
      • 其实其他的任何 On-policy 方法都可以使用 IS 方法进行修正 Off-policy 问题吧!
  • 这项工作没有专注于修改 GRPO 的损失,而是走了一条不同的路线,设计了一个新的、能够自然处理 Off-policy 数据的强化学习训练目标

Method: OAPL

  • 基于最优优势的带滞后推理策略策略优化(OAPL)是一个 Principled Off-policy 目标,即使在显著的策略滞后下也能保持稳定
    • 先前的方法:需要定制 Inference Engine 或用额外比率、裁剪算子或删除陈旧 Token/序列来增强 GRPO 及其 变体
    • 本文:接受强化学习后训练的 Off-policy 性质,并设计了一个简单、完全 Off-policy 的强化学习算法

Off-policy Loss Function

  • 本文的 Off-policy 策略优化目标,其动机源于 KL 正则化的强化学习形式,考虑以下目标:
    $$\max_{\pi}\mathbb{E}_{x,y\sim \pi (\cdot |x)}r(x,y) - \beta \text{KL}(\pi ||\pi_{\text{vllm} }) \tag {1}$$
    • 该目标旨在最大化奖励 \(r\),同时最小化与推理策略 \(\pi_{\text{vllm} }\) 的 KL 散度
    • 注意:一般的目标下,这里是 \(\pi_{\text{ref}}\),比如 (A-PO,A\PO)Accelerating rl for llm reasoning with optimal advantage regression, 20250527, Harvard 中
  • 上述 KL 正则化强化学习问题的最优策略 \(\pi^{\star}\) 和最优值函数 \(V^{\star}\) 具有以下闭式表达式:
    $$\pi^{\star}(y|x)\propto \pi_{\text{vllm} }(y|x)\exp (r(x,y) / \beta),$$ $$V^{\star}(x) = \beta \ln \mathbb{E}_{y\sim \pi_{\text{vllm} }(\cdot |x)}\exp (r(x,y) / \beta).$$
    • \(\pi^{\star}\) 的详细证明可见本人之前的博客:RL——CQL 的附录部分,DPO 论文(NLP——LLM对齐微调-DPO)中也有类似需要证明的式子
    • \(V^{\star}(x)\) 的详细证明见本文附录: 最优优势 \(A^{\star}\) 的推导部分
  • \(\pi^{\star}\) 和 \(V^{\star}\) 之间的关系可表示表示如下:
    $$\beta \ln \frac{\pi^{\star}(y|x)}{\pi_{\text{vllm} }(y|x)} = \underbrace{r(x,y) - V^{\star}(x)}_{\text{optimal advantage } A^{\star}}, \quad \forall x,y.$$
  • 特别说明:定义 \(V^{\star}\) 的期望是在采样策略 \(\pi_{\text{vllm} }\) 下取的,而不是 \(\pi^{\star}\)
    • 因此,给定 \(x\) 和一组从 \(\pi_{\text{vllm} }(\cdot |x)\) 采样的 \(G\) 个 Rollouts \(\{y_1,\ldots ,y_G\}\),Brantley 等人 (2025) 提出通过以下方式估计 \(V^{\star}\):
      $$\hat{V}^{\star}(x) = \beta \ln \frac{1}{G}\sum_{i = 1}^{G}\exp (r(x,y_i) / \beta) \tag {2}$$
      • 注:这与 (A-PO,A\PO)Accelerating rl for llm reasoning with optimal advantage regression, 20250527, Harvard 中的 \(V^{\star}\) 是不同的
  • 在采样分布 \(\pi_{\text{vllm} }\) 的温和假设下,估计量 \(\hat{V}^{\star}\) 可以是准确的
    • 特别是,对于二元奖励,如果 \(\pi_{\text{vllm} }\) 有非零概率解决 \(x\),那么随着 \(G\) 的增加,\(\hat{V}^{\star}(x)\) 收敛到 \(V^{\star}(x)\) (2025; 2025)
    • 这里 \(\beta\) 的作用是平滑:
      • 当 \(\beta \rightarrow 0\) 时,我们有
        $$\hat{V}^{\star}(x) = \max_{i}r(x,y_{i})$$
      • 当 \(\beta \rightarrow \infty\) 时,\(\hat{V}^{\star}(x)\) 成为平均值
        $$\hat{V}^{\star}(x) = \sum_{i}r(x,y_{i}) / G$$
        • 这是当前推理策略 \(\pi_{\text{vllm} }\) 平均奖励的无偏估计
  • 给定 \(\hat{V}^{\star}\),可以将最优优势 \(A^{\star}(x,y)\) 估计为
    $$r(x,y) - \hat{V}^{\star}(x)$$
  • 作者采用 Brantley 等人 (2025) 的 \(A^{\star}\)-PO 目标,并定义以下策略优化目标:
    $$\min_{\pi}\sum_{x}\sum_{i = 1}^{G}\left(\beta \ln \frac{\pi(y_{i}|x)}{\pi_{\text{vllm} }(y_{i}|x)} -(r(x,y_{i}) - \hat{V}^{\star}(x))\right)^{2} \tag {3}$$
    • 上述目标对应的损失函数和梯度 在 (A-PO,A\PO)Accelerating rl for llm reasoning with optimal advantage regression, 20250527, Harvard 附录 F 中同一批作者已经给出,上述公式的目标对应的损失函数为:
      $$
      \mathcal{l}(\theta) = \sum_{x}\sum_{i = 1}^{G}\left(\beta \ln \frac{\pi_\theta(y_{i}|x)}{\pi_{\text{vllm} }(y_{i}|x)} -(r(x,y_{i}) - \hat{V}^{\star}(x))\right)^{2}
      $$
      • 论文中的梯度不太好理解,本文附录中我给出了这个损失函数梯度和方向的分析
  • 当 \(\hat{V}^{\star} = V^{\star}\) 时,无论 \(y\) 的采样分布如何(例如,它适用于从 \(\pi_{\text{vllm} }\) 抽取的 Rollouts),公式 3 都由 KL 正则化的最优策略 \(\pi^{\star}\) 最小化
  • 虽然作者的损失函数的动机来自 \(A^{\star}\)-PO,但 \(A^{\star}\)-PO 被设计为一种 On-policy 算法,即它在从 \(\pi\) 生成的 On-policy 数据集下制定上述优化
    • 作者反而依赖该目标的唯一最小化器,并直接使用来自 Inference Engine 的 Off-policy 数据和对数概率
  • 正如原始 \(A^{\star}\)-PO 论文所提出的
    • 从 Rollouts 组中估计 \(\hat{V}^{\star}\) 能够避免做额外的假设
    • 例如 \(V^{\star}\) 由一个常数逼近 (2024),不用神经网络建模 \(V^{\star}\)(这可能在计算上很昂贵)

OAPL: The Off-policy RL Algorithm

  • 作者将公式 3 转换为一个带有滞后 Inference Engine 的实用后训练流程
  • 这产生了基于最优优势的带滞后推理策略策略优化(算法 1),缩写为 OAPL
    • Step1: 同步 \(\pi\) 和 \(\pi_{\text{vllm} }\),使它们共享相同的权重
    • Step2: 开始迭代:
      • 使用 \(\pi_{\text{vllm} }\) 的 Inference Engine 开始异步生成数据,并将其添加到缓冲区 \(\mathcal{D}\) 中
      • Trainer 通过最小化公式 3 来更新策略 \(\pi\),使用从 \(\mathcal{D}\) 中采样的数据
        • 注:公式中的 \(\hat{V}^{\star}(x)\) 可通过公式 2 直接计算得到(每次采样后可直接得到,不需要建模为神经网络更新)
      • 每隔 \(L\) 次 Trainer 迭代(\(L\) 是一个超参数),算法同步 \(\pi\) 和 \(\pi_{\text{vllm} }\) 的权重
  • 在同步的间隔上,算法以 Off-policy 方式运行:
    • \(\pi_{\text{vllm} }\) 既生成数据,又在公式 3 中充当 KL 参考
    • 由于其完全的 Off-policy 性质,OAPL 可以在 \(\pi\) 和 \(\pi_{\text{vllm} }\) 的两次同步步骤之间完全异步运行
  • 每当我们将 \(\pi_{\text{vllm} }\) 与 \(\pi\) 同步时,我们会清除缓冲区 \(\mathcal{D}\)
    • 以确保 \(\mathcal{D}\) 仅包含来自单个 \(\pi_{\text{vllm} }\) 的数据
    • 这是为了确保估计量 \(\bar{V}^{\star}\) 进而优势始终仅使用来自一个采样分布 \(\pi_{\text{vllm} }\) 的数据进行计算
    • 由于 OAPL 不依赖于重要性比率或裁剪操作,因此得到的更新简化为一个简单的最小二乘回归损失 ,即使在显著的策略滞后下也能保持稳定
Comparison to GRPO
  • GRPO 使用裁剪算子作用于 \(\frac{\pi(y|x)}{\pi_{\text{old} }(y|x)}\) 以防止 \(\pi\) 偏离 \(\pi_{\text{old} }\) 太远
    • 只是遵循了 PPO 的原始设计
    • 其中 \(\pi_{\text{old} }\) 是前一次迭代的 Trainer
  • 这个动机是保守策略迭代 (2002),但裁剪并不总是能有效地防止 \(\pi\) 偏离 \(\pi_{\text{old} }\)
    • 当从 \(\pi = \pi_{\text{old} }\) 开始时,使用 GRPO 损失的第一次梯度更新的计算不会引起任何裁剪
      • 如果第一个梯度很大,一步梯度下降就可能已经使 \(\pi\) 远离 \(\pi_{\text{old} }\),并且裁剪算子无法将 \(\pi\) 拉回到 \(\pi_{\text{old} }\)
      • 这是 PPO/GRPO 损失函数的一个已知问题 (2020)
      • 理解:其实每一步都会发生类似问题,不在于第一步,也不是因为第一步无裁剪,理论上,每一步都会有概率超过裁剪
  • OAPL 将 KL 正则化纳入优化目标,直接针对 \(\pi_{\text{vllm} }\),完全摒弃了 \(\pi_{\text{old} }\) 的概念,并直接使用来自采样分布 \(\pi_{\text{vllm} }\) 的对数概率
    • 在每次迭代中,OAPL 直接鼓励 Trainer \(\pi\) 在优化奖励的同时保持接近 \(\pi_{\text{vllm} }\)
    • 这种设计,加上 \(\pi_{\text{vllm} }\) 不频繁的更新,可以在训练期间防止策略的熵崩溃,从而带来比 GRPO 更好的测试时扩展能力
Comparison to \(A^{\star}\text{PO}\)
  • \(A^{\star}\text{PO}\) 最初被设计为一种 On-policy 强化学习算法,它使用损失函数中的 \(\ln \frac{\pi(y|x)}{\pi_{\text{ref} }(y|x)}\) 来估计在固定参考策略 \(\pi_{\text{ref} }\) 下定义的 \(V^{\star}\)
    • \(A^{\star}\text{PO}\) 在训练期间从不更新 \(\pi_{\text{ref} }\)
  • OAPL 以 Off-policy 方式运行,定期更新 Inference Engine \(\pi_{\text{vllm} }\),并且始终直接在损失函数中使用来自 \(\pi_{\text{vllm} }\) 的对数概率

Related Work

Off-policy RL Post-Training Approaches

  • 处理强化学习后训练中 Off-policy 采样的方法大致可以分为两类:一类避免重要性采样,另一类应用重要性采样或其相关变体
  • 避免重要性采样的方法示例包括:
    • Melo 等人 (2025) 估计 Fisher 信息用于 Token 掩码
    • Arnal 等人 (2025) 为其目标函数添加偏差以获得性能改进保证
  • OAPL 类似地避免了重要性采样带来的额外方差,但在保持无偏的同时不需要额外的估计过程
  • 这一类中与作者工作最相关的是使用平方回归损失进行 On-policy 或 Off-policy 训练的方法,例如 REBEL (2024a)、REFUEL (2024b)、AGRO (2025) 或 Kimi K2 (2025a)
    • 这些方法不像 OAPL 那样估计 \(V^{\star}\),而是用类似于 RLOO 估计器 (2019) 的组相对基线进行方差缩减
  • 依赖重要性采样,或仅依赖重要性比率 \(\frac{\pi(y|x)}{\pi_{\text{vllm} }(y|x)}\) 的方法,在具体如何应用它方面有所不同
    • 例如,DeepSeek-v3.2 (2025a) 删除那些在 \(\pi\) 下似然较低的 Rollouts
    • Zhao 等人 (2025) 和 Zheng 等人 (2025b) 删除那些 Token-level 比率过大或过小的 Token
    • Roux 等人 (2025) 和 Su 等人 (2026) 构建目标函数来限制具有大重要性比率的 Token 的梯度
  • 通过避免重要性采样,OAPL 避免了删除可能对学习有用的样本或 Token,并且不会因向比率或梯度添加裁剪而引入偏差或额外的调优成本

Off-Policy RL in Asynchronous Settings

  • 关于异步和大规模强化学习训练的工作也处理了 Off-policy 采样
  • 例如,最近关于扩展基于人类反馈的强化学习系统的工作 (2025; 2025) 为此使用了截断的重要性采样
  • 在语言模型领域之外,扩展策略梯度算法和利用 Off-policy 数据的方法也使用某种形式的(通常是截断的)重要性采样 (2018; 2016; 2017; 2015),或者约束其数据生成以避免收集过于 Off-policy 的数据 (2019)
  • 其他方法通过学习 Q 函数完全避免重要性采样 (2018; 2015, 2016)
  • OAPL 同样不需要重要性采样,并且实际上可以理解为一种值学习方法
    • OAPL 使用 \(\ln \frac{\pi}{\pi_{\text{vllm} } }\) 作为函数逼近器来直接估计最优优势 \(A^{\star}\)

Experimental Setup

  • 在竞赛数学问题求解和代码生成上评估 OAPL,重点关注异步训练期间的稳定性以及通过 Pass@k 衡量的性能
  • 对于竞赛数学和代码生成两种设置,与 Brantley 等人 (2025) 的做法一致,作者在公式 2 和公式 3 中分别使用两个不同的 beta(\(\beta_{1}\) 和 \(\beta_{2}\)),而不是单一的 \(\beta\)
    • 这为选择超参数提供了额外的自由度
  • 关于实验的训练设置和超参数的更多细节可以在附录 A 中找到

Math Experimental Setup

  • 数学实验使用 Deepscaler (2025b) 作为作者的训练数据集,并使用 AIME 25、HMMT 25(02 月和 11 月)和 BRUMO 25 作为作者的评估集
  • 将 OAPL 与 GRPO 进行比较,后者增加了考虑 Inference Engine 和 Trainer 之间对数概率差异的重要性采样 (2025)
  • 对于这两种方法,作者都实现了异步优化,即着 Inference Engine 可以在作者优化 Trainer 的同时生成数据
  • 对于 OAPL,作者设置 \(L = 50\),即作者每 50 次迭代同步一次 Inference Engine 和 Trainer
  • 对于 GRPO,作者使用错位一步的异步训练
    • Trainer 使用的训练数据可能来自比 Trainer 自身最多老 1 次迭代的推理策略
  • 使用 Qwen3-4B-Thinking-2507 作为作者的基础模型,两种方法的最大生成长度均为 16384 个 token

Code Generation Experimental Setup

  • 代码生成实验使用一个高度 off-policy 的两阶段训练过程来复现 DeepCoder (2025a) 的性能
    • DeepCoder 是一个公开可用的、通过 GRPO 并辅以几个额外启发式方法训练的代码模型
  • 从基础模型 DeepSeek-R1-Distill-Qwen-14B 开始,为 DeepCoder 训练数据集中的每个 Prompt 生成一个包含 8 个 Response 的离线数据集
  • 为了将训练集中在可解的问题上,额外过滤掉了模型没有生成任何正确 Response 的所有 Prompt
  • 使用 OAPL 在这个数据集上训练基础模型 1 个 epoch,期间不同步 Trainer 和 Inference Engine
    • 使用得到的模型,从一个随机抽取的 4000 个 Prompt 的子集(由于资源限制)生成一个新的离线数据集,并在这个数据集上继续训练额外的 4 个 epoch
    • 这相当于运行 OAPL,其中 \(L\) 设置为 1 个 epoch(大约 400 次梯度更新),总迭代次数 \(T = 2\)
    • 两轮训练的最大生成长度均为 32K 个 token
  • 对于评估,遵循 DeepCoder 的 LiveCodeBench (2024) 设置,使用相同的 279 个 LiveCodeBench 问题子集,并以最大生成长度 64K 进行评估
    • 本文评估了 OAPL 第二轮训练中每个 epoch 的所有四个检查点,并报告表现最佳的检查点的结果

Experimental Results

  • 作者从三个方面评估 OAPL:在标准推理基准上的最终准确率、异步 Rollout 下的训练动态和稳定性,以及通过 Pass@k 衡量的测试时扩展性
  • 作者首先研究竞赛数学,在那里作者可以跟踪学习曲线和训练过程中的熵,然后转向代码生成,在那里作者评估极端策略滞后下的鲁棒性,并与经过 GRPO 训练的 DeepCoder 模型进行比较

Results on Competition Math

Performance on benchmarks
  • 图 1 表明,在三个基准测试的所有 Pass@k(针对不同的 \(k\))上,OAPL 都优于 GRPO 基线
  • 图 2 展示了在三个基准测试上的平均训练过程性能
  • 总体来说 OAPL 比 GRPO 学习得更稳定且性能更优
    • 还观察到,对于 GRPO 和 OAPL,在 Pass@1 奖励(即仅结果奖励)上进行训练可以提高 \(k > 1\) 时的 Pass@k。包括作者将要展示的代码生成实验,作者通常没有观察到 RL 不能提高 \(k > 1\) 时 Pass@k 的现象
Entropy behavior
  • 图 3(左)显示了训练过程中序列熵的变化
  • 观察到 OAPL 的熵没有崩溃,而 GRPO 的熵崩溃了
  • 在使用 OAPL 训练时观察到的熵增加,有助于 OAPL 在图 2 中的 Pass@5 和 Pass@10 指标上优于 GRPO
  • 作者相信这种行为是由于 Inference Engine 和 Trainer 之间的不同步同步以及 Trainer 对 Inference Engine 的显式 KL 正则化所致
  • 注意,在作者的实验中,GRPO 和 OAPL 都不包含对 \(\pi_{\text{ref} }\) 的固定 KL 正则化
    • 这是因为 OAPL 和 GRPO 基线的目标都只是找到优化奖励的策略
Scaling k in Pass@k
  • OAPL 中更高的熵是否会导致 Pass@k 下更好的扩展行为?
    • 作者为每种方法选择最佳检查点(基于三个基准的平均 Pass@1),并随着 \(k\) 的增加评估 Pass@k
  • 图 4 表明
    • \(OAPL\) 平均而言(左图)比 GRPO 扩展得更好,并且在除 BRUMO 之外的每个基准上都是如此,在 BRUMO 上两种方法在 \(k = 64\) 时都已经达到了 \(90\) 以上的准确率
    • 特别是,对于 HMMT Nov 2025,OAPL 和 GRPO 之间存在很大差距
    • 有趣的是,RL 训练(OAPL 和 GRPO)在广泛的 \(k\) 范围内提高了 Pass@k
      • 与基础模型相比(例如,在 HMMT 25 Nov 上,OAPL 和基础模型之间的差距实际上随着 \(k\) 的增加而增加)
      • 这与许多先前的工作(例如 (2025))形成鲜明对比,后者认为 RL 只会锐化基础模型分布,从它不能提高大 \(k\) 时的 Pass@k 这个意义上说
Training stability with large policy lags
  • 当 Inference Engine 策略显著落后于 Trainer 时,OAPL 还能稳定学习吗?
    • 作者进一步评估了 \(L = 100\) 的 OAPL,即作者每 100 次迭代才同步 \(\pi_{\text{vlmm} }\) 和 \(\pi\)
  • 如图 3(右)所示,OAPL 继续稳定学习,这证明了 OAPL 对训练数据中不同程度的 off-policyness 的鲁棒性

Results on Code Generation

  • 使用第 5.2 节中描述的两阶段离线 Rollout 程序评估 OAPL 在极端 off-policyness 下是否仍然有效,并在 LiveCodeBench 上与 DeepCoder (2025a) 进行比较
Pass@k performance
  • 图 5(左)显示了 DeepCoder、作者的 OAPL 训练复现模型以及两者使用的基础模型 (Deepseek-R1-Distill-Qwen-14B) 在 LiveCodeBench 上的 Pass@k 性能
  • 对于所有模型,Pass@k 随着 \(k\) 的增加而增加
  • 在整个 \(k\) 范围内,OAPL 训练的模型与 DeepCoder 性能相当或略优
  • 与基础模型的扩展曲线相比,再次看到 RL 训练(OAPL 和用于 DeepCoder 的 GRPO 变体)提高了大 \(k\) 下的 pass@k
Sample efficiency
  • 使用 OAPL 训练也比原始的 DeepCoder 训练流程具有显著的样本效率
  • 图 5(右)显示了 OAPL 和 DeepCoder 的 Pass@1 性能随总训练样本数的变化
  • DeepCoder 在训练中使用了大约 65 万个样本
    • 相比之下,使用 OAPL 训练只需要 \(\sim 20\) 万个样本
  • 这表示所需的样本数量减少了大约 3 倍,同时达到相同或更好的性能
  • 这种比较确实略微夸大了 DeepCoder 的实际总计算成本,因为他们训练的第一部分(160 步)限制在 16K 长度的生成,之后才切换到 32K
  • 但即使作者将 16K 生成计为“半个”样本以进行更公平的核算,总数也大约是 58 万个样本,OAPL 仍然提供了显著的样本效率提升

附录 A:Experimental Details

A.1 Math Training Hyperparameters

  • 表 1 显示了两种方法使用的优化器超参数
    • 作者没有针对数学任务调整优化器
  • 表 2 显示了特定于方法的超参数
  • 表 3 显示了两种方法共享的超参数
  • 对于 OAPL,作者对 \(\beta_{1} = \{1,5\}\) 和 \(\beta_{2} = \{1e - 2,1e - 3\}\) 进行了超参数搜索
    • 可以观察到 \(\{\beta_{1} = 1,\beta_{2} = 1e - 3\}\) 给出了最佳的整体性能(平均而言),并报告使用这些值时的性能

Code Generation Training Hyperparameters

  • 表 4、5 和 6 分别显示了作者的代码生成实验的优化器、OAPL 特定和训练超参数
    • 由于运行的计算成本,作者没有进行超参数搜索来选择超参数,而是根据在其他实验中发现有效的默认值,为 OAPL 选择了 \(\beta_{1}, \beta_{2}\)

附录:公式 1 到 \(V^{\star}\) 的证明

证明目标

  • 在 KL 正则化 RL 的框架下,下面目标函数
    $$
    \max_{\pi} \mathbb{E}_{x, y \sim \pi(\cdot|x)} \left[ r(x, y) \right] - \beta , \text{KL}(\pi | \pi_{\mathrm{vllm} })
    $$
  • 的最优值函数 \(V^{\star}(x)\) 具有以下封闭形式:
    $$
    V^{\star}(x) = \beta \ln \mathbb{E}_{y \sim \pi_{\mathrm{vllm} }(\cdot|x)} \exp\left( \frac{r(x, y)}{\beta} \right)
    $$

证明

先求解最优策略的表达式
  • 本节证明亦可参考 RL——CQL 的附录部分
  • 给定 \(x\),作者考虑以下优化问题:
    $$
    \max_{\pi(\cdot|x)} \mathbb{E}_{y \sim \pi(\cdot|x)} \left[ r(x, y) \right] - \beta , \text{KL}(\pi(\cdot|x) | \pi_{\mathrm{vllm} }(\cdot|x))
    $$
  • KL 散度的定义:
    $$
    \text{KL}(\pi | \pi_{\mathrm{vllm} }) = \mathbb{E}_{y \sim \pi} \left[ \ln \frac{\pi(y|x)}{\pi_{\mathrm{vllm} }(y|x)} \right]
    $$
  • 因此目标函数可写为:
    $$
    \mathcal{L}(\pi) = \mathbb{E}_{y \sim \pi} \left[ r(x, y) - \beta \ln \frac{\pi(y|x)}{\pi_{\mathrm{vllm} }(y|x)} \right]
    $$
  • 可以用拉格朗日乘子法求解带归一化约束 \(\sum_y \pi(y|x) = 1\) 的优化问题,写出拉格朗日函数:
    $$
    \mathcal{L} = \sum_y \pi(y|x) \left[ r(x, y) - \beta \ln \frac{\pi(y|x)}{\pi_{\mathrm{vllm} }(y|x)} \right] + \lambda \left( 1 - \sum_y \pi(y|x) \right)
    $$
  • 对 \(\pi(y|x)\) 求导并令其为零(注意 \(\ln \pi\) 的导数):
    $$
    \frac{\partial}{\partial \pi(y|x)} \left[ \pi(y|x) \left( r(x, y) - \beta \ln \pi(y|x) + \beta \ln \pi_{\mathrm{vllm} }(y|x) \right) \right] - \lambda = 0
    $$
  • 展开得:
    $$
    r(x, y) - \beta \ln \pi(y|x) - \beta + \beta \ln \pi_{\mathrm{vllm} }(y|x) - \lambda = 0
    $$
  • 整理有:
    $$
    - \beta \ln \pi(y|x) + \beta \ln \pi_{\mathrm{vllm} }(y|x) + r(x, y) - \beta - \lambda = 0
    $$
  • 即:
    $$
    \ln \frac{\pi(y|x)}{\pi_{\mathrm{vllm} }(y|x)} = \frac{r(x, y) - \beta - \lambda}{\beta}
    $$
  • 令 \(Z = e^{(\beta + \lambda)/\beta}\),则:
    $$
    \pi(y|x) = \frac{1}{Z} \pi_{\mathrm{vllm} }(y|x) \exp\left( \frac{r(x, y)}{\beta} \right)
    $$
  • 由归一化条件 \(\sum_y \pi(y|x) = 1\),得:
    $$
    Z = \sum_y \pi_{\mathrm{vllm} }(y|x) \exp\left( \frac{r(x, y)}{\beta} \right)
    $$
  • 因此最优策略为:
    $$
    \pi^{\star}(y|x) = \frac{\pi_{\mathrm{vllm} }(y|x) \exp\left( \frac{r(x, y)}{\beta} \right)}{\sum_{y’} \pi_{\mathrm{vllm} }(y’|x) \exp\left( \frac{r(x, y’)}{\beta} \right)}
    $$
最优值函数 \(V^{\star}(x)\)
  • 将 \(\pi^{\star}\) 代入原目标函数:
    $$
    V^{\star}(x) = \mathbb{E}_{y \sim \pi^{\star} } \left[ r(x, y) - \beta \ln \frac{\pi^{\star}(y|x)}{\pi_{\mathrm{vllm} }(y|x)} \right]
    $$
  • 由 \(\pi^{\star}\) 的表达式:
    $$
    \ln \frac{\pi^{\star}(y|x)}{\pi_{\mathrm{vllm} }(y|x)} = \frac{r(x, y)}{\beta} - \ln \sum_{y’} \pi_{\mathrm{vllm} }(y’|x) \exp\left( \frac{r(x, y’)}{\beta} \right)
    $$
  • 代入得:
    $$
    \begin{align}
    V^{\star}(x) &= \mathbb{E}_{y \sim \pi^{\star} } \left[ r(x, y) - \beta \left( \frac{r(x, y)}{\beta} - \ln \sum_{y’} \pi_{\mathrm{vllm} }(y’|x) e^{r(x, y’)/\beta} \right) \right] \\
    &= \mathbb{E}_{y \sim \pi^{\star} } \left[ r(x, y) - r(x, y) + \beta \ln \sum_{y’} \pi_{\mathrm{vllm} }(y’|x) e^{r(x, y’)/\beta} \right] \\
    &= \beta \ln \sum_{y} \pi_{\mathrm{vllm} }(y|x) \exp\left( \frac{r(x, y)}{\beta} \right)
    \end{align}
    $$
  • 即,最终得到:
    $$ V^{\star}(x) = \beta \ln \sum_{y} \pi_{\mathrm{vllm} }(y|x) \exp\left( \frac{r(x, y)}{\beta} \right) $$
  • 证毕

附录:最优优势 \(A^{\star}\) 的推导

  • 副标题:公式 \(\pi^{\star}\) 和 \(V^{\star}\) 的关系推导

证明目标

  • 本节的证明目标是:
    $$\beta \ln \frac{\pi^{\star}(y|x)}{\pi_{\text{vllm} }(y|x)} = \underbrace{r(x,y) - V^{\star}(x)}_{\text{optimal advantage } A^{\star}}, \quad \forall x,y.$$

证明过程

  • 由之前的推导已知:
    $$
    \begin{align}
    \pi^{\star}(y|x) &= \frac{\pi_{\mathrm{vllm} }(y|x) \exp\left( \frac{r(x, y)}{\beta} \right)}{\sum_{y’} \pi_{\mathrm{vllm} }(y’|x) \exp\left( \frac{r(x, y’)}{\beta} \right)} \\
    V^{\star}(x) &= \beta \ln \sum_{y} \pi_{\mathrm{vllm} }(y|x) \exp\left( \frac{r(x, y)}{\beta} \right)
    \end{align}
    $$
  • 对 \(\pi^{\star}(y|x)\) 取对数:
    $$
    \ln \pi^{\star}(y|x) = \ln \pi_{\mathrm{vllm} }(y|x) + \frac{r(x, y)}{\beta} - \ln \sum_{y’} \pi_{\mathrm{vllm} }(y’|x) \exp\left( \frac{r(x, y’)}{\beta} \right).
    $$
  • 整理对齐待证明式子:
    $$
    \ln \pi^{\star}(y|x) - \ln \pi_{\mathrm{vllm} }(y|x) = \frac{r(x, y)}{\beta} - \ln \sum_{y’} \pi_{\mathrm{vllm} }(y’|x) \exp\left( \frac{r(x, y’)}{\beta} \right).
    $$
  • 两边乘以 \(\beta\):
    $$
    \beta \ln \frac{\pi^{\star}(y|x)}{\pi_{\mathrm{vllm} }(y|x)} = r(x, y) - \beta \ln \sum_{y’} \pi_{\mathrm{vllm} }(y’|x) \exp\left( \frac{r(x, y’)}{\beta} \right).
    $$
  • 由 \(V^{\star}(x)\) 的定义:
    $$
    V^{\star}(x) = \beta \ln \sum_{y} \pi_{\mathrm{vllm} }(y|x) \exp\left( \frac{r(x, y)}{\beta} \right),
    $$
  • 代入得:
    $$
    \beta \ln \frac{\pi^{\star}(y|x)}{\pi_{\mathrm{vllm} }(y|x)} = r(x, y) - V^{\star}(x).
    $$
  • 这是本文最优优势 \(A^{\star}(x, y)\) 的定义,证毕

附录:OAPL 策略更新损失函数的梯度推导及分析

  • 回顾论文中的公式 (3) 如下:
    $$
    \min_{\pi} \sum_{x} \sum_{i=1}^{G} \left( \beta \ln \frac{\pi(y_i | x)}{\pi_{\mathrm{vllm} }(y_i | x)} - \big( r(x, y_i) - \hat{V}^{*}(x) \big) \right)^2
    $$
    • \(\pi\) 是当前要优化的策略(trainer policy)
    • \(\pi_{\mathrm{vllm} }\) 是固定的推理策略(inference engine policy)
    • \(\beta > 0\) 是正则化系数
    • \(r(x, y_i)\) 是奖励
    • \(\hat{V}^{*}(x)\) 是通过组内样本估计的最优值函数
    • \(A^{*}(x, y_i) = r(x, y_i) - \hat{V}^{*}(x)\) 是估计的最优优势函数

OAPL 目标对 \(\pi\) 的梯度推导

  • 首先,上述目标对应的损失函数为:
    $$
    L = \sum_{x} \sum_{i=1}^{G} \left( \beta \ln \frac{\pi(y_i | x)}{\pi_{\mathrm{vllm} }(y_i | x)} - A^{*}(x, y_i) \right)^2
    $$
  • 为简化分析,令:
    $$
    u_i = \beta \ln \frac{\pi(y_i | x)}{\pi_{\mathrm{vllm} }(y_i | x)} - A^{*}(x, y_i)
    $$
  • 于是有:
    $$
    \frac{\partial L}{\partial \ln \pi(y_i | x)} = 2 u_i \cdot \beta
    $$
    • 注:对 \(\pi(y | x)\) 求梯度,本来考虑的是对某个具体的 token 序列 \(y\) 对应的 logits 的梯度,但为了清晰,我们直接先对 \(\ln \pi(y|x)\) 求导(这样已经足够分析梯度的含义了)
  • 因此有:
    $$
    \frac{\partial L}{\partial \pi(y_i | x)} = \frac{\partial L}{\partial \ln \pi(y_i | x)} \cdot \frac{\partial \ln \pi(y_i | x)}{\partial \pi(y_i | x)} = 2 \beta u_i \cdot \frac{1}{\pi(y_i | x)}
    $$
  • 故,原始损失函数的梯度为:
    $$
    \nabla_{\pi(y_i | x)} L = 2\beta \left( \beta \ln \frac{\pi(y_i | x)}{\pi_{\mathrm{vllm} }(y_i | x)} - A^{*}(x, y_i) \right) \cdot \frac{1}{\pi(y_i | x)}
    $$

OAPL 梯度方向分析

  • 这里本文关注的是 梯度下降 更新规则:
    $$
    \pi_{\text{new} }(y|x) = \pi_{\text{old} }(y|x) - \eta \nabla_{\pi} L
    $$
  • 当 \(u_i > 0\) 时
    $$
    \beta \ln \frac{\pi(y_i | x)}{\pi_{\mathrm{vllm} }(y_i | x)} > A^{*}(x, y_i)
    $$
    • 左边是当前的策略 \(\pi\) 相对于 \(\pi_{\mathrm{vllm} }\) 的对数比值,乘以 \(\beta\)
    • 右边是估计的最优优势函数
    • 如果 \(u_i > 0\),说明 当前策略 \(\pi\) 对 \(y_i\) 的偏好程度(相对于 \(\pi_{\mathrm{vllm} }\))已经超过了最优优势所指示的合理程度
    • 此时梯度为正,更新时会 降低 \(\pi(y_i|x)\) 的概率
  • 当 \(u_i < 0\) 时
    $$
    \beta \ln \frac{\pi(y_i | x)}{\pi_{\mathrm{vllm} }(y_i | x)} < A^{*}(x, y_i)
    $$
    • 说明 当前策略 \(\pi\) 对 \(y_i\) 的偏好程度低于最优优势所指示的合理程度
    • 此时梯度为负,更新时会 增加 \(\pi(y_i|x)\) 的概率
  • 当 \(u_i = 0\) 时
    $$
    \beta \ln \frac{\pi(y_i | x)}{\pi_{\mathrm{vllm} }(y_i | x)} = A^{*}(x, y_i)
    $$
    • 此时梯度为零,\(\pi(y_i|x)\) 已经达到最优

整体理解

  • OAPL 梯度更新方向实际上是在做 一种隐式的策略调整 :
    • 目标是最小化 \(\beta \ln(\pi/\pi_{\mathrm{vllm} })\) 与 \(A^{*}\) 之间的平方误差
    • 换句话说,它希望 当前策略 \(\pi\) 对某个序列的偏好程度(相对于 \(\pi_{\mathrm{vllm} }\))与最优优势函数的值匹配
    • 如果 \(\pi\) 对某个高优势序列的偏好不足(\(u_i < 0\)),就增加它的概率;
    • 如果 \(\pi\) 对某个低优势序列的偏好过高(\(u_i > 0\)),就降低它的概率;
    • 同时,这种调整受 \(\beta\) 控制,\(\beta\) 越大,越强调保持与 \(\pi_{\mathrm{vllm} }\) 接近

NLP——LLM对齐微调-OPSD

注:本文包含 AI 辅助创作

  • 参考链接:
    • 原始论文:(OPSD)Self-Distilled Reasoner: On-policy Self-Distillation for Large Language Models, 20260126 - 20260305, UCLA & Meta

Paper Summary

  • 整体总结:
    • 本文提出了新方法 OPSD(On-Policy Self-Distillation)
      • 无需外部 Teacher 模型 ,也无需奖励建模 ,仅利用模型自身的生成和评估能力进行自我提升
      • 显著提升样本效率 :比 GRPO 节省 8–12 倍生成 token(推测是奖励更密集导致)
    • 一些认知:
      • 成功的自蒸馏需要足够大的语言模型
      • 在 On-policy 采样阶段生成更多 Token 以及使用全词表 Logit 蒸馏能带来更好的学习效果
  • 问题提出:
    • 现有 RLVR 方法(如 GRPO)存在一些问题:
      • 样本效率低(每组需生成多个回复)
      • 奖励稀疏(仅 Sequence-level 反馈)
      • 梯度消失(当所有样本都对或错时)
      • 注:这里将 GRPO/PPO 等与 RLVR 强绑定描述非常奇怪,RLVR 更像是描述一类具有 Variable Reward 的 RL 信号建模方法,并不太适合描述为一个具体的 RL 训练方法
        • 本文中存在大量将 RLVR 和 GRPO 的方法等价来描述的错误措辞,需要小心辨别
    • 传统知识蒸馏:通过压缩 Teacher LLM 的知识来训练较小的 LLM
      • 依赖外部 Teacher 模型,存在分布偏移问题
    • On-policy 蒸馏:通过让 Student 模型采样自己的轨迹,同时 Teacher LLM 提供密集的 Token-level 监督,解决 Off-policy 蒸馏方法中训练和推理之间的分布不匹配问题
      • On-policy 蒸馏通常需要一个单独的、通常更大的 Teacher LLM,并且没有明确 利用推理数据集中的 ground-truth 的解决方案
  • Insight:一个足够强大的推理 LLM(Student)在看到正确答案后,可以理解并修正自己的错误
    • 可让 LLM 利用外部信息教导较弱的自身(即无法外部信息的版本)
  • On-policy Self-Distillation (OPSD) 核心思路:
    • 让同一个模型同时扮演 Teacher 和 Student ,通过不同的上下文条件生成不同的分布,并在 Student 自己的生成轨迹上进行逐 token 的分布匹配
    • 给定一个数据集 \(\mathcal{S} = \{(x_i, y_i^*)\}\),其中 \(x\) 是问题,\(y^*\) 是参考答案(包括推理过程)
      • Student 策略 :\(p_S(\cdot | x)\),仅基于问题生成答案
      • Teacher 策略 :\(p_T(\cdot | x, y^*)\),基于问题和参考答案生成答案
      • 两者共享模型参数 \(\theta\),仅输入不同
    • 基本思路:从 Student 策略采样, Student 生成一个回答,然后逐 token 分布匹配
  • OPSD 算法流程总结
    • Step 1:初始化模型参数 \(\theta\)
    • Step 2:对每个样本 \((x, y^*)\):
      • Student 生成回答 \(\hat{y} \sim p_S(\cdot | x)\)
      • 对每个token位置 \(n\):
        • 计算 Teacher 分布 \(p_T(\cdot | x, y^*, \hat{y}_{<n})\)
        • 计算 Student 分布 \(p_S(\cdot | x, \hat{y}_{<n})\)
        • 计算分布差异 \(D\)
      • 平均所有 token 的差异
    • Step 3:反向传播更新 Student 策略( Teacher 策略不更新,梯度不流入 Teacher )
      $$
      \mathcal{L}_{\mathrm{OPSD} }(\theta) = \mathbb{E}_{(x,y^*)\sim \mathcal{S} } \mathbb{E}_{\hat{y} \sim p_S(\cdot | x)} \left[ \frac{1}{|\hat{y}|} \sum_{n=1}^{|\hat{y}|} D\big(p_T | p_S\big) \right]
      $$
    • Step 4:重复直到收敛
  • SDPO vs OPSD(本文) 方法:
    • 除了 OPSD 强调信号来自已有数据集 \(\mathcal{D}\) 的参考答案外,OPSD 几乎和 SDPO 思路一致,都是 On-policy 蒸馏的
    • SDPO 强调外部评估环境信号
      • 实际上,在 SDPO 原始论文的表 2 中可以看到:如果存在正确 Rollout 的话,Teacher 的 Prompt 中可能会包含之前生成的正确 Rollout 作为 Hint
    • OPSD 强调参考答案 \(y^*\),类似 SFT 的样本(注意:OPSD 要求包含的参考答案 \(y^*\) 是原始数据集中必须存在的,不是 Student 也不是 Teacher 生成的)
      • 两者算法上几乎没有差异(两篇文章几乎同时发出 20260126 vs 20260128,算是并发的工作,OPSD 引用了 SDPO )
      • 总结来说:两者核心区别在于 hint 信号不同:
        • OPSD 更强调仅使用自身(能生成至少一次正确答案的自身)模型,数据集必须包含参考答案 \(y^*\)(类似 SFT 的样本)
        • SDPO 则强调外部评估信号的引入(数据集中只需要 Query,不需要参考答案 \(y^*\),但需要外部评估的反馈信号)

Introduction and Discussion

  • 已有各种方法的缺点:
    • RLVR(如 GRPO/PPO 等): 存在效率低下的问题,包括:
      • (1) 为每个 Prompt 采样一组 Response 在计算上代价高昂,并且可能在估计真实价值函数时引入高方差
        • 当所有样本都是正确或错误时,梯度信号会消失
      • (2) 奖励信号是稀疏的,并且统一应用于生成输出的所有 token,忽略了细粒度的 Token-level 反馈
    • 监督微调:
      • 存在曝光偏差 (训练的前缀往往是当前策略不会生成的)
      • 泛化能力较弱 (跟曝光偏差也有关系,数据本身受限于固定的数据)
    • 传统的知识蒸馏: 提供了来自 Teacher 模型的密集 Token-level 监督
      • 但依赖于 Off-policy 数据 (2015)
    • On-policy 蒸馏: 让 Student 模型采样自己的轨迹,Teacher 策略提供密集的 Token-level 监督
      • 通过结合 On-policy 训练的现实分布特性和密集反馈,展示了卓越的样本效率 (2024; 2025)
  • On-policy 蒸馏很好,但需要有一个一个独立与于 Student 的,比 Student 更好的 Teacher 模型来监督 Student
    • 理解:On-policy 蒸馏对 Teacher 模型的要求很高,必须要求 Teacher 模型比 On-policy 好许多才行
  • 研究问题提出:一个模型能否通过自蒸馏有效地充当自己的 Teacher ?
    • 受到人类学习的启发:在错误地解决一个问题后,Student 可以检查正确的解决方案,解释其步骤,并找出自己推理失败的地方
    • 先前研究表明,对于 LLM 来说,评估通常比生成更容易 (2024; 1996)
    • 本文作者假设,解释(对一个给定正确答案进行说明)同样比生成更容易
      • 吐槽:这么随意的吗?
    • 本文将 Teacher 和 Student 策略从一个单一的 LLM 中实例化
      • Teacher 策略被提供了 Privileged 信息 \(y^*\)
        • 例如 ground-truth 答案或参考思维链
        • Teacher 策略 \(p_T(\cdot |x,y^*)\) 同时基于问题和 Privileged 答案进行条件设定
      • Student 策略仅基于问题 \(x\) 进行条件设定
        • Student 策略 \(p_S(\cdot |x)\) 仅观察问题
    • 通过仅从 Student 策略采样轨迹 \(\hat{y}\) 来保留 On-policy 训练范式
      • 然后 Student 策略从 Privileged Teacher 策略那里接收密集的 Token-level 监督
  • 本文提出 On-policy Self-Distillation (OPSD) 框架
    • 其中单个模型同时扮演 Teacher 和 Student 的角色
    • Student 采样其自己的轨迹 \(\hat{y} \sim p_S(\cdot |x)\)
    • 计算 Student 和 Teacher 分布之间的每个 token 的散度,并将其最小化于 Student 自己的 Rollout 之上
    • 这个公式:
      • (i) 使用了 On-policy 监督( Student 自己的轨迹)
      • (ii) 提供了密集的每个 token 反馈
      • (iii) 利用了 ground-truth 解决方案 \(y^*\)
      • (iv) 不需要单独的 Teacher 模型
    • 学习过程由损失函数描述
      $$\mathcal{L}_{\text{OPSD} }(\theta) = \mathbb{E}_{(x,y^*)\sim \mathcal{S} }\mathbb{E}_{\hat{y}\sim p_S(\cdot |x)}\sum_{n = 1}^{|\hat{y}|}\ D\Big(p_T(\cdot |x,y^*,\hat{y}_{< n})\Big|\Big| p_S(\cdot |x,\hat{y}_{< n})\Big) \tag {1}$$

Background

Knowledge Distillation for Autoregressive Large Language Models

  • 知识蒸馏通过训练 Student 模型模仿 Teacher 模型的行为,将知识从较大的 Teacher 模型转移到较小的 Student 模型 (2015;2016;2019)
    • Teacher 模型在类别上的软概率分布包含了比硬标签更丰富的信息,因为 软概率分布 揭示了 Teacher 模型学习到的类别之间的相似性
    • 对于自回归语言模型,给定一个数据集
      $$ \mathcal{S} = \{(x,y^*)\}$$
      • \(x\) 表示输入
      • \(y^*\) 是对应的参考输出
      • 注意:这里 \( \mathcal{S}\) 跟后续的脚标 \(S\) 容易引起混淆,注意数据集是花体
    • Teacher \(p_T\) 和 Student \(p_S\) 都定义了词表 \(\mathcal{V}\) 上的 Token-level 分布
  • 传统的监督蒸馏最小化 Teacher 和 Student 分布之间的散度 \(D\),并在固定数据集上取平均:
    $$\mathcal{L}_{\text{Supervised Distillation} }(\theta) = \mathbb{E}_{(x,y)\sim \mathcal{S} }[D(p_T| p_S)(y|x)] \tag {2}$$
    • 其中 \(D(p_T| p_S)(y|x)\) 衡量每个 token 的差异:
      $$ D(p_T| p_S)(y|x) = \frac{1}{|y|}\sum_{n = 1}^{|y|}D(p_T(\cdot |y_{< n},x) || p_S(\cdot |y_{< n},x)) $$
    • 但这种 Off-policy 方法存在分布不匹配的问题:
      • Student 在自回归生成过程中遇到的部分序列 \(y_{< n}\) 与在固定数据集上训练时看到的序列不同,导致错误累积
  • On-policy 蒸馏(OPD) (2024;2025;) 使用 Student 采样序列 \(\hat{y} \sim p_S(\cdot |x)\)
    • 并从 Teacher 那里获得密集的 Token-level 反馈:
      $$\mathcal{L}_{\text{On-Policy Distillation} }(\theta) = \mathbb{E}_{x\sim \mathcal{S} }[\mathbb{E}_{\hat{y}\sim p_S(\cdot |x)}[D(p_T| p_S)(\hat{y} |x)]] \tag {3}$$
      • OPD 将蒸馏与模仿学习联系起来
      • OPD 中,Student 在 Student 自身的输出上学习 Teacher 的信号来迭代改进
        • 这结合了 RL 的 On-policy 相关性和监督学习的密集奖励信号
      • OPD 减轻了曝光偏差,同时保持了计算效率

RLVR:Reinforcement Learning with Verifiable Rewards

  • RLVR 是 LLM 后训练的一种流行方法,特别是在数学和编程等结果易于验证的任务上
    • RLVR 一般使用 PPO 和 GRPO 等算法
  • GRPO 通过为每个问题 \(x\) 从当前策略 \(\pi_{\theta}\) 采样一组 \(G\) 个 Response \(\{o_1,o_2,\ldots ,o_G\}\) 来进行训练
    • 每个 Response \(o_i\) 收到一个表示正确性的二进制奖励 \(r_i\in \{0,1\}\)
    • 该方法使用一个组归一化的奖励为 Response \(o_i\) 内的所有 token \(k = 1,\ldots ,|o_i|\) 分配优势:
      $$A_{i} = \frac{r_{i} - \text{mean}(\{r_{j}\}_{j = 1}^{G})}{\text{std}(\{r_{j}\}_{j = 1}^{G})} \tag {4}$$
      • 这个公式可以通过价值函数的角度来理解:
        • \(\text{mean}(\{r_j\}_{j = 1}^G)\) 作为价值函数 \(V(x)\) 的 \(G\) 样本蒙特卡洛估计
        • 稀疏的二进制奖励 \(r_i\) 代表(未折扣的)状态-动作价值 \(Q(x,o_i)\)
      • 由于奖励信号仅在 Sequence-level 提供,一个 Response 内的所有 token 共享相同的优势
    • GRPO 目标函数包含一个裁剪的替代损失以缓和策略更新,以及一个反向 KL 惩罚项以防止过度偏离参考策略:
      $$\begin{align}
      \mathcal{L}_{\text{GRPO} }(\theta) = \mathbb{E}_{x \sim \mathcal{S}, \{o_i\}_{i=1}^G \sim \pi_{\theta}(\cdot|x)} \left[\frac{1}{G}\sum_{i = 1}^{G}\frac{1}{|o_i|}\sum_{n = 1}^{|o_i|} \min (\rho_i^n A_i,\text{clip}(\rho_i^n,1 - \epsilon ,1 + \epsilon)A_i) -\beta D_{\text{KL} }[\pi_{\theta}(\cdot |x)||\pi_{\text{ref} }(\cdot |x)]\right] \end{align} \tag {5}$$
      • \(\rho_i^n = \frac{\pi_{\theta}(o_i^n|x,o_i^{< n})}{\pi_{\theta_{\text{old} } }(o_i^n|x,o_i^{< n})}\) 是重要性比率
        • 其中的 \(\pi_{\theta_{\text{old} } }\) 是本轮更新前的策略
      • \(\epsilon\) 控制裁剪范围
  • RLVR 方法面临两个关键限制:
    • (1) 奖励信号稀疏,仅提供 Sequence-level 反馈,而不是关于错误发生在哪里的 Token-level 指导
    • (2) 当所有采样的 Response 收到相同的奖励(全部正确或全部错误)时,优势变为零
      • 有采样成本,但无法进行任何策略更新
  • 问题:作者这里将 GRPO/PPO 等与 RLVR 强绑定描述非常奇怪,RLVR 更像是描述一类具有 Variable Reward 的 RL 信号建模方法,并不太适合描述为一个具体的 RL 训练方法

Methods

Learning from Verifiable Reasoning Dataset

  • 考虑一个问题-解决方案对的数据集
    $$ \mathcal{S} = \{(x_i,y_i^*)\}_{i = 1}^N$$
    • \(x_i\) 表示一个问题
    • \(y_i^*\) 是对应的参考解决方案(可能包含思维链推理)
    • 为简洁起见,后续本文省略样本索引 \(i\),并使用 \((x,y^*)\) 表示数据集中的一个通用样本
  • 可以通过不同方式利用这个数据集的学习信号:
    • SFT: 在该数据集 \(\mathcal{S}\) 上进行标准的 SFT 可以看作是一种使用专家轨迹的 Off-policy 蒸馏/模仿学习
      • 但 SFT 存在训练和推理之间的分布不匹配问题
    • RLVR: 基于 RLVR 也可以
      • 比如 GRPO 通过在 On-policy 样本上进行优化并通过将生成答案与 \(y^*\) 比较来分配二进制奖励来解决此问题
      • 但 RLVR 计算代价高昂,并且奖励信号稀疏,无论错误发生在哪里,都为所有 token 提供相同的反馈
        • 理解:这里的表述可以是对的,也可以是错的
          • “对的” 理解方式:RLVR 中的 Reward 反馈确实是 Sequence-level 的
            • 虽然 PPO 的 Advantage 是 Token-level 的,但是反馈也只是 Sequence-level 的,只是加了 KL 散度建模
          • “错的” 理解方式:若将 PPO 每一步的 KL 散度理解为反馈,那么这里的所谓 RLVR 方法就是错的
    • PRM 添加 Token-level 信号: 可以训练一个 PRM 在 RL 期间提供密集的 Token-level 反馈
      • 但获取用于 PRM 训练的标签非常昂贵且难以扩展 (2023;2025)
    • On-policy Distillation 方法 (2024;2025) 通过训练 Student 自身的样本来解决分布偏移问题
      • 但需要一个单独的、通常更大的 Teacher 模型来提供监督
  • 本文作者寻求一种密集的、on-policy 的、不需要外部 Teacher 或奖励模型的训练信号
    • 这引出了本文的 On-policy Self-Distillation 方法
  • 表 1 中总结了这些方法的差异

On-Policy Self-Distillation

Motivation: Learning by understanding solutions,通过理解解决方案来学习
  • 本文提出了一个受 Student 学习方式启发的不同视角:
    • 当遇到难题时,与其进行长时间的试错,不如让 Student 可以检查解决方案,理解推理过程,并内化该方法
    • 如果一个模型能够访问正确答案或推理过程 \(y^{*}\) 并且足够强大,它可以合理解释推理步骤并自我教导
      • 这类似于 Student 复习一个解决方案并回溯其有效的原因
    • 利用 ground-truth 解决方案 \(y^{*}\) 作为训练期间的 Privileged 信息,使模型能够在不需要外部奖励模型或更大 Teacher 模型的情况下充当自己的 Teacher
Teacher and student policies
  • 通过改变条件上下文,从同一个语言模型 \(p_{\theta}\) 实例化两个条件分布
  • Teacher 策略基于 Privileged 信息,即问题 \(x\) 和参考解决方案 \(y^{*}\) 进行条件设定:
    $$p_{T}(\cdot |x,y^{\star})\triangleq p_{\theta}(\cdot |x,y^{\star}) $$
  • Student 策略只观察问题陈述,与推理时的条件相匹配:
    $$p_{S}(\cdot |x)\triangleq p_{\theta}(\cdot |x) $$
  • Teacher 和 Student 策略共享相同的参数 \(\theta\),仅在条件上下文上有所不同
    • 为了鼓励 Teacher 自然地评估 Student 的生成结果,添加了一个 Prompt
      • 要求 Teacher 在看到参考解决方案后生成一个新的解决方案,如图 2 所示
      • 注:Teacher 不会生成 token,它只是通过前向传播隐式地进行合理化
On-policy sampling from the student
  • 给定一个问题 \(x\)
    • Student 生成一个 On-policy Response
      $$\hat{y} = (\hat{y}_1,\ldots ,\hat{y}_{|\hat{y}|})\sim p_S(\cdot |x) $$
    • 让 Teacher 和 Student 都评估这个 Student 生成的轨迹
    • 在每个位置 \(n\),基于相同的 Student 前缀诱导出下一个 token 的分布:
      $$p_{S}(y_{n}\mid x,\hat{y}_{< n}),\qquad p_{T}(y_{n}\mid x,y^{\star},\hat{y}_{< n}) $$
      • 其中 \(\hat{y}_{< n} \triangleq (\hat{y}_{1}, \ldots , \hat{y}_{n - 1})\)
Training objective: Full-vocabulary logit distillation
  • 本文实例化了一个全词表散度目标,该目标在每个位置上匹配 Teacher 和 Student 的下一个 token 分布
  • 给定一个 Student 生成的序列 \(\hat{y}\),定义轨迹平均的、按 token 计算的散度为
    $$D(p_{T}| p_{S})(\hat{y}\mid x)\triangleq \frac{1}{|\hat{y}|}\sum_{n = 1}^{|\hat{y}|}D\bigg (p_{T}(\cdot \mid x,y^{\star},\hat{y}_{< n})| p_{S}(\cdot \mid x,\hat{y}_{< n})\bigg) \tag {6}$$
    • \(p_S(\cdot \mid x,\hat{y}_{< n})\) 和 \(p_T(\cdot \mid x,y^*,\hat{y}_{< n})\) 表示下一个 token \(y_{n}\in \mathcal{V}\) 上的分布
  • 这里,\(D\) 可以是任何分布散度度量(Forward/Reverse KL 或者 Jensen-Shannon Divergence (JSD) 等),例如广义 Jensen-Shannon 散度 \(\text{JSD}_{\beta}\),对于权重 \(\beta \in [0,1]\) 定义为:
    $$\text{JSD}_{\beta}(p_{T}| p_{S}) = \beta D_{KL}(p_{T}| m) + (1 - \beta)D_{KL}(p_{S}| m) \tag {7}$$
    • 其中 \(m = \beta p_{T} + (1 - \beta)p_{S}\) 是插值混合分布
    • 这种全词表公式提供了密集的、按 token 计算的反馈:
      • 由 \(y^*\) 提供信息的 Teacher 将 Student 暴露在合理下一个 token 的整个分布中,并引导它走向能得出正确答案的推理路径
  • 本人最小化 On-policy Student 样本上的 Teacher 和 Student 之间的期望散度:
    $$\mathcal{L}(\theta) = \mathbb{E}_{(x,y^{\star})\sim \mathcal{S} }\left[\mathbb{E}_{\hat{y}\sim p_S(\cdot |x)}\left[D(p_T| p_S)(\hat{y}\mid x)\right]\right] \tag {8}$$
  • 梯度仅通过 Student 策略 \(p_S\) 反向传播,而 Teacher \(p_T\) 作为一个固定的、基于 Privileged 信息 \((x,y^*)\) 的全分布目标
Per-Token Pointwise Divergence Clipping
  • 本文实验观察到 Token-level 散度在词表条目上高度倾斜:
    • 一小部分风格化 Token 的散度远高于具有数学意义的 Token(见表 5)
    • 这种不平衡导致训练信号被风格化模式所主导
  • 为了解决这个问题,本文对词表级别的散度贡献应用逐点裁剪
    • 令 \(D_f(p_T | p_S)\) 表示一个 \(f\)-散度
    • 在每个 Token 位置 \(n\) 和词表条目 \(v\) 上,定义:
      $$
      \ell^{(f)}_{n,v} = p_T(v \mid \cdot) f\left(\frac{p_S(v \mid \cdot)}{p_T(v \mid \cdot)}\right)
      $$
  • 计算裁剪后的散度:
    $$
    D^{(f)}_{\text{clip} }(p_T | p_S) = \frac{1}{|\hat{y}|} \sum_{n=1}^{|\hat{y}|} \sum_{v \in \mathcal{V} } \min(\ell^{(f)}_{n,v}, \tau)
    $$
Alternative objective: Sampled-token distillation through policy gradient
  • 本文 Follow 最近的 On-policy 蒸馏方法 (2025),构建了一个 Sample-token 奖励信号(关于采样动作的反向 KL 信号),并使用策略梯度进行优化
  • 对于一个采样序列 \(\hat{y}\) 中的每个位置 \(n\),定义优势项
    $$ A_{n}(x,\hat{y}) = \log p_{T}(\hat{y}_{n}\mid x,y^{\star},\hat{y}_{< n}) - \log p_{S}(\hat{y}_{n}\mid x,\hat{y}_{< n})$$
  • 并优化策略梯度风格的目标函数
    $$
    \begin{align}
    \mathcal{L}(\theta) = -\mathbb{E}_{(x,y^{\star})\sim \mathcal{S} }\left[\mathbb{E}_{\hat{y}\sim p_S(\cdot |x)}\left[\frac{1}{|\hat{y}|}\sum_{n = 1}^{|\hat{y}|}A_n(x,\hat{y}) \cdot \log p_S(\hat{y}_n\mid x,\hat{y}_{< n})\right]\right]
    \end{align}
    \tag {9}
    $$
    • \(A_{n}(x,\hat{y})\) 被视为关于 \(\theta\) 的常数(即,梯度不会通过优势项流动),因此梯度采用通常的策略梯度形式 \(A_{n}\nabla_{\theta}\log p_{S}\)
    • 与全词表散度目标相比,这个 On-policy 塑形目标仅对采样的 token 进行操作,利用 Teacher 的 log-probabilities 提供密集的、轨迹级的塑形信号,而无需在每一步显式匹配完整分布
OPSD as dense-reward policy gradient and comparison to STaR,OPSD 作为密集奖励策略梯度以及与 STaR 的比较
  • 等式 (9) 中的目标可以看作是具有密集、 Token-level 奖励的策略梯度
  • 在附录 C 部分,本文对此进行了形式化,并与 STaR (2022) 进行了对比
    • STaR:
      • 使用相同的模型生成推理轨迹,然后进行拒绝采样,随后对正确的轨迹进行 SFT
      • 这个过程可以看作是具有 Sequence-level 二进制奖励的策略梯度,该奖励为所有 token 分配相同的信用,并在样本不正确时消失
    • OPSD:
      • 无论最终答案正确与否,OPSD 在每个 token 位置都提供反馈

Experiments

  • 本文开展了全面的实验,旨在解答以下研究问题:
    • (1) OPSD在推理性能和样本效率方面与SFT、GRPO相比表现如何?(§4.2)
    • (2) OPSD中的逐 Token 点态KL裁剪(per-Token pointwise KL clipping)如何帮助稳定训练?(§4.3.3)
    • (3) 生成风格、生成长度对模型性能有何影响?(§4.3.4)
    • (4) 全词表logit蒸馏(full-vocabulary logit distillation)相比采样 Token 策略梯度(sampled-Token policy gradient)是否具备优势?(§4.3.5)

Experimental Setup

Models and datasets
  • 本文基于 Qwen3 模型系列的三个参数量规模开展实验:Qwen3-1.7B、Qwen3-4B 和 Qwen3-8B
    • 注:文中强调这里使用的是 instruct 微调版本,但实际上 Qwen3-8B 是没有 Thinking Mode 和 Non-Thinking Mode 在一起的
    • 2507 出的 Qwen-4B 是有 Thinking 版本和 Instruct 版本的
  • 训练数据:
    • 本文会采用 OpenThoughts 数据集 (2025) 中的数学推理子集,抽取 30K 个包含思维链推理的问题-解决方案对
  • Benchmarks
    • 在 AIME 2024、AIME 2025 和 HMMT 2025
Baselines
  • 在相同数据集上与两种方法进行对比:
    • (1) SFT,即基于专家轨迹的标准有监督微调,可视为由生成推理轨迹的更强大LLM执行的离策略蒸馏
    • (2) GRPO(2024),即结合基于真实答案验证的二值结果奖励的分组相对策略优化
      • 最大生成长度设置为16k
Implementation details
  • 将教师策略固定为初始策略,而非当前更新的学习策略
    • 因为实验发现这一设置有助于稳定训练 ,且能隐式起到正则化作用,防止模型过度偏离初始策略 (这个理解不错)
    • 实验中采用全词表 logit 蒸馏的方式
  • 所有实验均在 A100 或 H100 GPU 上完成,并使用 LoRA 技术
    • 注意:这里使用的是 LoRA
  • 更多实验细节见附录B

Main Results

  • 表 2:Qwen3 模型在数学推理基准数据集上的性能对比
    • 按照 Qwen3 技术博客推荐的采样配置(温度值 1.0,最大生成长度 38k)报告 Avg@12 指标;完整细节见 表 8
    • 对于 OPSD,每 20 步评估一次模型检查点,直至 100 步,并报告最优分数
    • 对于 GRPO,报告 500 步训练内的峰值性能(实验发现部分任务中 GRPO 的性能会因后期的熵坍缩出现下降)
    • 对于 SFT,其训练样本量与 OPSD 保持一致
      • SFT 的性能退化源于在简洁的推理解决方案上进行微调,导致模型测试阶段的生成长度缩短
      • OPSD 则通过合理化(Rationalization)将这些解决方案转化为稠密的学习信号
  • 表 2 报告了在数学推理基准数据集上的实验结果
    • 在所有模型规模下,OPSD 始终优于 SFT,且相比基础模型均有性能提升
    • 在所有实验设置中 OPSD 均达到或超越 GRPO 的表现
  • 效率方面:
    • OPSD 仅对每个问题进行一次 rollout 即可实现上述性能提升
      • 在 100 步内收敛
      • 每个问题仅需采样 1024 个 Token
      • 理解:传统的 RL 中不能这样做(这是 OPD 专有的优点)
        • 在 OPD 场景中,不需要 Rollout 结束就可以有奖励(来源于 Teacher)
        • 在传统 RL 场景,一般是需要 Rollout 结束才能得到 Reward 反馈的
    • GRPO 对每个问题需要进行 8 次 Rollout
      • 每次生成 16k 个 Token
      • 后期还可能因熵坍缩出现性能退化
      • 在该 OpenThoughts 数据集上,采样组内的奖励标准差大多为 0,导致模型无法获得学习信号,造成采样预算的浪费
  • 其他观察,在相同数据集上训练时
    • SFT 在所有任务和模型规模下均出现一致的性能退化
    • 这一现象可归因于真实标签解决方案的推理风格简洁,导致模型在测试阶段的生成长度缩短
  • 一些推测:
    • OPSD 的 Token 效率得益于教师分布提供的稠密 Token-level 监督
    • 同时作者推测 :前序 Token 可能对有效蒸馏的贡献更大(因为这些 Token 可能代表了推理过程中更关键的分支节点)
  • 如图 3 所示
    • 在 100 步的训练范围内,OPSD 相比 GRPO 实现了更高的 Token 学习效率
    • 在 100 步训练内,当采样组内的结果奖励保持一致时,GRPO 的性能陷入停滞,学习信号减少,最终导致梯度为 0
    • 这些结果表明,OPSD 能比 GRPO 和 SFT 更高效地从相同的推理数据集中提取学习信号,同时大幅缩短训练时间
  • 图 3. OPSD 的 Token 效率
    • 在相同的有效训练批次大小下比较了 Qwen3-4B 上的 OPSD 和 GRPO,报告了平均 \(@16\) 性能随梯度更新步数和总生成 Token 数的变化
    • 两种方法在每次更新的采样生成数量方面具有相同的有效批次大小,但在生成长度上有所不同:
      • OPSD 的每个生成上限为 1024 个 Token,而 GRPO 为 16384 个 Token
    • OPSD 以明显更少的生成 Token 数量达到了与 GRPO 相当的性能,从而降低了采样成本和训练时间
    • 在此实验中,OPSD 的 Token 效率比 GRPO 高 \(8 - 12 \times\)
    • 实验细节见第 B 节

Ablation Studies & Discussions

  • 本节开展了大量消融实验,研究 OPSD 中关键的设计选择,包括:
    • (1) 散度目标函数
    • (2) 学生和教师的生成风格(如思维模式开启/关闭)
    • (3) 逐 Token KL 裁剪的效果;
    • (4) 学生生成长度的影响
    • (5) 全词表 logit 蒸馏与采样 Token 蒸馏的对比
Effect of Divergence Objective
  • OPSD 中一个关键的设计选择是散度函数的选择
    • 即用于实现教师与学生之间 Per-Token 分布匹配的散度函数
  • 本文在 AIME25 数据集上基于 Qwen3-1.7B 模型,对比了前向 KL 散度、反向 KL 散度和 JSD 散度的表现,结果见表 3
    • 所有目标函数均在相同的点态裁剪方案下评估以保证训练稳定性
    • 前向 KL 散度始终能带来最显著的性能提升,将模型在第 50 步的性能从 36.7 提升至 43.9,且在第 100 步仍高于基线模型
    • 反向 KL 散度和 JSD 散度仅带来有限的提升,甚至产生负面效果
    • 注:在后续所有实验中,作者均采用前向 KL 散度
Effect of Generation Styles And Per-Token KL Clipping,生成风格与逐 Token KL 裁剪的影响
  • OPSD 中另一项关键设计选择是学生和教师模型的生成风格,这一选择决定了学生的学习对象,以及教师提供的监督风格
  • Qwen3模型支持两种生成模式:
    • 思维模式开启(TM-on),模型会生成自反思的思维链 Token
    • 思维模式关闭(TM-off),模型会直接生成响应结果
  • 为确定哪种组合能产生最有效的学习信号,本文分析了四种学生/教师模式组合下的前向 KL 散度 \(KL(p_T | p_S)\),并将 Token 分为三类:
    • 数学类(数字、运算符和数学关键词)
    • 风格类(推理连接词)
    • 其他类
  • 表 5 报告了每个类别内的平均逐 Token KL 散度
  • 在所有模型规模下,思维模式关闭的学生与思维模式开启的教师组合,在数学类 Token 上的 KL 散度值最大,这表明该组合能对数学相关 Token 提供更强的监督
    • 报告的 KL 散度值对应每个位置上词表的期望散度
    • 如表 5 所示,这一期望分布存在严重的偏斜,风格类 Token 贡献的散度值占比过高
    • 这一现象促使作者采用点态裁剪的方式,控制此类厚尾分布的贡献
    • 从实验结果来看,该配置能实现最优的下游任务性能
    • 本文最终采用 思维模式关闭的学生/思维模式开启的教师 配置(注:其实这种实现严格来说已经不是 Self Distillation 了)
关于 Prompt 格式的实现说明
  • 在本预印本初次发布后,发现 Student 模型的采样 Prompt 与 Teacher 模型的 Prompt 之间存在意外的格式不匹配:
    • 具体情况: Student Prompt 缺少 Qwen3 的聊天模板,而 Teacher Prompt 则遵循 Qwen3 的思维风格聊天模板
    • 因此 Student 模型的推理是在无模板风格下生成的,而 Teacher 模型的分布则是在包含思考标签的 Prompt 条件下生成的
    • 尽管本文的方法不要求 Student 和 Teacher 模型的 Prompt 模板必须匹配,但本文在此记录这一实现细节以确保透明度和可复现性
      • 理解:这个问题会导致 Teacher 的性能远超 Student 的效果
  • 本预印本中报告的实验结果对应于这种配置
    • Prompt 模板/指令可以被视为本文方法的一个设计选择:
      • Teacher 和 Student Prompt 格式都可以作为框架中可优化的组件
      • 可以通过诸如 GEPA 等 Prompt 优化技术来优化 Teacher Prompt 以塑造监督信号,同时可以改变 Student Prompt 来研究哪种生成模式能产生最有效的学习
Effect of Per-Token Pointwise Clipping
  • 如表 5 所示,风格类 Token 的 KL 散度可能高于数学相关 Token ,导致其主导训练信号
    • 本文通过逐 Token 点态裁剪的方式缓解这一问题
  • 图 4 展示了 Qwen3-1.7B 模型的实验结果,裁剪操作能稳定训练过程,防止性能退化
    • 这一点对于在百步内快速收敛的 OPSD 而言尤为重要
Effect of Generation Length
  • 由于 OPSD 的目标函数在 Token-level 运作(公式 6)
    • 每个样本的生成 Token 数量直接决定了学生可获得的监督信号量
    • 更长的序列能让学生获得更多的教师反馈,但同时也会增加计算成本,且可能引入噪声或无信息的后续内容
  • 为研究这一权衡关系,本文在 Qwen3-1.7B 模型上开展消融实验
    • 将基于策略采样的学生响应生成长度设置为 1024 和 4096 个 Token 两种情况,并采用全词表 logit 蒸馏
  • 如图 5 所示,增加生成长度并未在两个任务上带来一致的性能提升
    • 本文作者将这一现象归因于前序 Token 对学习的关键性:
      • 当学生的生成序列变长时,在足够长的学生前缀条件下,教师对后续 Token 的预测会变得越来越确定,因此对后续 Token 施加的惩罚也会减少
        • 注:(2025)的研究中也发现了这一现象

Learning Objective Comparison: Full Vocabulary Logits Distillation vs Sampled-Token Distillation

  • 公式 6 中的目标函数定义为教师与学生分布之间的 Per-Token 差异
    • 回顾 公式 6:
      $$D(p_{T}| p_{S})(\hat{y}\mid x)\triangleq \frac{1}{|\hat{y}|}\sum_{n = 1}^{|\hat{y}|}D\bigg (p_{T}(\cdot \mid x,y^{\star},\hat{y}_{< n})| p_{S}(\cdot \mid x,\hat{y}_{< n})\bigg) \tag {6}$$
  • 在实际实验中,OPSD 可通过两种方式实例化该目标函数:
    • (1) 全词表 logit 蒸馏(Fullvocabulary logit distillation) (2024):
      • 在每个 Token 位置,通过全 softmax 操作计算整个词表上的 \(D(p_T | p_S)\),得到两个策略之间合理的逐 Token f-散度
      • 这种变体直接匹配完整的 Token 分布
    • (2) 采样 Token 优势策略梯度目标(Sampled-token advantage policy-gradient objective) (2025):
      • 仅在学生实际采样的 Token \(\hat{y}_n\) 位置评估教师和学生的对数概率,并将反向 KL 项作为标量优势,融入策略梯度风格的损失函数中
      • 这种变体优化由教师对数概率塑造的 On-policy RL 目标,而非完整分布的散度
      • 理解:这里的 Sampled Token 就是指 Rollout 得到的 Token
  • 本文在 Qwen3-4B 模型上对比了这两种变体,蒸馏过程中的生成预算设置为 2048 个 Token ,结果如表 4 所示
    • 全词表散度目标相比采样 Token 目标能带来稳定的性能提升
      • 这表明让学生学习完整的教师分布,相比仅依赖逐 Token 的在线策略塑造,能获得更丰富的监督信息
    • 但全词表计算需要在每个位置存储词表规模的 logit,会导致峰值内存占用更高,这也体现了性能与效率之间的权衡
  • 表 4:
    • OPSD 中散度计算策略的消融实验(基于 Qwen3-4B 模型,蒸馏生成长度 2048)
    • 报告在 AIME25 和 HMMT25 数据集上的 pass@8 指标
    • 全分布目标(logit 蒸馏)优于采样 Token 目标

Related Work

LLM Self-Training

  • 本文的与一系列研究表明 LLM 可以通过生成和利用自身的监督信号来改进的研究相关联 (2020;2024b;2024;2023;2023;2024;2024)
  • 在理念上最接近的是上下文蒸馏 (2022),它使用相同的底层模型作为 Teacher 和 Student ,通过为 Teacher 提供 Privileged 上下文,然后对 Student 在无上下文情况下生成的输出进行 SFT
    • 这可以视为 Off-policy,其学习信号是一个离散的 Token 序列
  • 在推理领域,ReST (2023) 和 STaR (2022) 同样依赖于迭代的自训练循环
    • 基于 Prompt 或答案生成推理过程,通过奖励或真实答案进行筛选,然后在成功的轨迹上进行微调
    • 注:这也是硬蒸馏
  • Mitra & Ulukus (2025) 将其扩展到软蒸馏
    • 上下文编辑 (2025) 从 Student 模型进行 On-policy 采样,并展示了通过最小化散度可以将上下文诱导的知识内化,并在知识编辑场景中展示了这一点
  • OPSD 与这些方法的不同之处在于,本文在推理任务上对 Student 自己的 Rollout 执行 On-policy 软蒸馏:
    • Teacher 的监督是每个 Token 的分布匹配,而不是生成用于 SFT 的推理过程
    • OPSD 将推理改进视为学习一个由数据集的真实解答和模型自身推理能力共同诱导的条件分布
  • 其他:
    • SDPO (Hü2026) 探索了类似的算法,利用环境反馈作为 Privileged 信息,详情见 (SDPO)Reinforcement Learning via Self-Distillation, 20260128
      • SDPO 方法除了信号以外来自环境反馈外,几乎和本文思路一致,都是 On-policy 蒸馏的
      • 特别说明:SDPO 中的损失函数也是在整个词表上计算的
    • SDFT (2026) 探索了持续学习任务中的 On-policy 自蒸馏

On-Policy Distillation methods

  • On-Policy Distillation 方法直接在从其自身策略采样的轨迹上训练 Student 模型,而 Teacher 模型则通过 KL 散度 (2024;2024a;2024;2025;2026;2025) 提供每个 Token 的指导
    • 这些方法通过直接优化 Student 的访问分布来缓解分布偏移,但它们通常依赖于一个独立的、通常更大的 Teacher 模型
  • 本文探索 LLM 是否可以通过利用更 Privileged 答案信息并依靠其自身的推理能力来引导其较弱版本改进推理,从而实现自我教学
  • On-policy 训练范式也广泛用于机器人和深度强化学习中,例如 DAgger (2011),其中人类 Teacher 为 Student 策略访问的状态提供纠正性监督

Improving LLM Reasoning through SFT and RL

  • SFT 和 RL 是提升 LLM 推理能力的两种主要方法
  • 在高品质推理轨迹上进行 SFT 已展示出强大的性能 (2023;2024;2023;2025a;2025;2025;2023)
    • 但先前的工作表明 SFT 可能依赖于记忆而非稳健的泛化能力 (2025)
  • 直接优化基于结果的目标的 RL 可以表现出更好的泛化能力 (2025)
    • 较新的算法如 GRPO 通过从组级别奖励估计优势来实现可扩展的 RL,而不需要像 PPO 那样需要一个显式的 Critic
  • 在这一系列工作的基础上,越来越多的研究强调了 RLVR 在推理任务中的有效性 (2025;2025;2025;2025a;2025)

附录 A:Limitations and Future Directions

  • 由于计算限制,本文实验仅限于 8B 参数以下的模型
  • 虽然更大的模型从 OPSD 中受益更多(这与本文的假设(即自我合理化需要足够的模型容量)一致)
    • 但这一趋势是否会在 8B 参数以上的规模(例如 70B 或更大的前沿模型)中持续,仍然是一个悬而未决的问题
  • 有几个有前景的方向值得进一步研究
    • 第一,本文当前的框架没有明确利用生成答案的正确性验证
      • 整合这些信号可以提供超越分布匹配的额外学习目标
    • 第二,问题难度在自我蒸馏中起着至关重要的作用:
      • 如果推理问题超出了模型的理解阈值,那么即使可以访问真实解决方案, Teacher 策略也无法提供有意义的监督
      • 这表明,课程学习策略(随着模型改进而逐渐增加问题难度)可以提高训练效果
      • 探索能够将问题保持在模型能力前沿的自适应课程,是将 OPSD 扩展到更具挑战性的推理任务的一个重要方向

附录 B:Experimental Details

  • 表 5、4 和 6 中提供了 SFT、GRPO 和 OPSD 实验的训练和评估配置
  • 表 2 中的评估设置:
    • 对于每种方法(GRPO、OPSD 和 SFT),报告在训练过程中,每 100 步评估一次,直到 1500 步,在每个任务上获得的最高得分
  • 由于本文对所有基线一致地应用了相同的协议,考虑到任何固定评估点存在的内在方差,这仍然是不同算法之间的公平比较
    • 本文作者在图 3 中报告了所有三个基线的检查点平均准确率
    • 在图 3 中
      • OPSD 的运行生成长度为 1024,学习率为 \(2 \times 10^{-4}\)
      • 对于 OPSD,对于较短的生成长度(如 1024),使用 \(2 \times 10^{-4}\) 比使用 \(2 \times 10^{-5}\) 能获得更好的结果
      • Remind:传统的 RL 中不能这样做(这是 OPD 专有的优点)
        • 在 OPD 场景中,不需要 Rollout 结束就可以有奖励(来源于 Teacher),但是在传统 RL 场景,一般是需要 Rollout 结束才能得到 Reward 反馈的
  • 所有实验均使用 8 张 A100 或 8 张 H100 GPU 进行,并启用了梯度检查点和 Flash Attention 2 以提高内存效率
    • 本文为所有训练运行使用了 AdamW (2017) 优化器和 bfloat16 精度
    • 对于 OPSD,除非另有说明,作者使用了全词表 Logit 蒸馏
  • 表 6. GRPO 和 OPSD 的训练配置
  • 表 7. SFT 的训练配置
  • 表 6. 评估参数

附录 C:Token Category Definitions

  • 本文将 Token 分类为 Style Token 和 Match Token(提前预定义的关键词)
    • 这些关键词常用语分析 Per-token KL 散度(分别针对风格 Token 和数学知识 Token)
  • Style Tokens.

    maybe, perhaps, probably, possibly, let, okay, ok, alright, hmm, wait, because, since, so, thus, hence, therefore, but, however, although, though, yet, or, alternatively, instead, otherwise, actually, really, just, simply, basically, very, quite, pretty, rather, fairly, now, then, next, first, second, finally, try, see, check, note, recall, think, idea, strategy, approach, method, way, would, could, should, might, can, huge, large, big, small, tiny, interesting, tricky, complex, simple.

  • Math Tokens.

    exponential, exponent, power, powers, base, logarithm, logarithms, log, ln, compare, comparing, comparison, less, equal, larger, smaller, greater, factor, factors, prime, divisible, equation, expression, formula, inequality, rational, irrational, real, integer, coefficient, variable, constant, sum, product, difference, quotient, fraction, denominator, numerator, root, square, cube, nth, maximum, minimum, optimize, bound.


附录 D:Policy-Gradient Interpretation of OPSD and Comparison to STaR,OPSD 的策略梯度解释以及与 STaR 的比较

  • 方程 (9) 中的 OPSD 目标可以解释为一种带有密集、 Token-level 奖励信号的策略梯度更新
    • 回顾方程(9)策略梯度风格的目标函数
      $$
      \begin{align}
      \mathcal{L}(\theta) = -\mathbb{E}_{(x,y^{\star})\sim \mathcal{S} }\left[\mathbb{E}_{\hat{y}\sim p_S(\cdot |x)}\left[\frac{1}{|\hat{y}|}\sum_{n = 1}^{|\hat{y}|}A_n(x,\hat{y}) \cdot \log p_S(\hat{y}_n\mid x,\hat{y}_{< n})\right]\right]
      \end{align}
      \tag {9}
      $$
  • 本节将展示:
    • (1) OPSD 可以被视为一种密集奖励的策略梯度
    • (2) 本文将 OPSD 与 STaR 进行对比,证明 STaR 的学习信号是 Sequence-level ,而 OPSD 是 Token-level

D.1. STaR as Sequence-Level Policy-Gradient

  • STaR (2022) 可以被视为 RL 风格策略梯度目标的一种近似
    • 语言模型 \(p_{\theta}\) 在 rationale(基本原理/根本原因) \(r\) 和答案 \(y\) 上诱导出一个联合分布:
      $$
      p_{\theta}(r,y\mid x) = p_{\theta}(r\mid x)p_{\theta}(y\mid x,r),
      $$
      • 这里表示:模型在预测最终答案 \(y\) 之前,先采样一个潜在的 rationale \(r\)
    • 给定一个指示器奖励 \(R(y) = \mathbf{1}(y = y^{*})\),在整个数据集 \(\mathcal{S} = \{(x_i,y_i^*)\}_{i = 1}^N\) 上的期望回报为:
      $$
      J_{\text{STaR} }(\theta) = \sum_{i = 1}^{N}\mathbb{E}_{(r,y)\sim p_{\theta}(\cdot |x_i)}\big[\mathbf{1}(y = y_i^*)\big] \tag {10}
      $$
    • 应用对数导数技巧,得到策略梯度:
      $$
      \nabla_{\theta}J_{\text{STaR} }(\theta) = \sum_{i = 1}^{N}\mathbb{E}_{(r,y)\sim p_{\theta}(\cdot |x_i)}\Big[\mathbf{1}(y = y_i^*)\nabla_{\theta}\log p_{\theta}(r,y\mid x_i)\Big] \tag {11}
      $$
      • 注意,指示函数丢弃了所有未导致正确答案 \(y_i^*\) 的 sampled rationale 的梯度:
        • 这对应于 STaR 中的筛选步骤
  • 一个局限性是 STaR 的奖励是 Sequence-level :
    • 二元指示器 \(\mathbf{1}(y = y^*)\) 为轨迹中的所有 Token 提供相同的信号,不提供中间的 Credit Assignment
    • 当所有采样的轨迹都不正确时,学习信号就会消失

C.2. OPSD as Dense-Reward Policy Gradient

  • 方程 (9) 中的采样 Token 目标也可以被视为一种策略梯度方法,但具有 Token-level 奖励
    • 固定一个训练对 \((x,y^{\star})\),并让 Student 生成一个轨迹 \(\hat{y}\sim p_S(\cdot |x)\)
    • 在每个位置 \(n\),定义每个 Token 的奖励:
      $$
      r_{n}(x,\hat{y})\triangleq \log p_{T}(\hat{y}_{n}\mid x,y^{\star},\hat{y}_{< n}) - \log p_{S}(\hat{y}_{n}\mid x,\hat{y}_{< n}).
      $$
  • 这个奖励衡量了拥有 Privileged 信息的 Teacher 相对于 Student ,偏好采样 Token \(\hat{y}_n\) 的程度
  • 如正文所述,在计算梯度时,本文将 \(r_n\) (等同于 advantage \(A_{n}\))视为关于 \(\theta\) 的常数
    • 即,在奖励计算中阻止了通过 \(p_T\) 和 \(p_S\) 的梯度传播
    • 在这种处理下,方程 (9) 的梯度呈现标准的策略梯度形式:
      $$
      \nabla_{\theta}\mathcal{L}(\theta) = -\mathbb{E}_{(x,y^{\star})\sim \mathcal{S} }\left[\mathbb{E}_{\hat{y}\sim p_S(\cdot |x)}\left[\frac{1}{|\hat{y}|}\sum_{n = 1}^{|\hat{y}|}r_n(x,\hat{y})\nabla_{\theta}\log p_S(\hat{y}_n\mid x,\hat{y}_{< n})\right]\right],
      $$
  • 这对应于最大化 Student 在线 Rollout 上的期望 Per-Token 奖励:
    $$
    J_{OPSD}(\theta) = \mathbb{E}_{(x,y^{\star})\sim \mathcal{S} }\left[\mathbb{E}_{\hat{y}\sim p_S(\cdot |x)}\left[\frac{1}{|\hat{y}|}\sum_{n = 1}^{|\hat{y}|}r_n(x,\hat{y})\right]\right].
    $$
  • 这个奖励是密集的:
    • 它在每个 Token 位置都提供学习信号,无论最终答案是否正确
Comparison
  • STaR 和 OPSD 都可以被理解为策略梯度方法,但它们的奖励结构有根本的不同
    • STaR 使用一个 Sequence-level 指示器 \(\mathbf{1}(y = y^{\star})\),为所有 Token 分配相同的信号
      • 当所有采样的轨迹都不正确时,学习信号完全消失
    • OPSD 在每个位置都提供一个 Token-level 奖励 \(r_n\),即使在最终答案错误的情况下也能实现细粒度的 Credit Assignment

附录:关于 JSD 的补充说明

  • 假定使用 \(\mathrm{JSD}_{\beta=0.5}\),其原始定义为
    $$ JS(P|Q) = \frac{1}{2}KL(P|M) + \frac{1}{2}KL(Q|M) \quad \text{ where } M = \frac{P+Q}{2}$$
    • JSD 是对称的:\(JS(P||Q) = JS(Q||P)\)
    • JSD 是有界的:值域在 \([0, \ln2]\) 之间
      • 注意:相对而言,KL 散度的阈值是 \([0, +\infty]\),因为某个节点 Q 很小的时候,KL 可能会非常大,而 JSD 则不存在这个情况

NLP——LLM对齐微调-RubricBench

注:本文包含 AI 辅助创作

  • 参考链接:
    • 原始论文:RubricBench: Aligning Model-Generated Rubrics with Human Standards, arXiv 20260303, CUHK & Tencent Hunyuan
    • GitHub:
    • 数据集 from HuggingFace:huggingface.co/datasets/DonJoey/rubricbench

Paper Summary

  • 整体总结:
    • 本文提出了第一个专门用于评估 RM 中 Rubric-guided 评估可靠性的综合基准: RubricBench
      • 包含 1,147 个 Pairwise 比较,专门设计用于 Assess Rubric-based Evaluation 的可靠性
      • 理解:类似于 RewardBench 或 RewardBench2 等,RubricBench 是用于评估 Rubric-based RM 的
      • 注:本文的 RewardBench 不是评估 Rubric-based RM 端到端的能力,而是评估 Rubric-based RM 生成 Rubrics 的能力(作者认为如果 Rubrics 生成的够好的话,其实就还行)
    • 作者的一些发现:
      • 对于 LLM 来说,合成 Rubrics 是困难的,即便是当前 SOTA LLM 模型也无法自主合成有效的 Rubrics(LLM 会优先考虑次要细节而非核心功能约束)
      • 简单理解就是:当前阶段,更应该关注 Rubrics 的生成质量而不是 Rubrics 的验证
        • 因为验证是简单的(小模型也能做);但是生成是复杂的,SOTA 模型也做不了,需要人工参与(作者称为:Rubric Gap)
      • RubricBench 验证了 Rubric-aware RM 的有效性 ,并提供了解决这些缺陷所需的 Foundation
    • 不足(部分来自原文):
      • 数据集来源于开源基准的样本重新筛选得到,数据分布受限于这些分布(特别无法覆盖专有领域的场景)
      • 完全依赖人工专注的 Golden Rubrics,规模较小
      • 为了方便验证,评估是二元的(True or False),可能无法捕捉创意写作等主观任务的质量连续性
  • 本文使用了一个新的名词 Rubric-aware,对比一下 Rubric-based、Rubric-guided 的区别:
    • Rubric-based:以 Rubric 为基础,完全按它来做
    • Rubric-guided:以 Rubric 为方向、指南、路线图
    • Rubric-aware:知晓/考虑 Rubric,但不被它完全绑定,兼顾到 Rubric 就行

Introduction and Discussion

  • RM 在训练期间可为策略优化提供反馈信号,在推理期间可作为候选选择的验证器
  • 当前的 RM 面临一个瓶颈:RM 倾向于优先考虑表面层次的复杂性,而非用户意图的实际满足
  • 新兴的生成式 RM 试图通过生成思维链推理来解决这个问题,但这种自由形式的推理通常缺乏严谨的基础
    • 因此,即使是具有推理能力的 RM (2026) 也常常将高质量的呈现误认为是实际问题的解决,优先考虑风格上的复杂性而非用户意图
    • 这种错位导致了一些广泛的问题:
      • 如冗长偏见(Verbosity Bias)和 Reward Hacking 行为
  • 这个领域正转向 Rubric-guided 评估(也称为检查清单或原则)
    • Rubric-guided 评估通过将模糊的质量定义分解为原子化的、可验证的约束,Rubric 提供了一个结构化的框架来引导评估过程,确保判断基于客观标准,而非模型的隐性直觉
    • 这种范式被迅速采用,但社区缺乏一个统一的基准来评估 Rubric-guided 评估的可靠性
  • 这种方法要求模型动态地合成针对特定、通常是复杂指令的约束 ,而当前的基准无法满足这一类模型的评估要求,如表 1 所示
    • 它们通常依赖于那些已经饱和或过时的样本,这些样本缺乏区分现代高性能模型所需的复杂度 (2025b)
      • 因此, Rubric-guided 方法 (2026) 常常在零散的、自定义的数据集上进行评估 (2025),阻碍了跨方法的严格比较
    • 最关键的是,现有的基准缺乏人类级别的 Rubric 标注
      • 没有这个参考基线,就不可能衡量模型生成的 Rubric 与实现可验证对齐所需的理想评估标准之间的差距
  • for 上述问题,本文作者构建了 RubricBench,包含 1,147 个专门设计用于评估 Rubric-guided 评估可靠性的 Pairwise 比较
    • 不依赖原始数据,而是采用一个多维过滤流程,在三个特定层面上保留具有挑战性的样本:
      • 输入复杂度(例如,需要未说明的语气适配的 Prompt )
      • 输出表面偏差(例如,具有过长篇幅或优秀格式的误导性 Response)
      • 过程失败(例如,包含逻辑错误的推理轨迹)
    • 每个样本都增加了从指令严格推导出的人工标注 Rubrics
      • 这些 Rubrics 作为原子化的、可验证的约束,提供了一个严谨的参考 ,用于评估生成 Rubric 的质量以及偏好判断的准确性
      • 理解:以人工标注的 Rubrics 为参考,评估 Rubric RM 合成的 Rubrics 质量如何
  • 在 RubricBench 上进行的全面实验揭示了三个结论:
    • (1) RubricBench 能有效地区分不同 RM 的性能 :
      • 虽然以往的 RM 和判断模型性能停滞在 40-47% 的准确率,但 Rubric-aware RM 达到了一个明显更高的层次(≈58%)
    • (2) 作者量化了模型生成 Rubric 与人工 Rubric 之间存在严重的 27% 准确率差距
      • 关键在于:人工 Rubric 随着规模扩大展现出持续的效能,而模型生成的 Rubric 则受到严重的收益递减效应影响
      • 这证明了瓶颈在于 Rubric 质量,而单纯地扩大规模无法解决这一问题
    • (3) 认知错位是根本原因 :当前的 RM 难以找出人类专家优先考虑的隐性规则
      • 虽然模型擅长检查显式指令,但它们无法自主地定义必要的约束
      • 这凸显了奖励建模下一个关键步骤是使 Rubric 与人类意图的深层认知保持一致

Benchmark Construction

  • 作者的目标是将现有的基准提炼成一个聚焦的偏好对子集,这些偏好对在现代 LLM 生成行为下仍能保持区分度
  • 该基准包含 1,147 个 Pairwise 比较,每个比较都附有专家标注的、从指令推导出的 Rubric
  • 这些标注将隐式的质量定义转化为显式的标准,作为基准测试 RM 生成评估的结构化参考

Design Principles

  • RubricBench 的构建遵循三个原则,旨在解决现有评估基准中的常见缺陷:
    • (1) 区分难度(Discriminative difficulty) :作者优先选择那些表面层次的线索(例如,冗长性、格式)与实际 Response 质量相矛盾的样本
      • 这确保了该基准对于依赖浅层启发式方法的模型仍然具有区分度
    • (2) Instruction derived :Rubric 仅从指令中推导得出,无法访问候选 Response
      • 这防止了 Rubric 制定过程中出现 Response 感知的信息泄露
      • 理解:这个很重要
    • (3) 原子化(Atomic verification) :Rubric 被制定为独立的二元(是/否)约束
      • 这种分解允许对评估失败进行细粒度、可检查的诊断

Data Source and Domain Coverage

  • To 确保在常见评估场景中的广泛适用性,从多个领域筛选样本,包括聊天、指令遵循、STEM、编程和安全
  • 所有样本都重新筛选自现有的高质量基准,如 HelpSteer3 (2024c)、PPE (2024) 和 RewardBench2 (2025)
  • 虽然这些来源提供了真实的用户样本,但它们大多包含偏好是显而易见的”简单”对
    • 作者应用过滤来精炼和重塑现有数据
  • 图 2 总结了基准的构成和结构统计信息

Stage I: Data Curation

  • 通过一个多维过滤过程来筛选 RubricBench
    • 目标是保留那些能够揭示整体性或表面驱动评估失败的示例
  • 每个候选示例都沿着三个独立的维度进行检查(不满足这些条件中任何一个的示例将被过滤掉):
    • 输入复杂度(Input Complexity)
    • 输出表面偏差(Output Surface Bias)
    • 过程失败(Process Failures)
Input Complexity
  • 优先选择复杂的、组合性的指令,这些指令要求多个不同的条件,然后将这些条件分为显式约束和隐式约束
    • 显式约束是直接陈述的,例如格式规则或内容指令(例如,”列出三个原因”或”避免使用循环”)
    • 隐式约束是通过推理推断出的核心条件;
      • 例如,向祖父母解释”区块链”需要避免使用术语,即使没有明确禁止
    • 这种过滤确保保留的样本具有足够的结构复杂性,以支持有区分度的评估
Detailed data statistics
  • 图 2(a) 报告了最终基准的领域构成
    • 通用聊天和编程占比最大(分别为 36.5% 和 23.9%),其次是 STEM 推理 (23.8%)、指令遵循 (8.8%) 和安全 (7.0%)
  • 如图 2(b) 所示,大多数示例与一组紧凑的 Rubric Item 相关联,其中大部分每个示例的检查项数量在 4 到 6 个之间
    • 这种模式在各个领域都是一致的,表明标注者倾向于以可比的粒度级别表达任务要求
    • 安全领域的平均项数略少,反映出许多违规行为更容易定位,同时仍然保持多个独立的检查
    • 文本长度统计进一步显示,Rubric 明显短于 Response,并且规模与指令相当,这表明标准侧重于基本约束,而非详尽的复述
Output Surface Bias
  • 针对 Rejected Response 充当表面层次干扰项、可能误导偏好判断的配对
    • 理解:这里是说一个 Query(Pair of Chosen and Response) 如果包含这种 Rejected Response,那么留下这个 Pair 整体
  • 具体方法是保留那些 Rejected Response 至少满足以下条件之一的 Pair:
    • (1) 长度偏差 : Rejected Response 长度是 Preferred Response 的 1.5 倍或更多
    • (2) 格式偏差 : Rejected Response 具有更优的结构(例如,JSON、Markdown 或 LaTeX)
    • (3) 语气偏差 : Rejected Response 表现出更高的表面自信度或使用了更多专业术语
    • 这种过滤隔离了那些表面的复杂性掩盖了未能满足核心指令要求的实例,确保模型学会将实质内容置于表面模式之上
Process Failures
  • 优先考虑依赖推理的实例,这些实例中偏好判断不能仅凭最终答案可靠地确定
    • 这些情况指的是,一个正确的结论可能掩盖了有缺陷的中间步骤
  • 为了隔离这些失败,作者利用一套评判模型来生成评估思维链,并仅保留那些表现出两个或更多不同推理谬误的示例;有三种典型的错误:
    • (1) 幻觉步骤 :这些步骤不受指令或上下文的支持
    • (2) 逻辑不一致 :推理转换之间的逻辑不一致
    • (3) 指令约束在推理过程中的削弱
  • 这种过滤确保了数据集需要实质性的过程级检查,从而为 RM 提供比最终判决基准更具区分度的信号

Stage II: Rubric Annotation Protocol

  • 作者将 Rubrics 定义为一组高质量 Response 必须满足的基本条件
    • Rubrics 不是一个详尽的检查清单,而是从指令中推导出的核心要求,为偏好提供客观基础
Rubric annotation guideline(标注指南,实践经验,重要)
  • 标注者为每条指令制定 Rubric,作为可执行的规范,该协议遵循两个主要标准:
    • (1) 结构原子性 :每个 Rubric 由 2-10 个 Item 组成
      • 为确保评估精度,每个 Item 都被表述为一个二元(是/否)检查
      • 标准必须恰好是一个约束,以防止内部冲突,并确保每个维度在评估期间可以被独立验证
    • (2) 语义客观性 :Rubric Item 的起草不参考候选 Response ,以防止事后偏差
      • 标准仅从指令中推导得出,并映射到相关领域:推理、内容、表达、对齐或安全
      • 这些标准既包括逐字陈述的显式约束,也包括从任务上下文中推断出的隐式要求
        • 例如,”为老年人设计步行游览”隐含地要求包含休息时间和无障碍路线
      • 任何依赖于特定 Response 特征的标准都被严格排除,以保持 Rubric 作为中立、与指令对齐的约束的作用

Stage III: Quality Control and Verification

  • 为确保作者 Rubric 的可靠性和结构完整性,作者实施了一个三阶段的质量控制协议:
    • (1) 专家整合 :在独立的双重标注之后,一位资深评审员将两个版本综合成一个统一的 Rubric
      • 这个过程仅保留基于共识的标准,同时移除主观的、模糊的或非必要的 Item
    • (2) 结构验证 :Rubric 经过最终验证,以确保:
      • i. 逻辑一致性 :检查内部是否存在冲突或矛盾的二元检查
      • ii. 最小冗余 :剔除重叠的标准以保持原子性
      • iii. 指令对齐 :验证每个 Rubric Item 是否直接源于原始 Prompt 的约束
    • (3) 压力测试 :对安全和推理任务进行抽查,并针对预留的模型 Response 验证 Rubric
      • 这确保了标准在广泛的 Response 质量范围内仍能保持区分度

Experiments

  • 本文实验旨在逐步剖析自动评估器的能力与局限性
  • 作者首先在 RubricBench 上对一系列不同的评估器进行基准测试,建立了一个清晰的能力层级,验证了本基准的区分能力
  • Beyond final verdict,作者分离了评估 Rubrics 的作用,揭示了一个深刻的 Rubric Gap:
    • 一个在自生成 rubrics 中持续存在的性能缺陷
    • 与人类标注的约束不同,这种缺陷在 test-time scaling 下仍然无法被弥补
    • 问题:这里说的 verdict 是什么?

Experimental Setup

Evaluation settings
  • 为了隔离 Rubric 质量的影响,作者在三种受控条件下评估评估器(见表 3),保持 Backbone (backbone)、 Prompt 和解码参数不变:
    • (1) Vanilla
      • 模型直接从指令生成偏好 verdict,无需显式的中间推理
      • 这作为模型内在区分能力的基线
    • (2) Self-Generated Rubrics
      • 反映当前的 Rubric-aware 流程,RM/评估器首先从指令中推导出 rubrics,然后根据这些 rubrics 验证响应
      • 此设置测试模型制定有效 rubrics 的能力
    • (3) Human-Annotated Rubrics
      • 作者注入来自 RubricBench 的人工撰写的 rubric
      • 通过绕过 Rubric 生成的瓶颈,此设置隔离了模型基于真实 rubrics 执行后续验证的能力,作为 Rubric-guided 评估的上限
Models
  • 涵盖了奖励建模中四种代表性范式(详见附录 A.2):
    • (1) Scalar RMs :直接对响应进行评分的开源权重模型
      • 包括 ArmoRM (2024a)、InternLM2-Reward (2024) 和 Tulu-3-RM (2025a)
    • (2) Generative RMs :在评分前生成 CoT 的模型
      • 如 Nemotron-GenRM-49B (2025)、Nemotron-BRRM-14B (2025) 和 RM-R1-32B (2026)
    • (3) LLM-as-a-Judge :标准的 Pairwise 评估器,包括专有 API(GPT-4o-mini、DeepSeek-v3.2、Gemini-3-Flash)和开源评估器(Self-Taught-Evaluator (2024b)、FARE (2025))
      • 理解:这里的 LLM-as-a-Judge 特指 标准的 Pairwise 评估器
    • (4) Rubric-Aware Judges :专门的流程(Auto-Rubric (2025)、RocketEval (2025)、CheckEval (2025)、TICK (2024)、OpenRubric (2025a)),在自生成和人类标注的 Rubric 设置下进行评估
Metrics
  • 采用两类指标来评估最终 verdict 和中间推理过程:
  • (1) Preference Accuracy
    • 每个样本包含一个指令和一对候选响应 \((y^{(A)}, y^{(B)})\)
    • 评估器输出一个二元偏好 \(\hat{z} \in \{A, B\}\)
    • 设 \(z^{*}\) 为人类偏好标签
    • 偏好准确率为
      $$
      \text{Acc} = \frac{1}{|\mathcal{D}|}\sum_{i\in \mathcal{D} }\mathbb{I}[\hat{z}_i = z_i^* ] \tag {1}
      $$
    • 作者报告各个领域的准确率和所有领域的平均准确率
  • (2) Rubric Alignment metrics
    • 衡量自动生成的标准在规则层面上与人类标注的 Rubric 的对齐程度
    • 具体方法:对于每个任务,将生成的标准 \(\hat{\mathcal{R} }\) 与参考 Rubric \(\mathcal{R}\) 进行比较,并报告用于诊断和消融实验的结构对齐统计量(第 5 节)
    • 设 \(\tilde{\mathcal{R} } = \{\tilde{r}_{1},\ldots ,\tilde{r}_{K}\}\) 为生成的 Rubric,\(\mathcal{R} = \{r_{1},\ldots ,r_{M}\}\) 为人类标注的参考 Rubric
    • Rubric Recall 衡量至少被一个生成项匹配到的参考项的比例:
      $$
      \text{RubricRecall} = \frac{H}{M} \tag {2}
      $$
    • 幻觉率 (Hallucination Rate) 计算未匹配到任何参考项的生成项的比例:
      $$
      \begin{align}
      u_{k} = \mathbb{I}\left[\sum_{j = 1}^{M}\text{match}(\tilde{r}_{k},r_{j}) = 0\right] \tag {3} \\
      \text{HallucinationRate} = \frac{1}{K}\sum_{k = 1}^{K}u_{k} \tag {4}
      \end{align}
      $$
    • Structural F1 使用精度代理 \(\text{Prec} = 1 - \text{HallucinationRate}\)
      $$
      \text{StructuralF1} = \frac{2 \cdot \text{RubricRecall} \cdot \text{Prec} }{\text{RubricRecall + Prec} } \tag {5}
      $$
    • 完整的匹配协议细节见附录 B

Main Results

  • 表 2 展示了一个清晰的性能层级,验证了 RubricBench 在区分评估器能力方面的有效性
隐式推理不足 (Implicit reasoning is insufficient)
  • 标量和生成式 RMs 难以持续优于随机水平(准确率 \(\approx 44 - 50%\) ),标准的 LLM 评估器表现同样不佳(GPT-4o-mini: \(40.2%\) )
    • 这表明,在没有显式约束的情况下,即使是强大的模型也难以捕捉 RubricBench 的细粒度要求
Rubric-aware 流程恢复性能 (Rubric-aware pipelines recover performance)
  • 引入自生成的 rubrics 相对于原生基线带来了一致的改进(例如,将 GPT-4o-mini 提升了 \(\sim 6%\) ,DeepSeek 提升了 \(\sim 19%\) ),最强的配置达到了 50% 以上
  • 最显著的提升发生在 Rubric 质量得到解决时:
    • 注入人类标注的 Rubrics 将准确率推高至 \(\sim 84.9%\) (OpenRubric with DeepSeek)
    • 由于 Backbone 和验证过程保持不变,这个增量 \((+27%)\) 有效地确认了当前自动化评估中的主要失败模式: Rubric Mis-specification
失败集中性 (Failure Concentration)
  • 失败并非均匀分布
  • 安全领域对 Rubric 质量表现出最高的敏感性:
    • 自生成方法未能强制执行安全边界(准确率 \(\approx 25 - 30%\) )
    • 明确编码了拒绝逻辑的人类 Rubrics 则将性能恢复到 \(\sim 90%\)
    • 这凸显了模型通常缺乏内在的“安全意识”来自我提出必要的拒绝约束
执行上限 (Execution Ceiling)
  • 即使使用人类 Rubrics,准确率也稳定在 \(85%\) 左右,而非接近 \(100%\)
  • 这反映了在开放式偏好中存在的、不可约的模糊性,以及剩余的执行错误(详见表 8),即模型即使在 Rubrics 被正确指定时也难以应用它们

The Rubric Gap

  • 表 3 量化了 Rubric Gap,即完全可归因于评估 Rubric 质量的性能差距
  • 通过隔离 Rubric 来源的影响,作者发现
    • 虽然自生成的 Rubrics 比原生 Prompt 有明显的改进(例如,DeepSeek-v3.2 从 \(38.8%\) 上升到 \(57.8%\) ),但在切换到人类标注的 Rubrics 时,仍然存在巨大的性能差距
      • 即使是最新的前沿推理模型,包括 GPT-OSS-120B、Gemini-3-Pro 以及最近发布的 Qwen3.5-Plus,这个差距也持续存在
  • 在所有模型家族中(从轻量级评估器到前沿规模的推理系统)人类 Rubrics 带来的性能增益稳定在 \(\sim 26%\)
    • 这个差距的稳定性表明,当前评估的主要限制不是推理能力,而是 Rubric 的生成
    • 模型在得到指导时拥有执行高质量判断的推理能力,但它们系统地无法自主地推导出必要的评估标准
    • 因此, Rubric Mis-specification 成为阻碍达到人类级别可靠性的主要瓶颈

计算无法弥合差距 (Compute Does Not Close the Gap)

  • 图 3 对比了在固定 Backbone 和验证程序下,仅改变测试时计算量时,合成 Rubrics 与人类 Rubrics 的扩展行为
  • 对于自动生成的 Rubrics(图 3a),增加采样的 Rubrics 数量会产生递减且非单调的回报:
    • GPT-4o-mini 从 \(\text{Rub@4}\) 的 \(48.0%\) 下降到 \(\text{Rub@32}\) 的 \(46.8%\)
    • Gemini-3-Flash 则保持在 \(56.7 - 57.5%\) 附近基本持平,表明额外的样本主要累积了噪声,而非遗漏的约束
  • 通过随机子采样来扩展人类标注的 Rubrics(图 3b)则表现出强劲的正相关性:
    • Gemini-3-Flash 从 \(75.4%\) (H-Rub@2)增加到 \(85.3%\) (H-Rub@8)
    • GPT-4o-mini 从 \(64.5%\) 增加到 \(72.7%\)
    • 这表明测试时扩展仅在底层 Rubric 结构健全时才有效
  • 扩展迭代优化深度(图 3c)同样未能弥合差距:
    • 增加优化步骤并未产生单调增益,甚至可能略有下降(例如,GPT-4o-mini \(46.7% \rightarrow 46.4% \rightarrow 45.7%\)
    • Gemini-3-Flash \(58.0% \rightarrow 58.6% \rightarrow 58.2%\) )
  • 这些结果共同证实,瓶颈在于 Rubric 质量而非计算量:
    • 无论是更多采样的合成 Rubrics 还是更深的优化,都无法弥补缺失或错误指定的标准,而即使是少量的人类 Rubrics 也已经超越了完整的合成集

Analysis

  • 本节剖析 RubricBench 上的评估过程
  • 鉴于作者发现 Rubric Gap 是主要瓶颈,作者的分析聚焦于 Rubrics 的形成,诊断自主生成的 Rubrics 的结构性失败,并随后说明这些失败如何导致判断反转

认知错位 (Cognitive Misalignment)

  • 为了量化 Rubric 质量的不足,作者采用了附录 B 中详述的严格匹配协议
  • 表 4 揭示了一个根本性的错位:依赖标准 Prompt 策略的当前模型难以找出人类专家所优先考虑的隐含规则
    • 这导致了注意力偏移 (Attention Displacement) :模型将其生成预算浪费在无关紧要的 Rubrics 上
      • 例如,尽管生成了冗长的检查清单(如 Auto-Rubric 和 OpenRubric 平均 \(>13\) 项),模型仍维持着高幻觉率 \((>70%)\) ,同时遗漏了近一半的关键约束
      • 即使是像 RocketEval(平均 4.4 项)这样减少噪声的方法,也是以牺牲覆盖率为代价,而非提高精确率
    • 这些结果揭示了一个严峻的现实:目前,简单的、完全自主的 Prompt 不足以复制人类专家的严谨内容选择
    • CheckEval 达到了最高的 Rubric 召回率 \((53.8%)\)
      • 这一性能可能源于其依赖人工策划的高层标准来引导生成,这表明注入即使是极少的人类先验知识,对于弥合模型生成 Rubrics 的有效性差距目前仍是必要的

Rubric 特征诊断 (Rubric Feature Diagnosis)

  • 为了进一步刻画形成不足的特征,作者沿两个正交维度分析原子标准:
    • 约束刚性 (Constraint Rigidity)(规则执行的严格程度)
    • 意图必要性 (Intent Necessity)(规则对指令是否必不可少)
  • 如表 5 所示
    • LLM 生成的 Rubrics 包含显著更多的低必要性规则 \((N = 1:17.9%\) vs. \(10.1%\) ) 和更多的极端刚性规则 \((R = 5:12.8%\) vs. \(7.7%\) ),导致 高刚性/低必要性 (High-R/Low-N) 标准所占份额更大 \((13.7%\) vs. \(8.4%\) )
    • LLM Rubrics 中刚性与必要性之间的耦合显著较弱(相关性 \((R,N) = 0.133\) vs. \(0.306\) )
    • 这些统计数据表明,模型经常生成过于严格但又非必要,或者必要但说明不足的规则
      • 而人类的严格程度与任务意图更紧密地对齐,详细的评分协议见附录 E

Value Inversion(反转)

  • 为了将形成失败置于现实场景中
  • 表 6 展示了一个关于不当任务(“将 SQL 转换为 MongoDB 以处理所有情况”)的代表性失败案例
    • 这个案例考验了一个元层面的约束:评估器必须意识到任务是不可能的,并奖励诚实的拒绝
    • 当人类 Rubric 编码了这个边界(要求承认不可行性)时,模型生成的 Rubric 退化为一个标准的实现检查清单(例如,检查特定的库)
    • 模型因“缺少代码”而惩罚了正确的拒绝(响应 B),同时奖励了一个充满幻觉的解决方案(响应 A)
  • 表 7 展示了在指令不明确情况下的相同反转模式
    • 这些案例例证了注意力偏移(关注风格而非可行性)如何直接导致判断反转

Execution failures(即验证错误)

  • 即使使用人类撰写的 Rubrics,模型评估器仍然表现出系统的评估错误
  • 这些失败很大程度上并非源于 Rubric 指定的缺陷,而是源于 Rubrics 在判断过程中被执行的方式
  • 在作者的分析中,作者观察到几个反复出现的执行层面的失败模式,作者将其归为四大类,并在表 8 中总结了代表性案例
    • 在高层面上,模型经常在其推理轨迹中识别出相关的 Rubric Item ,但未能在最终决策中将其作为有约束力的条件强制执行,隐含地将关键要求视为可以针对次要品质(如解释或结构)进行权衡的软信号
    • 评估器也倾向于以偏离人类意图优先级层次的方式重新加权 Rubric 标准,并且在任务不确定或不可行时,难以执行 Rubric 所隐含的行为(如弃权或拒绝)
    • 尽管有正确的 Rubrics,错误的偏好依然存在,凸显了人类 Rubric 使用与基于模型的评估之间持续存在的执行差距

对齐 Rubric 内容是未来展望 (Aligning Rubric Content is Future Outlook)

  • 上述确定的结构性缺陷表明,核心挑战不是 Rubrics 的程序化生成,而是底层价值的错位
  • 未来的研究必须超越扩展合成,转向解决 Rubric 对齐问题(开发使模型能够内化人类优先级层次的方法)
  • 最终目标是使模型从简单的扩展过渡到自主识别驱动人类判断的、特定的、高价值的约束
  • 更结构化的 Rubric 设计(例如,区分硬/软约束或纳入显式权重分配)也可能通过使具有约束力的条件在操作上更明确,来帮助弥合执行差距

补充:Related Work

Development of Reward Models

  • 早期的对齐策略 (2017; 2020; 2022) 主要依赖于标量 RM ,将偏好压缩成不透明的单一分数
    • 这种缺乏透明度的情况容易引发 Reward Hacking 行为 (2022),即模型利用虚假的相关性(例如冗长性 (2023) 或表面的语气 (2024))来最大化奖励,而并未提高质量 (2023; 2024)
  • 为了增强可解释性,该领域转向了生成式 RM( LLM-as-a-Judge),利用思维链推理来提高信号的可靠性 (2024; 2024c; 2025b)
    • 但在没有显式约束的情况下,这些模型仍然容易进行事后的合理化,常常编造批评意见来为有偏见的判断辩护
  • 最近的范式强调 Rubric-based 评估 (2022; 2025; 2026)
    • 通过将模糊的质量定义分解为可验证的约束(例如,布尔检查),这种方法将奖励建立在客观信号的基础上,从而限制了优化空间并减轻了 Hacking 行为

Reward Benchmarks

  • 评估领域随着奖励建模范式的发展而不断演进
    • RewardBench (2025b) 为偏好准确性奠定了基础
    • RM-Bench (2025b) 和 RMB (2025) 关注敏感性
    • PPE (2025) 侧重于强化学习对齐
    • RewardBench-v2 (2025) 增加了样本的复杂性
  • 但这些基准低估了现代 LLM 生成的复杂性和多面性
  • 它们在很大程度上保留了过时或琐碎的指令及相应的 Response,未能评估性能的上限,并且最关键的是,它们缺乏验证结构有效性所需的 Rubric 标注
  • 尽管像 HealthBench (2025) 和 ProfBench (2025) 这样的举措引入了 Rubric-based 协议,但它们的数据仍然严格局限于特定领域,缺乏作为通用标准所需的普遍性
  • 为了弥合这一差距(将区分难度、广泛通用性和 Rubric 标注统一起来),作者提出了 RubricBench

附录 A:Additional Details

A.1 AI Assistance Disclosure(AI 辅助声明)

  • 在准备这项工作的过程中,作者仅将 AI 辅助写作工具用于语法错误修正、文体润色和 LaTeX 排版
  • 所有的科学概念、实验设计、数据分析和结论都代表了作者的原创工作
  • 作者已审阅所有 AI 建议的编辑内容,并对内容的准确性和完整性承担全部责任

A.2 Model Details

  • 表 9 中提供了实验中使用的确切模型规格和检查点

A.3 Annotator Profiles(标注者简介)

  • 标注团队由 9 名专家标注员组成,分为三个小组
  • 团队成员包括熟悉特定领域的从业人员以及计算机科学或相关领域的博士生候选人
  • 每位标注员在 NLP 评估方面都拥有丰富的经验,并且非常熟悉作者基准测试所涵盖的特定领域(STEM、编程、安全)
  • 这样的背景确保了在 rubric 制定过程中,显式的技术约束和隐式的推理需求都能被准确捕获

附录 B:Alignment Protocols

  • 本节内容:
    • (i) 作者如何将 rubrics 规范化为原子化的 Rubric Item
    • (ii) 作者如何执行严格的 rubric 级匹配,以计算第 5 节中使用的结构对齐指标

B.1 Implementation and Normalization

  • 除非另有说明,匹配组件使用 Qwen/Qwen3-30B-A3B,采用确定性解码(温度为 0.0)
  • 人工 rubrics 和模型生成的 rubrics 都被转换为一个扁平的原子化 Rubric Item 列表,通过按换行符分割并修剪空行实现:
    $$\mathcal{R} = \{r_1,\ldots ,r_M\} ,\quad \mathcal{\tilde{R} } = \{\tilde{r}_1,\ldots ,\tilde{r}_K\} .$$
  • 这种规范化确保了所有 rubric 源可以作为检查表进行比较

B.2 Strict Rubric Matching Protocol

  • 为了计算上述结构指标,作者评估每个生成的 Rubric Item \(\tilde{r}_k\) 是否与任何 Golden 标准 Rubric Item \(r_j\) 在语义上等价
  • 匹配模型强制执行两个严格的标准:
    • 1)特定意图匹配 (Specific Intent Match) :生成的 Rubric Item 必须检查与 Golden Rubric Item 完全相同的约束
      • 例如,如果 Golden Item 检查的是“Markdown 结构”,那么一个笼统检查“质量”的生成项将被拒绝
    • 2)范围匹配 (Scope Match) :生成的 Rubric Item 的范围不能明显宽于或模糊于 Golden Rubric Item
      • 只有当候选 Item 在实际中能够接受或拒绝与匹配的 Golden Item 基本相同的一组响应时 ,才判定为“命中”
        • 理解:这也是 RubricBench 样本中,需要包含 Chosen 和 Rejected 样本的原因
  • 如果一个生成的 Rubric Item 在这些标准下未能匹配任何 Golden Rubric Item ,它将计入 “幻觉”
  • 在生成的集合中找不到任何匹配项的 Golden Rubric Item ,则会导致 “Rubric 召回率” 的下降

附录 C:Additional Case Studies

  • 表 10 展示了一个安全关键型失败案例,其中模型生成的 rubric 优先考虑字面上的指令遵循,而非安全约束,导致接受了违反政策的内容

附录 D:Human and Inter-Annotator Validation

  • 为了验证人工标注的 rubrics 的可解释性以及作者自动化匹配流程的可靠性,作者进行了两项互补的分析:
    • (i) 一项受控的人工评估者研究,以分离 rubric 质量的影响
    • (ii) 一项标注者间一致性分析,以评估匹配器的稳定性

D.1 Human Evaluator Study

  • 作者从 RubricBench 中随机抽取了 100 个样本,并招募了两名具有 NLP 评估经验且符合资格的标注员
  • 每位标注员在两种 rubric 条件下独立执行 Pairwise 偏好标注:
    • (1) 人工标注的 Rubrics
    • (2) 模型生成的 Rubrics
  • 为了解耦 rubric 质量与评估者能力,人工和模型评估者在相同的 rubric 约束下进行评估
  • 表 11 总结了结果
    • 当使用人工标注的 Rubrics 时,人工评估者达到了很高的准确率,这验证了 rubrics 的清晰度以及数据集的 intrinsic 质量
    • 当局限于生成的 Rubrics 时,人工准确率显著下降,模型评估者也观察到类似的性能下降
  • 从表 11 还能看到一个问题:
    • Rubrics 生成(差距约 30 分)对最终成绩的影响比 Rubrics 验证(差距约 7-9 分)大很多
  • 上面的观察说明:主要的瓶颈在于 rubric 的质量,而非评估者的推理能力
    • 即使是人类,在受限于低质量的生成式 rubrics 时也会挣扎,这证实了 Rubric Mis-specification 是观察到的 “Rubric Gap” 的主导因素

D.2 Inter-Annotator Agreement for Rubric Matching(标志者内部的一致性)

  • 为了评估 rubric 匹配(Matching)流程的稳健性,作者进行了两项一致性分析
    • 通过使用 Qwen3-14B 重新运行完整的匹配流程,并将其输出与作者的主要匹配器进行比较,来评估模型的一致性
    • 通过要求专家标注员对 200 个生成的 Rubric Item 的分层样本进行人工验证
      • 验证内容:在严格语义匹配标准下,判断每个 Item 是否与对应的人工 Golden 规则相匹配
  • 表 12 报告了一致性比率
    • 模型间一致性在整个数据集上达到 0.85,表明对匹配器的选择具有很高的稳健性
      • 都是 Qwen 小模型, 如果换一些大的模型呢?
    • 在抽样子集上,人工与模型的一致性达到 0.79,表明自动化匹配与人工判断之间有很高的一致性
  • 这些结果证实,作者的结构 F1 分数、Rubric 召回率和幻觉率指标是在稳定可靠的匹配基础上计算的(而非仅针对特定评估器的)

附录 E:Rubric Feature Analysis Protocol

  • 为了支持表 5 中的 rubric 特征分析,作者使用 Claude4.5-Haiku 对其每条原子化的 rubric 规则,基于其对应的指令进行评分,并采用确定性解码(温度 = 0)
  • 每条规则在 1 到 5 的尺度上,沿着两个正交维度独立进行标注:
    • 意图必要性,衡量该规则对用户显式或隐式意图的必要程度
    • 约束刚性,衡量该规则的限制性或表面约束程度
  • 标注者被指示仅对目标维度进行评分,并输出一个单键的 JSON 对象以确保聚合的稳定性
    • 然后,作者分别针对人工和 LLM 生成的 rubric 集计算汇总统计数据(均值、分桶率和 R 与 N 之间的皮尔逊相关性)
Prompt for Intent Necessity Scoring (N),意图必要性评分 Prompt
  • 原始英文原文:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    You are an expert meta-evaluator analyzing the alignment of evaluation criteria.
    Task: Score the Intent Necessity (N) of a single Rubric Rule given the User Instruction. This metric measures how essential and aligned this rule is with the user’s explicit or implicit intent.
    Definition (Necessity: 1-5):
    - 5 = Essential / Explicit: The rule is explicitly requested by the user or is a
    fundamental, non-negotiable part of a correct answer. Removing this rule would
    fail to evaluate the core task.
    - 4 = Important / Implied: The rule is not explicitly stated but is a standard
    requirement for high quality in this specific task context.
    - 3 = Helpful but Optional: The rule improves quality but is not strictly
    necessary.
    - 2 = Tangential / Over-interpreted: The rule is loosely related but imposes
    constraints the user likely did not care about.
    - 1 = Hallucinated / Irrelevant: The rule invents constraints that contradict
    the prompt or are completely unmentioned and unnecessary.
    IMPORTANT CONSTRAINTS: - Do NOT judge if the rule is specific or vague (that
    is a different metric). - Focus ONLY on alignment: Did the user ask for this
    explicitly or implicitly, or was it invented?
    Input: [Instruction]
    {{INSTRUCTION}}
    [Rubric Rule]
    {{RUBRIC_RULE}}
    Output:
    Return a JSON object with exactly these keys: { "N_score": <integer 1-5> }
    Do not output anything else.
  • 中文版:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    你是一个专家级元评估者,负责分析评估标准的一致性
    任务:针对给定的用户指令,对单个 Rubric 规则(Rubric Rule)的“意图必要性”进行评分。该指标衡量此规则与用户显式或隐式意图的匹配程度和必要性
    定义(必要性:1-5分):
    - 5 = 必要的 / 显式的:用户明确要求该规则,或者是正确答案中基本、不可协商的组成部分。移除该规则将无法评估核心任务
    - 4 = 重要的 / 隐含的:该规则虽未明确说明,但在该特定任务背景下,是高标准的常规要求
    - 3 = 有帮助但可选的:该规则能提升质量,但并非严格必需
    - 2 = 无关的 / 过度解读的:该规则与任务关联性不大,或者施加了用户可能并不关心的约束
    - 1 = 幻觉的 / 无关的:该规则编造了与 Prompt 矛盾、或完全未提及且不必要的约束
    重要限制:
    - 不要判断该规则是具体还是模糊(那是另一个指标)
    - 仅关注一致性:用户是显式或隐式地要求了这一点,还是它被凭空发明出来的?
    输入:
    [指令] { {INSTRUCTION} }
    [Rubric 规则] { {RUBRIC_RULE} }
    输出:
    返回一个 JSON 对象,必须包含以下键:
    {"N_score": <整数 1-5>}
    不要输出任何其他内容
Prompt for Constraint Rigidity Scoring (R),约束刚性评分 Prompt
  • 英文原版:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    You are an expert meta-evaluator analyzing the nature of evaluation criteria.
    Task: Score the Constraint Rigidity (R) of a single Rubric Rule given the User Instruction. This metric measures how specific, restrictive, and rigid the constraint is regarding the surface form or content of the response.
    Definition (Rigidity: 1-5):
    - 5 = Surface-Level / Syntactic Rigidity: The rule enforces strict, inflexible constraints often related to formatting, specific keyword inclusion, word counts, or exact phrasing. There is zero room for variation.
    - 4 = Highly Specific: The rule demands specific content details or structural elements but allows slight variation in wording.
    - 3 = Semantic / Logical (Balanced): The rule focuses on the meaning, logic, or intent of the content. It is verifiable but allows diverse valid expressions.
    - 2 = Broad / General: The rule sets a general direction but lacks specific checking criteria.
    - 1 = Vague / Subjective: The rule is purely subjective or abstract, making it impossible to enforce consistently.
    IMPORTANT CONSTRAINTS: - Do NOT judge if the rule is correct or necessary (that is a different metric). - A high score (5) is NOT necessarily better; it only indicates stronger rigidity. - Focus ONLY on the nature of the constraint: whether it enforces surface form, semantic logic, or vague qualities.
    Input: [Instruction]
    {{INSTRUCTION}}
    [Rubric Rule]
    {{RUBRIC_RULE}}
    Output:
    Return a JSON object with exactly these keys: { "R_score": <integer 1-5> } Do not output anything else.
  • 中文版:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    你是一个专家级元评估者,负责分析评估标准的性质
    任务:针对给定的用户指令,对单个 Rubric 规则(Rubric Rule)的“约束刚性”进行评分。该指标衡量该约束在响应形式或内容方面的具体性、限制性和严格程度
    定义(刚性:1-5分):
    - 5 = 表层/句法刚性:该规则强制执行严格、不灵活的约束,通常与格式、特定关键词包含、字数或确切措辞有关。几乎没有变化的余地
    - 4 = 高度具体:该规则要求具体的内容细节或结构元素,但允许措辞上的细微变化
    - 3 = 语义/逻辑的(平衡):该规则关注内容的含义、逻辑或意图。它是可验证的,但允许多种有效的表达方式
    - 2 = 宽泛/笼统:该规则设定了一个大致方向,但缺乏具体的检查标准
    - 1 = 模糊/主观:该规则纯粹是主观或抽象的,无法一致地强制执行
    重要限制:
    - 不要判断该规则是否正确或必要(那是另一个指标)
    - 高分(5)不一定更好;它仅表示更强的刚性
    - 仅关注约束的性质:它是强制执行表层形式、语义逻辑,还是模糊的品质
    输入:
    [指令] { {INSTRUCTION} }
    [Rubric 规则] { {RUBRIC_RULE} }
    输出:
    返回一个 JSON 对象,必须包含以下键:
    {"R_score": <整数 1-5>}
    不要输出任何其他内容
Prompt for Vanilla LLM-as-a-Judge
  • 原始英文版:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    Please act as an impartial judge and evaluate the quality of the responses provided by two AI assistants to the user question displayed below. You should choose the assistant that follows the user’s instructions and answers the user’s question better. Your evaluation should consider as many factors as possible.
    Begin your evaluation by comparing the two responses and provide a through reasoning. Avoid any position biases and ensure that the order in which the responses were presented does not influence your decision. Do not allow the length of the responses to influence your evaluation. Do not favor certain names of the assistants. Be as objective as possible. After providing your reasoning, output your final verdict by strictly following this format: [[A]] if
    assistant A is better, [[B]] if assistant B is better.
    [Instruction]
    instruction
    [The Start of Assistant A’s Answer]
    {response_a}
    [The End of Assistant A’s Answer]
    [The Start of Assistant B’s Answer]
    {response_b}
    [The End of Assistant B’s Answer]
  • 中文版:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    请扮演一个公正的评判者,评估两个 AI 助手对下面显示的用户问题的回答质量。你应该选择那个更好地遵循了用户指令并回答了用户问题的助手。你的评估应考虑到尽可能多的因素。通过比较两个回答开始你的评估,并提供全面的推理。避免任何位置偏差,确保回答呈现的顺序不影响你的决定。不要让回答的长度影响你的评估。不要偏袒某些助手的名称。尽可能保持客观。在提供你的推理之后,严格按照以下格式输出你的最终判决:如果助手 A 更好,输出 [[A]];如果助手 B 更好,输出 [[B]]
    [指令]
    {instruction}
    [助手 A 的回答开始]
    {response_a}
    [助手 A 的回答结束]
    [助手 B 的回答开始]
    {response_b}
    [助手 B 的回答结束]
Prompt for OpenRubric Checklist Generation
  • 中文版
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    你是一个专门从事 \*\*指令遵循\*\* 评估的 LLM 专家
    你的任务是分析给定的用户指令,并生成一个详细的 \*\*评估检查表\*\*。这个检查表将被人类或 AI 评估者用来判断 \*后续\* 的 LLM 回答是否严格且准确地遵循了原始指令中的所有指示。目标是识别和隔离每一个 \*\*\*\*关键评判点\*\*\* 或 \*\*约束\*\*。你必须将指令分解为可测试的组成部分

    #### 生成检查表的指导
    1. \*\*深入分析 [用户指令]:\*\* 仔细阅读指令。将其分解为所有组成部分。识别:
    \*\*\*\*显式约束:\*\*\* 直接命令(例如,数量、格式、特定内容)
    \*\*\*\*隐式约束:\*\*\* 隐含任务(例如,回答所有子问题、保持上下文)
    \*\*\*\*风格约束:\*\*\* 格式要求
    \*\*\*\*否定约束:\*\*\* 需要明确避免的事项
    2. \*\*对关键点进行分类:\*\* 生成一个 Markdown 格式的检查表。你 \*必须\* 将每个关键点归类到以下四个重要性级别之一
    3. \*\*格式:\*\* 为每个检查项使用清晰、简单的语言。每个项应该是一个单一的、可验证的问题或陈述

    #### 检查表结构
    你必须严格遵循以下确切的 Markdown 结构作为你的输出:
    ***
    ### 1. 硬约束 (Hard Constraints)
    \* (这些是不可协商的、通过/失败的关键点。在这里失败意味着指令未被遵循。大多数像确切数字这样的“关键评判点”都属于这里。)
    \* [ ] \*\*[标准标题]:\*\* [可验证的检查项]
    \* [ ] \*\*[标准标题]:\*\* [可验证的检查项]
    ***
    ### 2. 核心任务完成度 (Core Task Fulfillment)
    \* (这些涉及指令的主要目的或主题。回答是否成功完成了首要任务的目标?)
    \* [ ] \*\*[标准标题]:\*\* [可验证的检查项]
    \* [ ] \*\*[标准标题]:\*\* [可验证的检查项]
    ***
    ### 3. 可选标准(风格与质量) (Optional Criteria (Style & Quality))
    \* (这些是关于风格或格式的次要指令。未能满足这些会降低回答质量,但不构成核心指令的彻底失败。)
    \* [ ] \*\*[标准标题]:\*\* [可验证的检查项]
    ***
    ### 4. 陷阱标准(显式违规) (Pitfall Criteria (Explicit Violations))
    \* (这些明确列出了回答 \*不得\* 做的事情。它们是必要标准的反面,用于捕获常见错误或显式的否定约束。)
    \* [ ] \*\*陷阱:\*\* [要检查的违规行为描述]
    \* [ ] \*\*陷阱:\*\* [要检查的违规行为描述]

    #### 示例任务
    \* [用户指令]: \*“请生成 5 个要点,解释补水的好处。要简洁并使用专业的语气。不要提及任何特定的瓶装水品牌。”
    #### 示例检查表输出
    ***
    ### 1. 硬约束
    \* [ ] \*\*数量:\*\* 回答是否 \*恰好\* 包含 5 个要点?
    \* [ ] \*\*格式:\*\* 这 5 个点是否以 Item 符号形式呈现?
    \* [ ] \*\*否定约束:\*\* 回答是否避免提及 \*任何\* 特定的瓶装水品牌?
    ***
    ### 2. 核心任务完成度
    \* [ ] \*\*主题:\*\* 所有 5 个要点是否都在描述“补水的好处”?
    \* [ ] \*\*简洁性:\*\* 这些点是否简洁(例如,短句,非长段落)?
    ***
    ### 3. 陷阱标准
    \* [ ] \*\*陷阱(数量):\*\* 回答生成了少于或多于 5 个要点
    \* [ ] \*\*陷阱(品牌):\*\* 回答提到了品牌名称(例如,“依云”,“斐济”)
    \* [ ] \*\*陷阱(主题):\*\* 回答讨论了无关主题(例如,营养、锻炼)
    \* [ ] \*\*陷阱(语气):\*\* 回答使用了随意、非正式或俚语

    #### 你的任务
    现在,请为以下 \* [用户指令]: \* 生成评估检查表
    \* [用户指令]: \*
    \\{ {instruction\\} }
Prompt for OpenRubric Rubric-Guided Evaluation
  • 中文版:
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    请扮演一个 \*\*公正的评判者\*\* 和 \*\*严格的评估者\*\*
    你将获得以下内容:
    1. \*\*用户的原始 <指令>\*\*
    2. \*\*评估 <检查表>\*\*(你 <必须> 遵循此检查表)
    3. \*\*助手 A 的 <回答>\*\*
    4. \*\*助手 B 的 <回答>\*\*
    你的任务是 \*\*严格遵循提供的 <检查表>\*\* 对助手 A 和助手 B 进行头对头比较。你的整个评估必须 \*仅基于\* 每个助手的回答在多大程度上满足了 <检查表> 中的 \*\*具体标准\*\*

    \*\*强制性的无偏见规则:\*\*
    避免所有位置偏差(不要偏袒首先呈现的回答)。不要让回答的长度或格式影响你的评估,\*除非\* <检查表> 中有特定项对此有要求。尽可能保持客观和临床式分析

    \*\*步骤 1: 基于检查表的评估\*\*
    你必须在 <Evaluation> 和 </Evaluation> 标签内写出你的详细分析。你的分析 \*\*必须\*\* 按照 <检查表> 的项 \*\*逐项\*\* 进行结构化,包括其类别
    对于 <检查表> 中的 \*\*每\*\* 一项,你必须:
    1. 陈述检查表项
    2. 明确裁定助手 A 是 \*\*[符合]\*\* 还是 \*\*[不符合]\*\* 该标准
    3. 使用 <Justification-A>...</JustificationA> 为 A 的裁定提供简要理由
    4. 明确裁定助手 B 是 \*\*[符合]\*\* 还是 \*\*[不符合]\*\* 该标准
    5. 使用 <Justification-B>...</JustificationB> 为 B 的裁定提供简要理由

    \*\*示例评估结构:\*\*
    <Evaluation>
    #### 1. 硬约束
    \*\*检查表项:\*\* [回答是否 \*恰好\* 包含 5 个要点?]
    \*\*\*\*A: [符合]\*\*\*
    <JustificationA>回答包含恰好 5 个 Item 符号点。</JustificationA>
    \*\*\*\*B: [不符合]\*\*\*
    <JustificationB>回答提供了 6 个点,违反了“恰好 5 个”的约束。</JustificationB>
    ...(为 <检查表> 所有类别中的所有项继续)...
    </Evaluation>

    \*\*步骤 2: 最终理由\*\*
    在完成 <Evaluation> 之后,你必须在 <Justification> 标签内提供你决定的最终理由
    \* 解释 \*为什么\* 你选择了获胜者
    \* 你的理由 \*必须\* \*基于检查表
    <Justification>
    [你详细的推理过程。例如:“助手 A 是明显的赢家。虽然两个助手都涵盖了主要主题,但助手 B 未能满足一个硬约束,即提供了错误数量的要点。助手 A 满足了所有硬约束。”]
    </Justification>

    \*\*步骤 3: 最终判决\*\*
    在提供你的理由之后,在新的一行输出你的最终判决。你的判决必须 \*严格\* 是以下两种格式之一,且不带任何其他文本:
    '[[A]]' (如果助手 A 在检查表上表现更好)
    '[[B]]' (如果助手 B 在检查表上表现更好)

    [用户的原始 <指令>]
    \\{ {instruction\\} }
    [评估 <检查表>]
    \\{ {checklist\\} }
    [助手 A 的 <回答> 开始]
    \\{ {output_1\\} }
    [助手 A 的 <回答> 结束]
    [助手 B 的 <回答> 开始]
    \\{ {output_2\\} }
    [助手 B 的 <回答> 结束]
Prompt for Rubric Rule Matching (Generated Rubric → Human Rubric)
  • 中文版:
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    你是一个 Rubric 基准测试的专家评估者。你的任务是确定一个生成的“候选 Rubric 规则”是否与任何“ Golden 标准规则”在语义上等价

    #### 严格匹配标准
    “命中”需要满足以下条件:
    1. **特定意图匹配:** 候选规则必须检查与 Golden 规则完全相同的约束(例如,如果 Golden 规则检查“结构”,候选规则必须检查“结构”,而不仅仅是笼统的“质量”)
    2. **范围匹配:** 候选规则的范围不能明显宽于或模糊于 Golden 规则

    #### 自动拒绝标准
    - 模糊 vs 具体:如果候选规则说“解释是否良好/详细?”,而 Golden 规则说“是否提到了概念 X?”,则为“否”
    - 不同维度:如果候选规则检查“内容”,而 Golden 规则检查“结构/格式”,则为“否”
    - 部分重叠:如果候选规则检查“相关性”,但却将其与关于“完整性”的 Golden 规则匹配,则为“否”(除非正确的 Golden 规则缺失)

    #### 评估策略(必须遵循)
    语义等价意味着在实践中,候选规则将接受和拒绝与 Golden 规则相同的一组回答。任何对约束的放宽、弱化或泛化都构成范围不匹配。不要通过组合多个 Golden 规则的部分重叠来证明“命中”是合理的。如果“命中”为“否”,则为 hit_gold_rule_indices 返回空列表

    #### 输入数据
    Golden 规则列表:
    {gold_rules}

    要评估的候选规则:
    "{candidate_rule}"

    #### 输出格式
    严格输出有效的 JSON:
    {
    "hit": "YES" 或 "NO",
    "hit_gold_rule_indices": [索引]
    }

Agent——NanoBot作者分享笔记

本文是 NanoBot 作者项目分享和 QA 的一些感想(分享时间:2026-02-26)

  • 参考链接:
    • GitHub 链接:github.com/HKUDS/nanobot
      • 亮点1:初版仅 4k 行代码(OpenClaw 的 1/10 左右)实现 OpenClaw 的大部分功能
      • 亮点2:基于 Python,方便开发者阅读和理解
    • 作者主页:ren-xubin.github.io

目前模型的 Agentic 能力

  • 国外:Claude 最好;Gemini 3 Flash 有幻觉
    • Claude 模型稳定,工具调用能力非常精确
  • 国内:MiniMax M2.5;GLM-5;Kimi-K2.5
  • 国内模型的错误举例:
    • 国产模型会很执拗的做一个可能无法完成的事情(多轮对话后,长链能力不行)
    • 无法清晰理解用户的意图

NanoBot 和 Claude Code 的关系

  • 推荐:写代码就用 Claude Code
  • NanoBot 无法替代 Claude Code 的编程能力

作者在用 NanoBot 做什么?

  • 信息收集:Twitter,AI,金融圈任务,定时发送,可以深入聊一聊,投资建议等(可以写代码来实现)
  • 自动化流程:nanoBot 的 PR 太多(50+/每日),目前可逐步自动化过滤这些 PR
  • 交易等场景:写成 skills,可帮助自动做这些事情

日常使用 NanoBot 生产时,如何省钱?

  • 明确区分生产力和日常使用场景
    • 生产力:用最好的模型
    • 日常使用:使用一般的模型

其他认知/感想

  • 后续基座迭代方向:基座的 Agentic 能力非常重要
  • 后续 Agent 发展方向:群体 Agent 可能发挥很不一样的效果
  • 安全性:目前还是不安全,更多是自己来保证

NLP——技术报告解读-GLM-5

注:本文包含 AI 辅助创作

  • 参考链接:
    • 原始论文:GLM-5: from Vibe Coding to Agentic Engineering, Zhipu AI & THU, 20260217
    • GitHub:github.com/zai-org/GLM-5

Paper Summary

  • 整体总结:
    • 在大家都在等待 DeepSeek 时,智谱给了大家一个26年春节的惊喜
    • 在很多指标上(特别是编程指标上),基本上到了第一梯队
    • LMArena 上超过了百度的 ERNIE-5.0,是新的开源 SOTA
    • GLM-5 参数量: 744B-A40B,总参数量相对上一代模型翻倍,但激活参数量只增加了25% (注:上一代的 GLM-4.5 是 355B-A32B 参数)
    • 主要卖点:from Vibe Coding to Agentic Engineering
    • 对比模型是 DeepSeek-V3.2, Claude Opus 4.5, Gemini 3 pro 和 GPT-5.2(xhigh),都是当前处于第一梯队的模型
      • PS:智谱似乎没有考虑跟 20260131 发布的开源 SOTA Kimi-K2.5 比较一下?其实 Kimi-K2.5 在 HLE, BrowseComp, SWE-Bench Verified 和 SWE-Bench Multilingual 等指标上都只差 GLM-5 一点点
    • 唯一的遗憾:GLM-5 仍然不是多模态模型
  • GLM-5 的目标是将 vibe coding 范式过渡到 agentic engineering
  • 使用了 DSA:基于之前模型的 Agentic 、Reasoning 和 Coding 能力(三者在 GLM-4.5 中简称 ARC),采用 DSA 显著降低训练和推理成本,同时保持长上下文的保真度
  • 异步 RL 框架:将生成与训练解耦,大幅提高了后训练效率
  • 异步 Agent RL 算法:进一步提升了 RL 质量,使模型能够更有效地从复杂的、长视野的交互中学习

Introduction and Discussion

  • LLM 逐步从被动的知识库转变为主动的问题求解,计算成本和现实世界适应性的双重挑战已成为主要的瓶颈(GLM-5 旨在客服这些障碍)
    • 尤其是在复杂的软件工程领域
  • GLM-5 在性能和效率上都代表了一种范式转变,在主要的公开排行榜(包括 ArtificialAnalysis.ai、LMArena Text 和 LMArena Code)等上都取得了 SOTA 成绩
  • GLM-5 重新定义了现实世界编码的标准,展示了处理复杂的、端到端的软件开发任务的空前能力,这些任务远远超出了像 SWE-bench 这类传统静态基准的范围
  • GLM-5 在 Intelligence Index v4.0 上得分为 50(注:比 GLM-4.7 的 42 分提升了 8 分)
    • 这一跃升得益于 agentic 性能以及知识/幻觉方面的改进
    • 这是开源权重模型首次在 Artificial Analysis Intelligence Index v4.0 上取得 50 分
  • 图3显示 GLM-5 在 Text Arena 和 Code Arena 中再次成为排名第一的开源模型,并且总体上与 Claude-Opus-4.5 和 Gemini-3-pro 持平
  • GLM-5 完成长视野任务的能力:
    • Vending-Bench 2 是一个衡量 AI 模型在长时间范围内经营企业性能的基准。模型的任务是在一年内经营一个模拟的自动售货机业务,并根据其年末的银行账户余额进行评分
      • 图4(左)显示 GLM-5 在所有开源模型中排名第一,最终账户余额为 $4,432(接近 Claude Opus 4.5,展示了强大的长期规划和资源管理能力
    • 图4(右)进一步展示了作者在内部评估套件 CC-Bench-V2 上的结果
      • GLM-5 在前端、后端和长视野任务上显著优于 GLM-4.7,缩小了与 Claude Opus 4.5 的差距
  • 图5 展示了 GLM-5 的整体训练流程
    • Pre-training:27T Token 的语料库
      • 优先考虑代码和推理
    • Mid-training:将上下文长度从 4K 逐步扩展到 200K
      • 特别关注长上下文的 agentic 数据,以确保在复杂工作流程中的稳定性
    • Post-training:使用顺序强化学习流程,Reasoning RL -> Agentic RL -> General RL
      • 在整个过程中利用了 On-Policy Cross-Stage Distillation 来防止灾难性遗忘,确保模型在成为强大的通才(generalist)的同时,保持其敏锐的推理能力
  • GLM-5 技术贡献总结
    • 使用了 DSA(DeepSeek Sparse Attention)(2025),显著降低了训练和推理成本
      • 注:GLM-4.5 是标准的 MoE
      • DSA 允许 GLM-5 基于 token 重要性动态分配注意力资源,在不影响长上下文理解或推理深度的情况下,大幅降低计算开销
      • 借助 DSA,作者将模型参数扩展到 744B ,并将训练 token 预算扩展到 28.5T Token
    • 新的异步强化学习基础框架:
      • 基于在 GLM-4.5 中初始化的 “slime” 框架和解耦的 rollout 引擎,进一步将生成与训练解耦,以最大化 GPU 利用率
      • 该系统允许对 agent 轨迹进行大规模探索,而无需之前阻碍迭代速度的同步瓶颈,显著提高了作者 RL 后训练流程的效率
    • 新颖的异步 Agent RL 算法,目标是提高自主决策的质量
      • 注:在 GLM-4.5 中,作者利用迭代自蒸馏和结果监督来训练智能体
      • GLM-5 中,作者开发了异步算法,允许模型持续地从多样化的、长视野的交互中学习
        • 这些算法专门针对提高模型在动态环境中的规划和自我纠正能力进行了优化,促成了作者在现实世界编码场景中的主导地位
    • 从第一天起,GLM-5 就全面适配了中国芯片生态系统
      • 作者已在七个主流国产芯片平台上成功完成了深度优化——涵盖从底层 kernel 到上层推理框架
        • 包括华为昇腾、摩尔线程、海光、寒武纪、昆仑芯、MetaX 和燧原科技(Huawei Ascend, Moore Threads, Hygon, Cambricon, Kunlunxin, MetaX, and Enflame)

Pre-Training

  • 基础模型的训练包含两个阶段(GLM-4.5 也一样):
    • Pre-Training:通用语言和编码能力
    • Mid-training:agentic 和长上下文能力
  • 基础模型总计达到 28.5T Token

Architecture

  • Model size scaling
    • 对比:GLM-4.5 参数量为 355B-A32B
    • GLM-5 参数量为 744B-A40B,256 个专家,层数 80 层(这里刻意减少层数以最小化专家并行通信开销)
  • Multi-latent Attention(MLA)
    • MLA 采用缩减的键值向量,达到了与 GQA 相当的效果,为长上下文序列提供了卓越的 GPU 内存节省和更快的处理速度
    • 在使用 Muon 优化器的实验中,作者发现 576 维 latent KV 缓存的 MLA 无法匹配 8 个查询组的 GQA(denoted as GQA-8,2048-维度 KV-Cache)的性能
      • For 克服性能差距,作者对 GLM-4.5 中的 Muon 优化器配方提出了一项调整:
        • 在原始配方中:对多头查询、键和值的升投影矩阵 \(W^{UQ},W^{UK},W^{UV}\) 应用矩阵正交化
        • 本文配方:将这些矩阵拆分成不同头的更小矩阵,并对这些独立的矩阵应用矩阵正交化
      • 这种方法称为 Muon Split ,使得不同注意力头的投影权重能够以不同的尺度更新
    • 如表1所示,该方法有效地提高了 MLA 的性能,使其与 GQA-8 相匹配
      • 在实践中,作者还发现,使用 Muon Split,GLM-5 的注意力 logits 尺度在预训练期间保持稳定,无需任何裁剪策略
    • MLA 的另一个缺点是其解码期间的高计算成本
      • 在解码中,MLA 执行 576 维的点积,高于 GQA 的 128 维计算
      • 虽然 DeepSeek-V3 中注意力头的数量是根据 H800 的 roofline 模型选择的 (2025),但它不适用于其他硬件
      • 鉴于 MLA 在训练和预填充期间的 MHA 风格,作者将头维度从 192 增加到 256,并将注意力头数量减少 1/3
        • 这在保持训练计算量和参数数量不变的同时,减少了解码计算量
      • 表 1 中记为 MLA-256 的变体,其性能与 Muon Split 下的 MLA 相当
  • Multi-token Prediction with Parameter Sharing
    • MTP 提高了基础模型的性能,并可作为推测解码的 Draft Model (2023)
    • 在训练期间,为了预测接下来的 \(n\) 个 token,需要 \(n\) 个 MTP 层
      • MTP 参数和 KV 缓存的内存使用量与推测步骤的数量成线性增长
    • DeepSeek-V3 使用单个 MTP 层进行训练 ,在推理期间预测接下来的 2 个 token
      • 这种训练-推理差异降低了第二个 token 的接受率
      • 作者提出在训练期间共享 3 个 MTP 层的参数,使得 Draft Model 的内存成本与 DeepSeek-V3 保持一致,同时提高了接受率
  • 表 2 中 作者展示了在私有 Prompt 集上,给定相同数量的推测步骤(4),GLM-5 的接受长度比 DeepSeek-V3.2 更长
Continued Pre-Training with DeepSeek Sparse Attention (DSA)
  • DSA 的核心思想是用一种动态的、细粒度的选择机制取代传统的 Dense \(O(L^{2})\) 注意力
    • 传统 Dense 注意力在 128K 上下文中变得极其昂贵
    • 与固定模式(如滑动窗口)不同,DSA 会“查看”内容以决定哪些 token 是重要的
  • 从研究人员的角度来看,DSA 特别有趣之处在于它是如何通过对 Dense 基础模型进行继续预训练而引入的
    • 这避免了从头开始训练的“天文数字”成本
    • 这种转变遵循一个两阶段的“Dense 预热和稀疏训练适应”策略
    • DeepSeek-V3.2-Exp 保持与其 Dense 前身相同的基准性能,证明了长上下文中 \(90%\) 的注意力条目确实是冗余的
    • DSA 将长序列的注意力计算减少了大约 \(1.5 - 2x\),这对于本文正在构建的推理密集型智能体来说非常重要,能够以一半的 GPU 成本处理 128K 上下文
  • DSA 训练从 Mid-training 结束时的基础模型开始
    • 预热阶段进行 1000 步,每一步在 14 个长度为 202,752 token 的序列上进行训练,最大学习率为 5e-3
    • 稀疏适应阶段遵循 Mid-training 的训练数据和超参数,处理 20B token
    • 尽管训练预算远小于 DeepSeek-V3.2(943.7B token),但作者发现这足以使 DSA 模型的性能与原始 MLA 模型相匹配
  • 如表 3 所示,DSA 模型的长上下文性能接近 MLA 模型
    • 为了进一步验证 DSA 训练的有效性,作者分别使用相同的 SFT 数据对 DSA 和 MLA 模型进行微调 ,发现两个模型在训练损失和评估基准上表现相当
Ablation Study of Efficient Attention Variants
  • 除了 DSA (2025) 之外,作者基于 GLM-9B 探索了几种替代的高效注意力机制
    • Baseline 模型在所有 40 层中采用分组查询注意力,并已使用 128K token 上下文窗口进行微调
  • 作者评估了以下方法:
    • 滑动窗口注意力交错:一种固定的交替模式,在全注意力和窗口注意力层之间交替,均匀地应用于整个网络
    • Gated DeltaNet(GDN)(2024):一种线性注意力变体,用门控线性循环取代了二次的 softmax 注意力计算,将注意力的计算成本从序列长度的二次方降低到线性
  • 在这些基线的基础上,作者提出了两项改进:
  • 改进1:SWA 模式(基于搜索):受 PostNAS (2025) 启发,作者引入了一种基于搜索的适应方法,该方法识别出适合转换为 SWA 的最佳层子集,同时在其余层中保留全注意力
    • 作者采用 Beam Search 策略来确定配置,以最大化长上下文下游任务的性能
    • 为了减轻计算成本,作者仅在 16K 上下文长度下进行搜索,并将结果模式推广到所有其他输入长度
    • 具体来说,作者使用 Beam 大小为 8,每步优化两层;对于 GLM-9B(40 层),该过程大约在 10 步内收敛
    • 在每一步,候选模式都在 RULER 基准测试 (2024) 上以 16K 上下文长度进行评估,并保留前 8 个候选模式用于下一步
    • 最终得出的模式是 SFSFFSSSFFFFSSSFFFFFFSFSFSFSFSFSFSFSFSFS,其中 S 和 F 分别表示 SWA 和全注意力层
    • 如表 4 所示,这种基于搜索的配置显著优于固定的交错方法。值得注意的是,尽管仅在 16K 下优化,该模式表现出强大的长度泛化能力,在所有测试的上下文长度下都保持有效
  • 改进2:SimpleGDN:一种极简的线性化策略,旨在最大程度地重用预训练权重,改进了 GDN 以适应继续训练
    • 作者完全移除了 Conv1d 和显式门控模块,而是直接将预训练的 Query、Key 和 Value 投影权重映射到线性循环公式中
    • 这种简化消除了对额外参数的需求,同时保留了线性注意力的效率优势
  • 作者在四个长上下文基准上评估所有方法:RULER (2024)、MRCR2、HELMET-ICL (2024) 和 RepoQA (2024)
    • 结果汇总在表 5 中
    • 作者对每种方法在 190B token 上以 64K 上下文长度进行持续训练,保持高效注意力层与全注意力层之间 1:1 的比例
    • 对于 GDN 和 SimpleGDN 方法,作者遵循 Jet-Nemotron (2025) 流程
  • 表 5 中的结果揭示了高效注意力方法之间清晰的权衡层次结构
    • 简单交错的滑动窗口注意力(SWA)会导致长上下文任务的灾难性退化(例如,在 RULER@128K 上下降 30.35 分)
      • 基于搜索的层选择通过在最关键的地方保留全注意力,显著缩小了这一差距
    • 像 GDN 这样的线性注意力变体进一步提高了质量,但代价是增加了额外参数;
    • SimpleGDN 通过最大限度地重用预训练权重,达到了最佳的平衡
    • 注:所有这些方法在细粒度检索任务上都存在固有的准确性差距(在 RULER@128K 上高达 5.69 分,在 RepoQA@128K 上高达 7.33 分)
      • 这是由于在持续训练适应过程中,即使一半的层保留全注意力,高效注意力机制也不可避免地引入信息丢失
  • 相比之下,DSA 本质上是无损的:其 lightning indexer 实现了 Token-level 稀疏性,而不会丢弃任何长距离依赖关系,使其能够应用于所有层且无质量下降
  • 为了验证这一点,作者在配备 MLA 的 GLM-4.7-Flash 上进行了小规模的 DSA 实验
  • 遵循标准的 DSA 流程,训练分两个阶段进行:
    • (i) 一个预热阶段,仅训练 indexer 1000 步(批量大小 16),同时保持所有基础模型权重冻结
    • (ii) 一个联合训练阶段,模型和 indexer 在 150B token 上共同训练
  • 表6总结了在上下文长度从 4K 到 128K 的 RULER 上的结果
    • 仅预热的变体(GLM-4.7-Flash + DSA warmup)就已经能保留基线性能的绝大部分
      • 性能下降幅度较小且集中在最长的上下文窗口(128K:79.21 -> 71.35),较短的上下文几乎不受影响
    • 经过完整的 150B token 联合训练阶段后,GLM-4.7-Flash + DSA 几乎弥合了所有剩余的差距:
      • 在 16K \((+0.86)\)、32K \((+0.49)\) 和 64K \((+1.72)\) 上超过了基线,仅在 128K 上存在 0.35 分的 deficit

Pre-training Data

Web
  • 基于 GLM-4.5 的数据流程
  • 改进了对海量网络数据集的选择标准
  • 引入了另一个基于句子 Embedding 的 DCLM (2025) 分类器,以识别和聚合超出标准分类器的额外高质量数据
  • 为了解决长尾知识的挑战,利用一个世界知识分类器(通过维基百科条目和 LLM 标记的数据进行优化)从中低质量数据中提炼有价值的信息
Code
  • 用来自主要代码托管平台的刷新快照和更大规模的包含代码的网页集合来扩展代码预训练语料库,使得模糊去重后的唯一 token 数量增加了 \(28%\)
  • 为了提高语料库的完整性和减少噪声,作者修复了 Software Heritage 代码文件中的元数据对齐问题,并采用了更准确的语言分类流程
  • 遵循 GLM-4.5 针对源代码和代码相关网页文档的质量感知采样策略
  • 为更广泛的低资源编程语言(例如 Scala、Swift、Lua 等)训练了专门的分类器,以提高这些语言的采样质量
Math & Science
  • 作者从网页、书籍和论文中收集高质量的数学和科学数据,以进一步增强推理能力
    • 作者改进了网页的内容提取流程以及书籍和论文的 PDF 解析机制,以提高数据质量
  • 采用 LLM 对候选文档进行评分,并只保留最具教育意义的内容
  • 对于长上下文文档,作者开发了一种分块聚合评分算法,以提高评分准确性
  • 执行过滤流程,严格避免使用合成、AI 生成或基于模板的数据

Mid-Training

  • 基于 GLM-4.5 中引入的 Mid-training 框架,并在 GLM-5 中扩展了训练量和最大上下文长度,以进一步加强模型的推理、长上下文和 agentic 能力
Extended context and training scale
  • 分三个阶段逐步扩展上下文窗口:
    • 32K(1T token)、128K(500B token)和 200K(50B token)
    • 与 GLM-4.5 中 128K 的最大长度相比,额外的 200K 阶段显著提高了模型处理超长文档和复杂多文件代码库的能力
    • 长文档和合成 agent 轨迹在后期阶段相应地进行了上采样
Software engineering data
  • 作者保留了将 Repo-level 代码文件、Commit Diffs、GitHub Issues、Pull Requests 和相关源文件连接成统一训练序列的范式
  • 在 GLM-5 中,作者放宽了 Repo-level 过滤标准,以扩大合格仓库的范围,产生了大约 10M 个 issue-PR 对,同时加强了个别 issue 级别的质量过滤以减少噪音
  • 作者还为每个 issue-PR 对检索了更大规模的相关文件集合,从而产生更丰富的开发上下文和更广泛的现实世界软件工程场景覆盖
  • 经过过滤,数据集的 issue-PR 部分包含大约 160B 唯一 token
Long-context data
  • 长上下文训练集包括自然数据和合成数据
    • 自然数据来源于书籍、学术论文和来自通用预训练语料库的文档,采用多阶段过滤(PPL、去重、长度),并对知识密集型领域进行上采样
    • 在合成数据构建中,受 NextLong (2025) 和 EntropyLong (2025) 的启发,作者采用了多种技术来构建长程依赖关系
      • 通过交错打包将高度相似的文本聚合以产生序列,旨在缓解“中间丢失”现象,并提高在各种长上下文任务上的性能
  • 在 200K 阶段,作者还加入了一小部分类似 MRCR 的数据,设计了多种变体以扩展 OpenAI 的原始范式,以增强在扩展的多轮对话中的召回能力
    • 根据经验,作者发现增加数据多样性可逐步提高模型的长上下文性能
  • 特别说明:在最初的 128K 阶段之后,再进行一个 200K 的 Mid-training 阶段,即使在 128K 上下文窗口内也进一步增强了模型的性能

Training Infrastructure

Memory Efficiency
Flexible MTP placement
  • 在交错流水线并行 (2021) 下,模型组件被灵活地分配到各个 Stage
  • 问题:
    • MTP 模块跨越 Embedding 、transformer 和输出组件
    • MTP 其他模块消耗明显更高的内存,导致 Stage-level 不平衡
  • 解法:作者将 MTP 输出层与主输出层共同放置在最后一个 Stage 以实现参数共享,同时将其 Embedding 和 transformer 组件放置在前一个阶段
    • 这减少了最后一个 Stage 的内存压力,并改善了流水线 ranks 之间的平衡
Pipeline ZeRO2 gradient sharding
  • 每个流水线 rank 维护多个 Stages (2021),并且原生的每个 Stage 都需要一个完整的梯度缓冲区用于累积和优化器更新
  • 受 ZeRO2 (2020) 启发,作者在数据并行 ranks 之间对梯度进行分片,这样每个 Stage 只存储完整梯度的 \(1/dp\) 部分
  • 此外,仅保留两个 Stage 的完整累积缓冲区,并通过双缓冲重用它们
    • 当一个 Stage 缓冲区在连续微批次上累积梯度时,前一个 Stage 缓冲区的梯度同步并行执行
    • 这将持久性梯度内存减少到每 Stage 的分片缓冲区加上仅用于滚动累积的两个完整缓冲区,而实践中没有额外的同步开销
Zero-redundant communication for the Muon distributed optimizer
  • 朴素的 Muon 实现在每个数据并行 rank 上 All-gather 完整模型参数
    • 这导致了瞬时内存峰值和冗余通信
  • 作者将 All-gather 限制在每个 rank 拥有的参数分片上,并将本地计算与分片通信重叠
    • 这消除了冗余通信,并显著降低了与优化器相关的峰值内存开销
Pipeline activation offloading
  • 在流水线预热期间,前向执行先于反向传播,延长了中间激活的生命周期
  • 作者在前向执行后将激活卸载到主机内存,并在反向执行前重新加载它们 (2024)
    • 卸载以层粒度应用,以进一步减少峰值内存使用
    • 结合细粒度的重计算,在很大程度上消除了将激活常驻在 GPU 内存中的需要
  • 卸载和重新加载的调度与计算重叠,同时避免与点对点通信和 MoE token 路由(分发和组合)争用
    • 这显著减少了激活内存占用,且开销几乎为零
Sequence-chunked output projection for peak memory reduction
  • 输出投影和交叉熵损失会产生瞬态内存开销,这是由于存储用于反向传播的激活以及在损失计算期间将它们提升到更高精度
  • 为了减少这种开销,作者将输入序列划分为更小的块,并在每个块上独立计算投影和损失,完成前向和反向传播后立即释放激活
    • 因此,峰值内存使用随着块数量的增加而减少
  • 通过设置适当的块数量,这种方法减轻了输出层的内存压力,同时保持与未分块执行相当的性能
Parallelism Efficiency
Efficient deferred weight gradient computation
  • To Reduce Pipeline Bubbles,作者将一些权重梯度计算移出关键路径 (2023)
  • 通过优化存储和通信重叠的细粒度延迟,提高了吞吐量,同时保持内存开销可控
Efficient long-sequence training
  • 更长的序列加剧了数据并行和流水线并行组之间的负载不平衡
  • 作者通过工作负载感知的序列重排序、注意力计算的动态重新分配以及将数据并行 ranks 灵活划分为不同大小的上下文并行组来解决这个问题 (2025; 2025)
  • 一种分层 all-to-all 方式重叠 QKV 张量的节点内和节点间通信以减少延迟
INT4 Quantization-aware training
  • 为了在低精度下提供更好的准确性,作者在 SFT 阶段应用了 INT4 QAT
  • 为了进一步减轻训练时间开销,作者开发了一个适用于训练和离线权重量化的量化 kernel,确保训练和推理之间的行为按位一致(ensures bitwise-identical behavior between training and inference)

Post-Training

  • GLM-5 的后训练阶段旨在将基础模型转变为具有强大推理、编码和 agentic 能力的高性能助手
  • 如图5所示,作者的流程遵循一种渐进的对齐策略:
    • 从引入复杂交错思考模式的多任务监督微调开始
    • 然后是针对推理和 agentic 任务的专门强化学习阶段
    • 最后以通用 RL 阶段结束,以实现类似人类的对齐
  • GLM-5 利用 on-policy cross-stage distillation 作为最终的精炼步骤,在利用每个训练阶段带来的性能提升的同时,有效地缓解了能力退化

Supervised Fine-Tuning

  • 与 GLM-4.5 相比,GLM-5 在 SFT 阶段显著扩展了 Agent 和编码数据的规模,GLM-5 的 SFT 语料库涵盖三大类别:
    • 通用聊天:问答、写作、角色扮演、翻译、多轮对话和长上下文交互
    • 推理:数学、编程和科学推理
    • 编码与智能体:前端和后端工程代码、工具调用、编码智能体、搜索智能体和通用智能体
  • GLM-5 在 SFT 期间将最大上下文长度扩展到 202,752 个 token
  • 结合更新的聊天模板,该模型支持三种不同的思考特性(参见图7),包括:
    • Interleaved Thinking:模型在每次响应和工具调用前进行思考,提高了指令跟随能力和生成质量
    • Preserved Thinking:在编码智能体场景中,模型自动在多轮对话中保留所有思考块,重用现有推理而不是从头开始重新推导
      • 这减少了信息丢失和不一致性,非常适合长视野、复杂的任务
    • Turn-level Thinking:模型支持在会话中按轮次控制推理,为轻量级请求禁用思考以减少延迟/成本,为复杂任务启用思考以提高准确性和稳定性
  • GLM-5 在动作之间进行思考并保持跨轮次的一致性,在复杂任务上实现了更稳定和可控的行为
  • 对于通用聊天
    • 与 GLM-4.5 相比,优化了响应风格,使其更具逻辑性和简洁性
    • 对于角色扮演任务,收集和构建了一个更广泛、更多样化的数据集,涵盖多种语言和角色配置
    • 特别是,作者定义了几个评估维度(包括指令跟随、语言表现力、创造力、逻辑连贯性和长对话一致性),并应用自动和人工过滤来筛选和精炼数据
  • 对于推理任务
    • 进一步增强模型推理的深度
    • 对于逻辑推理,作者构建了可验证的问题,并使用拒绝采样合成高质量数据
    • 对于数学和科学问题,应用了基于难度的过滤流程,只保留那些对 GLM-4.7 模型具有挑战性的问题
  • 对于编码和智能体任务
    • 与 GLM-4.5 相比,GLM-5 构建了大量的执行环境以获得高质量的轨迹,特别强调现实世界场景和长视野任务
    • 使用专家强化学习和拒绝采样进一步改进 SFT 数据
    • 轨迹中的错误片段被保留,但在损失函数中被掩盖 ,允许模型学习纠错行为,而不会强化错误动作

Reasoning RL

RL algorithm backbone
  • 本文的 RL 算法建立在 GRPO 之上
    • 注:结合了 IcePop 技术 (2025) 以缓解训练-推理不匹配问题,即 RL 优化期间推理分布与训练分布之间的差异
  • 明确区分了用于梯度更新的训练策略 \(\pi^{\mathrm{train} }\) 和用于轨迹采样的推理策略 \(\pi^{\mathrm{infer} }\)
  • 与原始的 IcePop 公式相比,作者去除了 KL 正则化项以加速 RL 改进。最终的优化损失为:
    $$\begin{array}{rl}\mathcal{L}(\theta) = -\mathbb{E}_{x\sim \mathcal{D},\{y_i\}_{i = 1}^G\sim \pi_{\theta_{\mathrm{old} } }^{\mathrm{infer} }(\cdot |x)}\left[\frac{1}{G}\sum_{i = 1}^G\frac{1}{|y_i|}\sum_{t = 1}^{|y_i|}\mathrm{pop}(\rho_{i,t},1 / \beta ,\beta) \cdot \min \left(r_{i,t}\hat{A}_{i,t},\mathrm{clip}(r_{i,t},1 - \epsilon_{\mathrm{low} },1 + \epsilon_{\mathrm{high} })\hat{A}_{i,t}\right)\right] \end{array} \tag {1}$$
  • 其中训练-推理不匹配比率定义为
    $$\rho_{i,t} = \frac{\pi_{\theta_{\mathrm{old} } }^{\mathrm{train} }(y_{i,t}\mid x,y_{i,< t})}{\pi_{\theta_{\mathrm{old} } }^{\mathrm{infer} }(y_{i,t}\mid x,y_{i,< t})} $$
  • 操作符 \(\mathrm{pop}(\cdot)\) 抑制那些不匹配比率过度偏离的样本:
    $$ \mathrm{pop}(\rho, l, h) = \begin{cases} 0 & \text{if } \rho < l \text{ or } \rho > h \\ 1 & \text{otherwise} \end{cases} $$
  • PPO 风格的重要性比率和组归一化优势遵循原始的 GRPO 定义:
    $$r_{i,t} = \frac{\pi_{i}^{\mathrm{train} }(y_{i,t}\mid x,y_{i,< t})}{\pi_{i_{\mathrm{old} } }^{\mathrm{train} }(y_{i,t}\mid x,y_{i,< t})},\quad \hat{A}_{i,t} = \frac{R_{i} - \mathrm{mean}(R_{1},\ldots,R_{G})}{\mathrm{std}(R_{1},\ldots,R_{G})}.$$
  • 在训练期间,作者设置超参数 \(\beta = 2\),\(\epsilon_{\mathrm{low} } = 0.2\),\(\epsilon_{\mathrm{high} } = 0.28\)
  • 训练完全在 on-policy 下进行,组大小为 32,批量大小为 32
DSA RL insights
  • 作者在基于 DSA 架构的模型上进行了非常大规模的 RL 训练
  • 问题:
    • 与 MLA 相比,DSA 引入了一个额外的 indexer,它检索最相关的 top-k 键值条目,并在检索到的子集上稀疏地计算注意力
      • 检索到的 top-k 结果对于 RL 稳定性至关重要
      • 这类似于 MoE 模型如何使用路由重放 (2025) 来保留激活的 top-k 专家,以确保训练-推理一致性
    • 但在每个 token 位置存储 indexer 的 top-k 索引显然是不切实际的
      • 因为 indexer 使用的 \(k = 2048\) 远大于 MoE 中通常使用的 \(k\),并且存储所有这些索引将带来巨大的存储成本以及训练引擎和推理引擎之间的显著通信开销
  • 解法:
    • 作者发现采用确定性的 top-k 操作符可以有效解决这个问题
    • 与 SGLang 的 DSA Indexer 中使用的非确定性 CUDA 基础 top-k 实现相比,直接使用朴素的 torch.topk 稍慢但具有确定性
      • torch.topk 产生更一致的输出,并带来显著的 RL 收益
    • 相比之下,其他非确定性的 top-k 操作符(例如 CUDA 或 TileLang 实现)在仅仅几步 RL 后就导致了剧烈的性能下降,并伴随着熵的急剧下降
    • 因此,在作者的整个 RL 阶段,作者在训练引擎的 DSA Indexer 中使用 torch.topk 作为默认的 top-k 操作符
    • 作者在 RL 期间默认冻结 indexer 参数,以加速训练并防止 indexer 中的学习不稳定
Mixed domain reasoning RL
  • 在推理 RL 阶段,作者在四个领域进行混合 RL 训练:数学、科学、代码和工具集成推理(Tool-integrated Reasoning ,TIR)
  • 对于数学和科学,作者从开源数据集 (2025) 和与外部标注供应商共同开发的集合中筛选数据
    • 作者进一步应用难度过滤,将训练重点放在 GLM-4.7 很少或始终无法正确解决,但更强的教师模型(例如 GPT-5.2 xhigh 和 Gemini 3 Pro Preview)能够解决的问题上
  • 对于代码,作者涵盖竞争性编程风格的任务和科学编码任务
    • 前者主要来源于 Codeforces 和代表性数据集,如 TACO (2023) 和 SYNTHETIC-2-RL (2025),而后者则通过将问题分解为正确解决方案所需的最小代码实现,从内部问题库中构建
    • 对于 TIR,作者复用了数学和科学 RL 数据中更具挑战性的子集,并另外与标注供应商共同构建了 STEM 问题,这些问题明确设计为使用外部工具来回答
    • 在 RL 训练期间,作者分配领域和来源特定的 judge 模型或评估系统来产生二元结果奖励
    • 作者保持四个领域之间的整体混合大致平衡,并始终观察到在混合 RL 设置下,每个领域都取得了稳定且显著的收益

Agentic RL

  • 朴素的同步 RL 在长视野智能体 rollout 期间存在严重的 GPU 空闲时间
  • 为了促进 GLM-5 的 agentic 性能,作者开发了一个完全异步和解耦的 RL 框架,并在编码和搜索智能体任务上优化 GLM-5
    • 通过中央多任务 Rollout 协调器将推理引擎和训练引擎解耦,作者在不同的 agentic 工作负载上实现了高吞吐量的联合训练
  • 为了在异步 off-policy 条件下保持训练稳定性,GLM-5 引入了两个关键机制
    • 机制1:Token-in-Token-out(TITO)网关通过保留精确的动作级对应关系,消除了重新 tokenization 的不匹配
    • 机制2:直接双面重要性采样,对 rollout log-probabilities 应用 Token-level 裁剪机制 \((1 - \epsilon_{t},1 + \epsilon_{h})\),同时有效控制 off-policy 偏差,而无需跟踪历史策略检查点
  • 为了加速,作者还采用了 DP-aware 路由,以在长上下文推理期间最大化大型 MoE 模型的 KV 缓存重用
  • 为了扩展 agentic 环境,作者在三个领域扩展了可验证的训练环境:
    • 超过 10,000 个现实世界的软件工程任务
    • 终端任务
    • 高难度多跳搜索任务
  • 注:关于 agentic RL 的更多细节可以在后面的第 4 节中找到

General RL

Multi-dimensional optimization objectives
  • 作者将通用 RL 的优化目标分解为三个互补的维度:
    • 基础正确性,foundational correctness
    • 情感智能,emotional intelligence
    • 任务特定质量,task-specific quality
  • 三个维度的详细解释如下:
    • 基础正确性 维度作为响应质量的基石
      • 针对一系列削弱模型输出可用性的错误类型,包括指令跟随失败、逻辑不一致、事实不准确、知识幻觉和语言不流畅
      • 目标是最大限度地降低错误率,使响应达到可用的基线水平
      • 作者认为这是所有后续优化的先决条件:包含事实错误或误解用户意图的响应,无论其外观多么精致,都可能误导用户
    • 情感智能 维度优化核心正确性之外的用户体验
      • 目标是产生富有同理心、有洞察力且风格接近自然人类交流的响应,使与模型的交互感觉更自然、更吸引人
    • 任务特定质量 维度针对各种特定任务进行细粒度优化
      • 建立在基础正确性建立的可用性之上,它旨在将响应从仅仅是正确的提升到在每个任务类别内真正高质量的级别
      • 该维度涵盖广泛的任务,包括写作、文本处理、主观和客观问答、角色扮演和翻译。每个任务领域都要求不同的奖励信号,需要混合奖励系统
Hybrid reward system
  • 为了监督上述多样化的目标,作者构建了一个混合奖励系统,它集成了三种互补类型的奖励信号:
    • 基于规则的奖励函数,rule-based reward functions
    • 结果奖励模型,outcome reward models (ORMs)
    • 生成式奖励模型,generative reward models (GRMs)
  • 每种方法都有其独特的优缺点,它们的结合是稳定、高效和可扩展的通用 RL 训练过程的关键
    • 基于规则的奖励 提供精确且可解释的信号,但仅限于可表达为确定性规则的方面
    • ORM 提供低方差信号和高训练效率,但更容易受到 Reward Hacking 行为的影响
      • 即策略利用表面模式而不是真正提高核心能力
    • GRM 利用语言模型产生标量或结构化评估,并且更能抵抗这种利用,但往往表现出更高的方差
  • 通过混合这三种信号类型,作者获得了一个平衡了精度、效率和鲁棒性的奖励系统,减轻了任何单一组件的弱点
Human-in-the-loop style alignment
  • 通用 RL 流程的一个独特之处在于明确纳入了高质量的人类编写的响应
  • 作者不只依赖模型生成的响应,而是引入专家人类响应作为风格和质量的锚点
  • 以上是基于观察得到的:纯模型生成的优化倾向于收敛到可识别的“类似模型”模式,通常是冗长的、公式化的,或者缺乏熟练人类写作的细微差别
  • 通过让模型接触人类编写的范例,作者鼓励它采用更自然、更符合人类习惯的响应模式

On-Policy Cross-Stage Distillation

  • 在多阶段 RL 流程中,为不同目标进行顺序优化可能导致先前获得的能力累积退化
  • 为了缓解这个问题,作者执行 on-policy cross-stage distillation 作为最终阶段,采用 on-policy 蒸馏算法 (2025) 快速恢复早期 SFT 和 RL 阶段(Reasoning RL 和 General RL)获得的技能
  • 具体方法:
    • 先前训练阶段的最终检查点作为教师模型,其中训练 Prompt 从相应教师的 RL 训练集中采样,并以适当比例混合
    • 训练损失可以通过用以下公式替换公式1中的优势项来获得(’sg’ 代表 stop gradient 操作,例如 .detach()):
      $$\hat{A}_{i,t} = \mathrm{sg}\left[\log \frac{\pi_{i,\mathrm{base} }^{\mathrm{infer} }(\boldsymbol{y}_{i,t}\mid\boldsymbol{x},\boldsymbol{y}_{i,< t})}{\pi_{i,\mathrm{in} }^{\mathrm{infer} }(\boldsymbol{y}_{i,t}\mid\boldsymbol{x},\boldsymbol{y}_{i,< t})}\right]. \tag {2}$$
  • 目前,作者利用推理引擎获取教师的 logits
  • 将来,作者计划将推理后端迁移到训练引擎,并统一采用 MLA 的多查询注意力模式进行推理
    $$ (\pi_{i,\mathrm{base} }^{\mathrm{infer} }\rightarrow \pi_{i,\mathrm{base} }^{\mathrm{train} })$$
  • 在训练期间,GRPO 算法中的组大小配置为 1 以增加数据吞吐量,批量大小设置为 1024
    • 在这个阶段这样做是可行的,因为不再需要为每个 Prompt 维持一大组样本来估计优势;优势直接根据与教师模型的差距计算得出

RL Training Infrastructure: The slime Framework

  • GLM-5 继续使用 slime 作为统一后训练基础设施,实现大规模的端到端强化学习
  • GLM-5 没有引入新的系统组件,而是充分利用了 slime 的能力:
    • (1) 通过自由形式的 rollout 定制和基于服务器的执行模型来拓宽任务覆盖范围
    • (2) 通过混合精度训练/rollouts 结合 MTP 和 Prefill-Decode 分离,特别是对于多轮 RL 工作负载,来显著提高吞吐量
    • (3) 通过心跳驱动的 rollout 容错和路由器级服务器生命周期管理,来提高鲁棒性
Scaling Out: Flexible Training via Highly Customizable Rollouts
  • GLM-5 的后训练涵盖多样化的目标谱系
    • 为了支持这种多样性而无需特定于任务的分支,GLM-5 利用了 slime 高度可定制的 rollout 接口及其基于服务器的 rollout 执行
Highly customizable rollouts
  • slime 提供了一个灵活的接口,用于实现特定于任务的 rollout 逻辑(包括多轮交互循环、工具调用、环境反馈处理和验证器引导的分支)而无需修改底层基础设施
    • GLM-5 利用此功能支持广泛的领域和训练范式,包括但不限于推理 RL、通用 RL、agentic RL 和 on-policy 蒸馏,所有这些都在统一的训练栈中完成
Server-based rollouts via HTTP APIs
  • slime 通过标准 HTTP API 暴露其 rollout 服务器和推理路由器,允许用户以与传统推理引擎相同的方式与 slime 的服务层交互
  • 这将 rollout 逻辑与训练进程边界解耦:
    • 外部智能体框架和环境可以直接调用服务器/路由器端点
    • 短视野的单轮训练和长视野的多轮轨迹,优化后端保持不变
Scaling Up: Tail-Latency Optimization for RL Rollouts
  • 对于 RL rollouts,优化目标不是总吞吐量,而是端到端延迟,由每一步中最慢的样本主导
  • 在实践中,单个拖尾轨迹可能会阻塞同步点(例如,批次完成、缓冲区就绪、训练器更新),并直接决定挂钟进度
  • 因此,GLM-5 充分利用 slime 的延迟导向服务和调度机制,以最小化中位数延迟,更重要的是,尾部延迟
No-queue serving via multi-node inference with DP-attention for MLA
  • 通过具有 MLA 的 DP 注意力实现多节点推理的无队列服务
  • 为了避免排队延迟,即使在突发流量下也必须及时服务 rollout 请求,这需要大量的 KV 缓存容量
  • GLM-5 采用多节点推理部署(例如,在 8 个节点上使用 EP64 和 DP64)来提供充足的分布式 KV 缓存
  • 引入 DP 注意力主要是为了防止在不同 ranks 之间复制 KV
Tail-latency reduction with FP8 rollouts and MTP
  • 使用 FP8 rollouts 和 MTP 减少尾部延迟
  • GLM-5 使用 FP8 进行 rollout 推理,以减少每 token 延迟并缩短长轨迹的完成时间
  • 此外,GLM-5 利用 slime 对多 token 预测的支持,这在 RL rollouts 典型的小批量解码 regime 下特别有效。由于尾部延迟通常由小批量
Tail-latency reduction with FP8 rollouts and MTP
  • 1)GLM-5 使用 FP8 进行 Rollout 推理,以减少每 Token 延迟并缩短长轨迹的完成时间
  • 2)GLM-5 利用了 slime 对 MTP 的支持
    • 这在 RL Rollout 典型的小批量解码场景下尤其有效
    • 由于尾延迟通常由小批量中的掉队者(stragglers)引起(例如,罕见的长上下文、复杂的多轮推理、密集使用工具的执行轨迹)
      • MTP 在长尾部分提供了不成比例的巨大收益,改善了最慢样本的完成时间,从而减少了步骤级的停滞时间
PD disaggregation to prevent prefill-decode interference in multi-turn RL
  • 在多轮设置中,长前缀的预填(prefill)操作非常频繁(对话历史、工具执行痕迹、代码上下文)
  • 在 DP-Attention 下,将预填和解码混合在同一个服务资源上会产生严重的干扰:一个繁重的预填操作可能会抢占或中断服务器上正在进行的解码,阻碍其他样本持续取得进展,并急剧恶化尾延迟
  • GLM-5 利用了 slime 的预填-解码 (PD) 分离功能
    • 通过在专用资源上运行预填和解码,解码过程保持稳定且不受中断,使得长时程样本能够持续进行,从而显著改善了多轮智能体 RL 中的尾延迟表现

Rollout Robustness: Heartbeat-Driven Fault Tolerance

  • 在大规模下,瞬时故障(例如,单个服务器崩溃、网络问题或性能下降)是不可避免的
  • GLM-5 利用 slime 的心跳驱动容错来确保在此类事件下的训练连续性:
    • rollout 服务器定期发出由编排层监控的心跳,不健康的服务器会被主动终止并从推理路由器注销
  • 重试会自动从故障或降级服务器路由到健康服务器,防止单个服务器事件中断 rollouts,并保持不间断的端到端 RL 训练

Agentic Engineering

  • 作者描述了从氛围编程(vibe coding,即通过人类 Prompt 编程)到智能体工程(agentic engineering)的转变
    • 在氛围编程中,人类 Prompt AI 模型编写代码
    • 在智能体工程中,AI 智能体自己编写代码
      • 它们进行规划、实现和迭代
  • 为了支持这些 Long-horizon 任务,GLM-5 利用了一个完全异步和解耦的 RL 框架,通过减少智能体 Rollout 过程中的空闲时间,显著提升了 GPU 利用率
  • 为了扩展智能体环境,作者开发了环境构建流水线
    • 对于编码任务,作者通过创建超过 10,000 个可验证的训练场景,设置了真实的软件工程问题和终端任务
    • 对于搜索智能体,作者开发了一个自动且可扩展的复杂多步推理数据合成流水线,用于构建智能体训练数据

Asynchronous RL for Agentic Tasks

  • 为智能体任务 RL 训练设计了一个完全异步和解耦的 RL 基础设施
    • 能高效处理 Long-horizon 智能体 Rollout,并支持跨不同智能体框架的灵活多任务 RL 训练
  • 采用基于组的策略优化算法进行 RL 训练
    • 对于每个问题 \(x\) ,作者从旧策略 \(\pi_{\mathrm{old} }\) 中采样 \(K\) 条智能体轨迹 \(\{y_{1},\ldots ,y_{K}\}\) ,并根据以下目标优化模型 \(\pi_{\theta}\) :
      $$L(\theta) = \mathbb{E}_{x\sim \mathcal{D} }\left[\frac{1}{K}\sum_{i = 1}^{K}(r(x,y_i) - \bar{r} (x))\right],$$
      • 其中 \(\begin{array}{r}\bar{r} (x) = \frac{1}{K}\sum_{i = 1}^{K}r(x,y_i) \end{array}\) 是采样响应的平均奖励
      • 注:只有模型生成的 Token 用于优化,环境反馈在损失计算中被忽略
Asynchronous RL Design for Agentic Training
  • 由于 Rollout 过程的长尾特性,同步 RL 训练在 Rollout 阶段会引入大量气泡,这是因为智能体任务生成的严重不平衡,可能导致 GPU 长时间空闲
  • 为了提高训练吞吐量,作者对 Agentic RL 采用完全异步的训练范式,以提升 GPU 利用率和训练效率
  • 具体方法:
    • 将训练引擎和推理引擎解耦到不同的 GPU 设备上
    • 推理引擎持续生成轨迹,生成的轨迹数量达到预定义的阈值后,该批次就会被发送到训练引擎以更新模型
  • 为了减少策略滞后并保持训练近似 On-policy,Rollout 引擎使用的模型权重会定期与训练引擎的权重同步
    • 训练引擎每进行 \(K\) 次梯度更新,就会更新模型参数并将新权重推回推理引擎
    • 虽然异步可以显著提高整体训练效率,但这也意味着不同的轨迹可能由不同版本的模型生成,从而引入了严重的 Off-policy 问题
    • 由于推理策略的变化使得权重更新面临不同的优化问题,在每次更新推理引擎的权重后需要重置优化器
      • 理解:混合策略下的优化目标不再是“当前策略下的期望回报”,而是一个混合策略分布下的期望回报,这本质上是一个不同的优化问题(different optimization problem),因为:
        • 数据分布变了
        • 策略的梯度方向可能不一致
        • 训练不再是对当前策略的稳定改进
      • 理解:为什么“重置优化器”能缓解这个问题?
        • 在标准的优化器(如 Adam)会维护动量(momentum) 和方差(variance) 等状态
          • 这些状态是累积历史梯度信息的,假设优化目标是平滑变化的
        • 但在异步 RL 中:
          • 每次推理引擎更新后,优化目标(采样数据分布决定了优化目标)发生了突变
          • 如果保留旧的优化器状态,可能会:
            • 引入错误的梯度方向
            • 导致训练不稳定
            • 延缓收敛
        • 因此,作者选择在每次推理引擎权重更新后重置优化器,相当于:
          • 清空历史梯度信息
          • 重新开始优化当前策略下的新目标
Server-based multi-task training design
  • 为了解决多任务 RL 中轨迹生成的异质性(不同任务通常依赖不同的工具集和特定于任务的 Rollout 逻辑),作者引入了一个基于服务器的多任务 Rollout Orchestrator 用于多任务 RL 训练
    • 该组件旨在通过一个中心 Orchestrator 协调多个注册的任务服务,确保 slime RL 训练框架与下游任务之间的无缝兼容
  • 具体方法:
    • 每个任务将其自己的 Rollout 和奖励逻辑实现为一个独立的微服务,并在中心 Orchestrator 上注册以进行管理和调度
    • 在 Rollout 阶段,中心 Orchestrator 控制每个任务的 Rollout 比例和生成速度,以实现跨任务的数据收集平衡
      • 这里的关键在于:将所有智能体任务的轨迹标准化为统一的消息列表表示形式
      • 这使得能够对复杂的智能体框架(例如软件工程任务)进行联合训练,同时也支持对异构工作负载进行集中的后处理和日志记录
    • 这种设计将任务特定的逻辑与核心训练循环清晰地隔离开来,实现了与多任务 RL 训练的无缝集成
  • 作为 GLM-5 训练基础设施的骨干,该 Orchestrator 支持超过 1000 个并发的 Rollout,并能够自动动态调整任务采样比例,以及对任务进度进行细粒度监控
Optimizing Asynchronous Training Stability
Token-in-Token-out vs. Text-in-Text-out
  • 在 RL Rollout 设置中:
    • Token-in-Token-out (TITO) 意味着训练流水线消费由推理引擎产生的确切 Tokenization 和解码后的 Token 流,并直接使用它来构建用于学习的轨迹
    • Text-in-Text-out 将 Rollout 引擎视为一个黑盒,返回最终确定的文本;然后训练器通过对该文本进行重新 Tokenization (通常还要重新推导边界和截断)来重建轨迹,然后再计算损失
  • 以上这个看似微小的选择却至关重要:
    • 重新 Tokenization 可能会在 Token 边界、空格/标准化处理、截断或特殊 Token 放置方面引入细微的不匹配,这进而可能破坏动作和奖励/优势之间的步骤对齐
      • 尤其是在 Rollout 被流式传输、截断或跨多个执行器交错时
    • 作者发现 Token-in-Token-out 对于异步 RL 训练至关重要,因为它保留了采样内容与优化内容之间精确的动作级对应关系,同时使执行器能够立即发出轨迹片段(Token ID + 元数据),而无需经过有损的文本往返过程,也无需在学习器端等待事后的重新 Tokenization
  • 在实践中,作者实现了一个 TITO Gateway,拦截来自 Rollout 任务的所有生成请求,并记录每条轨迹的 Token ID 和元数据
    • 这种设计将繁琐的 Token ID 处理与下游智能体 Rollout 逻辑隔离开 来,同时避免了 RL 训练期间因重新 Tokenization 导致的不匹配
Direct double-sided importance sampling for token clipping
  • 与第 3 节中的同步 RL 训练设置不同,在异步设置中,Rollout 引擎可能在单条轨迹生成过程中经历多次更新 ,这使得追踪确切的行为概率 \(\pi_{\theta_{\mathrm{old} } }\) 在计算上变得不可行
    • 在这种情况下,我们可能将不得不维护一个庞大的模型检查点历史 \(\{\pi_{\theta_{\mathrm{old} }^{(1)} },\ldots ,\pi_{\theta_{\mathrm{old} }^{(N)} }\}\) ,这在实际实现中是行不通的
  • 解决方案:
    • 1)采用一种简化的 Token-level 重要性采样机制,该机制重用 Rollout 期间生成的 Log-probabilities 作为直接的行为代理
      • 通过将重要性采样比率计算为 \(r_t(\theta) = \frac{\pi_{\theta} }{\pi_{\mathrm{rollout} } }\) ,并丢弃传统的 \(\pi_{\theta_{\mathrm{old} } }\) ,作者消除了单独进行旧策略推理的计算开销
    • 2)采用一种双面校准的 Token-level 掩码策略
      • 注:这不是使用标准 PPO 中使用的非对称裁剪,而是将信任区域限制在 \([1 - \epsilon_t, 1 + \epsilon_h]\) ,其中 \(\epsilon_t\) 和 \(\epsilon_h\) 是裁剪超参数
      • 落在此区间之外的 Token 将完全从梯度计算中掩盖,以防止因策略极端分歧而导致的不稳定性
      • 这与 IcePop 机制 (2025) 有相似之处,但 GLM-5 作者的策略更简单,因为它进一步移除了 \(\pi_{\theta_{\mathrm{old} } }\) 并实现了更稳定的训练
  • 形式上,带有 Token-level 裁剪的优化目标可以写成:
    $$
    \mathcal{L}(\theta) = \mathbb{E}_t \left[ f(r_t(\theta), \epsilon_l, \epsilon_h) A_t \log \pi_{\theta}(a_t|s_t) \right] \tag {3}
    $$
    • 在这个公式中,重要性采样比率 \(r_t(\theta)\) 计算如下:
      $$
      r_t(\theta) = \exp \left( \log \pi_{\theta}(a_t|s_t) - \log \pi_{\text{rollout} }(a_t|s_t) \right) \tag {4}
      $$
    • 稳定性进一步通过校准函数 \(f(x; \epsilon_l, \epsilon_h)\) 来加强:
      $$
      f(x; \epsilon_l, \epsilon_h) =
      \begin{cases}
      x, & \text{If } 1 - \epsilon_l < x < 1 + \epsilon_h \\
      0, & \text{Otherwise }
      \end{cases} \tag {5}
      $$
  • 在实验中,作者发现重用 Rollout Log-probabilities 允许一定程度的可控 off-policy 偏差,以避免追踪历史策略的需求,同时提升训练稳定性
Dropping off-policy and noisy samples
  • 问题1:在异步 RL 中,过长的轨迹可能会变得高度 off-policy,这可能会 destabilize 训练
  • 解法1:为了过滤掉这些严重 off-policy 的样本,作者在生成时记录了 Rollout 引擎使用的策略权重版本
  • 解法1 具体方法(维护陈旧性指标并丢弃过于陈旧的轨迹):
    • 对于每个 Response,作者记录了所涉及的模型版本序列 \((w_0, \ldots, w_k)\),其中 \(w_0 < \cdots < w_k\)
    • 令 \(w’\) 表示当前的策略版本
    • 如果某个样本的最旧 Rollout 版本过时,即如果 \(w’ - w_0 > \tau\)(其中 \(\tau\) 是一个预定义阈值),就丢弃该样本
    • 这移除了那些落后于当前策略太多的轨迹
  • 问题2:Coding-agent 沙箱可能 inherently 不稳定,并且可能因与模型无关的原因(例如,环境崩溃)而失败
    • 此类失败会引入有噪声的训练信号,因为它们反映的是环境的不稳定性,而非模型的能力
  • 解法2:记录每个样本的失败原因,并排除了因环境崩溃而失败的样本
    • 对于像 GRPO 这样基于组的采样方法,移除失败的样本可能会导致组不完整,在这种情况下:
      • 如果有效样本的数量超过组大小的一半,通过重复有效样本的方式来填充该组
      • 否则,丢弃整个组
    • 这个过程减少了虚假的奖励噪声,并提高了训练稳定性
DP-aware routing for acceleration
  • 作者提出了一种 DP 感知的路由机制,以便在为大规模 MoE 推理进行数据并行时,保留 KV 缓存的局部性
  • 在多轮 Agent 工作负载中,来自同一个 Rollout 的连续请求共享相同的前缀
  • 为了最大化 KV 重用,作者强制执行 Rollout 级的亲和性:
    • 属于给定 Agent 实例的所有请求都被路由到同一个 DP rank
  • 具体方法:
    • 引入一个有状态的路由层,它使用一致性哈希将每个 Rollout ID 映射到一个固定的 DP rank
      • 这种映射在多轮之间保持稳定,消除了跨 rank 的缓存缺失
    • 为了防止长期的不平衡,将哈希与哈希空间上的轻量级动态负载均衡结合起来
      • 这种设计避免了冗余的 Prefill 计算,而无需在 DP rank 之间同步 KV
    • 随着 Rollout 长度的增加,Prefill 成本仍然与增量 token 成正比,而不是与总上下文长度成正比
      • 改善了端到端的延迟,并为长上下文 Agentic 推理带来了更高的有效吞吐量
Asynchronous Attention-aware Load Balancing for Agentic Inference
  • 问题:Rollout 过程中时间线的延长和环境的异构性,大规模智能体训练的推理工作负载可能存在显著差异,导致在 MoE 模型中将请求路由到不同专家时出现负载不平衡
    • 这种不平衡会导致推理延迟出现不可接受的峰值
  • 解法:在 MoE 模型的 Attention 和 FFN 部分都采用了负载均衡感知的路由策略
  • 在训练有素的 MoE 模型中
    • FFN 路由已经相对稳定,其负载不平衡可以通过专家并行和数据并行策略的组合来缓解
  • 但 Attention 路由的动态性要高得多:
    • 在不同 Agentic 任务中,指令和中间生成的 Token 的内容变化多样,导致 Attention 路由(即 DSA 中的 Lightning Indexer)选择的 Top-k KV 条目出现显著的负载波动
      • 这会导致 KV 检索延迟出现长尾分布,严重拖慢 Rollout 速度,并在异步设置中阻碍稳定的训练
  • 解法:
    • 作者提出了一种用于智能体推理的异步注意力感知负载均衡策略
    • 该策略旨在预测和平衡由 Lightning Indexer 选中的 KV 条目分布
    • 核心思想是利用异步 Inference 引擎和训练引擎之间的权重同步间隔,从历史 KV 访问分布中学习,以预测未来的路由模式
  • 具体方法:
    • 在每个 Inference 引擎上,维护一个全局的 KV 检索频率统计量 \(H(t)\) ,它记录了过去 \(t\) 个推理步骤中每个 KV 条目被选中的次数
    • 当接收到新的推理请求时,模型首先进行前向传播以获得 Query Embedding,Lightning Indexer 据此计算每个 KV 条目的重要性分数 \(s_i\)
    • 传统的 DSA 会直接选择分数最高的 \(k\) 个条目,本文的策略在此基础上,引入了一个负载均衡正则化项:
      $$s_i’ = s_i + \alpha \cdot \left(1 - \frac{H_i(t)}{H_{\text{avg} }(t)}\right)$$
      • \(H_i(t)\) 是第 \(i\) 个 KV 条目在历史中的检索频率
      • \(H_{\text{avg} }(t)\) 是所有 KV 条目的平均检索频率
      • \(\alpha\) 是一个平衡因子
  • 这个正则化项会提升那些历史上被较少选中的 KV 条目的优先级,从而将检索负载从热点条目分散到冷门条目上
    • 最终,模型根据调整后的分数 \(s_i’\) 选择 Top-k KV 条目
    • 这种方法需要跨 Inference 引擎同步 \(H(t)\)
    • 鉴于 Inference 引擎可能分布在不同 GPU 上,作者采用异步通信方式,定期(例如每 \(N\) 个 Rollout 步骤)聚合所有引擎的局部统计量,更新全局的 \(H(t)\) ,然后再将其广播回各个引擎
    • 实验表明,该策略能将 KV 检索的延迟峰值降低约 30%,同时不影响最终的模型性能

Environment Scaling for Agents

  • 为支持跨多种 Agentic 任务的强化学习,构建了可验证、可执行的环境,这些环境能为以代码为中心的和内容生成的工作流程提供 grounded 的反馈
  • 对于 Agentic 编码任务,开发了两种构建可验证可执行环境的环境构建流程:
    • 一个基于真实世界软件工程问题构建的环境设置流程
    • 一个用于终端 Agent 环境的合成流程
  • 除了编码任务:还进一步引入了一个 slide 生成环境
    • 在该环境中,Agent 在结构化的 HTML 上操作,并伴有可执行的渲染和基于布局的验证
Software Engineering (SWE) Environments
  • 在构建可执行环境之前,作者收集了一个大规模的真实世界 Issue-Pull Request (PR) 对语料库,并应用了严格的基于规则和基于 LLM 的过滤,以确保获取真实、高质量的 Issue 陈述
  • 将这些实例分类到不同的任务类型中(包括 Bug 修复、功能实现、代码重构等)并包含了必要的任务要求,以确保模型的实现与测试补丁保持一致
  • 采用一个基于 RepoLaunch 框架 (2025) 的环境设置流程,该流程能够规模化地从真实世界的 SWE Issue 中构建可执行环境
    • 这个流程会自动分析仓库的安装和依赖设置,以构建一个可执行环境并生成测试命令,然后利用 LLM 根据测试输出生成语言感知的日志解析函数,从而能够提取出 Fail-to-Pass (F2P) 和 Pass-to-Pass (P2P) 测试用例
  • 最终,作者使用这个流程,在跨越 9 种编程语言(包括 Python、Java、Go、C、CPP、JavaScript、TypeScript、PHP 和 Ruby)的数千个仓库中,构建了超过 10,000 个可验证环境
Terminal Environments
Synthesis from seed data
  • 为了大规模构建可验证的终端智能体环境,作者设计了一个智能体数据合成流水线,包含三个阶段:
    • 任务草稿生成
    • 具体任务实现
    • 迭代任务优化
  • 具体如下:
    • Step1:从收集到的真实世界软件工程和基于终端的计算机使用场景中的一组种子任务开始,利用 LLM 进行头脑风暴,生成一个大型的可验证终端任务草稿池
    • Step2:由一个构建智能体将这些草稿实例化为符合 Harbor (2026) 格式的具体任务,包括结构化的任务描述、Docker 化的执行环境和相应的测试脚本
    • Step3:一个优化智能体根据人工定义的评估标准检查并迭代优化生成的任务,确保 Docker 镜像能够可靠地构建,测试用例与任务规范一致,并且环境能够抵御潜在的漏洞或捷径
  • 该流水线产生了数千个多样化且可验证的终端智能体环境,Docker 构建准确率超过 90%
Synthesis from web-corpus
  • 作者开发了一个可扩展的自动化流水线,并基于网络语料库构建了经 LLM 验证的、基于终端的编码任务,采用闭环设计,即构建智能体同时也充当其自身的初筛评估器
  • First,收集大规模与代码相关的网页语料库,并应用数据质量分类器,只保留高质量内容,丢弃那些主要非技术性或缺乏实质性代码内容的页面
    • 从筛选后的子集中,进一步识别出适合构建终端式任务的网页
  • Second,按主题类别和难度级别进行分层采样,以确保生成任务池的分布均衡和多样性
  • Third,Prompt 一个编码智能体,向其提供 Harbor 任务构建规范(包括任务模式、格式要求和示例任务),以及每个选中的源网页,指示该智能体:
    • (i) 基于网页内容合成一个完整的终端任务
    • (ii) 对其自身的输出执行 Harbor 验证脚本
    • 如果验证失败,智能体会迭代地诊断和修订任务,直到它通过所有自动化检查。只有成功通过此自我验证循环的任务才会被纳入最终的数据集
Search Tasks
  • 对于深度搜索信息寻求任务,作者构建了一个数据合成流水线,用于生成具有挑战性的多跳 QA 对
  • 每个问题都需要基于从多个网络来源聚合的证据进行多步推理
Web Knowledge Graph (WKG) Construction and Question Generation
  • 从早期搜索智能体的轨迹开始,收集并去重所有遇到的 URL,保留了超过两百万个跨不同领域的高信息量网页
  • LLM 执行语义解析,进行实体识别、噪声过滤和结构化信息提取
  • WKG 会持续用新页面更新,并通过实体对齐、属性规范化、关系合并和语义一致性校正等下游验证信号进行优化
  • 基于 WKG,采样中低频率实体作为种子节点,并扩展其多跳邻域以形成完整的子图,同时控制扩展以减少重叠
  • 使用针对高难度、多领域推理的 Prompt ,将每个子图转换为一个隐式编码了多实体关系链的问题
High-Difficulty Question Filtering and Verification
  • 作者应用一个三阶段流水线来平衡难度和正确性:
    • (1) 移除那些无工具推理模型在八次独立尝试中至少能正确回答一次的问题
    • (2) 过滤掉那些早期智能体通过基本搜索、浏览和计算在几步之内就能解决的问题
    • (3) 应用一个验证智能体进行双向验证:
      • 收集第 2 阶段搜索轨迹中的候选答案,然后独立验证候选答案和标注的真实答案的问题-答案一致性,拒绝那些答案不唯一、证据不一致或标签错误的样本
  • 这产生了高质量、高难度、可靠的多跳 QA 对
Inference with Context Management for Search Agents
  • 作者发现 BrowseComp (2025) 的性能对评估 Prompt 和评估模型都很敏感,开源的评估器可能会引入系统性偏差
    • 为了确保一致性和可重复性,作者使用官方的 OpenAI 评估 Prompt 和专有模型 o3-mini 作为评估器,标准化所有基于评估器的组件
    • 案例研究表明,这种设置最符合人工标注的真实情况,因此作者在所有实验中采用它
  • 先前的工作 (2025) 引入了上下文管理,其中 Discard-all 通过移除整个工具调用历史来重置上下文
    • 作者进一步观察到,在极长上下文(例如,超过 100k Token)下,模型准确率会显著下降
    • 受此启发,作者采用一个简单的 Keep-recent-k 策略
      • 当交互历史超过阈值 \(k\) 时,早于最近 \(k\) 轮的内容将被折叠以控制上下文长度
      • 设轨迹为
        $$ (q,r_{1},a_{1},o_{1},r_{2},a_{2},o_{2},\dots ,r_{n},a_{n},o_{n})$$
        • \(q\) 表示问题
        • \(r_{i}\) 表示第 \(i\) 轮的推理
        • \(a_{i}\) 表示动作(作者设计了搜索、打开、查找和 Python 四种工具)
        • \(o_{i}\) 表示工具观察
      • 作者只折叠早于最近 \(k\) 轮的观察结果:
        • 即折叠 \(o_{i}\gets\) 工具结果被省略以节省 Token,其中 \(i = 1,\ldots ,n - k\)
    • 在作者的实验中,设置 \(k = 5\) 产生了稳定的改进,将 GLM-5 的性能从 \(55.3%\) (不使用 keep-recent-\(k\))提升到了 \(62.0%\) (使用 keep-recent-\(k\))
    • 作者还发现,使用不同的 keep-recent \(k\) 值,或者在上下文长度达到预定义的 Token 阈值时触发 keep-recent,都会得到相同的结果
  • 在此基础上,作者将 keep-recent 与 Discard-all 结合起来,形成一种混合的分层上下文管理策略
    • 在使用 keep-recent 进行推理期间,如果总上下文长度超过阈值 \(T\) ,作者将丢弃整个工具调用历史并重新开始一个新的上下文,同时继续应用 keep-recent 策略
    • 作者通过参数搜索选择了 \(T = 32k\)
  • 如图 8 所示,在不同的计算预算下,该策略有效地释放了上下文空间,使模型能够执行更多步骤,并持续提升性能
    • 与单独使用 Discard-all 相比,结合 keep-recent-k 在所有预算下都取得了稳定的增益,最终得分达到 75.9,超过了所有配备上下文管理的开源模型
Slide Generation
  • 注:这里的 slide 生成不是多模态的,而是通过 HTML 脚本来生成
  • 采用一个自我改进的流水线,旨在通过强化学习和拒绝采样微调,训练一个专门的幻灯片生成专家,系统地提升幻灯片生成性能
  • 首先使用监督式微调初始化模型,以提供基本的幻灯片生成能力,然后使用基于演示幻灯片常见美学和结构属性的多层次奖励公式进行强化学习
    • 这个阶段显著提升了生成质量
  • 进一步进行拒绝采样微调和掩码微调,使得强化学习期间获得的知识可以被注入回训练语料库
    • 这个过程以协调和迭代的方式共同提升了数据质量和模型能力
  • 作者提出了一个多层次的奖励公式,将基于 HTML 的幻灯片生成过程中的奖励信号划分为三个层次:
    • Level-1: Static markup attributes
      • 此级别关注生成 HTML 中的声明性属性,包括定位、间距、颜色、排版、饱和度和其他样式属性
      • 基于专业设计原则,设计了一套规则来规范模型在生成此类声明时的行为
        • 这些规则确保生成的 HTML 在语法上可通过,同时将标记层面的设计空间约束在一个针对表现力、结构清晰度、视觉和谐度与可读性进行了优化的子空间内
      • 此外,作者引入了幻觉图像和重复图像检测机制,以抑制幻觉或冗余的图形
    • Level-2: Runtime rendering properties
      • 与静态检查不同,此级别评估渲染期间 DOM 节点的运行时属性,例如元素的宽度和高度、边界框以及其他几何布局度量
        • 通过约束这些属性,作者鼓励生成的幻灯片在空间组织上更贴近人类的审美偏好
      • 作者开发了一个分布式渲染服务,能够以高吞吐量执行渲染作业,同时提取所需的运行时属性
      • 在训练过程中,作者观察到了几种 Reward Hacking 行为,例如硬截断过长的内容或过度操纵间距(见图 9)
        • 为了缓解这些问题,作者改进了渲染器实现,消除了可利用的漏洞,确保奖励信号真正激励的是美学上连贯的布局,而不是对几何度量的肤浅遵从
    • Level-3: Visual perceptual features
      • 除了运行时渲染约束外,作者还将对渲染后幻灯片的感知级别评估纳入其中
        • 例如,作者检测异常空白模式作为辅助信号,以进一步改善整体构图平衡和视觉美感
Training strategy
  • 这些信号在 RL 期间被联合优化,以提高生成 HTML 的结构有效性,增强布局组织,并提升整体视觉审美质量
  • 除了奖励设计,还通过动态采样重塑训练分布
  • 结构上微不足道的样本被概率性地丢弃,使优化能够集中在更具挑战性的页面上,从而提高在复杂组合场景下的鲁棒性
  • 采用 Token-level 策略梯度损失来稳定优化 (2025)
  • 引入了一种平衡策略,将同一样本的不同 Rollout 结果分布到多个训练批次中,减少了优化偏差,提高了训练稳定性
Rejection sampling
  • 在拒绝采样阶段,RL 中使用的奖励函数被转移到一个数据过滤流水线中,以构建一个高质量的训练子集
    • 在页面级别,过滤标准包括代码有效性和编译可行性
    • 在轨迹级别,进一步强制执行工具执行正确性和全局内容多样性约束,确保结构一致性
  • 采用 Best-of-\(N\) 选择策略,从多个独立生成的候选中保留最高质量的样本
    • 这种机制有效地将分布重新加权到更高质量的实例,从而提高了样本效率和训练稳定性
Masking-based refinement
  • 尽管拒绝采样移除了大部分低质量输出,但某些轨迹的缺陷可能仅局限于少量页面
    • 丢弃此类样本会降低有效数据利用率并增加生成成本
  • 解法:引入了一个基于掩码的校正机制,该机制自动识别有缺陷的页面并应用掩码,同时保留同一轨迹中的高质量内容
    • 这种选择性优化保留了有价值的监督信号,提高了有效数据效率,并减少了冗余的再生成开销,从而提升了整体训练效率
Empirical improvements
  • 严格遵守 16:9 宽高比的生成页面比例从 \(40%\) 增加到 \(92%\) ,同时页面溢出情况大幅减少
  • 人工评估进一步显示,与 GLM-4.5 相比,GLM-5 在内容质量上实现了 \(60%\) 的胜率,在布局合理性上实现了 \(57.5%\) 的胜率,在视觉美感上实现了 \(65%\) 的胜率,总体胜率达到 \(67.5%\)
  • 这些结果为所提出的多层次奖励设计和自我改进框架的有效性提供了经验证据

Adapting GLM-5 to Chinese Chip Infrastructure(优秀!)

  • 将 GLM-5 适配到多样化的中国芯片基础设施面临着重大挑战,因为硬件生态系统的异构性常常使得高性能部署变得复杂
  • 尽管存在这些障碍,通过与七个主流中国芯片平台(包括华为昇腾、摩尔线程、海光、寒武纪、昆仑芯、MetaX 和燧原科技)的紧密合作,作者已成功实现了 GLM-5 的全栈适配
  • 本节以昇腾 Atlas 系列为案例研究,展示作者的适配方法,重点关注三个核心支柱:极致量化、高性能算子融合以及先进推理引擎调度

Mixed-Precision W4A8 quantization

  • 为了将 750B 参数的 GLM-5 模型适配到单个 Atlas 800T A3 机器上,作者实现了一种复杂的 W4A8 混合精度量化策略
  • 利用 msModelSlim 7 工具,对不同的模型组件应用了特定的精度:
    • 标准的 Attention 和 MLP 模块使用 W8A8 (INT8)
    • MoE 专家压缩到 W4A8 (INT4) 以大幅减少内存占用,同时不造成显著的精度损失
  • 采用像 QuaRot (2024) 用于抑制异常值和 Flex_AWQ_SSZ 用于缩放校准这样的先进算法,以维持在低位宽部署中的稳定性

High-Performance fusion kernels

  • 为了克服昇腾 NPU 上稀疏注意力的计算瓶颈,作者开发了一套定制化的融合算子:Lightning Indexer、Sparse Flash Attention 和 MLAPO( MLA 预处理优化)
    • Lightning Indexer 将分数计算、ReLU 和 TopK 操作集成到一个内核中,使得 NPU 能够将计算与内存访问重叠
    • 对于 Sparse Flash Attention 内核,作者专门针对 GLM-5 的稀疏模式进行了优化
      • 该内核并行处理从 KV 缓存中选择 TopK Token 以及稀疏注意力计算
    • MLAPO 将 13 个小型的预处理算子融合成一个“超级算子”,利用向量单元和 Cube 单元之间的并行处理来提升端到端效率

Specialized inference engine optimizations

  • 作者适配了两个领先的推理引擎 vLLM-Ascend 和 SGLang,以最大化硬件利用率:
    • 异步调度(Asynchronous Scheduling): 在 vLLM 内部,作者实现了一种机制,将“设备到主机”的采样拷贝与下一个解码步骤的准备重叠起来,有效地消除了调度“气泡”
    • Context Management: 像 RadixCache(前缀共享)和 Prefix Cache(将 KV 存储扩展到系统 RAM)这样的特性实现了 KV 条目的高效重用,这对于长上下文性能至关重要
    • Parallel Strategy: 作者采用了一种结合注意力数据并行和 MoE 专家并行的混合方法,并结合了 FlashComm,它将 AllReduce 操作拆分以将通信延迟隐藏在计算之后
    • Multi-Token Prediction (MTP): 通过在每步推理中生成多个 Token,作者显著提高了 NPU 的计算密度,并减少了总的序列生成时间
  • 通过这些硬件层面的协同优化,单个中国节点上的 GLM-5 实现了与双 GPU 国际集群相当的性能,同时在长序列场景下将部署成本降低了 \(50%\)

Evaluation

  • GLM-5 标志着从视频编码到智能体工程新纪元的转变
  • 作者首先在智能体、推理和编码(ARC)基准测试上评估 GLM-5 与前沿模型
  • 为了全面评估 GLM-5 在真实世界智能体工程场景中的性能,作者提出了一个新的内部评估套件 CC-Bench-V2,它包括前端、后端和 Long-horizon 任务
  • 最后,作者在五个常见的真实世界场景中评估了 GLM-5 的通用能力

Evaluation of ARC Benchmarks

  • 表 7 报告了 ARC 基准测试的主要结果
    • GLM-5 比 GLM-4.7 有显著提升,并在开源模型中实现了 SOTA 性能,缩小了与 Claude Opus 4.5 等专有模型的差距
  • 评估细节详见第 B.2 节
Evaluation of Reasoning and General Benchmarks
  • 对于推理和通用基准测试,作者评估了 Humanity‘s Last Exam (HLE) (2025)、AIME 2026、HMMT 2025、IMO-AnswerBench (2025)、GPQA-Diamond (2024) 和 LongBench v2 (2025)
  • 对于 HLE,仅评估基于文本的子集,并使用 GPT-5.2 (medium) 作为评判模型。大多数推理任务的最大生成长度设置为 131,072 个 token,而对于 HLE-with-tools,则使用 202,752 个最大 token
  • 从表 7 可以看出
    • GLM-5 在推理任务上取得了与强大的开源基线 Kimi-K2.5 相当的性能
    • 与专有模型相比,GLM-5 在 HLE(带工具)上优于 Claude Opus 4.5 和 Gemini 3 Pro
    • 与其前身 GLM-4.7 相比,GLM-5 在 HLE 基准测试(带工具和不带工具)上也取得了显著进步
    • 在 HMMT 2025 年 2 月/11 月的基准测试中,GLM-5 的表现优于 Claude Opus 4.5 和 Gemini 3 Pro
    • GLM-5 在长上下文任务上也取得了重大进展,在长上下文推理基准测试 LongBench v2 上获得了最高分,仅次于 Gemini 3 Pro
Evaluation of Coding Benchmarks
  • 对于编码基准测试,作者在 SWE-bench Verified (2023)、SWE-bench Multilingual (2025)、Terminal Bench 2.0 (2025) 和 CyberGym (2025) 上评估了 LLM
    • 对于 SWE-bench Verified 和 Multilingual,使用 OpenHands 框架,并为 GLM-5 定制了指令 Prompt
    • 对于 Terminal-Bench 2.0,使用了两个智能体框架(即 Terminus-2 和 Claude Code),作者还报告了在已验证的 Terminal-Bench 2.0 上的性能,该版本解决了一些模糊的指令
    • CyberGym 基准测试在 Claude Code 2.1.18 中进行评估
  • 从表 7 可以看出
    • GLM-5 在开源 LLM 中实现了编码基准测试的 SOTA 性能
    • 与专有 LLM 相比,GLM-5 在 SWE-bench Verified 上的表现优于 Gemini 3 Pro,并且在 SWE-bench Multilingual 上也击败了 Gemini 3 Pro 和 GPT-5.2 (xhigh)
    • 在 Terminal-Bench 2.0 上,GLM-5 取得了与 Claude Opus 4.5 相当的结果,甚至在修复了该基准测试的模糊指令后取得了更好的结果
    • For 编码能力的泛化性,在两个智能体框架上评估了 Terminal Bench 2.0,GLM-5 显示出与 Claude Opus 4.5 和 GPT-5.2 (xhigh) 相媲美的一致性能
Evaluation of Agentic Abilities
  • 对于智能体基准测试,作者在 BrowseComp (2025)、BrowseComp-ZH (2025)、\(\tau^2\)-Bench (2024)、MCP-Atlas (2026)、Tool-Decathlon (2025)、Vending-Bench 2 (2025) 和 GDPval-AA (2025) 上评估了 GLM-5 和前沿模型
    • BrowseComp 衡量语言智能体如何通过浏览网页来解决具有挑战性的问题,而 BrowseComp-ZH 主要针对中文网页
      • 作者对 BrowseComp 使用 discard-all 策略作为上下文管理,这与 DeepSeek-V3.2 和 Kimi K2.5 相同
    • \(\tau^2\)-Bench 评估对话智能体在双控环境中的能力。作者对 Retail 和 Telecom 添加了一个小的 Prompt 调整,以避免由于用户过早终止而导致的失败(参见 B.3)
      • 对于 Airline,应用 Claude Opus 4.5 系统卡 (2025) 中提出的领域修复以获得更准确的结果
    • MCP-Atlas 是一个真实的工具使用基准测试,用于评估 LLM 在给定模型上下文协议(MCP)服务器的多步骤工作流中的表现
      • 为了公平比较,作者重新评估了所有模型在 500 个任务的公共集合上,并将每个任务的超时时间从 4 分钟延长到 10 分钟,以避免因部署条件导致的任务失败
      • 作者使用 Gemini 3 Pro 作为 MCP-Atlas 的评判模型
    • Tool-Decathlon 也是一个工具使用基准测试,但针对的是真实世界、 Long-horizon 的任务
    • Vending-Bench 2 衡量 LLM 在模拟环境中长期业务场景下的智能体能力,与其前身 Vending-Bench 相比增加了更多现实因素
    • GDPval 关注 AI 智能体在具有经济价值的任务上的表现
  • 从表 7 可以看出,与 GLM-4.7 相比,GLM-5 在智能体基准测试上显著提升
    • 在 BrowseComp 上,GLM-5 在使用和不使用上下文管理的情况下,都在前沿 LLM 中实现了 SOTA 性能
    • 在 BrowseComp-ZH 上,GLM-5 也击败了 Claude Opus 4.5 和 Gemini 3 Pro。对于三个工具使用的智能体任务(即 \(\tau^2\)-Bench、MCP-Atlas 和 Tool-Decathlon),GLM-5 取得了与 Claude Opus 4.5 相当的性能,这显示了 GLM-5 强大的工具使用能力
    • GLM-5 在 Vending-Bench 2 上的表现(即 $4,432)进一步证明了其在商业任务中的 Long-horizon 能力
    • 在经济场景中,GLM-5 在 GDPval-AA 上的表现优于 Claude Opus 4.5,仅次于 GPT-5.2 (xhigh)

Evaluation of Real-world Agentic Engineering Experience

  • 真实世界的经验比排行榜更重要
  • 作者将内部 CC-Bench 升级为 CC-Bench-V2,以评估模型是否能够在现实的前端、后端和 Long-horizon 任务的智能体工程环境中正确完成端到端任务
  • CC-Bench-V2 完全去除了人工标注,并通过 Claude Code 和其他智能体工具,结合单元测试和“智能体即评判”(Agent-as-a-Judge)技术实现完全自动化
  • Frontend
    • 使用一个流水线首先构建由智能体生成的前端项目,并检查是否存在任何语法、依赖和兼容性错误
    • 然后使用“智能体即评判”(Agent-as-a-Judge)通过配备 Playwright 和 bash 工具的 GUI 智能体模拟用户交互,来验证端到端的正确性
  • Backend
    • 任务来自 C++、Rust、Go、Java、TypeScript 和 Python 的真实世界开源项目,涵盖功能实现、错误修复、回归修复和性能优化
    • 每个更改必须在现实的工程约束下通过完整的单元测试
  • Long-horizon
    • 首先评估模型在大型代码库上的信息搜寻能力,这是像人类开发者一样定位正确文件和理解项目上下文的前提条件
    • 然后通过挖掘具有大量提交历史的已合并 Pull Requests 并将其提交聚类成连贯的任务链,来评估端到端的正确性
      • 智能体顺序执行这些任务链,测试其维护上下文和解决阶段间依赖关系的能力
    • 评估结合了单元测试和“智能体即评判”(Agent-as-a-Judge),以验证功能正确性和语义遵从性
Frontend Evaluation - Agent-as-a-Judge
  • 作者开发了一个全面的自动化评估基准,专门针对前端开发场景
  • 该基准涵盖了开发者日常构建的多样化应用程序,包括落地页、管理仪表盘、数据可视化、图形与动画、在线生产力工具、互动游戏以及表单驱动的工作流,跨越主流技术栈,包括 HTML、React、Vue、Svelte 和 Next.js
  • 每个测试用例由一个包含多个具体且可实施规格的Task ,以及一个与之配对的Checklist 组成,其中每个检查项直接源自相应的规格,评估过程遵循两阶段流水线:
    1) 静态验证 (Static Verification) :作者首先验证生成的代码能否成功构建和运行
    2) “智能体即评判” (Agent-as-a-Judge) :对于正确执行的代码,作者使用一个 GUI 智能体模拟人类测试行为,以交互方式验证每个检查项,并根据要求的完成情况分配分数
  • 定义以下指标:
    • 构建成功率 (Build Success Rate, BSR) 衡量成功初始化和运行的项目比例
    • 实例成功率 (Instance Success Rate, ISR) 衡量通过所有相关规格的项目比例
    • 检查项成功率 (Check-item Success Rate, CSR) 衡量所有检查项的细粒度完成率
    • 有关数据分布以及构建和验证过程的更多详细信息,请参见附录 B.4.1
Agent-as-a-Judge
  • 前端的正确性本质上是视觉和交互性的,即错误通常只在用户点击按钮或调整窗口大小时才会显现,这使得静态分析和固定的测试套件不足以胜任
  • 因此引入“智能体即评判”(Agent-as-a-Judge)(图 10):
    • 每个生成的项目被部署在 Docker 容器中并构建以验证静态正确性
    • 成功构建的实例随后被交给一个自主的评判智能体(配备 Playwright MCP 工具的 Claude Code with Claude Sonnet 4.5),该智能体以闭环周期运行:对于每个检查项,智能体读取源代码,与实时 UI 交互(点击、按键、截图),检查终端输出,并给出通过/未通过的判断
  • 为了验证可靠性,将“智能体即评判”(Agent-as-a-Judge)的判断与独立的人类专家判断在两个维度上进行了比较
    • 对于逐点一致性,抽样了 130 个检查项,让人类专家独立评分每个项,并与智能体的判断进行比较:
      • 两者在 \(94%\) 的项上达成一致,分歧集中在主观的视觉质量标准上,而非功能规格
    • 对于排名一致性,作者使用自动化框架和人类专家评估了 8 个前沿模型(Claude Sonnet 4.5、Claude Opus 4.5、Gemini 3 Pro、GLM-4.7、DeepSeek-V3.2 等)
      • 由此产生的模型排名实现了 \(85.7%\) 的斯皮尔曼相关性,表明存在强正相关
  • 如表 8 所示
    • GLM-5 实现了 \(98.0%\) 的 BSR,并在 CSR 方面与 Claude Opus 4.5 具有竞争力
    • 但在所有三个技术栈中,ISR 仍然存在显著差距
    • 表明 GLM-5 满足了大部分单项要求,但在端到端完成整个任务方面仍落后于 Claude Opus 4.5
Backend Evaluation
  • 后端评估衡量一个编码智能体是否能够在现实的工程约束下 ,对真实世界的服务器端代码库进行正确、通过测试的修改
  • 作者整理了 85 个任务
    • 涵盖六种语言(Python、Go、C++、Rust、Java 和 TypeScript)
    • 涉及搜索引擎、数据库引擎、Web 框架、AI 推理服务、知识管理系统以及独立的算法和系统编程挑战等领域
    • 任务类型包括功能实现、错误修复、回归修复和性能优化,反映了日常后端开发的多样性
  • 为实现完全自动化评估,每个任务都配备了人工精心设计的单元测试(每个任务 5-10 个),用于验证功能正确性和边缘情况处理
    • 任务以终端基准(terminal-bench)风格打包:每个任务在一个从项目实际构建环境初始化的 Docker 容器中运行,智能体接收描述所需更改的自然语言问题陈述
    • 作者报告 Pass@1,其中只有当任务的所有相关单元测试都通过时,才认为该任务被解决
      • 这种严格的全或无标准使得该基准测试特别具有挑战性:GLM-5 和 Claude Opus 4.5 表现相当(表 8),两者都显著领先于 GLM-4.7
Long-horizon Evaluation
  • Long-horizon 评估针对的是将生产级智能体工程与单轮“氛围编码”区分开来的能力:
    • navigating 大型代码库和执行多步骤开发,其中每个动作都会为后续步骤重塑上下文
  • 作者将此分解为两个互补的任务
    • Large Repo Exploration
      • 任何 non-trivial 编码任务的前提都是能够在一个大型、不熟悉的仓库中定位到正确的源文件
      • 作者在包含数万个文件的实际高星级 GitHub 仓库上构建了一个自动化基准测试
      • 每个问题都以自然、面向用户的业务语义级别提出,严格避免提及任何文件名、类名或函数名
      • 此外,问题需要从面向用户的描述到实际实现的一两跳逻辑推理
        • 例如,关于生成视频中唇形同步错位的问题,可能映射到视频生成后端内部的参数调整块
      • 目标文件的选择旨在最大化导航难度:它们位于至少三层深的目录中,名称晦涩难懂,难以通过关键词搜索找到,实现的功能在仓库中是独特的且无重复,并且位于其主要功能表面之外
      • 作者报告三次运行的平均 Pass@1,如果智能体在探索过程中成功读取了目标文件,则认为该问题被解决
      • 在此任务中,GLM-5 优于 Claude Opus 4.5(表 8),两者都远远领先于 GLM-4.7
      • 结果表明,有效的仓库探索较少依赖于原始的代码生成能力,而更多依赖于策略性搜索,即通过目录级推理和语义关联迭代缩小文件空间,而 GLM-5 在智能体工具使用轨迹上的训练提供了明显的优势
    • Multi-step Chained Tasks
      • 主流的编码基准测试如 SWE-bench 将评估简化为单次提交、孤立的编辑,因此无法评估智能体执行增量开发的能力,其中每一步都会为后续步骤改变代码库状态
      • 为了解决这个问题,作者通过从高质量仓库中挖掘已合并的 Pull Request 并按照以下流水线组装任务链,构建了一个 Long-horizon 基准测试:
        • 1)PR Filtering
          • 仅保留包含测试、包含 3-15 次提交且遵循线性(非合并)历史的已合并 PR
        • 2)Semantic Grouping
          • 一个 LLM 对相邻提交之间的成对语义相关性进行评分;动态规划找到最优分区,将其划分为连贯的任务组,同时保持提交顺序并最大化组内连贯性
        • 3)补丁分类 (Patch Triage)
          • 每个任务的累积差异被分为三类:golden patch(智能体必须生成的核心代码)、test patch(验证测试)和自动应用补丁 (auto-apply patch)(自动应用的配置和固定内容)
        • 4)Problem Statement Generation
          • 一个 LLM 根据每个任务的补丁和提交消息生成自然语言的问题陈述
        • 5)Task Classification
          • 任务被自动分类(功能/错误修复/重构/测试/配置),并沿着三个轴进行评估:错误消除、关键路径准确性和测试通过率
        • 6)Environment Validation
          • 构建 Docker 环境,并应用黄金补丁以验证整个链上的零回归
  • 给定一个包含 \(K\) 个任务的链,智能体从基础提交开始,顺序工作:
    • 完成第 \(k\) 个任务后,其更改被提交,然后应用第 \(k + 1\) 个任务的自动应用补丁,因此代码库状态是累积演变的
    • 评估依次检查每个提交,并在运行完整测试套件之前,累积应用从任务 1 到 \(k\) 的测试补丁,从而捕获当前任务的失败以及早期任务的回归
    • 作者报告单个任务的 Pass@1
    • 这种链式和状态递归的设计直接评估了长程上下文跟踪、规划和增量开发能力,而这些是单次提交基准测试未涉及的
  • 如表 8 所示
    • GLM-5 比 GLM-4.7 有了显著改进,但与 Claude Opus 4.5 相比仍有显著差距
      • 这是因为错误会在整个链中累积:一个任务中的次优编辑可能会悄无声息地破坏后续任务的测试
    • 缩小这一差距需要在长上下文一致性和 Long-horizon 自我纠正方面取得进展,这两个方面都是作者正在进行的研究的重点领域
Evaluation on evolving SWE tasks
  • SWE-bench Verified 是一个静态的、公开的、人工验证的测试集,并且已经发布两年多了
    • 注:SWE-rebench 构建在一个自动化流水线上,该流水线持续挖掘新鲜的、真实的 GitHub 问题修复任务,从而实现数据去污和时间鲁棒的评估,更好地衡量对新软件工程问题的泛化能力,而不是在静态基准测试上的性能
  • 表 9 显示了 GLM-5 在 SWE-rebench 上的官方性能:GLM-5 可以有效地泛化到新的 SWE 问题

Evaluation of Real-world General Abilities

  • 虽然标准化学术基准提供了有用的信号,但它们并不能完全捕捉模型在实际使用中的方式
  • 为了认识到这一差距,作者在从部署环境中观察到的高频用户交互模式中衍生出的真实世界通用能力集合上评估了 GLM-5
  • 这些能力包括机器翻译、多语言对话、指令跟随、世界知识和工具调用
  • 与传统的以基准为中心的评估不同,作者的目标是衡量能直接转化为用户感知质量提升的改进
  • 对于每种能力,作者采用内部人工评估、内部自动化评估、外部人工评估和外部自动化基准测试相结合的方式,确保诊断粒度细致和跨模型可比性
  • 在使用外部基准测试时,作者优先选择那些能反映真实交互模式而非狭隘构建的测试分布的数据集
  • 图 11 展示了 GLM-5 和 GLM-4.7 在五个真实世界能力领域上的比较结果
    • 在所有评估维度上,GLM-5 在机器翻译、多语言对话、指令跟随、世界知识和工具调用方面都表现出一致的改进
  • 每种能力的详细评估协议和数据集描述如下
Machine Translation
  • 使用 ZMultiTransBench
    • 这个是 智谱内部的数据集,包含 1,220 个样本,来源于自行收集的高频翻译场景,涵盖七个语言对:中文到西班牙语(300 个)、俄语(250 个)、法语(220 个)、韩语(200 个)、日语(150 个)、阿拉伯语(50 个)和德语(50 个)
    • 所有样本均由受过正式翻译学研究生教育的毕业生进行整理、翻译和独立验证
    • 该数据集强调自然发生的使用环境,而非人为构建的测试用例
    • 评估是通过与固定基线 Response 进行成对比较来进行的
    • 判断由基于 GPT-4.1 的自动化评估器提供,该评估器评估语义保真度、流畅度和整体翻译质量
Multi-lingual Dialogue
  • LMArena
    • 报告来自 LMArena 的 Elo 评分,这些评分源自大规模的、社区提交的成对比较
    • 这些评分反映了在开放式对话环境中模型的相对偏好,并提供了对话性能的外部信号
  • ZMultiDialBench
    • 作者在 ZMultiDialBench(一个内部多语言对话基准测试)上进行人工评估
    • 该数据集包含 141 个精选实例,涵盖不同的对话类别
    • 样本来自多个国家母语标注者提供的高质量对话数据,以及在线用户报告的具有挑战性的失败案例
    • 人工标注者根据类别特定、标准化的评估标准,对匿名化的模型 Response 进行 1-10 分的逐点评分
Instruction Following
  • IF-Badcase
    • IF-Badcase 是一个智谱内部基准测试,由实际生产环境中真实用户报告的指令跟随失败案例构建而成
    • 该数据集旨在评估对现实的、多约束指令的严格遵守程度,强调程序准确性、逻辑一致性和严格的格式要求
    • 评估使用详细的基于检查清单的协议进行,该协议验证对显式约束(包括有序步骤、基于规则的条件和结构规范)的遵从性
    • 所有样本均由人类专家进行标注、审查和迭代过滤,最终得到 450 个精选测试实例
  • IF-Bench (2025)
    • IF-Bench 评估 LLM 遵循复杂、客观约束的能力,例如特定的格式规则、长度限制和内容限制
    • IF-Bench 提供精确指令跟随能力的量化度量,侧重于可验证的遵从性,而非开放式生成质量
  • MultiChallenge (2025)
    • MultiChallenge 通过真实的多轮对话场景检验 LLM
    • MultiChallenge 针对需要准确指令跟随、上下文分配和上下文内推理的复杂交互
World Knowledge
  • SimpleQA (2024)
    • SimpleQA 使用具有单一、无可争议答案的挑战性问题来衡量简短形式的事实性
    • SimpleQA 通过将 Response 分类为正确、不正确或未尝试来评估模型的校准能力,优先考虑准确性而非生成长度
  • Chinese SimpleQA (2024)
    • 将 SimpleQA 方法应用于中文语境,该基准测试评估跨六个主要领域和 99 个子主题的事实性
    • Chinese SimpleQA 利用高质量、静态的、简短回答问题,专为可靠的自动化评分设计,以评估 LLM 的知识准确性
Tool Calling
  • ToolCall-Badcase
    • ToolCall-Badcase 是一个智谱内部基准测试,源自用户在生产环境中报告的工具调用场景的失败案例
    • 每个实例都关联一个可验证的真实工具调用,从而能够客观评估工具选择和参数填充

Easter Eggs

  • “Pony Alpha” 实验对我们来说确实是一个关键时刻
    • 注:GLM-5 最初被匿名以 “Pony Alpha” 的身份发布在 OpenRouter 上
  • 在 OpenRouter 上匿名发布 GLM-5 是一个大胆的决定,但结果令人难以置信地满意
  • 通过剥离作者的品牌名称,作者让模型的内在能力为自己发声,确保作者收到的反馈是纯粹且无偏见的。以下是一个简要总结:
    • 几天之内,Pony Alpha 就引起了轰动,OpenRouter 社区的开发者们开始注意到其卓越的性能,尤其是在复杂的编码任务、智能体工作流和角色扮演场景中
    • 猜测四起,许多用户猜测这是来自 Anthropic(Claude Sonnet 5)的泄露更新、一个秘密的 Grok 发布,或者 DeepSeek V4
    • 初步统计显示,\(25%\) 的用户猜测是 Claude Sonnet 5,\(20%\) 猜测是 DeepSeek,\(10%\) 猜测是 Grok,其余猜测是 GLM-5
    • 最终确认它确实是 GLM-5,这对作者来说是一个意义深远的时刻,有效地平息了关于中国 LLM 是否能在前沿水平竞争的疑虑
      • Pony Alpha (GLM-5) 的成功不仅仅关乎原始基准测试;它标志着作者专注于工程级可靠性的转变
    • 这次匿名发布使作者能够超越地缘政治偏见,社区接受这个模型是因为它有效
  • 在作者庆祝这一成功的同时,必须保持务实
    • 开源权重模型与绝对专有前沿之间的差距正在缩小,但这场竞赛远未结束
    • 作者的重点仍然是坚定不移地推动可扩展、高效和智能系统的可能性边界

附录 A:Hyper-parameters

  • GLM-5 模型架构相关的超参数如表 10 所示
  • 在训练方面,遵循 GLM-4.5 的设置
    • Muon 优化器、余弦衰减和批量大小预热
    • 学习率经历从 0 到 2e-4 的预热阶段,然后在预训练阶段结束时衰减到 4e-5
    • 在 Mid-training 阶段,学习率从 4e-5 线性下降到 1e-5
    • 其他超参数与 GLM-4.5 相同
  • 对于 DSA 预热阶段,学习率从 5e-3 下降到 2e-4
  • 对于 DSA 稀疏适应阶段,使用 1e-5 的恒定学习率

附录 B:Evaluation Details

B.1 Evaluation of Base Models

  • 表 11 评估了 GLM-5 的基础模型在英语、中文、代码和数学基准上的表现

B.2 Evaluation of ARC Benchmarks

  • Humanity’s Last Exam(HLE)和其他推理任务 :
    • 使用最大生成长度 131,072 个 token 进行评估 (temperature \(= 1.0\) , top_p \(= 0.95\) , max_new_tokens \(= 131072\) )
    • 默认情况下,报告纯文本子集的结果;
      • 标记为 * 的结果来自完整数据集
    • 使用 GPT-5.2 (medium) 作为评判模型
    • 对于 HLE-with-tools,使用最大上下文长度 202,752 个 token
  • SWE-bench 和 SWE-bench Multilingual :
    • 使用 OpenHands 运行 SWE-bench 套件,并采用定制的指令 Prompt
    • 设置:temperature \(= 0.7\) , top_p \(= 0.95\) , max_new_tokens \(= 16384\) , 上下文窗口为 200K
  • BrowseComp :
    • 在没有上下文管理的情况下,保留最近 5 轮交互的详细信息
    • 在启用上下文管理的情况下,作者使用与 DeepSeek-V3.2 和 Kimi K2.5 相同的 discard-all 策略
  • Terminal-Bench 2.0 (Terminus 2) :
    • 使用 Terminus 框架进行评估
    • 设置 timeout \(= 2h\) , temperature \(= 0.7\) , top_p \(= 1.0\) , max_new_tokens \(= 8192\) , 上下文窗口为 128K
    • 资源限制上限为 16 个 CPU 和 32 GB 内存
  • Terminal-Bench 2.0 (Claude Code) :
    • 在 Claude Code 2.1.14 (think mode) 中进行评估
    • 设置 temperature \(= 1.0\) , top_p \(= 0.95\) , max_new_tokens \(= 65536\)
    • 作者做了如下改动:
      • 移除了墙上时钟时间限制,但保留了每项任务的 CPU 和内存约束
      • 修复了 Claude Code 引入的环境问题
    • 报告了在已验证的 Terminal-Bench 2.0 数据集上的结果,该数据集解决了模糊的指令问题 (参见: https://huggingface.co/datasets/zai-org/terminal-bench-2-verified)
    • 分数是 5 次运行的平均值
  • CyberGym :
    • 在 Claude Code 2.1.18 (think mode, no web tools) 中进行评估
    • 设置 (temperature \(= 1.0\) , top_p \(= 1.0\) , max_new_tokens \(= 32000\) ),每个任务超时 250 分钟
    • 结果是超过 1,507 个任务的单次运行 Pass@1
  • MCP-Atlas :
    • 所有模型都在 think mode 下进行评估,使用 500 个任务的公开子集,每个任务超时 10 分钟
    • 使用 Gemini 3 Pro 作为评判模型
  • \(\tau^{2}\) -Bench :
    • 在 Telecom 和 Retail 领域添加了小的 Prompt 调整,以避免因用户过早终止而导致的失败
    • 对于 Airline 领域,作者应用了 Claude Opus 4.5 系统卡中提出的领域修复
  • Vending-Bench 2 :
    • 运行由 Andon Labs10 独立进行

B.3 Optimized User Simulator for \(\tau^{2}\)-Bench

  • 作者在 Telecom 和 Retail 领域添加了小的 Prompt 调整,避免因用户过早终止而导致的失败

  • 优化的 Prompt 如图 12 和图 13 所示,这些优化的 Prompt 作为系统 Prompt 的一部分被整合进来

  • Figure 12: The optimized user prompt for \(\tau^{2}\)-Bench Telecom

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    SYSTEM_PROMPT = """"
    {global_user_sim_guidelines}
    <scenario>
    {instructions}
    </scenario>
    {optimized_user_prompt}
    """".strip()

    # Note:
    - Do not generate the ’###TRANSFER###’ before agent clearly tells "YOU ARE BEING
    TRANSFERRED TO A HUMAN AGENT. PLEASE HOLD ON.".
    Example:
    Case1:
    - agent: "Would you like me to transfer you to a human agent who can assist you with these options and help get your service restored?"
    - user: "Yes, please transfer me to a human agent.".
    Case2:
    - user: "YOU ARE BEING TRANSFERRED TO A HUMAN AGENT. PLEASE HOLD ON."
    - user: "###TRANSFER###"
  • Figure 13: The optimized user prompt for \(\tau^{2}\)-Bench Retail

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    # Rules:
    - Just generate one line at a time to simulate the user’s message.
    - Do not give away all the instruction at once. Only provide the information that is necessary for the current step.
    - Do not hallucinate information that is not provided in the instruction. Follow these guidelines:
    1. If the agent asks for information NOT in the instruction:
    - Say you don’t remember or don’t have it
    - Offer alternative information that IS mentioned in the instruction
    2. Examples:
    - If asked for order ID (not in instruction): "Sorry, I don’t remember the order ID, can you search for it? My name/email/phone number/zipcode is ..."
    - If asked for email (not in instruction): "I don’t have my email handy, but I can give you my name and zip code which are..."
    - Do not repeat the exact instruction in the conversation. Instead, use your own words to convey the same information.
    - Try to make the conversation as natural as possible, and stick to the personalities in the instruction.
    # Constraint Handling:
    - Provide requests strictly based on what is explicitly stated in the instruction.
    - Do not assume, extend, substitute, or generalize in any form.
    - Do not modify or relax constraints on:
    - Time / Date
    - Budget
    - Specific terms (e.g., "same" must not be replaced with "similar")
    - Core Rule: Any attribute NOT mentioned in the instruction can be either changed
    or kept the same
    - Examples:
    - If instruction says "exchange red item to blue": Only color must change, other attributes (size, material, etc.) are flexible
    - If instruction says "exchange red item to blue, keep the same size": Both color must change AND size must stay the same
    - Exception: Only follow additional constraints when explicitly stated in the
    instruction
    # Domain-Specific Rules:
    ## For Retail scenarios:
    - Focus on product attributes and exchange/return processes as specified in instructions.
    - During confirmations: Always respond based strictly on the original instruction, never deviate to match agent’s provided options. Restate your requirement from the instruction rather than selecting from agent’s choices.
    - Example: If the agent provides specific options (A/B/C) but the instruction states a general requirement (e.g., "same as pending order"), always restate or confirm based on what the instruction says, not by directly selecting from the agent’s provided options.
    # When NOT to finish the conversation:
    - Do not end until you have clearly and completely expressed all your requirements and constraints.
    - Do not end until the agent has completed all tasks mentioned in the instruction and verified no operations were missed.
    - Do not end if the agent’s execution results do not match your expectations or are incorrect/incomplete.
    # When you CAN finish the conversation:
    - Only when all above conditions are satisfied AND all tasks are completed correctly.
    - OR when you have clearly expressed complete requirements but the system explicitly states it cannot complete them due to technical limitations - in this case, accept transfer to human.
    # How to finish the conversation:
    - If the agent has completed all tasks, generate the ’###STOP###’ token to end the conversation.
    # Note:
    - You should carefully check if the agent has completed all tasks mentioned in the instruction before generating ’###STOP###’.

B.4 Evaluation of Real-world Agentic Engineering Experience

B.4.1 Frontend Evaluation
  • Data

    • 作者的数据集涵盖了七种不同的前端场景,旨在评估模型在多样化功能领域的工程能力:业务管理系统、网页游戏、SVG/Canvas 渲染、创意工具和编辑器、展示页面、表单和表格以及数据可视化
  • Data Distribution by Coding Languages

    • 该基准全面覆盖了三种主流范式:Vanilla Web 栈 (HTML/CSS/JS)、React 基于组件的框架以及 Vue 3 + Vite 渐进式解决方案
  • Data sample

    • 每个测试用例由三个部分组成:Task、Checklist 和专用环境 (Dedicated Environment)。下面是一个具有代表性的测试用例示例:

      1
      2
      3
      4
      5
      6
      Task: Develop an online drawing tool that includes a brush, an eraser, a white canvas, and a save button. The brush color and thickness should be selectable via buttons on the left. 
      Users can draw on the canvas by clicking and dragging the mouse. The eraser size should be selectable via buttons on the left. Users can erase content by clicking and dragging the mouse over the canvas.
      Once the drawing is complete, clicking the "Save" button should allow the user to save the image locally. Please implement this using the React framework in the current directory.

      Checklist: The user can select the brush color and thickness using the left-hand buttons, and drawing is functional via mouse click-and-drag on the canvas. The user can select the eraser size using the left-hand buttons,
      and erasing is functional via mouse click-and-drag on the canvas. Upon clicking the "Save" button, the generated image is successfully saved to the local machine.
    • 中文版:

      1
      2
      3
      4
      5
      **Task** :开发一个在线绘图工具,包含画笔、橡皮擦、白色画布和一个保存按钮。画笔颜色和粗细应可通过左侧按钮选择。用户可通过点击并拖动鼠标在画布上绘图。橡皮擦大小应可通过左侧按钮选择。用户可通过点击并拖动鼠标在画布上擦除内容。绘图完成后,点击“保存”按钮应允许用户将图像保存到本地。请使用 React 框架在当前目录中实现此功能
      **Checklist** :
      * 用户可以使用左侧按钮选择画笔颜色和粗细,并且可以通过鼠标点击并拖动在画布上绘图
      * 用户可以使用左侧按钮选择橡皮擦大小,并且可以通过鼠标点击并拖动在画布上擦除内容
      * 点击“保存”按钮后,生成的图像成功保存到本地机器
  • Data Construction and Validation ,作者实施了一个严格的四阶段流程来确保数据质量:

    • Stage 1: Task Synthesis:
      • 任务由资深前端专家设计,以确保其反映现实世界的工程挑战,同时在多样化的场景和技术之间保持平衡分布
    • Stage 2: Checklist Generation and Refinement:
      • 首先使用 Claude Sonnet 4.5 根据任务规范 \(T\) 合成候选检查表
      • 然后由专家进行细致的审核和整合
      • 通过多轮完善,作者确保每个检查项在语义上是明确的、客观的,并提供用户需求的详尽覆盖
    • Stage 3: Execution- based Correction:
      • 在 Agent-as-a-Judge 框架和人类专家之间进行交叉验证
      • 判断中的任何差异都会触发对底层数据的重新评估和修正,以消除潜在噪声
    • Stage 4: Dynamic Benchmark Iteration:
      • 为保持较高的区分度,移除那些不再对 SOTA 编码智能体构成挑战的琐碎任务,来迭代更新测试套件
      • 这个由专家主导的筛选过程最终形成了 220 个高质量的前端编码任务及其相应的检查表

NLP——LLM对齐微调-FP16-Defeats-Training-Inference-Mismatch

注:本文包含 AI 辅助创作

  • 参考链接:
    • 原始论文:Defeating the Training-Inference Mismatch via FP16, 20251030, Sea AI & NUS

Paper Summary

  • 整体说明:
    • Training-Inference Mismatch 从根本上讲是一个数值精度问题
    • 本文提出一种简单的方法:简单地从标准的 BF16 格式 切换到 更高精度的 FP16 格式 几乎可以消除这种不匹配
    • 结论:FP16 应被重新考虑作为 LLM 稳健 RL 微调的基础选项
  • 背景 & 总结:
    • Training-Inference Mismatch 是 RL 微调中不稳定的主要来源
      • LLM 的 RL 常常因训练策略与推理策略之间的数值不匹配而遭受不稳定性
      • 先前的工作试图通过算法修正或工程对齐来缓解此问题
    • 本文表明其根本原因在于浮点精度本身
      • BF16 被广泛采用,尽管其动态范围很大,但引入了较大的舍入误差,破坏了训练和推理之间的一致性
      • 本文证明了简单地恢复到 FP16 就能有效地消除这种不匹配
        • 只需更改几行代码,并且不需要修改模型架构或学习算法
    • 结果表明,在各种任务、算法和框架中,统一使用 FP16 能带来更稳定的优化、更快的收敛速度和更强的性能
  • 图 1: BF16 和 FP16 训练比较
    • 不同的算法 (GRPO, GSPO, TIS, MIS, PG)
    • 不同的模型家族 (R1D, Qwen 和 OctoThinker)
    • 微调方法 (Lora)
    • 更大规模的模型 (Dense-14B, MoE)
    • 框架:VeRL 和 Oat

Introduction and Discussion

  • 背景 & 问题提出
    • LLM 的 RL 训练常常充满不稳定性
      • 训练过程对超参数极为敏感,并且可能遭遇训练崩溃
    • 这种不稳定的一个关键来源源于现代 RL 框架中的一个基本差异: Training-Inference Mismatch
      • 为加速训练,RL 框架通常使用不同的计算引擎:
        • 一个用于快速推理 (Rollout)
        • 一个用于训练 (梯度计算)
      • 在数学上是相同的,但由于精度错误和硬件特定的优化,这些引擎会产生数值上不同的输出
      • 正如最近的工作所强调的 (2025; 2025a; 2025a),这种看似微小的推理与训练之间的不匹配给优化过程带来了严重问题
  • 现有解决方案:
    • 现有的解决方案试图通过基于重要性采样的算法补丁来解决这种不匹配
      • (TIS)Your Efficient RL Framework Secretly Brings You Off-Policy RL Training, 20250805-20251013(参见本人博客:NLP——LLM对齐微调-TIS) 引入了一个 Token-level 重要性采样比率作为对 GRPO 梯度的补丁(这种简单的修正可以延长训练时间)
      • 后来 (Sequence-level MIS)When speed kills stability: Demystifying RL collapse from the training-inference mismatch, 20250927, ByteDance(参见本人博客:NLP——LLM对齐微调-RL-Collapse-Training-Inference-Mismatch(Sequence-level MIS)) 指出 Token-level TIS 方法的梯度偏,不足以完全稳定训练
        • 他们提出使用无偏的、 Sequence-level 重要性采样比率进行修正
        • 这种方法更稳定,但其有效性受限于缓慢的收敛速度,这是 Sequence-level 比率固有高方差的直接结果
    • 上述这两种算法方法都面临两个根本问题:
      • 1)计算效率低下,实现需要额外的前向传播来计算其修正所需的重要性采样比率
        • 假设反向传播的成本是前向传播的两倍,这大约增加了 \(25%\) 的训练成本
      • 2)部署差距 (deployment gap) 仍然存在
        • 解决方案在训练期间修正了不匹配问题,但最终的模型参数是针对训练引擎的概率分布进行优化的
        • 这意味着得到的模型对于部署中使用的推理引擎并非真正最优,这可能导致实际性能下降
      • 以上这两点要求我们从根源上消除不匹配,而不仅仅是补偿它
  • 本文的解法:
    • 本文研究数值不匹配的根本原因:浮点精度
    • 本文确定现代混合精度训练的标准(BFloat16,BF16)是主要的罪魁祸首
      • BFloat16 具有广泛的动态范围,这对于稳定的预训练非常有利,但其低精度使其极易受到舍入误差的影响 ,这些误差会累积并最终导致训练策略和推理策略发散
  • 实验:在 RL 微调期间,通过从 BF16 切换到 FP16,几乎可以消除 Training-Inference Mismatch
    • FP16 拥有更多的尾数位,提供了更高的数值精度,使得结果对训练和推理之间的实现差异不那么敏感
  • 这一简单改变的好处是多方面的
    • 消除了复杂的算法变通方案以及伴随的概率评估,将 RL 恢复到其最纯粹的重要性加权策略梯度形式
    • 弥合了现有修正方案都无法解决的部署差距
    • 在性能和稳定性上都有显著且统一的提升,为基于 RL 的 LLM 对齐中的一个关键挑战提供了一个干净、高效且普遍适用的解决方案

Background

  • 现代 LLM 微调的 RL 框架中,为最大化系统效率,推理和训练使用了不同的引擎

  • 不可避免地导致了推理策略 \(\mu (\cdot |\theta)\) 和训练策略 \(\pi (\cdot |\theta)\) 之间的不匹配,这是由于微妙的数值差异造成的,尽管原则上两者在数学上应该是相同的 \((\mu = \pi)\)

  • 这种不匹配带来了下面详述的两个问题

    • Biased Gradient:
      • 为了优化策略 \(\pi_\theta(\cdot|\theta)\),一般典型的做法是优化下面的目标:
        $$\mathcal{J}(\theta) = \mathbb{E}_{x\sim p_{\mathcal{X} } }\left[\mathcal{J}(x,\theta)\right] = \mathbb{E}_{x\sim p_{\mathcal{X} } }\left[\mathbb{E}_{y\sim \pi (\cdot |x,\theta)}[R(x,y)]\right] \tag {1}$$
        • \(x\) 是从分布 \(p_{\mathcal{X} }\) 中采样的提示
        • \(y\) 是 Response
        • \(R(x,y)\) 是 \(y\) 的奖励
      • 策略梯度可以通过 REINFORCE 估计量计算:
        $$
        \begin{align}
        \nabla_{\theta}\mathcal{J}(\theta) &= \mathbb{E}_{x\sim p_{\mathcal{X} } }\left[\nabla_{\theta}\mathcal{J}(x,\theta)\right]\\
        \nabla_{\theta}\mathcal{J}(x,\theta) &= \mathbb{E}_{y\sim \pi (\cdot |x,\theta)}\left[\nabla_{\theta}\log \pi (y|x,\theta)\cdot R(x,y)\right]. \end{align}\tag {2}
        $$
      • 实践中,从推理策略 \(\mu\) 中采样 Response,而不是从训练策略 \(\pi\)
        • 正如 (TIS)Your Efficient RL Framework Secretly Brings You Off-Policy RL Training, 20250805-20251013 和 (Sequence-level MIS)When speed kills stability: Demystifying RL collapse from the training-inference mismatch, 20250927, ByteDance 所指出的,如果简单地忽略这种不匹配,策略梯度将变得有偏
          $$
          \begin{align}\nabla_{\theta}\mathcal{J}_{\text{biased} }(x,\theta) &= \mathbb{E}_{y\sim \mu (\cdot |x,\theta)}\left[\nabla_{\theta}\log \pi (y|x,\theta)\cdot R(x,y)\right]\\
          &\neq \nabla_{\theta}\mathcal{J}(x,\theta) \end{align}\tag {3}
          $$
  • Deployment Gap

    • 另一个重要但难以修复的问题是部署 Gap
    • 虽然训练的是 \(\pi (\cdot |\theta)\),但在部署和评估时使用的是 \(\mu (\cdot |\theta)\)
    • 在训练引擎 \(\pi\) 下优化的参数 \(\theta\) 对于推理引擎 \(\mu\) 来说不一定是最优的:
      $$\arg \max_{\theta}\mathbb{E}_{x\sim p_{\mathcal{X} },y\sim \mu (\cdot |x,\theta)}[R(x,y)]\neq \arg \max_{\theta}\mathbb{E}_{x\sim p_{\mathcal{X} },y\sim \pi (\cdot |x,\theta)}[R(x,y)]\tag {4}$$
    • 这种部署差距导致了由于这种不匹配而产生的不可忽视的性能下降
    • 虽然算法补丁 (2025; 2025a) 修正了有偏梯度,但它们在本质上无法弥合部署差距,这要求我们从根本上消除这种不匹配

Correcting Biased Gradient via Importance Sampling,通过重要性采样修正有偏梯度

  • 为了修正由 Training-Inference Mismatch 引入的有偏梯度,一个 Principled 方法是使用重要性采样 (IS)
    • 使用 Sequence-level 概率比率对梯度计算进行重新加权,确保梯度估计量是无偏的
    • 给定提示 \(x\) 的策略梯度被修正为:
      $$\nabla_{\theta}\mathcal{J}_{\text{pg - is} }(x) = \mathbb{E}_{y\sim \mu (\cdot |x,\theta^{\prime})}\left[\frac{\pi(y|x,\theta)}{\mu(y|x,\theta^{\prime})}\nabla_{\theta}\log \pi (y|x,\theta)\cdot A(x,y)\right] \tag {5}$$
      • \(\theta^{\prime}\) 表示用于采样的参数,在 off-policy 设置中可能与 \(\theta\) 不同
      • \(A(x,y) = R(x,y) - B(x)\) 是优势函数,\(B(x)\) 作为降低方差的基线
  • 这种修正理论上合理,但这个估计量通常存在高方差问题,尤其是在 LLM 的背景下,Response 序列很长,导致极端的概率比率
    • 为了缓解这个问题,人们提出了诸如截断重要性采样 (Truncated Importance Sampling, TIS) (2018; 2025) 和掩码重要性采样 (Masked Importance Sampling, MIS) (2025; 2025b; 2025a) 等技术,它们用少量的偏差来换取方差的大幅降低:
      $$\begin{align}\nabla_{\theta}\mathcal{J}_{\text{pg - tis} }(x) &= \mathbb{E}_{y\sim \mu (\cdot |x,\theta^{\prime})}\left[\min \left(\frac{\pi(y|x,\theta)}{\mu(y|x,\theta^{\prime})},C\right)\cdot \nabla_{\theta}\log \pi (y|x,\theta)\cdot A(x,y)\right]\\
      \nabla_{\theta}\mathcal{J}_{\text{pg - mis} }(x) &= \mathbb{E}_{y\sim \mu (\cdot |x,\theta^{\prime})}\left[\frac{\pi(y|x,\theta)}{\mu(y|x,\theta^{\prime})}\cdot \mathbb{I}\left\{\frac{\pi(y|x,\theta)}{\mu(y|x,\theta^{\prime})}\leq C\right\} \cdot \nabla_{\theta}\log \pi (y|x,\theta)\cdot A(x,y)\right], \end{align}\tag {7}$$
      • \(C\) 是一个裁剪超参数
      • \(\mathbb{I}\{\cdot \}\) 是指示函数
  • 以上这些方法都通过控制重要性权重的幅度来稳定训练
Existing Implementations,现有实现
  • 虽然总体上受到 IS 原理的启发,但最近的方法 (TIS)Your Efficient RL Framework Secretly Brings You Off-Policy RL Training, 20250805-20251013 和 (Sequence-level MIS)When speed kills stability: Demystifying RL collapse from the training-inference mismatch, 20250927, ByteDance 实际上是作为 GRPO 之上的辅助补丁来实现的,而不是遵循严格 Principled 公式
    • 许多 RL 框架 (例如,VeRL) 是以 GRPO 为中心的,并未原生提供公式 (5)、公式 (6) 和公式 (7) 中概述的标准重要性加权估计量
  • 标准的 GRPO 梯度 (2024; 2025c) 没有修正 Training-Inference Mismatch ,其计算如下:
    $$\begin{align}\nabla_{\theta}\mathcal{J}_{\text{grpo} }(x) &= \mathbb{E}_{y\sim \mu (\cdot |x,\theta^{\prime})}\left[\sum_{t = 1}^{|y|}\nabla_{\theta}\min \left(r_{t}A_{t},\text{clip}(r_{t},1 - \epsilon ,1 + \epsilon)A_{t}\right)\right]\\
    \text{where } r_{t} &= \frac{\pi(y_{t}|x,y_{< t},\theta)}{\pi(y_{t}|x,y_{< t},\theta^{\prime})}\text{ and } A_{t} = R(x,y) - \frac{1}{G - 1}\sum_{i = 1}^{G - 1}R(x,y_{i}) \end{align}\tag {8}$$
    • 注:这里是 RLOO 的实现,且没有添加 Group 归一化(Dr.GRPO 的做法)
    • 对于每个 Prompt \(x\)
      • 从推理策略 \(\mu (\cdot |x,\theta^{\prime})\) 中采样一组 \(G\) 个 Response \(\{y_{i}\}_{i = 1}^{G}\),以计算优势函数 \(A_{t}\)
      • 如同在 GRPO 和 RLOO (2024; 2019) 中一样
  • 基于 GRPO,(TIS)Your Efficient RL Framework Secretly Brings You Off-Policy RL Training, 20250805-20251013 引入了一个 Token-level TIS 修正:
    $$\begin{align}\nabla_{\theta}\mathcal{J}_{\text{grpo - tok - tis} }(x) &= \mathbb{E}_{y\sim \mu (\cdot |x,\theta^{\prime})}\left[\sum_{t = 1}^{|y|}\min (\rho_{t},C)\cdot \nabla_{\theta}\min \left(r_{t}A_{t},\text{clip}(r_{t},1 - \epsilon ,1 + \epsilon)A_{t}\right)\right]\\
    \text{where }\rho_{t} &= \frac{\pi(y_{t}|x,y_{< t},\theta^{\prime})}{\mu(y_{t}|x,y_{< t},\theta^{\prime})}. \end{align}\tag {9}$$
  • 随后,(Sequence-level MIS)When speed kills stability: Demystifying RL collapse from the training-inference mismatch, 20250927, ByteDance 通过提出一个 Sequence-level MIS 变体推进了这种方法
    • 此修正应用于整个 GRPO 梯度项,使用整个序列的单个比率来决定是否应用更新:
      $$\begin{align}\nabla_{\theta}\mathcal{J}_{\text{grpo-seq-mis} }(x) &= \mathbb{E}_{y\sim \mu (\cdot |x,\theta^{\prime})}\left[\rho \cdot \mathbb{I}\{\rho \leq C\} \cdot \sum_{t = 1}^{|y|}\nabla_{\theta}\min \left(r_{t}A_{t},\text{clip}(r_{t},1 - \epsilon ,1 + \epsilon)A_{t}\right)\right]\\
      \text{where }\rho &= \frac{\pi(y|x,\theta^{\prime})}{\mu(y|x,\theta^{\prime})}. \end{align}\tag {10}$$
  • 与原始的 policy gradient 估计量 (公式 (5) 及其 TIS/MIS 变体) 相比,现有的基于 GRPO 的实现需要 额外的前向传播 来计算 \(\pi (\cdot |\theta^{\prime})\) 以进行它们的 off-policy 修正
    • 假设反向传播的成本是前向传播的两倍 (2023),这个额外步骤在训练期间大约会产生 \(25%\) 的计算开销

Engineering Attempts to Reduce the Mismatch, 工程尝试 for 减少 Mismatch

  • 另一条工作路线试图从工程角度减轻 Training-Inference Mismatch ,但成效有限
    • 用 FP32 的语言模型头 (2025)
      • 被证明不足以防止训练崩溃 (2025; 2025a)
    • 最近,Team 等 (2025a) 报告了通过手动对齐训练和推理实现取得了有希望的结果
      • 但这种方法需要深入的领域知识和大量的工程努力,并且目前尚不清楚这种特定的修复方法能否在不同的框架或模型之间推广
    • He (2025) 的一项相关工作展示了如何在推理中强制执行确定性
      • 但其方法会带来显著的成本效率降低,并且不能直接解决 Training-Inference Mismatch 问题
  • 尽管做出了这些工程努力,但由于训练和推理计算之间的根本差异难以调和,这种不匹配仍然存在
    • Token 在推理期间是自回归生成的,但在训练期间是并行处理的
      • 不同的并行化策略以及诸如 MoE 模型中的 top-k 专家选择等对精度敏感的操作,使情况进一步复杂化
    • 这种固有的困难凸显了需要一个更根本的解决方案,以避免这种复杂而脆弱的工程变通方法

Revisiting FP16 Precision,重新审视 FP16 精度

  • 对 Training-Inference Mismatch 的调查中,本文发现了一个非常简单但非常有效的补救措施,它避免了复杂的算法或工程修正
  • 这种方法没有引入额外的机制,而是关注一个更基础的因素:数值精度
  • 仅仅将训练精度从当前占主导地位的 BF16 格式 (2012; 2019) 切换到较早的 Float16 (FP16) 格式 (2017),就能显著减轻策略不匹配,并在各种 RL 算法上产生显著的性能提升
  • 本节将回顾这些浮点格式的历史和特性,以揭示这一反直觉但强大的结果

FP16 vs. BF16

  • 浮点格式通过在其两个组成部分之间分配比特位来表示实数:
    • 指数位 (exponent bits),决定数值的范围(数值可以有多大或多小)
    • 尾数位 (mantissa bits,也称为小数位),决定数值的精度(在该范围内数值的区分精细程度)
    • FP16 和 BF16 都使用总共 16 比特,它们的分配方式不同,导致了在范围和精度之间的不同权衡(见表 1)
  • FP16 (IEEE 754 半精度) 分配 5 比特给指数,10 比特给尾数
    • 相对较大的尾数使 FP16 具有更高的数值精度,使其能够准确地表示相邻值之间的微小差异
    • 但其有限的 5 比特指数严重限制了动态范围,使得 FP16 容易发生溢出(数值超过可表示的最大值)和下溢(数值舍入为零)
    • 使用 FP16 训练通常需要稳定性技术,如损失缩放 (loss scaling),以缓解这些问题(参见第 3.2 节)
  • BF16 (bfloat16) 由 Google 推出,分配 8 比特给指数(与 32 比特 FP32 格式的范围相匹配),只分配 7 比特给尾数
    • 这种设计提供了与 FP32 相当的广泛动态范围,使 BF16 对溢出和下溢具有很强的抵抗力,但代价是精度降低
    • 由此产生的低精度下的数值鲁棒性是其在大规模深度学习系统中被广泛采用的关键原因

Stabilizing FP16 Training with Loss Scaling,使用损失缩放稳定 FP16 训练

  • FP16 有限范围带来的主要挑战是梯度下溢,这可以在混合精度训练的历史早期通过一种称为损失缩放的技术有效解决 (2017),该过程很简单:
    • 1)在反向传播之前,将损失乘以一个大的缩放因子 \(S\)
    • 2)这将所有梯度放大了 \(S\) 倍,将小的梯度值移出下溢区域,进入 FP16 的可表示范围,从而保留它们
    • 3)在更新权重之前,通过除以 \(S\) 将梯度缩放回原始值
  • 现代实现通过动态损失缩放进一步改进了这一点
    • 缩放因子 \(S\) 在训练期间自动调整
      • 如果在一定步数内未检测到溢出(梯度中的无穷值),则增加 \(S\)
      • 如果发生溢出,则立即减小 \(S\)

The Rise of BF16 in Modern LLM Training,BF16 在现代 LLM 训练中的兴起

  • 损失缩放有效,但它在分布式环境中使系统复杂化,因为在执行优化器步骤之前需要全局同步以检查溢出并确保所有工作节点上的缩放因子一致
  • BF16 在诸如 Google TPU 以及后来的 NVIDIA GPU(从 Ampere 架构开始)等硬件上的引入是一个游戏规则的改变者
    • 由于具有与 FP32 相同的动态范围,BF16 提供了 FP32 的“直接替代品”,无需繁琐的损失缩放
    • 其对溢出和下溢的鲁棒性使得训练 LLM 更加稳定和直接
    • 因此,BF16 迅速成为现代混合精度训练的事实标准

Why FP16 is the Key for RL Fine-Tuning,为什么 FP16 是 RL 微调的关键

  • BF16 的稳定性对预训练模型来说是优势,但本文作者的发现表明,其低精度是 Training-Inference Mismatch 的根源
  • 现代 RL 框架经常使用不同的引擎或优化过的内核进行训练和推理
    • 即使两者都配置为使用 BF16,它们在实现上的细微差异(例如,CUDA 内核优化、并行策略)也可能导致 BF16 上产生不同的舍入误差
    • 当这些微小的差异在自回归采样期间累积到一个 token 序列上时,\(\pi\) 和 \(\mu\) 产生的概率分布可能会出现显著差异
    • 这种差异正是前面讨论的有偏梯度和部署差距的根源
  • 这正是切换到 FP16 能提供根本性解决方案的原因
    • 凭借其 10 位尾数,FP16 提供的精度是 BF16 的 8 倍 (\(2^{10}\) 个值 vs. \(2^{7}\) 个值)
    • 这种更高的保真度意味着训练和推理引擎的输出在数值上更有可能相同
    • 更高的精度创建了一个缓冲区,吸收了这两个引擎之间微小的实现差异,防止了舍入误差累积并导致策略发散
  • 对于 RL 微调,模型权重和激活值的动态范围已经在预训练期间确立
    • 因此,BF16 的极端范围变得不那么关键,而它牺牲的精度则成为一个主要的缺点
    • 通过恢复到 FP16,本文用 BF16 不必要的范围换取了关键的精度,从而在没有任何复杂算法或工程变通方案的情况下有效地缩小了训练和推理之间的差距

Offline Analysis Results

  • 在进行 RL 微调之前,本文首先进行离线分析,以检查在不同数值精度下的性能和 Training-Inference Mismatch 情况
  • 实验一:使用 DeepSeek-R1-Distill-Qwen-1.5B 模型 (2025),在 BF16 和 FP16 两种精度下,从 AMC 和 AIME 基准 (2024) 中为每个问题采样 32 个 Response,总 Token 预算为 32K
    • 如表 2 所示,它们的性能大体相当,这表明仅提高推理精度本身并不一定能带来改进
  • 实验二:使用温度 1.0 并且不使用 top-\(p\) 采样(这样 \(\mu\) 可以直接与 \(\pi\) 比较),为每个问题重新生成 32 个 Response,并在 DeepSpeed 训练引擎内使用相同的模型权重,在 BF16 和 FP16 设置下评估 Token 的 log-probabilities
    • 图 2 左侧的两张图显示了由此产生的 Token 概率分布
    • 可以发现 FP16 显著减少了 \(\mu\) 和 \(\pi\) 之间的不匹配,数据点更紧密地围绕对角线集中
  • 除了 Token-level 不匹配,本文还分析了 Sequence-level 不匹配,因为 \(\frac{\pi(y|x)}{\mu(y|x)}\) 作为完整 Response 的重要性采样权重的无偏估计量
    • 图 2 右侧的两张图描绘了不同生成长度下 Sequence-level log-probability 比率的分布
    • 结果清楚地表明,BF16 引入了指数级增大的不匹配,并且由于累积的自回归误差,这种不匹配随着 Response 变长而恶化,而 FP16 将不匹配保持在一个温和得多的水平(大约小 \(24 \times\) 倍)

A Sanity Test for RL Algorithms,健全性测试

  • 注:Sanity Test 是软件工程里的标准专有名词,中文一般叫 健全性测试/sanity 测试/简易冒烟测试
  • 为了严格评估 RL 算法的可靠性和鲁棒性,引入了一个新颖的健全性测试
  • 标准基准测试通常包含难度各异的问题,包括那些对于初始模型来说过于琐碎或无法解决的问题
  • Trivial 问题浪费计算资源,而无法解决的问题则使得难以判断性能不佳是源于算法缺陷还是模型本身的局限性
  • 本文的健全性测试旨在高效地消除这种歧义
    • 通过创建一个每个问题已知可解但并非 Trivial 完美数据集,可以清晰地隔离并评估 RL 算法解锁模型潜在能力的能力
    • 在这个完美数据集上,一个可靠的 RL 算法理论上应该能够达到 \(100%\) 的训练准确率
  • 通过过滤掉初始模型中那些过于琐碎和无法解决的问题来构建这个完美数据集
    • 具体来说,对 MATH 数据集 (2021) 中每个问题展开 40 个 Reponse,仅保留初始准确率介于 \(20%\) 和 \(80%\) 之间的问题
      • 这为 DeepSeek-R1-Distill-Qwen-1.5B 模型 (2025) 生成了一个包含 1,460 个问题的目标数据集
      • 该数据集的较小规模使得达到接近 \(100%\) 的准确率在计算上变得可行,从而能够进行高效且结论性的测试
  • 本文用一个明确的标准来定义本文的健全性测试:
    • 如果 RL 算法在这个完美数据集上的训练准确率收敛到高于一个高阈值(例如 \(95%\)),则视为通过
    • 未能通过此测试的算法可被视为不可靠或存在根本性缺陷,因为它无法引导模型解决已知在其能力范围内的问题
    • 虽然通过测试并不能保证普遍成功,但失败则是算法设计不良的有力指标,使该测试成为一个关键诊断工具

Experimental Setup

  • 在此健全性测试下,评估了几种代表性的 RL 算法,特别是那些旨在解决 Training-Inference Mismatch 问题的算法(见第 2.1 节)
  • 所有实验均使用 DeepSeek-R1-Distill-Qwen-1.5B 作为初始模型,上下文长度为 8,000
  • 在 8 块 NVIDIA A100 80G GPU 上运行每个实验
    • 对于每次策略迭代 (2017),对 64 个问题(每个问题有 8 次 Rollout)使用一个 batch 大小,并进行 4 次梯度更新
    • 对于 GRPO 系列的算法,默认将 clip_higher 设置为 0.28 (2025)
    • 重要性采样方法(公式 (7) 和公式 (10))的裁剪阈值设为 \(C = 3\)
  • 本文评估了一套旨在解决 Training-Inference Mismatch 问题的方法,包括:
    • 一个 vanilla GRPO 基线(具体是来自公式 (8) 的 Dr.GRPO 变体)(2024; 2025c)
    • 带有 Token-level TIS 校正(公式 (9))的 GRPO (2025)
    • 带有 Sequence-level MIS 校正(公式 (10))的 GRPO (2025a)
    • 带有重要性采样的标准策略梯度算法(公式 (5))
  • 此外,还加入了 GSPO (2025)
    • 虽然 GSPO 主要是为了解决 MoE 模型引入的不匹配问题而设计的

Comparison with Existing Algorithmic Corrections,与现有算法比较

  • 为确保鲁棒性并排除实现相关的特例,本文在两个不同的框架上进行了实验:VeRL (2024) 和 Oat (2025b)

    We identified and corrected an implementation bug in VeRL’s Dr.GRPO for our experiments. We optimized the training speed of VeRL based on https://github.com/sail-sg/odc.

  • 结果如图 3 所示,现有方法在使用 BF16 精度时显示了不稳定性
    • Vanilla GRPO 基线在训练早期就崩溃了,在 VeRL 中仅达到 \(73%\) 的峰值准确率,在 Oat 中达到 \(84%\),之后性能下降
    • Token-level TIS 校正略微延长了训练时间,但最终也失败了,在达到 \(82%\)(VeRL)和 \(88%\)(Oat)准确率后崩溃
      • 这一观察结果与 Sequence-level MIS 的发现一致
    • 令人惊讶的是,GSPO 表现出比带 Token-level TIS 的 GRPO 更长的稳定训练期
      • 尽管完全不使用推理策略 \(\mu\),但仍获得了更高的奖励

        In our VeRL experiment, the GSPO gradient norm became ‘NaN’ after 1200 steps, halting further model updates

  • 在 BF16 的所有算法校正中,只有带有 Sequence-level MIS 的 GRPO (2025a) 保持了稳定的训练而没有崩溃
    • 但这种稳定性是有代价的
    • 由于其 Sequence-level 重要性比的高方差(见图 2),该方法收敛缓慢
    • Sequence-level MIS 的峰值效果也不及 FP16
      • 理解:其实继续训练下去不好说吧?
      • Sequence-level MIS 在健全数据集上达到的最大训练准确率仅为 \(95%\)(而 FP16 为 \(99%\))
      • Sequence-level MIS 在在 AIME 2024 基准上的得分为 \(34%\)(而 FP16 为 \(39%\))
      • 以上差异显示出明显的性能上限
    • 此外,与 FP16 方法相比,Sequence-level MIS 也表现出显著的部署差距
      • 关于部署差距的更多证据可以在图 1 和图 6 中找到
The Efficacy of FP16 Precision
  • 与这些算法方法相比,简单地将训练和推理精度从 BF16 切换到 FP16 带来了巨大的改进
  • 如图 1 和图 6 所示,FP16 训练运行显著更稳定,收敛更快,并且在所有测试算法中实现了更高的最终奖励和评估分数
    • 这一结果表明,在精度层面解决不匹配问题比应用不稳定或低效的算法校正是更直接、更有效的解决方案
  • 最令人惊讶的发现是,FP16 精度从根本上改善了重要性采样的行为
    • 在 FP16 中, Sequence-level 比率(以其高方差而臭名昭著)变得更加集中和稳定(见图 2)
    • 这种稳定性使得使用经典的无偏策略梯度估计器(公式 (5))而无需任何修改成为可能
    • 如图 3 所示,这种简单的、无偏的方法在 FP16 的支持下,显著优于 BF16 中所有现有的算法校正
Training Dynamics
  • 有趣的现象:最终崩溃的算法在崩溃前都一致地显示出不断增长的 Training-Inference Mismatch ,使其成为一个潜在早期预警信号(见图 3)
  • 在此期间,即使使用的是相同副本的权重,策略差异 \(\pi (\cdot |\theta^{\prime}) - \mu (\cdot |\theta^{\prime})\) 也收敛到极端值
    • 其中一个策略的概率接近 1,而另一个接近 0
  • 本文作者怀疑这是由某种优化偏差驱动的(需要进一步验证)
  • 相比之下,稳定的算法保持了有界的不匹配
    • 重点:FP16 训练显示出比任何 BF16 方法都低得多的 Mismatch 水平
    • 这种精度层面的固有稳定性解释了为什么带有 FP16 的简单策略梯度能够超越所有现有的、更复杂的解决方案
Framework-Specific Differences
  • 虽然本文作者的核心结论在 VeRL (2024) 和 Oat (2025b) 两个框架中都成立,但作者观察到了微妙的实现依赖差异
  • 最初,Oat 中的 Training-Inference Mismatch 略小于 VeRL
    • 初始策略差异 \(\pi (\cdot |\theta^{\prime}) - \mu (\cdot |\theta^{\prime})\):
      • 在 Oat 中的最小值接近 -0.9
      • 在 VeRL 中为 -1.0
    • 即使在 FP16 下(两个框架都表现出较小的不匹配),VeRL 也更容易出现偶尔的数值尖峰
      • 这些微妙的稳定性差异(本文将其归因于它们不同的分布式后端,即 DeepSpeed ZeRO 与 PyTorch FSDP)可能解释了为什么 Oat 产生略高的训练奖励,特别是对于那些最终崩溃的算法

Reviewing RL Algorithms under FP16

  • 本节回顾各种 RL 算法在使用 FP16 精度训练时的性能
  • 如图 4 所示,算法之间的性能差异几乎变得难以区分
  • 将这种性能上的趋同归因于 FP16 中 Training-Inference Mismatch 显著减少,这有效地将优化问题转化为一个近乎 On-Policy 的设置
  • 在这种状态下,不同算法提供的复杂校正几乎没有带来额外的好处
    • 一个微小的例外:原始的 GRPO 在 AIME 2024 基准上得分略低,但在 AIME 2025 上得分也略高,因此很难对其相对性能得出明确的结论

Ablation on the Precision

  • 为了隔离训练和推理精度的影响,本文在 VeRL 框架上进行了一项消融研究,使用 vLLM (2023) 进行推理,使用 PyTorch FSDP (2023) 进行训练
  • 结果如图 5 所示
    • 当使用 BF16 精度训练时,提高推理精度能持续延长训练的稳定性并改善性能
      • 当与 FP32 推理配对时,训练运行变得完全稳定,没有崩溃的迹象
      • 但这种稳定性带来了巨大的成本:FP32 推理比 FP16 或 BF16 推理慢近三倍,使得这种组合在大规模实验中不切实际
    • 将 FP16 同时用于训练和推理产生了最佳结果
      • 这种组合不仅产生了最低的 Training-Inference Mismatch ,而且产生了最稳定的训练动态
      • 成功地在这个完美数据集上达到了接近 \(100%\) 的训练准确率,且没有任何速度损失,在稳定性和效率方面都展现出明显的优越性

Generalization Across Models, Data, and Training Regimes,跨模型、数据和训练范式的泛化

  • 第 4 节中在健全性检查设置下仔细研究了各种算法修复,结论是
    • 简单地从 BF16 切换到 FP16 可以显著提高训练稳定性(第 4.2 节),且其效果常常掩盖了算法调整的作用(第 4.3 节)
  • 本节将超越健全性检查设置,在更多样化的场景中验证本文的发现,包括 MoE RL、LoRA RL,以及在更大的 Prompt 集和其他模型家族上的 RL

MoE RL

  • MoE RL 训练以其不稳定性而闻名,通常需要复杂的稳定策略 (2025)
  • MoE 模型的训练和推理通常涉及不同的并行化策略和对精度敏感的操作,例如 top-\(k\) 专家选择,这进一步使情况复杂化,并且与密集模型相比通常会导致更大的 Training-Inference Mismatch
  • 鉴于 MoE 架构在现代 LLM 中的广泛采用,本文使用 Qwen3-30B-A3B-Base 对 MoE 模型进行 RL 实验
  • 本文评估了三种不同的算法:GRPO-Seq-MIS、GRPO-Token-TIS 和 PG-Seq-TIS,详细实验设置见第 A.1 节
    • 使用 FP16 的实验显示出更高的稳定性和持续更高的训练准确率(见图 1 中的 (i)、(j) 和 (k))以及更高的验证奖励(见图 6 中的 (i)、(j) 和 (k))
    • 这种改进在所有三种算法中都是一致的,表明采用 FP16 有效地缓解了 Training-Inference Mismatch 并提升了整体性能

LoRA RL

  • LoRA (2022) 因其效率以及与全微调相当的性能而在 LLM RL 中重新流行起来 (2025a; 2025)
  • 为了研究基于 LoRA 的 RL 如何受数值精度影响,本文在标准 MATH 数据集上使用 GRPO-Token-TIS(公式 (9))训练 Qwen2.5-Math-1.5B 模型
  • LoRA 以 rank 为 32 和缩放因子 \(\alpha = 64\) 应用于所有层
  • 遵循 Schulman 和 Lab (2025) 的做法,采用比全微调中使用的稍大的学习率 \((4 \times 10^{-5})\)
  • 如图 1 (h) 所示,基于 BF16 的 LoRA 训练在大约 600 步后崩溃,而 FP16 则在整个训练过程中保持稳定

RL on Large Dense Models

  • 使用 Qwen3-14B-Base 进行实验,并遵循 DAPO 算法 (2025)
    • 实验设置详情请参阅第 A.1 节
  • 如图 1 (l) 所示,FP16 的训练奖励增长速度远快于 BF16
  • 图 6 (l) 表明 FP16 在 AIME 2024 上取得了更高的验证准确率
  • 以上这些结果表明,使用 FP16 而不是 BF16 能有效缓解大型模型中的 Training-Inference Mismatch

RL on Other Model Families

  • 作为 RL 初始策略的基础模型可以显著影响学习动态
    • 它们不仅决定了探索的范围,还决定了网络参数和激活的数值范围和敏感性
  • 为了加强本文的实验结论,本文将研究扩展到基于 Qwen 的模型之外,并使用 GRPO 训练 OctoThinker-3B (2025b),这是一个从 Llama3.2-3B (2024) 经过推理密集型数据中间训练得到的模型
  • 如图 1 (g) 所示,由于数值不匹配,BF16 训练在大约 150 步后变得不稳定,而 FP16 则继续平稳训练,没有崩溃

Discussions

Rethinking the Precision Tradeoff in RL Fine-Tuning

  • 数值精度是 LLM 训练栈中的一个基础选择,但长期以来这一选择在预训练和后训练中都由 BF16 主导
    • 因 BF16 的广泛的动态范围和使用便捷性而备受青睐
  • 本文结果表明,对于 RL 微调,这种默认选择值得慎重考虑
    • 在 RL 阶段, Training-Inference Mismatch 成为不稳定的关键来源,BF16 的低精度加剧了这一问题
    • 只需用 BF16 的广泛动态范围换取 FP16 的更高精度,就可以实现显著更稳定的 RL 训练、更快的收敛速度和更优的最终性能
  • 注:本文作者并非声称 FP16 是普遍最优的选择
    • 对效率的追求可能会引导开发者走向更低精度,如 FP8
    • 此外,对于极其庞大的模型,使用 FP16 可能会带来与其有限范围相关的工程挑战 ,例如管理潜在的溢出
  • 但作者认为这些都是可解决的挑战,近期在大型 FP8 训练方面的成功就证明了这一点

The Bias-Variance Tradeoff under BF16 Precision

  • 第 4.2 节中的结果揭示了在 BF16 精度下运行的 RL 算法之间存在偏差-方差权衡
  • 具有较低方差但较高偏差的方法(如 GRPO、 Token-level TIS 和 GSPO)最初收敛很快,但不稳定并最终崩溃
    • 理解:
      • GRPO 假设 inference policy 和 training policy 是相同的,忽略了两者的不同,所以有偏差(需要做重要性采样),因为忽略了,所以方差理论上为 0
      • Token-level TIS 在 GRPO 的基础上进行了修正,但修正是 Token-level 的,存在偏差(但因为本身是 Token-level,相对 Sequence-level 的多个概率连乘来说,方差不大)
      • GSPO 虽然是 Sequence-level 的,但使用了几何平均,所以方差确实小,但因为不是严格的 IS 权重,所以存在偏差
  • 更准确地校正策略不匹配的低偏差算法(如 PG-Seq-IS 和 GRPO-Seq-MIS)实现了稳定性,但代价是高方差,这减慢了它们的收敛速度
    • Sequence-level 的校准本身是无偏的,但是会引入高方差
  • 这种权衡在 FP16 精度下变得不那么关键
    • 通过从根本上减少 Training-Inference Mismatch ,FP16 自然地降低了由不匹配引起的偏差和重要性采样校正的方差
    • 这种增强的稳定性使得即使是最简单的策略梯度估计器也能高效收敛,从而创造出一种所有测试算法都表现良好且稳定性与速度之间的张力得到有效解决的训练动态

附录 A:Detailed Experimental Settings

A.1 MoE RL

  • 对于 MoE RL 的实验,使用 Qwen3-30B-A3B-Base 作为 Base 模型
  • 训练数据来自 DAPO-Math-17k (2025),使用 avg@32 指标在 AIME 2024 上进行在线评估
  • 训练采用 VeRL 框架 (2024),关键超参数总结在表 3 中
  • Dr.GRPO (2025c) 提出使用一个常数归一化器,而不是基于 token 计数的归一化器
  • 注:开源的 VeRL 实现并未正确实现这一点
    • 本文作者将其修正后的版本称为 VeRL 中 actor.loss_agg_mode 的 “seq-mean-token-sum-norm”

A.2 RL on Large Dense Models

  • 对于大稠密模型上的实验,使用 Qwen2.5-14B-Base 作为基础模型
  • 训练数据来源于 Cheng 等 (2025) 整理的一个数学领域数据集
    • 聚合了最近的一些数学推理集合,包括 OR1 (2025)、DAPO (2025) 和 DeepScaler (2025),然后执行了去重和过滤,得到最终的 54.4k 个数学训练样本集合
  • 使用 avg@8 指标在 AIME 2024 上进行在线评估
  • 训练算法和超参数遵循 Yu 等 (2025) 中描述的设置,如表 3 所总结

附录 B:More Experimental Results

  • 图 6:在不同框架、算法、数据集和训练机制下,BF16 和 FP16 之间的评估比较
  • 对比:
    • 图 1 展示了不同精度下的训练奖励曲线
    • 图 6 展示了使用这些精度训练的检查点的评估结果
  • 结论:FP16 训练的模型能够很好地泛化到未见过的基准测试上,进一步支持了本文的结论

NLP——技术报告解读-ERNIE-5.0

注:本文包含 AI 辅助创作

  • 参考链接:

    • 原始论文:ERNIE 5.0 Technical Report, Baidu, 20260204
  • 注:暂时仅关注 Post-training 部分

Paper Summary

  • 评价:
    • ERNIE 5.0 26年1月刚线上线时,LMArena 排名位于国内第一,最高曾至第 6 名(截止到 20260210 日本文写作时位于 11 名),在用户体验方面是做的很好的
      • 补充:在 20260212 日被 GLM-5 超过
    • ERNIE 5.0 没有开源模型权重,只有本次的技术报告
    • 模型大小是 万亿参数

Post-training(原文第4节)

  • 经过多模态统一预训练后,采用与 ERNIE 4.5 相同的训练后流程来获得最终的 ERNIE 5.0
    • 该流程包括两个阶段:SFT 和 RL
    • SFT:
      • 高质量指令对集合
      • 基础的指令遵循能力
      • 长链思维推理的能力
    • RL:
      • 统一多模态 RL
      • 推理、智能体、指令遵循等各种任务的训练在一个多阶段 RL 流程中
      • 扩展了统一验证器系统,使其能够为广泛多模态场景中的模型 Response 生成准确且一致的奖励信号
  • RL 训练面临几个挑战
    • First,RL 训练计算成本高昂,ERNIE 5.0 的大规模进一步加剧了这一点(似乎没有说模型的参数量是多少?)
    • Second,超稀疏 MoE 架构加剧了训练-推理差异并破坏了稳定性
    • Third,与独立的 RLVR 任务相比,训练一个同时支持多种场景和模态的模型引入了更高的复杂性
  • 本文主要以解决以上几个问题为主旨

Enhancing Rollout Efficiency with Unbiased Replay Buffer

  • Rollout 生成在 RL 训练中占据了超过 \(90%\) 的总时间,效率往往受限于 Rollout Response 长度的长尾分布
    • 少数异常长的 Response 会阻塞整个批次,导致 GPU 空闲且利用率不足
  • 最近如 APRIL (2025)等试图通过超额供应 Rollout 请求来缓解长尾低效问题
    • 收集到目标数量的 Response 立即终止生成;未完成的 Response 会被回收并在后续步骤中继续生成
    • 但 APRIL 存在问题:
      • 倾向于使用推理步骤较短的轨迹来更新模型参数 ,这些轨迹通常对应于较容易的 Query
      • 更长步数的样本被推迟,导致数据难度分布不稳定
      • 数据难度的周期性变化可能阻碍收敛并最终降低模型性能
U-RB:Unbiased Replay Buffer Generation
  • U-RB 是 APRIL 的一种无偏扩展,旨在加速 RL 中的 Rollout 生成
  • 如图 5 所示,U-RB 引入了一种数据排序约束,在此约束下,只有初始化时分配给当前迭代的数据组才被允许参与后续训练过程
  • 上图中的一些解释:
    • IB 表示 Inference Batch
    • 同步方式:被长尾拖住,浪费资源
    • APRIL:足够了就停,对长难样本不友好
    • U-RB:既不浪费资源,又等待长尾样本完成
  • U-RB 构建了两个模块
    • 第一个模块:高吞吐量推理池 \(\mathcal{P}_\text{infer}\),容量为
      $$ \Omega_{RBS} = \Omega_{BS} * N$$
      • 其中 \(\Omega_{BS}\) 是训练批次大小,\(N\) 是缓冲区大小
    • 第二个模块:训练池 \(\mathcal{P}_\text{train}\),用于收集已完成的轨迹以进行 RL 训练,容量为:
      $$ \Omega_{BS} $$
  • 在迭代 \(t\) 时,推理引擎 \(\pi_{infer;\theta_t}\) 通过并行生成 Rollout 来填充推理池
    • 推理持续进行,直到达到分配给迭代 \(t\) 的数据组 \(\mathcal{D}_t\) 中最长 Rollout 的终止状态
    • 此时,与 \(\mathcal{D}_t\) 相关的 Rollout 将从 \(\mathcal{P}_\text{infer}\) 移动到训练池 \(\mathcal{P}_\text{train}\),使训练引擎 \(\pi_{train;\theta_t}\) 能够更新模型参数
    • 这些 Rollout 可能包括从早期推理运行中恢复的轨迹
  • 通过动态划分 Rollout 生成,U-RB 防止了因单个长 Rollout 导致的计算闲置,同时保持了无偏的数据分布

Stabilizing Training with Mitigated Entropy Collapse

  • 多模态模型中快速熵崩溃的现象表现为 RL 早期阶段策略熵的急剧增加或减少
  • 在集成文本、视觉和音频信息的多模态决策任务中,这种崩溃会逐渐削弱模型融合跨模态信息以进行灵活推理的能力,并显示出明显的模态偏向
  • 近期研究将熵崩溃主要归因于两个因素
    • First,大多数当代 RL 框架依赖独立的引擎进行训练和推理,这引入了数值计算的不一致性,并最终破坏了策略优化的稳定性
      • 对于 MoE 模型,这个问题变得更加严重,因为动态路由进一步放大了数值不匹配问题
    • Second,策略模型通常在训练早期阶段过拟合于简单 Query
      • 这种行为加速了熵崩溃并限制了模型探索的能力
  • 解决方案:引入 Multi-granularity Importance Sampling Clipping 和 Well-learned Positive Sample Mask ,在大规模 RL 训练中稳定训练
MISC:Multi-granularity Importance Sampling Clipping
  • IcePop 通过对 GRPO 进行双端掩码校准来抑制训练-推理不匹配:
    $$
    \begin{align}
    \mathcal{I}_\text{IcePop}^\text{GRPO}(\theta) &= \mathbb{E}_{x\sim D,(y_i)_{i = 1}^G\sim \pi_\text{infer}(\cdot |x;\theta_\text{old})}\\
    &\frac{1}{G}\sum_{i = 1}^G\frac{1}{|y_i|}\sum_{j = 1}^{|y_i|} \mathcal{M}\left(\frac{\pi_\text{train}(y_{ij}|x,y_{i,j};\theta_\text{old})}{\pi_\text{infer}(y_{ij}|x,y_{i,j};\theta_\text{old})};\alpha ,\beta\right) \cdot \min (r_{ij}\hat{A}_{ij},clip(r_{ij},1 - \epsilon ,1 + \epsilon)\hat{A}_{ij})\\
    r_{ij} &= \frac{\pi_\text{train}(y_{ij}|x,y_{i,j};\theta)}{\pi_\text{train}(y_{ij}|x,y_{i,j};\theta_\text{old})} \\
    \mathcal{M}(k) &= \begin{cases}
    k & \text{if } k\in [\alpha ,\beta ]\\
    0 & \text{otherwise}
    \end{cases}
    \end{align} \tag{1}
    $$
    • 其中 \(\alpha ,\beta\) 控制下限和上限
  • 作者将 IcePop 的掩码技术应用于 GSPO:
    $$
    \begin{align}
    \mathcal{I}_\text{IcePop}^\text{GSPO}(\theta) &= \mathbb{E}_{x\sim D,(y_i)_{i = 1}^G\sim \pi_\text{infer}(\cdot |x;\theta_\text{old})}\\
    &\frac{1}{G}\sum_{i = 1}^G[\mathcal{M}\left(\frac{\pi_\text{train}(y_i|x,\theta_\text{old})}{\pi_\text{infer}(y_i|x,\theta_\text{old})}\right)^{\frac{1}{|y_i|} };\alpha ,\beta)\cdot \min (s_i(\theta)\hat{A}_i,clip(s_i(\theta),1 - \epsilon ,1 + \epsilon)\hat{A}_i)\\
    s_i(\theta) &= \left(\frac{\pi_\text{train}(y_i|x;\theta)}{\pi_\text{train}(y_i|x;\theta_\text{old})}\right)^{\frac{1}{|y_i|} } = \exp \left(\frac{1}{|y_i|}\sum_{j = 1}^{|y_i|}\log \frac{\pi_\text{train}(y_{ij}|x,y_{i,j};\theta)}{\pi_\text{train}(y_{ij}|x,y_{i,j};\theta_\text{old})}\right)\\
    \mathcal{M}(k) &= \begin{cases}
    k & \text{if } k\in [\alpha ,\beta ]\\
    0 & \text{otherwise}
    \end{cases}
    \end{align} \tag{2}
    $$
  • 注意:作者的实验表明,直接将 \(\mathcal{I}_\text{IcePop}^\text{GSPO}\) 应用于 ERNIE 5.0 的 RL 训练会导致快速熵崩溃,如图 6 中的浅蓝色线所示
    • 这种现象是由序列级截断重要性采样引起的,由于训练-推理不匹配,修剪了大量低熵 Response
  • 为了解决这个问题,作者将 \(\Im_\text{IcePop}^\text{GSPO}\) 修改为 \(\Im_\text{IcePop}^\text{Mixed}\)
    $$\begin{align}
    \Im_\text{IcePop}^{Mixed}(\theta) &= \mathbb{E}_{x\sim D,[y_i]_{i = 1}^{C}\sim \pi_\text{infer}(\cdot |x;\theta_\text{old})}\\
    &\frac{1}{G}\sum_{i = 1}^{G}[\mathcal{M}_{i\in [1,y_i]}] (\frac{\pi_\text{train}(y_{i,j}|x,y_{i,j};\theta_\text{old})}{\pi_\text{infer}(y_{i,j}|x,y_{i,j};\theta_\text{old})};\alpha ,\beta)\cdot \min(s_i(\theta)\hat{A}_i,clip(s_i(\theta),1 - \epsilon ,1 + \epsilon)\hat{A}_i)\\
    s_i(\theta) &= \left(\frac{\pi_\text{train}(y_i|x;\theta)}{\pi_\text{train}(y_i|x;\theta_\text{old})}\right)^{\frac{1}{|\theta_i|} } = \exp\left(\frac{1}{|y_i|}\sum_{j = 1}^{|y_i|}\log \frac{\pi_\text{train}(y_{i,j}|x,y_{i,j};\theta)}{\pi_\text{train}(y_{i,j}|x,y_{i,j};\theta_\text{old})}\right)\\
    \mathcal{M}(k) &= \begin{cases}
    k& \text{if } k\in [\alpha ,\beta ]\\
    0& \text{otherwise}
    \end{cases}
    \end{align} \tag{3}
    $$
  • 通过根据模态敏感性调整信任区域,作者实现了更平衡的探索-利用权衡
    • 该机制避免了在复杂的多场景设置中过早收敛到“安全”但次优的策略,并保持了跨不同输入的灵活性
WPSM:Well-learned Positive Sample Mask
  • 为防止模型对已经掌握的 Query 进行过优化,作者引入了一种样本掩码策略
    • 注:其中熟练程度通过维护每个 Query 的成功率来跟踪
  • 对于一个给定的 Query \(x\) 及其 Rollout 组 \(\mathcal{Y}^x = \{y_1^x,y_2^x,\dots,y_G^x\}\),其中 \(G\) 是组大小
    • 如果迭代 \(t\) 中的平均准确率 \(acc_i^x\) 超过阈值 \(\tau\),并且其 策略熵 \(\mathcal{H}_{y_i^x}(\pi_\theta)\) 低于稳定边界 \(\eta\)
    • 则标记 \(\mathcal{Y}^x\) 中的 Rollout \(y_i^x\) 为“已习得(Well-learned)” Response
  • 在训练期间,“已习得”的 Response 被掩码如下:
    $$
    \begin{align}
    \mathcal{I}(\theta) &= \mathbb{E}_{x\sim D,[y_i]_{i = 1}^{C}\sim \pi_{\theta_\text{old} }(\cdot |x)\left[\frac{1}{G}\sum_{i = 1}^{G}[1 - \mathbf{M}_{mask}^i ]min(s_i(\theta))\hat{A}_i,clip(s_i(\theta),1 - \epsilon ,1 + \epsilon)\hat{A}_i\right]}\\
    \mathbf{M}_{mask}^i &= \begin{cases}
    &\alpha & \mathcal{H}_{y_i^x}(\pi_\theta) < \eta \text{ and } \text{acc}_i^x >\tau \\
    &0 & \text{otherwise}
    \end{cases}
    \end{align} \tag{4}
    $$
    • \(s_i(\theta)\) 表示重要性比率
    • \(\alpha \in [0,1]\) 控制应用于“已习得” Response 的补充学习程度
  • 在此设计下,梯度预算被转移到更困难的样本上,例如那些奖励稀疏或推理路径多样的样本
    • 通过掩码冗余的正信号,WPSM 缓解了因过拟合于简单 Query 而引起的熵崩溃问题,并鼓励模型提升具有挑战性的、低表现任务的性能
    • 问题:相当于直接直接在线过滤样本了?

Boosting Sample Efficiency with Hint-based Learning

  • 近期研究表明:
    • RL 方法通过强化高奖励完成来提升 pass@1 指标,但它们在基础模型表现不佳的挑战性任务上表现出明显的局限性
  • 具体来说,当所有 Rollout 都获得零奖励时,GRPO 框架无法为策略优化提供有效的梯度信号
    • 在这种情况下,困难 Query 上的 RL 训练往往会进展得更慢,因为稀疏奖励和有限的样本效率阻碍了学习
  • 为了应对这一挑战,作者提出了 Prompt-based 自适应强化学习,一种缓解困难 Query 上稀疏奖励问题的方法
    • 如图 7 所示,Prompt-based 自适应强化学习引入了部分提示,将复杂问题分解为中间步骤,并逐步提高训练模型的性能
AHRL:Adaptive Hint-based Reinforcement Learning
  • Prompt-based 自适应 RL 旨在 RL 训练期间将部分思维提纲注入到 Query 中
  • Prompt-based 自适应 RL 增加了基础模型生成正确 Response 的倾向,并提高了样本效率
    • 因此,模型被驱动去掌握最困难的问题,从而加速了 RL 训练过程
  • 对于一个给定的 Query \(x\),其 Response 由思维轨迹和最终解决方案组成,表示为 \(y = (\text{think, solution})\)
    • Prompt-based 自适应强化学习通过将 think 的前 \(p_\text{hint}\) 个 token 附加到原始 Query ,将 \(x\) 增强为 \(\bar{x}^{(p)}\)
      • \(p_\text{hint}\) 表示被揭示的思维比例,允许对 Query 难度进行细粒度控制
  • 具体来说,概率 \(p_\text{hint}\) 遵循退火计划:
    $$p_\text{hint}(x^t) = p_\text{initial}\cdot \exp (-\gamma \cdot t\cdot \text{pass}_\text{initial}^x) \tag{5}$$
    • \(t\) 是训练迭代次数
    • \(\gamma\) 是衰减率
    • \(pass_\text{initial}^x\) 是在监督微调模型上评估的 Query \(x\) 的 pass@k 分数
    • 问题:\(x^t\) 表示迭代 \(t\) 中的 Query \(x\) 吗?
    • 理解:
      • \(t\) 越大,最终使用的比例 \(p_\text{hint}(x^t)\) 越小
      • \(\text{pass}_\text{initial}^x\) 越大,最终使用的比例 \(p_\text{hint}(x^t)\) 越小
  • 随着训练的进行和模型性能的提高,揭示的提示比例逐渐减少,使模型过渡到完全的自我探索
  • 该机制提供了必要的“脚手架”以弥合初始探索和成功完成任务之间的差距
  • 它防止了在复杂任务中训练停滞,在这些任务中有效的推理路径在统计上是罕见的,并确保了跨模态的性能持续改进

Scalable and Disaggregated RL Infrastructure

  • 将 RL 扩展到具有万亿参数的统一多模态模型,在多个方面提出了独特的挑战:
    • 计算一致性 (computational consistency)
    • 数据分布偏差 (data distribution bias)
    • 异构资源利用 (heterogeneous resource utilization)
  • 解决方案:引入了 ERNIE 5.0 RL Infrastructure,一个解耦的系统,旨在编排大规模异步训练
  • 优先考虑高吞吐量执行和计算确定性 (computation determinism),系统确保了稳定且高效的 RL 训练
  • The key architectural components are summarized as follows:
    • Disaggregated Control Plane for Asynchronous RL
      • 一个完全解耦的控制平面,围绕一个集中式 RL 控制器 (RL controller) 构建,以最大化系统吞吐量
      • 该控制器以异步方式协调训练、推理、环境交互和奖励评估
      • 这些子系统之间的逻辑解耦实现了灵活的扩展和高效的流水线管理,为大规模异步多模态 RL 奠定了基础
    • FP8 栈 (Unified FP8 Stack for Consistent Training and Inference).
      • 精度分歧 (Precision divergence) 是低比特 RL 训练中的常见问题
      • 为了缓解这种情况,作者构建了一个统一的 FP8 执行引擎 (execution engine)
      • 通过在训练和推理 (rollout) 阶段采用相同的高性能算子,并整合 Rollout Router Replay (2025b) 策略,该引擎最大限度地减少了数值不匹配,并确保了低精度设置下的稳定收敛
    • Replay Buffer for Sequence-Length Bias Mitigation
      • RL 中的异步 rollout 可能会引入序列长度偏差 (sequence-length bias),即较短的 Response 更早进入训练,从而扭曲数据分布
      • 作者设计了一个无偏回放缓冲区 (unbiased replay buffer),与第 4.1 节描述的算法协同工作,保留了原始数据顺序,确保数据一致到达,并减轻了异步完成引起的偏差
    • Heterogeneous Resource Optimization with Elastic CPU Pooling
      • 为解决在以 GPU 为主的 AI 集群中常见的 CPU 资源利用不足问题,作者使用了弹性 CPU 池策略
        • 该弹性机制从集群中隔离并虚拟化空闲的 CPU 容量,以支持计算密集型的任务,例如密集的 RL 环境交互和结果验证
      • 有效地放大了可用于环境 rollouts 的计算资源,实现了大规模的并行模拟
      • 减少了训练迭代的 wall-clock time,同时显著提高了底层硬件的总体拥有成本 (Total Cost of Ownership, TCO) 效率

NLP——LLM对齐微调-MaMs

注:本文包含 AI 辅助创作

  • 参考链接:
    • 原始论文:(MaMs)Learning Query-Specific Rubrics from Human Preferences for DeepResearch Report Generation, 20260203, Tencent & Fudan

Paper Summary

  • 整体总结:
    • 本文为 DeepResearch 报告生成设计了一种特定的 Rubric Generator 训练流程
      • 注意:主要关注 Rubric 生成而不是验证;且主要关注 DeepResearch Report Generation 场景
    • 本工作解决了 DeepResearch 报告生成中的一个核心挑战:
      • 核心目标:在没有显式 Golden Signal 情况下,使用 Rubrics 获得了可靠的监督信号(可扩展、可靠且与人类对齐的)
      • 核心特点:没有依赖预定义或人工标注的 rubrics,而是从人类偏好中学习 Query-specific rubric generator
    • 本文的流程和示例主要看原论文 图 1
  • DeepResearch 缺乏可验证的奖励信号,这种场景中,Rubric-based 评估已经比较常用
  • 但现有方法要么依赖于缺乏足够细粒度的、粗粒度的预定义 Rubric,要么依赖于手动构建的 Query-specific Rubric,这些方法成本高昂且难以扩展
  • 本文提出了一种为 DeepResearch 报告生成量身定制的、与人类偏好对齐的 Query-specific Rubric Generator 的训练流程
  • 本文主要工作:
    • 构建了一个包含人类对成对报告偏好的、带 Annotations 的 DeepResearch 风格 Query 数据集
    • 通过结合人类偏好监督和 LLM-based Rubric 评估的混合奖励进行强化学习来训练 Rubric Generator
    • for 长程推理,为报告生成引入了一种 多智能体马尔可夫状态(Multi-agent Markov-state, MaMs) 工作流
  • 实验表明本文的 Rubric Generator 比现有的 Rubric 设计策略提供了更具区分性和更好人类对齐的监督
  • 当集成到 MaMs 训练框架中时,配备了本文 Rubric Generator 的 DeepResearch 系统在 DeepResearch Bench 上持续优于所有开源基线,并达到了与领先的闭源模型相当的性能

Introduction and Discussion

  • 背景:
    • 不同于 BrowseComp (2025)、GAIA (2023) 和 HLE (2025) 等短格式 DeepResearch 任务,报告生成要求模型能够对不同来源进行多步推理、检索和整合,同时以连贯且结构良好的方式呈现结果
  • 问题提出1:
    • 训练和评估 DeepResearch 报告 Generator 仍然存在根本性的挑战
      • 一个关键困难在于缺乏可验证的奖励
      • 人工评估虽然可靠,但成本高昂且难以扩展,Rubric-based 评估 (2025) 已经作为一种实用替代方案的广泛采用
    • 理论上来说,专家设计的、 Query-specific Rubric,如 ResearchRubrics (2025),在评估 DeepResearch 报告时可以作为人类判断的可靠代理
      • 但为每个 Query 编写此类 Rubric 需要大量的领域专业知识和努力,使得这种方法难以扩展到大型和多样化的训练语料库
  • 已有解法1:
    • 部分工作使用预定义的通用 Rubric (2024) 或 LLM 生成的 Query-specific Rubric (2025) 来为报告生成任务提供结构化反馈
      • 这些方法存在两个局限性:
        • 第一:预定义的 Rubric 必然是通用的,缺乏区分不同研究 Query 之间细微质量差异所需的粒度
        • 第二:LLM 生成的 Query-specific Rubric 通常没有基于人类偏好数据,这使得它们容易与人类实际比较和判断研究报告的方式不一致
      • 这些问题可能导致监督信号弱、奖励黑客行为和低效的学习动态
  • 本文解决方案:
    • 本文重新考虑用于评估 DeepResearch 报告的监督来源
    • 作者认为评估 报告质量 最直接的监督信号之一是人类对候选报告的偏好 (2023; 2024)
  • 与其应用通用或人工 Annotations 的 Rubric,能否学习以一种既能在大型训练数据上扩展又与人类偏好对齐的方式来评估报告?
    • 理解:这个是本文要回答的最根本问题

Method

Motivations

  • 专家 Annotators 可以提供高质量的评估 Rubric,但大规模手动设计 Query-specific Rubric 从根本上是不切实际的
    • 即使是训练有素的专家也难以为大量且多样化的 Query 集生成一致且细粒度的标准
    • 这种方法对密集专家工作的依赖限制了其在大规模 DeepResearch 训练中的适用性
  • 本文的目标是开发一种与人类偏好对齐的 Query-specific Rubric Generator ,从而能够通过强化学习,利用更可靠和与人类对齐的奖励信号来训练 DeepResearch 系统

Creation of the Preference Dataset

Stage 1: Query Construction
  • 首先构建一组多样化的、反映 DeepResearch 场景中实际信息需求的研究导向型 Query
  • 每个 Query \(q\) 被表述为一个开放的研究 Prompt,需要多步推理、证据综合和结构化的长格式报告,而不是简短的事实性答案
  • 原始 Query 是从构建于不同领域实体的知识图谱中自动生成的
    • 通过利用图谱的关系结构,作者采样多跳实体路径,并 Prompt 一个 LLM 来合成相应的自然语言问题
    • 这确保了每个 Query 都基于实体关系,同时需要跨多个事实进行推理 ,使其适合于评估深度研究和综合
  • 然后使用 GPT-5 (2025) 重写 Query
    • 使其措辞和自然度多样化,使其与现实用户提问风格对齐,并自然地诱导报告质量的差异
  • 用 \(N\) 个构建的 Query 表示数据集 \(\mathcal{Q}\) 为
    $$ \mathcal{Q} = \{q_i\}_{i = 1}^N $$
    • 其中每个 \(q_i\) 作为生成后续候选报告的条件输入
    • 重写 Query 的案例研究和详细类别见附录 A
Stage 2: Candidate Report Generation via Multi-Agent Markov State Framework
  • 给定一个固定的 Query
    $$ q \in \mathcal{Q}$$
  • 改变多个 LLMs 的超参数来生成多个候选报告
    • 包括 DeepSeek V3.1 (2024a) 和 TongyiDeepResearch (2025),这些模型都已经经过智能体数据训练,具备工具调用能力
  • For 解决 ReAct 风格推理 (2022) 中的长上下文依赖性和自动化 DeepResearch 的多步性质所带来的挑战
    • 本文从先前的工作中汲取灵感 (2025b),并提出了一个 多智能体马尔可夫状态(Multi-Agent Markov-State, MaMs) 工作流,详见第 3.4 节
    • 使用此工作流 独立生成 候选报告被,且不接触任何人工 Annotations
  • 在提交进行人工 Annotations 之前,对所有候选报告进行一个过滤过程
    • 这个过滤过程包含了人工评审员和 Auxiliary LLM-based 验证器的过滤过程
    • 移除具有明显事实错误、引用混乱或不一致、或者内容表现出表面聚合而无连贯推理的报告,最终只保留两个最高质量的报告 for Annotations
Stage 3: Preference Annotation by Human Experts
  • 对于人工 Annotations ,作者招募了 16 名人类专家,每人至少持有硕士学位 ,并具备批判性阅读和评估长格式研究报告的能力
    • 专家们对为同一 Query 生成的候选报告进行成对比较
  • 给定一个 Query \(q\) 和两个候选报告 \(r_a, r_b \in \mathcal{R}(q)\), Annotators 被要求选择他们整体上更喜欢的报告,考虑因素包括有用性、连贯性、完整性以及与 Query \(q\) 所表达的信息需求的对齐程度
    • 每次比较产生一个 Prefered \(r_{\mathrm{acc} }\) 和一个 Less Prefered \(r_{\mathrm{rej} }\),形成一个偏好三元组
      $$ (q, r_{\mathrm{acc} }, r_{\mathrm{rej} }) $$
  • 聚合所有 Annotations 的比较结果得到最终的人类偏好数据集
    $$ \mathcal{D} = \{(q, r_{\mathrm{acc} }, r_{\mathrm{rej} })\}$$
    • 该数据集用作建模和评估偏好对齐报告生成的监督
  • 注:以上得到的是专家的相对判断而非绝对评分,该数据集捕获了难以用通用或 LLM 生成的评估指标表达的细粒度人类偏好
    • 理解:人工判别生成的数据,确实非常宝贵

Training Rubric Generators with Hybrid Rewards

  • For 生成与人类偏好良好对齐的评估 Rubric,使用 GRPO (2024b) 来训练 Rubric Generator
  • 给定一个 Query \(q\),策略模型 \(\pi_{\theta}\) 采样一组 Rubric 候选 \(\{y_1, y_2, \ldots , y_G\}\),其中每个候选 \(y_i\) 指定了一个结构化的评估标准集(Evaluation Criteria)
  • 遵循 Gunjal 等人 (2025) 提出的 Rubric 规范,每个 Rubric 项目用三个关键字段表示:
    • 1)Title
    • 2)Description
    • 3)关联的重要性权重
    • 以上三部分形成一个加权的评估维度列表(例如,JSON 格式)
    • 理解:这里一个 Rubric 就包含三个部分,相对来说是比较复杂的,特别是权重方面有点不好生产,可以考虑看下模型是否真的可以生成这个
  • For 稳健地指导学习,作者设计了一个混合奖励函数 \(R_{\mathrm{total} }\),整合了三个互补的信号:
    • Preference Consistency Reward
    • Format Reward
    • LLM-as-a-Judge Quality Reward
  • 总体训练信号计算为上述分量的加权组合:
    $$R_{\mathrm{total} } = \lambda_{\mathrm{pref} }R_{\mathrm{pref} } + \lambda_{\mathrm{llm} }R_{\mathrm{llm} } + R_{\mathrm{fmt} } \tag{1}$$
Preference Consistency Reward \((R_{\mathrm{pref} })\)
  • 一个有效的 Rubric 必须具有区分性,即当应用于真实报告时能够反映人类偏好
  • 作者利用第 3.2 节创建的由三元组 \((q, r_{\mathrm{acc} }, r_{\mathrm{rej} })\) 组成的偏好数据集 \(\mathcal{D}\)
    • 其中对于同一 Query \(q\),人类 Annotators 更偏好 \(r_{\mathrm{acc} }\) 而非 \(r_{\mathrm{rej} }\)
    • 给定一个生成的 Rubric \(y\),通过计算项目级评分的加权平均值来为一个报告 \(r\) 打分:
      $$S(r\mid y) = \frac{\sum_{k = 1}^{K}w_{k}\cdot v_{k} }{\sum_{k = 1}^{K}w_{k} } \tag{2}$$
      • 其中 \(w_{k}\) 表示第 \(k\) 个 Rubric 项目的权重,\(v_{k}\) 是由评判 LLM 分配的相应符合度分数
      • 每个 \(v_{k}\) 按 1-10 的李克特量表 (2023a; 2024) 评分,并线性归一化到 \([0,1]\) 范围进行聚合
      • 偏好一致性奖励取决于 Rubric 是否正确地将人类更偏好的报告排在较不偏好的报告之上:
        $$R_{\mathrm{pref} }(y) = \left\{ \begin{array}{ll} +1, & \mathrm{if } \ S(r_{\mathrm{acc} }\mid y) > S(r_{\mathrm{rej} }\mid y);\\ -1, & \mathrm{otherwise}. \end{array} \right. \tag{3}$$
Format Reward \((R_{\mathrm{fmt} })\)
  • 下游评估流程需要机器可解析的 Rubric 表示,本文将结构有效性作为硬约束强制执行
  • 本文会检查每个生成的候选是否符合所需的 JSON 模式(包括必填字段,如 Title、Description 和 Weight)
    • 未通过此检查的候选会受到 \(-1\) 的惩罚(注:通过此检查的 Rubric 则不会获得额外奖励)
LLM-as-a-Judge Reward \((R_{\mathrm{llm} })\)
  • For 评估生成的 Rubric 的内在质量
    • 本文进一步采用了一个 LLM-as-a-Judge 的机制,充当语义元评估器
  • 评判者不是依赖于预定义的规则,而是在 Query \(q\) 的背景下评估一个 Rubric \(y\)
    • 关注其逻辑连贯性、覆盖全面性及其评估维度的相关性
    • 将这些因素综合成一个标量质量分数(例如,缩放到 \([0,4]\)):这些标准被聚合成一个标量质量分数
      $$ R_{\mathrm{llm} } = \mathrm{Judge}(q,y) $$
  • 具体的提示词可以在附录 C.3 中找到

Multi-Agent Markov-State Workflow with Rubric-Based GRPO

  • 在获得训练良好的 Rubric Generator 后,利用它通过 GRPO 为训练 DeepResearch 系统提供可靠且 Query-specific 奖励信号
  • 本文中的 DeepResearch 框架称为 多智能体马尔可夫状态(Multi-Agent Markov-State, MAMs) 工作流
  • 与之前的 容易产生上下文饱和和错误积累的单一架构 不同
    • MaMs 框架明确地将高层推理、信息获取和报告综合分离到专门的智能体中,这些智能体通过迭代的状态转移循环进行交互
  • 为了提高多智能体系统的效率,作者提出了一种并发执行方案,详见附录 F
State Abstraction and Iterative Transitions
  • 将深度研究过程建模为一个在抽象状态空间上的序列决策问题
  • 对于用户 Query \(q\),迭代 turn \(t\) 的研究状态定义为
    $$s_{t} = \langle m_{t},p_{t},r_{t}\rangle$$
    • \(m_{t}\) 代表结构化记忆
    • \(p_{t}\) 表示动态执行计划
    • \(r_{t}\) 是逐步演变的报告
  • 注:传统 RAG 依赖于原始检索上下文,但这里框架基于这种紧凑的抽象(Compact Abstraction),确保跨长程工作流的可扩展性
    • 转移遵循分层结构:高层搜索动作触发低层状态处理,形式上有:
      $$s_{t + 1} = \mathcal{T}(s_{t},a_{t}) $$
    • 其中 \(\mathcal{T}\) 封装了工具执行和后续的多智能体处理流程(如下所述)
    • 详细的算法描述请参见附录 B
Agent Modules and Chunk-based Process
  • MAMs 工作流由 3 个具有明确定义职责的专门智能体组成,如图 1 所示
Search Agent
  • Search Agent 作为高层控制器,观察当前状态 \(s_{t}\) 并确定最佳下一步
  • Search Agent 生成一个搜索动作 \(a_{t}\)(例如,生成 <tool_call></tool_call>)并优化全局计划:
    $$ a_{t},p_{t}^{\prime} = \mathcal{A}_{\mathrm{search} }(q,s_{t})$$
  • Search Agent 负责识别 \(m_{t}\) 中的信息差距并驱动探索过程
    • 如果收集到足够的信息,搜索循环终止,并最终确定输出
State Agent
  • 在执行动作 \(a_{t}\) 后,环境返回一个原始观察 \(O_{t}\)(例如,长搜索内容)
    • 一个关键的挑战是 \(O_{t}\) 常常超过 LLM 的上下文窗口限制
    • 理解:搜索的得到的内容一般都是很大的类似 HTML 或 PDF 等文档
  • For this Question,作者遵循 MemAgent, 20250703 实现一个基于分块的处理机制
    • 原始文本 \(O_{t}\) 使用尊重语义边界(例如,段落)的文本分割器被分割成一系列较小的块
      $$ \{c_{1},c_{2},\ldots ,c_{K}\} $$
  • State Agent 按顺序处理这些块,以更新记忆和计划,同时最小化信息损失
    • 令 \(m_{t,0} = m_{t}\) 且 \(p_{t,0} = p_{t}^{\prime}\)
    • 对于每个块 \(k \in \{1, \ldots , K\}\),智能体执行增量更新:
      $$m_{t,k},p_{t,k} = \mathcal{A}_{\mathrm{state} }(q,c_{k},m_{t,k - 1},p_{t,k - 1}). \tag{4}$$
      • 问题:这里的 \(p_{t,k}\) 是什么?
      • 理解:这里的 \(p_{t,k}\) 是计划(注:\(m_{t,k}\) 表示记忆)
  • Prompt 逻辑明确强制一种“增量融合”策略:
    • 保留 \(m_{t,k - 1}\) 中的现有知识,同时压缩并合并来自 \(c_{k}\) 的新事实
    • 处理完所有 \(K\) 个块后,为下一次迭代建立的最终状态为 \(m_{t + 1} = m_{t,k}\) 和 \(p_{t + 1} = p_{t,k}\)
Report Agent
  • Report Agent 随着状态更新增量地完善研究报告:
    $$r_{t,k} = \mathcal{A}_{\mathrm{report} }(q,c_{k},m_{t,k - 1},r_{t,k - 1}). \tag{5}$$
  • 这种设计有效地将信息压缩(由 State Agent 处理)与叙述生成(由 Report Agent 处理)解耦
  • Report Agent 使用流式证据 \(c_{k}\) 来起草、更正和扩展报告 \(r_t\) 的各个部分,确保全局一致性并降低一次性生成长报告时产生幻觉的风险
  • 满足终止条件(如达到最大回合数或无需进一步工具调用)后,生成最终报告 \(r_{\mathrm{final} }\)
Reward Assignment with Weighted Rubrics
  • 对于每个 Query \(q\),Rubric Generator 会生成一个带有相关权重的评估 Rubric 列表,捕获 Query-specific 报告质量概念
  • 在系统为 \(q\) 生成一组候选报告后,作者采用一个 LLM-as-a-Judge ,根据这些加权 Rubric 对每个生成的报告进行评分
  • 所得的标量奖励按照公式 (2) 中定义的相同加权聚合方案计算,并用于监督策略优化
  • 所有提示请参考附录 C

Experiments

  • 在本节中,作者进行了一系列实验来回答以下研究问题:
    • RQ1: 使用 GRPO 训练的 rubric generator 是否能有效地捕捉人类对生成报告的偏好?
    • RQ2: 当用于训练 DeepResearch agent 时,rubric generator 是否能提供更可靠的 reward 信号?
    • RQ3: 在复杂的 DeepResearch 任务中,所提出的 multi-agent Markov-state workflow 是否优于传统的 ReAct-style 框架?

Experimental Settings

数据集
  • 为了解决 RQ1,作者将构建的人类偏好数据集 \(\mathcal{D}\) 按 8:1:1 的比例划分为训练集、验证集和测试集,其中 \(10%\) 的数据留作测试。划分以主题平衡的方式进行,确保所有主题在训练集、验证集和测试集中都有体现。为了解决 RQ2 和 RQ3,作者在广泛采用的 DeepResearch Bench (2025) 上评估作者的方法,该基准包含 100 个 Query (50 个中文和 50 个英文),涵盖了多样化的研究主题
实施细节
  • 所有实验均在一个专用的大规模 GPU 集群上进行,集群配备了 NVIDIA H20 GPU。Rubric generator 在 8 块 H20 GPU 上训练,而 MaMs workflow 内的 DeepResearch agent 训练则使用 32 块 H20 GPU。为了在强化学习过程中实现大规模、高并发的推理以进行 rubrics 评分和 LLM-as-a-Judge 评估,作者进一步部署了 192 块 H20 GPU,使用 vLLM 框架 (2023) 运行 Qwen3-235B-A22B,确保所有请求都能在 4 分钟内端到端处理完毕。完整的实现、基础设施细节和超参数见附录 D
指标
  • 作者使用两个互补的指标来评估偏好建模的性能。偏好准确度衡量模型给偏好回复赋予的分数高于被拒绝回复的频率,它等同于成对偏好评估中的 AUC,反映了排序的正确性。为了进一步评估偏好分离的幅度和稳定性,作者报告了配对 Cohen’s \(d\),它量化了不同 Query 间接受和拒绝回复之间的标准化差异。虽然偏好准确度捕捉了排序是否正确,但 Cohen’s \(d\) (Diener, 2010) 表征了模型区分偏好输出的强度和一致性,提供了对偏好质量更细致的观察。在 DeepResearch Bench 中,”comprehensiveness”、”Depth”、”instruction following” 和 “readability” 是预定义的评估维度,每个维度都由 LLM judges 使用官方基准提示进行评估
基线
  • 对于人类偏好评估,作者考虑以下基线:
    • (1) Human-defined General Rubrics,采用遵循 (2025) 中提出的通用报告 rubrics 的手动指定的评估 rubrics
    • (2) Pointwise Preference Scoring,其中每个三元组 \((q, r_{\mathrm{acc} }, r_{\mathrm{rej} })\) 中的接受和被拒绝报告 \((r_{\mathrm{acc} }, r_{\mathrm{rej} })\) 由模型独立评分,偏好由分数比较决定
    • (3) Pairwise Preference Judgment,其中 \((r_{\mathrm{acc} }, r_{\mathrm{rej} })\) 被共同提供给模型进行直接偏好判断
    • (4) Generated Rubrics,提示模型从 \(q\) 生成 Query-specific rubrics,然后进行 LLM-based 评估
    • (5) Supervised Fine-Tuning,使用 GPT-5 生成的 rubrics 作为监督目标
    • (6) Reinforcement Learning with Various Rewards,应用 GRPO 时在公式 (1) 中使用不同的 reward 权重配置
  • 对于 DeepResearch Bench,闭源基线的结果直接来自官方排行榜
    • 由于资源限制,作者无法用 Qwen3-30B-A3B 作为 Backbone 复现 DRTulu 系统
  • 作者还比较了 ReAct 和作者的 MaMs workflow
    • 该工具执行基于关键词的搜索并返回完整的检索结果
    • 对于 ReAct 框架,作者提供结果的摘要版本,以防止输出长度问题并确保有效推理
    • 为了公平起见,所有结果均使用具有最佳验证性能的检查点获得

Evaluation on Human Preferences

  • 作者在人类偏好数据集的测试集上报告结果(表 1),这直接解决了 RQ1
  • 可以得出几个关键观察结果:
    • (1) 基于 Query-specific rubrics 的方法持续优于依赖人类定义的通用 rubrics 的方法
      • 如表 1 的第一部分所示,通用 rubrics 产生了接近随机的偏好准确度和较小的效应量,而生成的、以 Query 为条件的 rubrics 显著提高了偏好准确度和配对 Cohen’s \(d\)
      • 这证实了在下游训练中,纳入 Query-specific 评估标准对于提供可靠的 reward 信号至关重要
    • (2) 直接应用强大的 LLM(如 GPT-5)生成 rubrics,或对此类 rubrics 进行监督微调,并不足以捕捉细粒度的人类偏好
      • 尽管这些方法在偏好准确度上取得了提升,但其配对 Cohen’s \(d\) 仍然相对较小,并且在接受和被拒绝报告之间没有表现出明显的分离,这表明与人类偏好边际的对齐有限
    • (3) 基于偏好的奖励进行强化学习,在两个 Qwen Backbone 上都显著提高了配对 Cohen’s \(d\)
      • Cohen’s \(d\) 的增加反映了接受和被拒绝报告之间评分差距的增大,表明模型在区分人类偏好的报告方面变得越来越好
      • 此外,使用混合奖励的 RL 取得了最佳的整体性能,结合了强劲的偏好准确度和持续较大的效应量,展示了整合偏好信号与辅助奖励分量的互补优势

Results on DeepResearch Bench

  • 通过表 2,作者可以回答 RQ2 和 RQ3
  • First:比较相同 Tongyi-DeepResearch Backbone 下不同的 rubrics 策略,作者观察到使用 RL 训练的 rubric generator 在所有评估维度上持续取得最佳性能
    • 它明显优于人类定义的通用 rubrics、GPT-5 生成的 rubrics 和 SFT 训练的 generator,这表明所提出的 rubric generator 为训练 DeepResearch agent 提供了更可靠和信息丰富的 reward 信号
    • 这验证了 RQ2,表明通过强化学习学习 rubrics 相比静态或纯监督的替代方案能产生更有效的监督
    • 如表所示,Tongyi-DeepResearch 比 Qwen3-30B-A3B 表现出更强的工具调用和执行能力,但在报告生成方面不如 WebWeaver agent 专业
      • 这使其成为作者研究的合适 Backbone ,因为它使作者能够更好地检验 rubrics 学习和 workflow 设计的有效性,而不是依赖强大的内在生成能力
  • Second:配备所提出 MaMs 的模型在相同的 rubrics 策略下,持续优于其 ReAct-style 的对应物
    • 特别是,配备 MaMs workflow 和 RL 训练的 rubric generator 的 Tongyi-DeepResearch,在所有开源方法中取得了最强的整体性能,在全面性、遵循指令性、可读性和总体得分上均有明显提升
    • 这些结果表明,将研究过程明确构建为一个以状态为条件的 workflow,相比传统的 ReAct 范式,能够实现更有效的推理和信息整合,从而回答了 RQ3

Analysis on Entropy over Two RL Algorithms

  • 由于 Qwen3-30B-A3B 是一个 Mixture-of-Experts 模型,在训练期间应用 GRPO 可能会引入用于优化的 expert routing 与用于 rollout 的 expert routing 之间的不匹配
  • 为了缓解这个问题,作者额外探索了 GSPO (2025) 来训练 rubric generator
  • 尽管 GSPO 和 GRPO 共享相同的训练配置,但作者观察到,使用 GSPO 训练的 rubric generator 持续产生具有更高熵的 rollout,如图 3 所示,尽管在生成的样本上取得了几乎相同的 reward 值
  • 作者将此行为归因于 GSPO 的序列级优化方案,其中重要性权重和裁剪是在整个响应而非单个 token 上执行的
  • 这种设计降低了对局部 token 级偏差的敏感性,并允许多个具有相似全局 reward 的实现共存,从而增加了输出多样性
  • 相比之下,GRPO 在整个 rollout 上应用组间相对优势,但依赖于 token 级的似然比,这隐含地施加了更强的结构约束
  • 鉴于 rubrics 生成优先考虑稳定性、一致性和偏好对齐,而非语言多样性,作者采用 GRPO,因为它更符合任务的模式寻求性质
  • 使用 GSPO 训练的 rubric generator 的性能在附录 G 中报告
  • 关于工具调用行为的额外分析在附录 H 中提供

补充:Related Work

DeepResearch Agent

  • LLMs-based 智能体系统对静态内部知识的依赖,促使了结合规划、检索和基于证据综合的深度研究智能体的出现
  • 现有的 DeepResearch 智能体可以根据其主要任务领域大致分类
短格式问答
  • 在此设置中,DeepResearch 智能体主要针对基于检索的短格式问答任务
  • GAIA (2023; 2025)、BrowseComp (2025; 2025) 和 HLE (2025) 等基准提供了可验证的目标,使得能够通过 RLVR (2025; 2025a) 进行智能体训练
  • 一些系统利用这种范式来增强搜索和推理能力
  • Search-R1 (2025) 和 WebExplorer (2025a) 采用 GRPO (2024b) 来改进在具有明确正确性信号的短格式 QA 任务中的检索效果
  • 相比之下,WebThinker (2025a) 采用 DPO (2023) 来使 LLMs 具备 DeepResearch 能力,而不依赖于可验证的奖励
  • 同时,Tongyi DeepResearch (2025) 专门设计用于支持长程信息寻求行为
长格式报告生成
  • 长格式报告生成要求智能体从大规模、异构的文档集合中综合证据,并为复杂的、开放式 Query 生成连贯、结构良好的报告
  • 除了检索孤立的事实外,智能体必须执行多步推理、调和相互矛盾的证据,并在文档级别组织信息
  • 由于缺乏参考答案,评估长格式输出本身就存在困难,因此该领域的基准(例如 DeepResearch Bench (2025) 和 ResearchQA (2025))通常将 LLM-as-a-Judge ,应用于人工 Annotations 的通用或 Query-specific Rubric
  • 最近的研究集中于设计用于报告合成的端到端工作流
  • Web-Weaver (2025b) 开发了一个模拟协作人类研究过程的双智能体框架
  • Dr Tulu (2025a) 是最早的用于长格式任务的全开源 DeepResearch 智能体之一

Rubrics for Reward Modeling

  • 为长格式报告生成训练智能体本质上涉及弱监督,因为明确的标准答案报告很少可用,并且正确性无法简化为可验证的目标
  • 先前的工作通常依赖于人类偏好 Annotations 或 Rubric-based 评估来评估报告质量,这对训练稳定性和与人类判断的对齐都带来了挑战
  • 现有方法:
    • 一些研究探索了使用固定 Rubric (2024; 2024; 2024a) 以及 Query-specific Rubric (2025a; 2025) 来为长格式输出提供评估反馈
    • 一些研究 (2024b; 2025b; 2025; 2025) 进一步将 Rubric 视为强化学习框架内的奖励模型
  • 本工作专注于通过 Rubric Generator 为训练 DeepResearch 智能体使用 RL 生成长格式报告提供有原则的奖励信号
  • 作者的目标:
    • 学习一个能够生成 Query 感知评估标准的 Rubric Generator ,通过在 RL 训练期间提供细粒度和可解释的奖励信号 ,实现更稳定的优化和更好的人类偏好对齐

附录 A:Case Study on Query Rewriting

  • 作者创建的 Query 集涵盖了与 DeepResearch 场景相关的广泛领域
  • 高频类别包括 Law & Regulation 、Business & Finance 、Science & Technology 以及 Health & Medical Care ,这反映了需要进行多步推理和证据合成的常见研究型信息需求
  • 该数据集还包含多样化的中低频主题,例如 Media & Entertainment 、Daily Life 、Education 、Arts 和 Trending News ,以及包括 Academic Literature 和 Job & Career 在内的长尾领域
  • 这种分布反映了 DeepResearch 系统的真实使用模式,支持了对异构报告生成任务中人类偏好的研究

Query 改写的案例研究

  • Original Query:
    • 在《爱丽丝梦游仙境》中,启发柴郡猫的真实猫品种最常见的眼睛颜色是什么?
  • DeepResearch-style Query:
    • DeepResearch 风格 Query :请对《爱丽丝梦游仙境》中的柴郡猫进行研究:确定最可能作为其灵感来源的现实世界猫品种,并总结该品种最常见的毛色以及每种毛色通常关联的眼睛颜色

附录 B:Global Algorithm of the MaMs workflow

  • 算法 1 中展示了详细的算法描述

附录 C:MaMs 工作流和 LLM-as-a-Judge 中使用的 Prompt

  • 对于每个 prompt,作者都有中文和英文版本,因为问题数据集是双语的
  • 这里仅展示英文版本,而相应的中文版本包含在补充材料中
    • 问题:补充材料没有找到

C.1. 用于生成 Query-Specific Rubrics 的 Prompt

  • 原始论文英文版(大致重写翻译为中文)
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    您是一位专业的 Rubric 写作专家。您的任务是基于给定的 **report-generation query** 生成一套连贯且自包含的评估 Rubrics,该 Rubrics 将用于评估生成响应(即报告)的质量

    由于未提供参考答案,您必须 **直接从 Query 中推断理想答案的特征** ,包括其目标、结构、信息覆盖范围和表达要求

    评估 Rubrics 应包括但不限于以下方面:
    * 内容的事实相关性和准确性
    * 报告的结构和逻辑组织
    * 信息的完整性和深度
    * 推理和论证的合理性
    * 表达的清晰度和连贯性
    * 语气和风格相对于报告意图(例如,总结、分析、建议)的适当性

    每个 Rubric 条目必须是 **自包含的 (self-contained)** ,以便非专业读者无需额外上下文即可独立理解。每个描述必须以以下前缀之一开头:
    * **关键标准 (Key Criterion):**
    * **重要标准 (Important Criterion):**
    * **可选标准 (Optional Criterion):**
    * **错误标准 (Error Criterion):**

    ### Input:
    * Query : 报告生成请求的完整文本

    ### Number of Rubric Items
    * 根据 Query 的复杂性,在 7 到 20 个 Rubric 条目之间选择

    ### Each rubric item must include:
    * 'title' (2-6 个单词)
    * 'description': 一个句子,以类别前缀开头,并明确指出应在生成报告中观察到的内容**
    * 'weight': 一个数值
    * 关键/重要/可选标准的值为 1-5 (5 = 最重要)
    * 错误标准的值为 -1 或 -2(表示惩罚)

    ### Category Definitions
    * **Key Criterion:** 必须存在的核心事实、结构或目标;缺少它们会使答案无效 (weight = 5)
    * **Important Criterion:** 显著影响质量的关键推理、完整性或清晰度 (weight = 3-4)
    * **Optional Criterion:** 风格或深度相关的增强 (weight = 1-2)
    * **Error Criterion:** 常见的错误或遗漏,明确指示‘缺失’或‘不正确’的元素 (weight = -1 或 -2)

    ### Additional Guidelines
    如果报告应包含结论或建议,请包括:'Key Criterion: 包含由证据支持的清晰结论。' 如果报告需要解释或推理,请包括:'Important Criterion: 解释关键点背后的推理并提供支持性论证。' 如果报告需要清晰的结构,请包括:'关键标准 (Key Criterion): 使用清晰的章节和逻辑流程组织内容。' 如果报告有特定的语气(例如,学术、政策导向、商业),请包括:'Important Criterion: 保持与报告上下文一致的专业和客观语气。' 如果需要简洁性,请包括:'Optional Criterion: 保持简洁并避免冗余。'

    ### Output Requirements
    输出格式为 JSON 数组:[..], [..], [..],其中每个对象对应一个 Rubric 条目。每个 JSON 对象 **必须仅包含 (must contain *only*)** 三个键:'title', 'description' 和 'weight'。不要包含任何额外的键或复制 Query 的大部分内容。每个 'description' 必须以所需的类别前缀之一开头。**Important formatting rule:** 如果 'title' 或 'description' 中需要引号,**仅使用单引号 ('')** 。请勿使用双引号 (" "),因为它们会破坏 JSON 格式。例如:使用 'Michelin star' 而不是 "Michelin star"

    ### Summary
    您的任务是 **仅从给定 Query 推断理想报告的基本特质 (infer the essential qualities of an ideal report solely from the given query)** ,并构建一个结构化的、带权重的 JSON 格式 Rubric,以评估报告生成质量

    **Return *only*** 所请求的 JSON 数组。请勿包含任何额外的解释或文本

C.2. 通过 LLM-as-a-Judge 为单个 Rubric 给报告评分的 Prompts

  • 原始论文英文版(大致重写翻译为中文)
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    您是一个精确且公正的评分模型

    您的任务:仅基于给定的单个 Rubric 描述,评估一份报告与该 Rubric 的符合程度

    **Input Information**
    Query : {query}
    Rubric: {rubric}
    Report to be scored: {report}

    **Scoring Instructions**
    您只需要判断报告“匹配” Rubric 描述的程度。请勿判断 Rubric 是代表积极目标还是消极约束。请勿尝试反转或纠正 Rubric 的语义方向。请勿引入任何额外的评估标准

    **Scoring Requirements**
    - 输出一个 1 到 10 的整数分数:
    - 10 = 报告完全符合 Rubric 描述
    - 7-9 = 大体符合
    - 4-6 = 部分符合
    - 1-3 = 基本不符合

    **Output Format** (严格,单行,无标点): rating: <1 到 10 的整数>

C.3. 用于 LLM-based Judgement of Rubrics 的 Prompts

  • 原始论文英文版(大致重写翻译为中文)
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    您是一个准确且公正的评分模型(Reward Model)。您的任务是评估 **Rubrics**(evaluation criteria)的质量。Rubric 是用于评估模型生成答案质量的一套标准。您需要判断给定的 Rubric 是否合理、全面以及与任务目标对齐

    基于以下信息,您应评估 Policy model 生成的 Rubric(response)与您的标准的匹配程度

    **[Input Information]**
    Question: {question}
    待评估的 Rubric (response): {response}

    **[Scoring Requirements]** 您必须输出三项内容:
    1. **[reward]** : 一个范围在 0.00 到 4.00 的小数(最多两位小数)
    * 4.00 = 高质量:结构清晰、维度全面、逻辑严谨、与问题高度契合
    * 3.00 = 基本合理:覆盖了关键维度,但存在轻微遗漏或表达不够简洁
    * 2.00 = 部分合理:涵盖了一些重要方面,但缺乏关键元素或存在显著逻辑缺陷
    * 1.00 = 弱相关:与任务相关性低或存在严重格式问题
    * 0.00 = 完全不相关或无意义:不符合评估目的或为空/乱码
    2. **[confidence]** : 您对分数的置信度 (0%-100%)。数值越高表示越确定
    3. **[reason]** : 对评分理由的简要解释

    **[Important Note]** 您正在评估的是 **Rubric 本身的设计质量** ,而非任何报告或答案的质量

    **[Output Format]** (严格三行,无标点):
    reward: <0.00 到 4.00 之间的小数>
    confidence: <0% 到 100% 之间的整数百分比>
    reason: <英文简要解释>

C.4. MaMs 工作流中 Search Agent 的 System Prompt

  • 原始论文英文版(大致重写翻译为中文)

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    您是一位能够生成高质量深度研究报告的智能助手。您的目标是通过多个“计划-执行-观察”循环来解决复杂的用户问题

    1. **Analyze State:** 审查当前的 <memory>(已获取的信息)和 <plan>(当前进度)
    2. **Develop Strategy:**
    * 如果信息不足或计划不完整 -> 更新计划并使用工具(例如,搜索)来收集信息
    * 如果信息充足且计划完整 -> 整理您的思路并输出最终报告
    3. **Output Specifications:**
    * 更新计划表 <plan>...</plan>: 标记已完成的项目并列出来完成的任务
    * 最终动作:要么调用工具,要么输出 <answer>...</answer>

    ### Annotations (Notes)

    * **Plan:** 必须是一个 Markdown 列表,清晰地显示当前和即将进行的步骤
    * **Answer:** 仅当您确信所有必要信息都已收集时,才生成 <answer>...</answer>

    **Tool Instructions:** {tool description}
    • 注意:这里仅仅是 System Prompt

C.5. MaMs 工作流中 Search Agent 的 User Prompt

  • 原始论文英文版(大致重写翻译为中文)
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    <user_input> { { query } } </user_input>

    <memory> { { memory } } </memory>

    <plan> { { plan } } </plan>

    <report> { { report } } </report>

    剩余工具调用次数: { { tool_call_chance } }

    基于当前状态(Memory/Plan)和 <report> 的完整性,计划下一步动作

    如果当前 <report> 不令人满意,请继续更新 <plan> 并使用工具进行搜索

    如果认为 <report> 已完成,请直接输出 <answer>...</answer> 以结束

    严格遵守输出格式:

    <plan>更新的执行计划</plan>

    <tool_call>工具调用详细信息(如果有)</tool_call> 或 <answer>结束</answer>

    当工具调用动作的计数达到阈值(默认为 10)时,作者将 User Prompt 更改为:

    工具调用次数已用尽

    基于以下信息:

    <user_input> { { query } } </user_input>

    <memory> { { memory } } </memory>

    <plan> { { plan } } </plan>

    列出您的最终计划。请勿再次调用工具

C.6. MaMs 工作流中 State Agent 的 System Prompt

  • 原始论文英文版(大致重写翻译为中文)
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    您是一位信息处理专家,负责维护一个“long-term memory”数据库。您当前正处于分块阅读长文本的多步骤过程中

    ### Task Objective

    在阅读完当前的“Observation Fragment”后,您需要 **incrementally merge** 新发现的信息到现有的 **memory** 中

    注意:输入的记忆(*memory)包含所有先前积累的关键信息。**当通过压缩进行更新时,细节很容易丢失,因此您必须采取一切措施防止这种情况发生。**

    ### Core Principles
    1. **Preserve Old Memory (Most Important):**
    * 输入的记忆(*memory)中未被当前片段提及的信息 **必须被保留**
    * 不要仅仅因为信息在当前片段中缺失就从记忆中删除它
    2. **Incremental Integration:**
    * 仅将来自当前片段的 **新** 事实、数据或见解添加到记忆中
    * 如果新信息更正了旧信息,则修改它;如果是冗余的,则忽略它
    3. **Maintain High Density:**
    * 记忆应是一堆“事实(pile of facts)”,而不是文章摘要
    * 保留具体的数字、名称、日期和参考文献。不要写“关于 XX 的详细讨论”;而应写“XX 声明了 YYY”

    ### Steps
    1. 阅读输入的 *memory*(旧知识)
    2. 阅读下面的“工具输出(Tool Output)”(新片段)
    3. 输出新的 *memory*:它 = 旧记忆 + 来自片段的新知识

    ### Output Format
    严格遵守此格式,以便在下一个决策步骤中使用:<memory>整合新旧信息的更新后记忆</memory>

C.7. MaMs 工作流中 State Agent 的 User Prompt

  • 原始论文英文版(大致重写翻译为中文)
    1
    2
    3
    4
    5
    6
    7
    8
    9
    <user_input> { { query } } </user_input>

    <memory> { { memory } } </memory>

    <plan> { { plan } } </plan>

    请阅读以下工具输出片段。任务:提取关键信息以更新 <memory>

    严格遵守输出格式:<memory>更新后的关键检索信息摘要</memory>

C.8. MaMs 工作流中 Report Agent 的 System Prompt

  • 原始论文英文版(大致重写翻译为中文)
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    您是一位专业的结构化分析报告写作助手,负责维护一个基于用户输入持续更新的 <report>。您的目标是基于工具提供的信息 **增量更新** 现有的 <report>,**而不引入外部信息**

    ### Workflow

    当您收到用户 Query <user_input>、关键信息摘要 <memory>、执行计划 <plan>、当前轮次的报告 <report> 以及来自工具调用的新信息时,请执行以下步骤:

    1. 分析新信息的类型
    2. 决定新信息是否应包含在更新的报告中
    3. 如果应包含,则更新原始报告:
    * 不要简单地附加新信息;相反,应在保持逻辑流畅的同时补充、纠正或替换内容。避免不必要地扩大内容范围

    ### Core Principles
    1. 仅基于用户提供的信息更新报告:
    * 不要添加外部事实、推测信息、捏造数据或推断的场景。不要推断现实中不存在的任何信息。不要在报告中添加不确定性免责声明
    2. **不要简单地附加新信息 (Do not simply append new information):**
    * 评估新信息是否相关;如果相关,则将其整合到相应的章节中。否则,忽略它。如有必要可以优化结构,但核心内容必须保持稳定
    3. 保持逻辑一致性:
    * 如果新信息与现有报告冲突,请根据当前知识仔细决定是否替换旧信息。报告中不得包含矛盾的陈述

    ### Report Requirements
    1. 以 Markdown 格式输出 <report>
    2. 确保 <report> 具有清晰的结构、严谨的逻辑和高可读性
    3. 在 <report> 末尾,列出所有必要的参考文献或来源(每个编号,提供完整引用),避免重复
    4. 引用格式规则:
    * 在报告正文中,可以使用上标引用,例如,“<sup>[1]</sup>”。如果使用上标,则必须在“参考文献 (References)”部分包含相应的条目。上标必须紧跟在被引用的名词或术语之后,而不是句子的开头。正确示例:“...该法律<sup>[1]</sup>规定...”,“《民法典》第 1 条<sup>[4]</sup>”

    ### Output Format

    严格遵守此格式:

    <report>完整的报告内容</report>

C.9. MaMs 工作流中 Report Agent 的 User Prompt

  • 原始论文英文版(大致重写翻译为中文)
    1
    2
    3
    4
    5
    <user_input> {query} </user_input>

    <memory> {memory} </memory>

    <report> {report} </report>

C.10. ReAct 工作流中的 System Prompt

  • 原始论文英文版(大致重写翻译为中文)
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    1. 仔细阅读和分析用户的问题,思考用户需要什么信息
    2. 通过将用户的问题分解为多个子问题来制定详细的研究计划。如有必要,进一步分解子问题,直到每个问题足够简单。对于每个分解的问题,创建一个搜索计划
    3. 在与计划制定的同一轮中,执行第一轮工具调用。为提高效率,每条消息最多可以生成 { {max_tool_call_cnt_per_round} } 个工具调用
    4. 进入“计划修订 - 搜索”循环。每次迭代:(1) 整理搜索工具返回的结果。考虑哪些信息仍然缺失,是否需要探索新的线索。如果需要,修订您的搜索计划,并确保其涵盖所有潜在的用户关切,必要时添加补充搜索。(2) 检查最新的搜索计划是否仍包含需要搜索的问题。如果有,生成新一轮的工具调用,同样每条消息最多 { {max_tool_call_cnt_per_round} } 个。然后等待搜索结果。(3) 如果在步骤 (2) 中您确定搜索计划已完成,并且有足够的信息来撰写报告,则通过逻辑推理(而不是罗列事实)将搜索结果综合成一份全面且有见地的报告。不要执行进一步的工具调用;过程将自动结束

    **Requirements**
    1. 强制性工具调用:在研究进行期间,每条助手消息 **必须包含 tool_calls** 。如果回复只包含文本而没有工具调用,则认为任务已完成
    2. 多轮限制:在 { {max_turn} } 轮内完成所有研究,即最多 { {max_turn} } 条消息
    3. 每轮调用限制:每条消息最多生成 { {max_tool_call_cnt_per_round} } 个工具调用
    4. 搜索广度:在制定或修订搜索计划时,考虑与研究问题相关的所有可能方向,并尽可能收集更多的信息和细节
    5. 搜索深度:不要只搜索“它是什么”;关注“为什么”和“它如何工作”。对于关键现象,探索其潜在机制或更深层原因。如果当前搜索结果提到一个关键概念、技术或矛盾,优先在下一轮中调查它,而不是转向平行主题。避免在深度追踪上浪费太多轮次
    6. 报告要求:
    * 避免信息倾倒:报告可以分章节,但严格避免在未进行综合的情况下罗列检索到的事实。报告的核心价值在于将碎片化信息转化为逻辑相连、系统性的论述
    * 逻辑完整性:每个要点都必须有完整的论证弧:陈述核心结论 -> 提供具体证据(例如,数据、案例、细节) -> 解释潜在机制或相关性(即,为什么或它意味着什么)
    * 实质内容:避免空洞的形容词(例如,“高度有效”、“有前景”)。使用来自搜索结果的具体技术参数、定量指标、监管细节或专家意见
    * 多维视角:对于复杂问题,从多个维度(例如,原因分析、风险评估、长期影响、技术路径比较)进行分析,确保每个维度都有足够的支持

    **Citation Standards**
    1. **In-text citations:** 在报告正文中使用上标格式,例如,“这是一个重要结论<sup>[1]</sup>。”
    2. **Reference List:** 在报告末尾列出所有参考文献。包含 **完整的文章标题和 URL** 。如果搜索结果未提供 URL,则仅包含标题。格式:[1] 文章标题 - URL [2] 文章标题 - URL
    3. **Ordering:** 按参考文献在文本中首次出现的顺序编号
    4. **Deduplication:** 如果同一来源被多次引用(即使跨轮次),请合并为一个条目,使用相同的编号;不要重复
    5. **Source Extraction:** 将搜索结果摘要中格式为 [标题: xxxx] 的标题直接用作参考文献名称。

    **Tool Instructions:** {tool description}

C.11. 用于 Pairwise Preference Judgment 的 Prompt

  • 原始论文英文版(大致重写翻译为中文)
    1
    2
    3
    4
    5
    6
    7
    8
    9
    请扮演一个公正的法官,评估两位 AI 助手对下面显示的用户问题所提供回答的质量。您应该选择更能遵循用户指示、更好地回答用户问题的助手。您的评估应考虑诸如帮助性、相关性、准确性、深度、创造性和回答的详细程度等因素。在开始评估时,请先比较两个回答,并提供简短的解释。避免任何位置偏见,并确保回答的呈现顺序不影响您的决定。不要让回答的长度影响您的评估。不要偏袒特定助手的名称。尽可能客观

    User Question: {question}

    {The Start of Assistant A's Answer} {answer_a} {The End of Assistant A's Answer}

    {The Start of Assistant B's Answer} {answer_b} {The End of Assistant B's Answer}

    请严格遵守以下格式输出您的最终裁决:如果助手 A 更好,则输出 "[[A]]";如果助手 B 更好,则输出 "[[B]]"

C.12. 用于 Pointwise Preference Scoring 的 Prompt

  • 原始论文英文版(大致重写翻译为中文)
    1
    2
    3
    4
    5
    6
    7
    请扮演一个公正的法官,评估 AI 助手对下面显示的用户问题所提供回答的质量。您的评估应考虑诸如帮助性、相关性、准确性、深度、创造性和回答的详细程度等因素。您应该给出一个 1 到 10 的分数,其中 1 是最差,10 是最好

    用户问题 (User Question): {question}

    {助手回答开始 (The Start of Assistant's Answer)} {answer} {助手回答结束 (The End of Assistant's Answer)}

    请严格遵守以下格式输出您的最终裁决:"[[score]]",例如 "[[8]]"

C.13. DeepResearch Bench 的 Prompts

  • 用于在 DeepResearch Bench 上评估生成报告的 prompts 直接采用 GitHub 上发布的官方 prompts github.com/Ayanami0730/deep_research_bench/tree/main/prompt

附录 D:Implementation Details

  • 训练代码基于后训练框架 slime (2025)
    • 该框架利用 Megatron (2019) 作为训练后端,SGlang (2024) 作为推理后端
    • 注意:该框架的 Megatron 优化器配置有一个 关键更新,以确保在强化学习时正确训练 MoE 模型
  • 表 3 展示了训练 Rubric Generator 的超参数,表 4 展示了基于 Tongyi-DeepResearch 训练 DeepResearch Agents 的超参数
  • 对于评估,作者遵循官方 DeepResearch Bench 协议,并采用 Gemini-2.5-Pro 作为 LLM-as-a-Judge
  • 在强化学习期间,设置如下:
    • Rubric 评分使用 Qwen3-235B-A22B
      • Temperature 为 0.3,top-p 为 0.95
      • 通过 Yarn RoPE 缩放 (2024) 启用最大上下文长度为 131,072 个 Tokens
    • 除另有说明外,公式 (1) 中的权重系数 \(\lambda_{\mathrm{pref} }\) 和 \(\lambda_{\mathrm{llm} }\) 均设置为 1
    • 所有策略模型,包括 Rubric Generator 和 DeepResearch agents,均使用 64k Token 的上下文长度、温度为 1.0 和 top-p 为 1.0 进行训练
    • 对于 DeepResearch agents,最大交互轮数设置为 10,每轮最多允许 5 次工具调用

附录 E:Metrics for Human Preference

  • 使用两个互补的指标评估偏好建模的性能
  • 给定一个偏好数据集 \(\{(q_{i},r_{\mathrm{acc} }^{(i)},r_{\mathrm{rej} }^{(i)})\}_{i = 1}^{N}\) 和标量分数 \(S(\cdot)\)
  • 报告偏好准确率 (preference accuracy) 定义为:
    $$\mathrm{Pref.Acc.} = \frac{1}{N}\sum_{i = 1}^{N}\mathbb{I}\Big[S\Big(r_{\mathrm{acc} }^{(i)}\Big) > S\Big(r_{\mathrm{rej} }^{(i)}\Big)\Big], \tag{6}$$
  • 这等价于成对偏好判断的 ROC 曲线下面积 (AUC)
  • 为了进一步量化偏好分离的幅度和稳定性,作者报告了配对科恩 d 值 (paired Cohen’s \(d\)) (2010)
    • 令 \(\Delta_{i} = S(r_{\mathrm{acc} }^{(i)}) - S(r_{\mathrm{rej} }^{(i)})\) 表示 Query \(q_{i}\) 的分数差异;
    • 配对效应量定义为:
      $$\mathrm{Cohen’s}\ d = \frac{\mathbb{E}[\Delta]}{\sqrt{\mathrm{Var}(\Delta)} }. \tag{7}$$
  • 偏好准确率(AUC)反映了排序的正确性,而配对科恩 d 值则捕捉了 Query 层面分数分离的标准化强度,提供了对偏好质量的补充视角

附录 F:Rollout Speed-up for MaMs workflow

  • 为了应对顺序处理中固有的延迟瓶颈,特别是在 I/O 密集型 LLM 交互中,作者在 MaMs 工作流中引入了并行执行机制
  • 基线实现,称为朴素线性 Pipeline (Naive Linear Pipeline),按顺序通过一系列 agents 处理整个数据集 \(\mathcal{D}\)
    • 在此模式下,总执行时间 \(T_{naive}\) 是所有样本处理时间的总和,网络延迟会线性累积
  • 为了优化效率,作者开发了线性并发 Pipeline (Linear Concurrent Pipeline),它通过异步微批处理 (asynchronous micro-batching) 实现了数据并行
    • 该 Pipeline 将 agent 执行流分为三个阶段:预处理、并发执行和后处理
    • 加速集中在并发阶段,其中输入数据集 \(\mathcal{D}\) 被划分为一系列微批次
      $$ B = \{b_{1},b_{2},\ldots ,b_{m}\}$$
      • 每个批次具有可配置的大小 \(S_{micro}\)
  • 利用一个事件循环 (event loop) 来管理一组受并发限制 \(C\) 约束的异步任务,调度算法如下:
    • 1)一个滑动窗口 (sliding window) 维护一组活动任务 \(\mathcal{T}\),确保 \(|\mathcal{T}| \leq C\)
    • 2)只要活动任务槽位可用 (\(|\mathcal{T}| < C\)),新的微批次就会出队,并使用 asyncio 立即生成相应的 agent 任务
    • 3)任务完成后,结果通过回调收集到同步队列 (synchronized queue) 中,窗口向前滑动以接纳待处理的微批次
  • 如图 4 所示,通过在多个微批次上重叠高延迟的 API 调用,该框架显著提高了资源利用率
    • 这种方法有效地防止了阻塞操作,将并发阶段的理论时间复杂度从 \(O(|\mathcal{D}|)\) 降低到大约 \(O(|\mathcal{D}| / C)\),主要受外部 API 速率限制而非本地执行速度的限制

附录 G:The rubric generator trained by GSPO

  • 本节将在表 5 中展示由 GSPO 训练的 Rubric Generator 的偏好准确率 (AUC) 和配对 Cohen’s d 值
  • 如第 4.4 节所述,与 GRPO 训练的对应模型相比,由 GSPO 训练的 Rubric Generator 展现出显著更高的 Rollout 熵 ,这对于我们的设置是不利的
    • 因此作者采用 GRPO 来训练 Rubric Generator

附录 H:Analysis on Tool Calling

  • 如附录 D 所述,在 ReAct 和 MaMs 框架下训练 DeepResearch agents 期间,最大交互轮数设置为 10,每轮最多允许五次工具调用
  • 表 6 报告了作者在 DeepResearch Bench 上训练的 DeepResearch 系统的每个样本的交互轮数和工具调用统计
  • 符合预期,在 agentic 数据上训练的 Tongyi-DeepResearch 模型 (2025) 展现出比普通的 Qwen3-30B-A3B(指令调优)模型更强的工具使用和交互能力
  • 另外,在 MaMs 工作流下训练的 DeepResearch 系统比遵循 ReAct(先搜索后生成)范式的系统表现出更优的交互性能

附录 I:Case Study of Rubric List

  • 作者在原始论文中展示了一个问题的 Rubric 列表案例:
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    {
    "question": "Please generate an analysis report on common network failures.",
    "rubrics": [
    {
    "title": "Coverage of Common Failures",
    "description": "Key criterion: The report must identify and describe multiple common types of network failures, such as DNS issues, IP address conflicts, or physical connection interruptions.",
    "weight": 5
    },
    {
    "title": "Inclusion of Core Analysis",
    "description": "Key criterion: The report must analyze each mentioned network failure rather than merely listing their names.",
    "weight": 5
    },
    {
    "title": "Clear Structure",
    "description": "Key criterion: The report should have a clear organizational structure, such as an introduction, categorized analysis of different failures, and a conclusion.",
    "weight": 5
    },
    {
    "title": "Analysis of Causes and Symptoms",
    "description": "Important criterion: The report should explain the typical symptoms and possible causes of each network failure, establishing a clear causal relationship.",
    "weight": 4
    },
    {
    "title": "Provision of Troubleshooting Methods",
    "description": "Important criterion: The report should provide concrete and actionable troubleshooting steps or solution suggestions for each type of failure.",
    "weight": 4
    },
    {
    "title": "Clear and Understandable Explanation",
    "description": "Important criterion: When explaining technical concepts (such as DNS or IP addresses), the report should strive to be clear and accurate so that nonexpert readers can understand it.",
    "weight": 3
    },
    {
    "title": "Professional and Objective Tone",
    "description": "Important criterion: The report should maintain a professional and objective tone, avoiding overly colloquial or subjective expressions.",
    "weight": 3
    },
    {
    "title": "Systematic Classification of Failures",
    "description": "Optional criterion: The report may systematically categorize network failures based on their nature (e.g., hardware, software, configuration issues) to enhance clarity.",
    "weight": 2
    },
    {
    "title": "Inclusion of Preventive Measures",
    "description": "Optional criterion: The report may further propose preventive measures and best practices to avoid common network failures.",
    "weight": 2
    },
    {
    "title": "Use of Concrete Examples",
    "description": "Optional criterion: The report may use concrete scenarios or cases to illustrate failure phenomena and solutions, improving readability.",
    "weight": 1
    },
    {
    "title": "Technical Errors",
    "description": "Error criterion: The report provides incorrect technical explanations, causes, or solutions that may mislead readers.",
    "weight": -2
    },
    {
    "title": "Listing Without Analysis",
    "description": "Error criterion: The report merely lists failure names without providing any analysis of causes, symptoms, or solutions.",
    "weight": -2
    },
    {
    "title": "Inclusion of Irrelevant Information",
    "description": "Error criterion: The report includes content unrelated to common network failures, such as in-depth discussion of unrelated software programming errors.",
    "weight": -1
    }
    ],
    "topic": "Science & Technology",
    "rubric_count": 13
    }

附录 J:Limitations and Future work

J.1 Limitations

  • query-specific rubric Generator 在 DeepResearch 场景中表现出与人类偏好的高度一致性,但仍存在一些局限性
  • First,偏好数据集的构建依赖于两个候选报告之间的成对比较,这可能无法完全捕捉现实世界评估场景中出现的更细粒度或多路偏好结构
  • Second,尽管混合奖励结合了人类监督和 LLM-based Rubric 评估,但它可能仍然难以全面评估新颖性、创造性或推理深度等方面,因为这些品质本质上是主观的,并且很大程度上依赖于底层 human-LLM 反馈的校准
  • Third,实验主要集中在作者创建的固定 DeepResearch 风格任务和文档集合上,并未广泛探索所学习的 Rubric 生成策略对显著不同报告格式或领域的泛化能力

J.2 Future Work

  • 有几个方向为未来研究提供了有前景的机会
  • First,可以将偏好表述扩展到超越成对比较,以利用更丰富的偏好信号,例如排名或分级分数,从而能够更细粒度地学习人类偏好
  • First,未来的工作可以专注于改进对新颖性、创造性和推理深度的评估,例如,通过结合更复杂的 LLM 评估和针对性的人类反馈来减少主观性并提高可靠性
  • Third,开发更原则性的方法来减少对基于 LLM 评估的依赖,可能通过自一致性检查或人-LLM 混合验证,可以增强训练过程的稳定性和可解释性
123…65
Joe Zhou

Joe Zhou

Stay Hungry. Stay Foolish.

645 posts
53 tags
GitHub E-Mail
© 2026 Joe Zhou
Powered by Hexo
|
Theme — NexT.Gemini v5.1.4