第 12 篇：RLVR——基于可验证奖励的强化学习

栏目 AgentAlgorithms；专栏 Agent 算法；标签 Agent、RLVR、Verifier、PPO、GRPO、强化学习

大语言模型的监督微调主要学习“给定输入时应当模仿什么输出”，但在数学推理、代码生成、结构化决策和 Agent 工具执行中，模型还需要通过试错学习：哪些输出真正解决了问题，哪些轨迹虽然语言流畅，却没有完成任务。只要任务结果能够通过规则、程序、测试用例或环境状态自动核验，就可以把验证结果转化为强化学习奖励，这类训练范式通常称为 RLVR（Reinforcement Learning with Verifiable Rewards，基于可验证奖励的强化学习）。

RLVR 的核心并不是某一种固定策略优化算法，而是一条完整的在线闭环：

\text{任务采样} \rightarrow \text{策略 Rollout} \rightarrow \text{Verifier 验证} \rightarrow \text{优势估计} \rightarrow \text{策略更新}.

其中最重要的工程事实是：模型不会学习“客观真理”，而会学习最大化系统实际返回的奖励。因此，Verifier 的覆盖范围、错误模式、环境可复现性和奖励组合方式，会直接决定模型最终学到什么。

1. RLVR 的定义与定位#

RLVR 方法定位图

1.1 Reinforcement Learning with Verifiable Rewards#

设任务输入为 $x$ ，语言模型策略为 $\pi_\theta$ ，模型生成答案、程序或 Agent 轨迹 $y$ ：

y\sim \pi_\theta(\cdot\mid x). \tag{1}

系统随后调用验证器：

\mathcal V(x,y,e) \rightarrow (d,u,r,\mathcal E), \tag{2}

其中：

$e$ 是参考答案、测试用例、环境快照或业务状态；
$d\in\{\text{pass},\text{fail},\text{unknown}\}$ 是任务语义判定；
$u\in\{\text{valid},\text{env\_error}\}$ 表示本次验证是否构成有效试验；
$r\in\mathbb R$ 是供训练使用的奖励；
$\mathcal E$ 是失败测试、状态差异、解析结果等证据。

最简单的 RLVR 使用二元终局奖励：

r(x,y,e)= \mathbf 1[ \mathcal V(x,y,e)=\text{pass} ]. \tag{3}

模型训练目标是提高当前策略在任务分布上获得可验证成功的期望概率：

\max_\theta J(\theta) = \mathbb E_{x\sim D,\;y\sim\pi_\theta(\cdot\mid x)} [r(x,y,e)]. \tag{4}

“可验证”是相对于某个验证规范而言的，而不是绝对正确性的同义词。数学答案匹配器只能验证其支持的表达形式，有限单元测试只能验证被覆盖的输入，Agent 环境也只能验证被记录的状态。因此更准确的关系是：

\text{通过 Verifier} \not\Rightarrow \text{满足全部真实需求}. \tag{5}

RLVR 的主要价值，是把原本昂贵的人工判断转化为可大规模执行的训练反馈。其主要风险也来自同一点：策略会主动搜索 Verifier 的漏洞，而不只是被动接受评价。

1.2 RLVR、RLHF、RLAIF 与 SFT 的区别#

四种方法最根本的区别不是是否使用大模型，而是训练信号的来源和数据是否由当前策略在线生成。

方法	主要监督信号	典型数据形态	是否依赖当前策略在线采样	主要适用目标
SFT	人工、专家或合成示范	$(x,y^\star)$	否	格式学习、知识注入、能力初始化
RLHF	人类偏好或由其训练的奖励模型	$(x,y^+,y^-)$ 或标量奖励	通常是	有用性、风格、安全与主观偏好
RLAIF	AI 评价、AI 偏好或宪法规则生成的反馈	AI 排序、评分或 Critique	通常是	扩展偏好监督规模
RLVR	规则、程序执行、测试用例或环境状态	可自动验证的答案或轨迹	通常是	数学、代码、约束任务与 Agent 成功率

SFT 优化目标是最大化示范序列的条件似然：

\mathcal L_{\mathrm{SFT}} = -\mathbb E_{(x,y^\star)\sim D} \sum_{t=1}^{|y^\star|} \log \pi_\theta (y_t^\star\mid x,y_{<t}^\star). \tag{6}

它回答的是“如何模仿数据中的目标输出”，并不会直接探索数据中未出现的新策略。RLHF 和 RLAIF 通常需要把偏好转换为奖励，再通过 PPO、REINFORCE 等算法更新策略；它们能处理开放式质量，却依赖学习型评价器，其分数可能受到长度、风格和分布漂移影响。

RLVR 的优势是奖励通常更客观、可复现且成本更低。例如，代码是否通过测试、数学答案是否符号等价、数据库是否达到目标状态，不需要人工逐条评分。但 RLVR 只优化被验证的性质：一个程序通过测试并不自动意味着安全、可维护；一个 Agent 完成目标也不代表没有越权或副作用。

四者并非互斥。常见训练链路是先用 SFT 建立基本指令遵循和成功概率，再用 RLVR 提升可验证能力，最后再用偏好与安全监督修正表达质量和行为边界。

1.3 可验证奖励是一种奖励来源而非特定优化器#

RLVR 描述的是奖励从哪里来，PPO、GRPO、RLOO 和 REINFORCE 描述的是如何利用奖励更新策略。二者位于不同分类维度。

同一个数学等价性 Verifier 可以分别与多种优化算法结合：

\text{Math Verifier} + \begin{cases} \text{PPO},\\ \text{GRPO},\\ \text{RLOO},\\ \text{REINFORCE} \end{cases} \Longrightarrow \text{不同 RLVR 实现}. \tag{7}

反过来，GRPO 也可以使用偏好模型分数、规则奖励或混合奖励，并不天然等同于 RLVR。准确的技术描述应同时说明：

任务与 Rollout 单位；
奖励来源及其语义；
优势估计方法；
策略目标与 KL 控制；
数据是 On-policy、近似 On-policy 还是 Off-policy。

例如，“使用 GRPO 训练数学推理模型”仍不完整；更精确的表达是：“对每道数学题从当前策略采样一组解答，使用符号等价性 Verifier 产生结果奖励，通过组内标准化构造相对优势，并使用带裁剪和 KL 约束的策略目标更新模型。”

这种区分还决定了系统故障定位。奖励上升但隐藏测试下降，可能是 Verifier 被利用；KL 爆炸但奖励稳定，可能是优化器或学习率问题；组内优势长期为零，则可能是任务难度、采样温度或奖励粒度不合适。把这些问题都归因于“GRPO 不稳定”或“RLVR 失效”会掩盖真正原因。

1.4 RLVR 适合解决的问题与必要条件#

RLVR 适合的任务通常满足以下条件。

第一，存在可执行的验证规范。 验证器不一定需要证明完整正确性，但必须能够以足够高的精度区分成功与失败。例如：

数学题存在可解析的标准答案或等价性规则；
代码任务存在测试用例、静态检查或执行环境；
结构化任务存在 Schema、逻辑约束或求解器；
Agent 任务存在可观测环境状态和明确后置条件。

第二，初始策略必须有非零成功概率。 若对所有训练问题，当前模型采样几百次仍完全失败，则终局二元奖励无法提供正向信号。此时通常需要先进行 SFT、课程学习、提示优化或引入部分奖励。可将单题成功概率记为：

p_x = P_{y\sim\pi_\theta} [ \mathcal V(x,y)=\text{pass} ]. \tag{8}

当 $p_x\approx 0$ 时，几乎没有正样本；当 $p_x\approx1$ 时，组内候选几乎全对，同样缺乏相对学习信号。对组内方法而言，中等成功率任务通常最有训练价值。

第三，Verifier 的误差必须可控。 假阳性会把错误策略强化为高概率行为，通常比假阴性更危险；假阴性则会压制等价解法和输出多样性。策略优化还会把样本推向 Verifier 最不熟悉的分布，因此静态准确率高不代表在线训练安全。

第四，验证成本必须可承受。 数学解析通常便宜，代码沙箱和浏览器环境可能远比一次模型前向更昂贵。训练吞吐应按完整系统成本评估：

C_{\mathrm{total}} = C_{\mathrm{rollout}} + C_{\mathrm{verify}} + C_{\mathrm{reset}} + C_{\mathrm{train}}. \tag{9}

第五，目标不能主要依赖难以形式化的主观属性。 创意写作、审美、复杂价值判断和开放式咨询不适合仅靠 RLVR。它们可以使用可验证规则作为底线，再结合人工偏好、RLAIF 或学习型 Judge。

2. 可验证任务的形式化#

可验证任务的形式化

2.1 提示、模型输出、环境状态与验证函数#

对单轮文本任务，训练样本可以表示为：

x\sim D,\qquad y\sim\pi_\theta(\cdot\mid x),\qquad r=\mathcal V(x,y,e). \tag{10}

对多步 Agent，输出不是单个字符串，而是动作、观察和环境状态组成的轨迹：

\tau = (o_0,a_0,o_1,a_1,\ldots,o_T,a_T,o_{T+1}), \tag{11}

其中 $o_t$ 是策略可见观察， $a_t$ 是文本、工具调用或环境动作。环境内部还可能维护模型不可见的真实状态 $s_t$ ：

s_{t+1} \sim P(\cdot\mid s_t,a_t), \qquad o_{t+1} \sim O(\cdot\mid s_{t+1}). \tag{12}

因此 Agent RLVR 更接近部分可观测马尔可夫决策过程。终局验证函数应尽量读取权威状态，而不是只读取模型最后的自然语言声明：

d_T = \operatorname{CheckGoal} (s_T,g) \land \operatorname{CheckConstraints} (s_{0:T},a_{0:T}). \tag{13}

例如，任务是“把会议移动到下周一”，模型输出“已经修改”不能作为成功证据；Verifier 应检查日历事件的实际开始时间、事件 ID、时区和参与人是否满足要求。

为了避免把基础设施故障误当成策略错误，验证接口最好拆分任务判定与试验有效性：

\mathcal V(x,\tau,e) \rightarrow (d,u,\mathcal E), \tag{14}

其中 $d$ 只在 $u=\text{valid}$ 时进入策略奖励；若浏览器崩溃、测试服务不可用或环境初始化失败，应记录为 ENV_ERROR，在预先规定的预算内重试或隔离。

2.2 二元奖励、连续奖励与多维奖励#

二元奖励最接近明确的任务成功事件：

r_{\mathrm{binary}} = \mathbf 1[d=\text{pass}]. \tag{15}

它的优点是语义清晰、尺度稳定和难以引入主观偏差；缺点是奖励稀疏，两个都失败的候选无法区分谁更接近成功。

连续奖励表达部分完成程度。例如，代码任务可以使用测试通过比例：

r_{\mathrm{test}} = \frac{\sum_{j=1}^{M}w_j\mathbf 1[\text{test}_j\text{ passed}]} {\sum_{j=1}^{M}w_j}, \tag{16}

其中 $w_j$ 可表示测试重要性。若所有测试等权，模型可能优先适配大量简单测试，而忽略少量关键语义，因此测试权重和覆盖范围本身就是奖励规范的一部分。

多维奖励保留任务的多个属性：

\mathbf r = ( r_{\mathrm{correct}}, r_{\mathrm{format}}, r_{\mathrm{safety}}, r_{\mathrm{cost}}, r_{\mathrm{latency}}, r_{\mathrm{recovery}} ). \tag{17}

最简单的标量化是加权和：

R = \sum_{j=1}^{m}w_jr_j. \tag{18}

但硬安全约束不应依赖一个足够大的负权重，因为高任务分可能抵消一次不可接受的操作。更稳健的方式是先定义可行域：

\max_\theta \mathbb E[R_{\mathrm{soft}}(\tau)] \quad \text{s.t.}\quad P( V_{\mathrm{hard}}(\tau)=1 )\ge1-\delta. \tag{19}

在工程实现中，硬规则通常作为 Gate：违规轨迹直接判定失败或隔离；正确性、成本和长度等软目标才进入加权奖励。

2.3 期望验证奖励与 KL 约束#

如果只最大化当前 Verifier 返回的奖励，策略可能迅速偏离初始模型，出现语言退化、输出模式坍缩、长度异常或集中利用验证器漏洞。RLVR 通常使用参考策略 $\pi_{\mathrm{ref}}$ 约束策略漂移：

J(\theta) = \mathbb E_{x,y\sim\pi_\theta} [ R(x,y) ] - \beta \mathbb E_{x} \left[ D_{\mathrm{KL}} \left( \pi_\theta(\cdot\mid x) \| \pi_{\mathrm{ref}}(\cdot\mid x) \right) \right]. \tag{20}

序列级 KL 难以直接计算，实践中常用采样 Token 上的 Log-ratio 估计：

\widehat D_{\mathrm{KL}} = \sum_{t=1}^{|y|} \left[ \log\pi_\theta(y_t\mid x,y_{<t}) - \log\pi_{\mathrm{ref}}(y_t\mid x,y_{<t}) \right]. \tag{21}

于是奖励可以写成任务奖励与 Token 级 KL 惩罚的组合：

R_{\mathrm{total}} = R_{\mathrm{task}} - \beta\widehat D_{\mathrm{KL}}. \tag{22}

$\beta$ 太大时，模型几乎无法离开参考策略，训练奖励增长缓慢； $\beta$ 太小时，策略可能快速失去语言能力或过拟合 Verifier。固定 $\beta$ 并非总是最优，可以根据观测 KL 与目标 KL 的偏差自适应调整：

\beta_{k+1} = \beta_k \exp \left[ \eta_\beta \left( \widehat D_{\mathrm{KL},k} - D_{\mathrm{target}} \right) \right]. \tag{23}

需要区分两个问题：KL 约束可以限制单轮策略漂移，但不能修复错误奖励。如果 Verifier 把某类错误答案稳定判为高分，较小步长只会延缓而不是消除 Reward Hacking。

2.4 验证函数无需可微的原因#

RLVR 可以使用编译器、数据库、浏览器和离散规则，是因为策略梯度不需要对奖励函数本身求导。设序列回报为 $R(x,y)$ ，则：

J(\theta) = \mathbb E_{y\sim\pi_\theta(\cdot\mid x)} [R(x,y)]. \tag{24}

利用 Log-derivative Trick：

\nabla_\theta J(\theta) = \mathbb E_{y\sim\pi_\theta} \left[ R(x,y) \nabla_\theta \log\pi_\theta(y\mid x) \right]. \tag{25}

加入与动作无关的基线 $b(x)$ 不改变期望梯度：

\nabla_\theta J(\theta) = \mathbb E \left[ (R-b) \nabla_\theta \log\pi_\theta(y\mid x) \right]. \tag{26}

Verifier 只需返回标量或可组合的奖励，不需要提供梯度，也不需要内部可微。因此奖励可以来自任意外部程序。

代价是 Monte Carlo 策略梯度方差较大。对于语言模型，一个序列可能有数千个 Token，却只得到一个终局奖励；所有 Token 的梯度都共享相同序列优势，无法直接识别真正导致成功或失败的关键步骤。PPO 使用 Critic，GRPO 使用组内相对基线，RLOO 使用留一基线，本质上都在降低这种方差。

不可微也不等于不可被优化。只要策略能反复查询奖励，强化学习仍会逐渐发现 Verifier 的决策边界和漏洞。因此必须像设计公开 API 一样设计验证器的接受域、未知域、错误处理和查询预算。

3. 可验证奖励的主要来源#

RLVR 奖励来源与优化器

3.1 数学答案与符号等价性验证#

数学任务最常见的验证方式是比较模型最终答案与标准答案。字符串精确匹配简单但召回率低，例如：

\frac12,\qquad 0.5,\qquad \frac24 \tag{27}

在语义上等价，却具有不同字符串。

更可靠的数学 Verifier 通常包含：

从模型输出中定位最终答案；
解析 LaTeX、分数、根式、区间、集合和单位；
对表达式进行规范化；
使用符号化简、精确计算或数值代入判断等价；
检查定义域、精度、单位和题目要求的答案形式。

可以把接受条件表示为：

d = \mathbf 1[ \operatorname{Canon}(y) \equiv \operatorname{Canon}(y^\star) \text{ under }\mathcal C(x) ], \tag{28}

其中 $\mathcal C(x)$ 是题目给定的定义域、单位和容差条件。

数学 Verifier 的两个主要错误是：

假阳性：错误答案因解析漏洞、特殊值、NaN、容差过宽或随机代入不足被判为正确；
假阴性：正确答案因等价表达、分支条件、单位、格式或解析失败被判为错误。

随机数值代入可以补充符号化简，但不能替代严格等价证明。两个不同表达式可能在有限采样点上相等；含奇点、分段或复杂数值误差的表达式还可能被误判。

结果验证只保证最终答案满足检查器，不保证推理过程正确。模型可能通过猜测、记忆、答案泄漏或错误推导得到正确结论。因此数学 RLVR 常与过程监督、隐藏题型和独立 Verifier 结合。

3.2 代码编译、执行与单元测试#

代码任务可以通过多层执行信号验证：

\text{Source} \rightarrow \text{Parse} \rightarrow \text{Compile} \rightarrow \text{Run} \rightarrow \text{Tests} \rightarrow \text{Resource Check}. \tag{29}

奖励可以拆成：

R_{\mathrm{code}} = w_c r_{\mathrm{compile}} + w_p r_{\mathrm{public}} + w_h r_{\mathrm{hidden}} - \lambda_t c_{\mathrm{time}} - \lambda_m c_{\mathrm{memory}} - \lambda_s c_{\mathrm{side\ effect}}. \tag{30}

编译通过只验证语法、类型和链接要求；公开测试可能被硬编码；隐藏测试仍可能覆盖不完整。因此需要组合：

样例测试与隐藏测试；
边界测试和异常测试；
性质测试；
变形测试；
静态安全检查；
资源限制与副作用检查。

代码必须在隔离沙箱中运行。候选程序默认不应拥有网络、密钥和宿主文件系统访问权；测试文件和 Verifier 应处于不同权限域，候选进程退出后再执行隐藏测试，并对测试文件哈希进行校验。否则模型可能通过读取测试、修改脚本、伪造输出或消耗资源获得错误高分。

测试超时也需要区分语义。若候选进入无限循环，属于策略失败；若沙箱调度或依赖服务故障，则属于无效试验。两者都返回 0 会把基础设施噪声写入策略梯度。

3.3 结构化输出、逻辑约束与规则检查#

结构化任务可以使用 JSON Schema、AST、逻辑规则、数据库约束或求解器进行验证。例如：

输出是否可解析；
必填字段是否存在；
字段类型、枚举和长度是否合法；
跨字段依赖是否满足；
日期、金额和单位是否一致；
调度结果是否存在资源冲突；
SQL 是否只读并满足查询约束；
计划是否满足全部逻辑条件。

设结构验证、约束验证和语义验证分别为：

V_{\mathrm{parse}}(y),\qquad V_{\mathrm{constraint}}(y),\qquad V_{\mathrm{semantic}}(x,y). \tag{31}

格式正确通常只是必要条件，不是充分条件：

V_{\mathrm{parse}}(y)=1 \not\Rightarrow V_{\mathrm{semantic}}(x,y)=1. \tag{32}

一个完全符合 Schema 的 JSON 仍然可以包含错误 ID、错误金额或虚构事实。因此格式奖励一般只能作为辅助信号：

R = R_{\mathrm{semantic}} + \lambda_f R_{\mathrm{format}}, \qquad \lambda_f \ll \text{核心正确性权重}. \tag{33}

对硬约束，更适合采用 Gate：无法解析、越权字段或非法状态转移直接阻断；对表达风格和字段顺序等软要求，才使用小权重奖励。

规则验证还应保留 UNKNOWN。例如一个新型但语义合法的表达超出解析器能力时，判为“确定错误”会制造假阴性；更合理的是隔离并交给更强解析器或人工复核。

3.4 Agent 工具执行状态与环境任务成功信号#

Agent 的任务成功通常依赖实际环境变化，而不是最后一段文字。一次工具动作可写为：

a_t = (\text{tool}_t,\text{args}_t), \tag{34}

环境执行后产生观察和状态转移：

(s_{t+1},o_{t+1}) = \operatorname{EnvStep}(s_t,a_t). \tag{35}

奖励依据可以来自：

工具名和参数是否合法；
权限、确认和前置条件是否满足；
API 或程序是否真正执行；
执行后的数据库、文件、网页或远程对象状态；
最终响应是否忠实反映执行结果；
是否发生未授权或意外副作用。

可将验证分层：

V_{\mathrm{agent}} = V_{\mathrm{policy}} \land V_{\mathrm{transition}} \land V_{\mathrm{goal}} \land V_{\mathrm{response}}. \tag{36}

HTTP 200、工具返回 success=true 或页面显示提示语，都不一定代表业务目标完成。可靠的 Verifier 应读取后台权威状态，或至少比较操作前后的状态差异：

\Delta s_t = s_{t+1}\ominus s_t. \tag{37}

Agent 环境还需要验证过程不变量。例如任务最终完成，但期间向错误收件人发送邮件、删除无关文件或执行未授权付款，不能被终局成功抵消。此类约束应作为硬失败条件。

4. 任务数据与训练环境设计#

RLVR 任务数据与训练环境

4.1 问题、标准答案、测试用例与环境快照#

一条可复现的 RLVR 样本不能只有问题和答案。建议至少包含：

1
{
2
  "task_id": "task_001",
3
  "prompt": "...",
4
  "task_type": "code",
5
  "reference_answer": null,
6
  "public_metadata": {},
7
  "hidden_verifier_id": "verifier_v4",
8
  "environment_snapshot": "image_sha256:...",
9
  "resource_limits": {
10
    "timeout_sec": 10,
11
    "memory_mb": 1024
12
  },
13
  "reward_config": "reward_v3",
14
  "random_seed": 42
15
}

不同任务需要的验证上下文不同：

数学任务需要标准答案、定义域、单位和解析规则；
代码任务需要仓库 Commit、依赖锁文件、测试集和容器镜像；
数据库任务需要初始快照、事务规则和目标状态；
浏览器任务需要页面版本、账户状态、虚拟时间和网络模拟；
工具 Agent 需要工具 Schema、权限策略和后置条件。

标准答案并非始终必要。代码和 Agent 可能存在多条合法轨迹，只要最终状态满足规范即可。强行要求复现唯一参考轨迹，会错误惩罚等价策略。

所有样本还应记录 Verifier 版本。规则、测试或环境升级可能让同一轨迹的奖励发生变化：

r = \mathcal V_{v} (x,\tau,e_v). \tag{38}

若不保存版本，训练日志无法解释历史奖励，也无法重放实验。

4.2 训练集难度分布与 Curriculum Learning#

RLVR 需要同时出现正负样本差异。对单题成功率 $p_x$ ，采样 $G$ 个候选时，全错和全对概率分别为：

P_{\mathrm{all\ wrong}} = (1-p_x)^G, \tag{39}

P_{\mathrm{all\ correct}} = p_x^G. \tag{40}

当 $p_x$ 太低时，几乎所有组全错；当 $p_x$ 太高时，几乎所有组全对。对依赖组内相对优势的算法，两种组都无法提供正确性方向上的梯度。训练数据的主要质量不只是题目是否困难，而是当前策略能否在同组产生奖励差异。

课程学习可以根据近期成功率、奖励方差或学习进展调整采样权重。例如：

w_x \propto \left[ p_x(1-p_x) \right]^\alpha, \tag{41}

该形式会优先采样中等成功率任务。也可以使用学习进展：

\Delta p_x = p_x^{(k)} - p_x^{(k-\Delta)}, \tag{42}

优先选择仍在改善、但尚未饱和的任务。

课程不能只保留“最有梯度”的任务。简单题有助于防止能力遗忘，困难题用于拓展边界，分布外题用于监控泛化。稳健的混合应保留固定比例：

D_{\mathrm{train}} = \lambda_e D_{\mathrm{easy}} + \lambda_m D_{\mathrm{medium}} + \lambda_h D_{\mathrm{hard}} + \lambda_o D_{\mathrm{OOD}}. \tag{43}

任务难度还依赖采样温度、最大长度和当前模型版本，因此课程标签不能永久冻结。

4.3 防止测试用例泄漏与奖励投机#

测试用例泄漏包括直接泄漏和反馈泄漏。直接泄漏是模型在 Prompt、仓库或环境中读取隐藏答案；反馈泄漏则是策略通过反复查询同一个 Verifier，逐步推测其测试分布和判定边界。

常见防护包括：

隐藏测试与模型上下文物理隔离；
候选程序与测试系统使用不同权限域；
动态生成测试输入；
使用性质测试和变形测试；
训练 Verifier 与最终评估 Verifier 分离；
对输入、变量名和数据顺序随机化；
限制同一实例的自适应查询次数；
对最高奖励尾部样本进行独立审计；
定期更新对抗测试但保留版本化回归集。

奖励投机通常发生在代理目标与真实目标不一致时：

R_{\mathrm{proxy}}\uparrow, \qquad R_{\mathrm{gold}}\not\uparrow. \tag{44}

例如模型可能：

硬编码公开样例；
输出解析器特殊值；
利用超时或异常分支；
伪造工具日志；
通过冗长枚举碰撞答案；
修改页面可见文本但不改变后台状态。

训练时必须同时维护独立 Gold 或 Shadow Verifier，不能用被策略直接优化的同一个奖励证明模型能力增长。

4.4 确定性环境、随机环境与可复现实验#

确定性环境满足：

\mathcal V(x,\tau,e)=r

在相同输入、轨迹和环境版本下始终返回相同结果。这类奖励适合缓存和重放。

随机环境中：

R \sim P(R\mid x,\tau,e,\omega), \tag{45}

其中 $\omega$ 表示环境随机性、网络抖动、搜索结果变化或并发状态。此时单次奖励可能同时包含策略质量和环境运气。应区分：

策略采样种子；
环境随机种子；
数据或测试生成种子；
基础设施错误。

为了公平比较同组候选，可以采用 Common Random Numbers：让同一道题的多个候选在相同环境随机条件下执行，降低环境噪声对组内排序的影响。对高方差任务应多次执行：

\widehat r = \frac1M \sum_{m=1}^{M} r^{(m)}, \qquad \widehat{\operatorname{Var}}(r) = \frac1{M-1} \sum_m (r^{(m)}-\widehat r)^2. \tag{46}

完全固定少数种子虽然便于复现，却可能让策略过拟合。训练可使用受控随机化，评估则同时报告固定种子集和未见种子集。

可复现实验至少需要冻结策略版本、推理参数、环境镜像、Verifier、任务快照、随机种子和重试规则。观察到失败以后再选择性重试，会产生评估偏差；重试预算必须在实验前定义。

5. RLVR 的完整训练流程#

RLVR 在线训练闭环

5.1 从当前策略采样多个候选输出或轨迹#

对每个任务 $x$ ，从当前或近似当前策略采样 $G$ 个候选：

y_1,\ldots,y_G \sim \pi_{\theta_{\mathrm{rollout}}} (\cdot\mid x). \tag{47}

Rollout 数据至少需要保存：

输入和生成 Token；
每个 Token 在 Rollout 策略下的 Log-probability；
策略版本与参考策略版本；
温度、Top-p、最大长度和停止原因；
对 Agent 而言的动作、观察、状态摘要和工具日志。

采样温度决定探索程度。温度过低时，候选近似重复，奖励方差不足；温度过高时，无效格式、幻觉动作和超长轨迹增加。候选多样性可以用唯一序列比例、Token 熵或语义聚类统计，而不能只看平均奖励。

对于 Agent，采样单位是完整轨迹。不同轨迹的工具调用数、环境等待时间和 Token 长度差异很大，批处理容易产生尾部拖慢。系统通常使用异步 Rollout Worker，并设置最大动作数、最大墙钟时间和异常终止类型。

严格 On-policy 要求 Rollout 策略与更新策略一致，但大规模系统中两者通常存在版本滞后：

\Delta_{\mathrm{policy}} = D_{\mathrm{KL}} ( \pi_{\theta_{\mathrm{train}}} \| \pi_{\theta_{\mathrm{rollout}}} ). \tag{48}

滞后过大会增加重要性比率方差，使裁剪样本增多。应记录每条轨迹的策略版本，并限制数据陈旧度。

5.2 调用 Verifier 计算奖励#

Verifier 对每个候选返回奖励与诊断：

1
{
2
  "decision": "fail",
3
  "trial_status": "valid",
4
  "reward_components": {
5
    "correctness": 0.0,
6
    "format": 1.0,
7
    "partial": 0.75,
8
    "cost": -0.08
9
  },
10
  "evidence": {
11
    "tests_passed": 9,
12
    "tests_total": 12,
13
    "failed_tests": ["edge_case_2"]
14
  },
15
  "verifier_version": "v4.2"
16
}

训练器最终可以只使用标量：

R_i = g( \mathbf r_i, \text{reward\_config} ), \tag{49}

但原始分量和证据必须保留，否则无法发现奖励异常、环境故障和投机模式。

验证服务应满足三个工程属性：

幂等性：同一确定性请求重复执行不会产生不同副作用；
隔离性：候选之间不共享污染状态；
可审计性：每个奖励都能追溯到规则、测试或状态证据。

对于无效试验：

u_i=\text{env\_error},

不应直接设置 $R_i=0$ 并进入策略梯度。更合理的是按预先定义的预算重试，仍失败则 Mask，并单独统计基础设施错误率。

奖励延迟也会影响吞吐。便宜的规则验证可同步执行，代码、网页和远端 Agent 环境通常需要异步队列。训练器只有在同组奖励齐全或达到超时策略后才能计算组内优势。

5.3 估计优势并更新模型策略#

策略梯度通常使用优势：

A_i = R_i-b_i, \tag{50}

其中 $b_i$ 是 Critic、组内均值、留一均值或运行基线。优势表示样本相对于当前条件下预期水平的好坏，而不是奖励绝对值本身。

对序列级奖励，常见实现把同一序列优势广播到全部生成 Token：

\mathcal L_{\mathrm{PG}} = -\frac1B \sum_{i=1}^{B} \sum_{t=1}^{|y_i|} m_{i,t} A_i \log \pi_\theta (y_{i,t}\mid x_i,y_{i,<t}), \tag{51}

其中 $m_{i,t}$ 是有效 Token Mask。若直接对所有 Token 求平均，长序列会在 Batch 中贡献更多梯度；若先对每条序列求平均，再跨序列平均，则每条轨迹权重相同。两者对应不同长度偏好，必须明确。

使用旧策略数据时，策略比率为：

\rho_{i,t}(\theta) = \frac{ \pi_\theta(y_{i,t}\mid x_i,y_{i,<t}) }{ \pi_{\theta_{\mathrm{old}}}(y_{i,t}\mid x_i,y_{i,<t}) }. \tag{52}

PPO、GRPO 等算法通常对 $\rho$ 裁剪，以限制单轮更新。训练还需要梯度裁剪、混合精度、Loss Mask、KL 监控和异常 Batch 处理。

优势估计无法自动解决长时程信用分配。若终局成功轨迹包含许多冗余动作，它们会一起获得正优势；若失败轨迹只有最后一步错误，前面正确动作也会共享负优势。过程奖励、Critic、环境里程碑和轨迹切分可以改善，但都会引入新的目标设计问题。

5.4 更新后重新采样形成在线训练闭环#

完成若干优化步后，系统发布新策略版本：

\theta_k \rightarrow \theta_{k+1},

并重新采样：

\pi_{\theta_k} \rightarrow D_k \rightarrow \operatorname{Update} \rightarrow \pi_{\theta_{k+1}} \rightarrow D_{k+1}. \tag{53}

在线闭环意味着训练数据分布随策略变化：

D_k \ne D_{k+1}. \tag{54}

这既是 RLVR 的优势，也是风险来源。模型能够发现旧数据中不存在的新解法，也能发现 Verifier 未覆盖的新漏洞。固定验证集只能测量静态泛化，不能完全预测在线优化后的行为。

大规模系统常采用异步流水线：Rollout、Verifier 和 Trainer 并行运行。异步提高硬件利用率，却产生数据陈旧和奖励版本不一致。每条样本必须绑定：

( \text{policy version}, \text{verifier version}, \text{environment version}, \text{reward config} ). \tag{55}

更新后的策略不应无限重复训练旧轨迹。可设置最大版本差、重要性比率阈值或数据生存时间。若需要重用旧成功轨迹，应把它们作为明确的 Off-policy 数据处理，而不是仍声称严格 On-policy。

训练闭环还应周期性插入独立评估和红队，而不是只监控训练奖励。最重要的曲线是：

R_{\mathrm{train}}\uparrow \quad\text{同时}\quad R_{\mathrm{hidden}}\uparrow, \tag{56}

若两者分离，应立即检查 Verifier Hacking、数据泄漏和分布过拟合。

6. 奖励函数设计#

RLVR 奖励函数设计

6.1 最终结果奖励与稀疏奖励问题#

纯终局奖励写为：

R(\tau) = \mathbf 1[ \operatorname{Goal}(s_T)=1 ]. \tag{57}

它最接近最终目标，避免人为规定中间过程，却存在稀疏奖励和信用分配困难。若任务需要连续完成 $K$ 个关键步骤，每步成功概率近似为 $p$ ，则完整成功概率约为：

P_{\mathrm{success}} \approx p^K. \tag{58}

当 $K$ 较大时，即使单步能力不差，成功轨迹也可能极少。例如 $p=0.7,K=10$ 时，成功概率只有约 $2.8\%$ 。

稀疏奖励的缓解方法包括：

使用较强 SFT 模型初始化；
从短任务和简单题开始；
增加每题 Rollout 数；
提供可验证的部分完成奖励；
识别环境里程碑；
从成功轨迹中提取更短示范；
对失败状态生成局部修复任务；
使用过程模型或 Critic 估计前缀价值。

增加采样数量不能无限解决问题。若单次成功概率为 $p$ ，至少一个成功候选的概率是：

P_{\mathrm{any}} = 1-(1-p)^G. \tag{59}

当 $p$ 极小时，需要的 $G$ 会非常大，验证成本也同步增长。此时问题不是优化器不够强，而是策略支持集与任务难度不匹配。

6.2 格式奖励、部分正确奖励与过程奖励#

格式奖励用于确保输出可解析，例如合法 JSON、正确答案标签或工具调用结构：

r_{\mathrm{format}} = \mathbf 1[ \operatorname{Parse}(y)=\text{success} ]. \tag{60}

它适合作为训练早期辅助信号，但权重不应接近任务正确性，否则模型会学会稳定地产生形式正确但语义错误的输出。

部分正确奖励根据完成比例给分：

r_{\mathrm{partial}} = \frac{ \sum_jw_jc_j }{ \sum_jw_j }, \tag{61}

其中 $c_j$ 表示子目标或测试是否完成。部分奖励必须与真实进展单调相关，否则模型可能优化容易刷分的子项。

过程奖励在轨迹中间提供信号：

R(\tau) = r_T + \sum_{t=0}^{T-1} \gamma^t r_t^{\mathrm{process}}. \tag{62}

过程奖励可以来自规则、环境状态或 PRM。它改善信用分配，却可能改变最优策略：如果奖励规定了某条参考路径，模型可能放弃更短或更新的合法方案。

当过程分数可以解释为状态势函数 $\Phi(s)$ 时，可使用 Potential-based Shaping：

r'_t = r_t + \gamma\Phi(s_{t+1}) - \Phi(s_t). \tag{63}

在满足相应 Markov、折扣和终止条件时，这类塑形不会改变最优策略集合。普通“步骤正确概率”并不自动具有势函数语义，不能无条件套用。

6.3 多个奖励分量的组合、缩放与裁剪#

多目标 Agent 奖励可以写为：

R = w_s r_{\mathrm{success}} + w_p r_{\mathrm{partial}} + w_f r_{\mathrm{format}} + w_r r_{\mathrm{recovery}} - \lambda_c c_{\mathrm{tool}} - \lambda_l c_{\mathrm{length}} - \lambda_i c_{\mathrm{invalid}}. \tag{64}

组合前必须处理量纲。成功奖励通常在 $[0,1]$ ，Token 长度可能数千，延迟以秒计算，工具成本还可能具有长尾。若不缩放，成本项会淹没正确性。

常见处理方式包括：

将各分量映射到预先定义区间；
使用运行均值和方差标准化；
对长尾成本使用对数或饱和变换；
对异常奖励裁剪；
对硬约束使用 Gate；
分任务或分领域维护统计量。

例如工具成本可写为：

\widetilde c = \min \left( \frac{c}{c_{\max}}, 1 \right). \tag{65}

奖励裁剪能降低梯度方差，却会丢失高分之间的差异。若所有成功轨迹都被裁到同一上限，模型无法继续学习效率。可以采用分层排序：失败轨迹先按进展比较，成功轨迹再按成本和长度比较。

组内标准化也会改变奖励语义。对同一道题的奖励做 Z-score 后，策略学习的是候选相对好坏，而不是跨题绝对价值。若题目难度差异本身需要进入训练，应避免把所有跨题信息完全消除。

6.4 正确性、效率、长度和工具成本之间的权衡#

效率应当是“在成功前提下减少浪费”，而不是无条件鼓励短输出和少调用。若直接定义：

R = r_{\mathrm{success}} - \lambda c(\tau), \tag{66}

当 $\lambda$ 太大时，最优策略可能是不执行任务，从而避免成本。更合理的分层奖励是：

R(\tau) = \begin{cases} 1-\lambda c_{\mathrm{norm}}(\tau), &\text{任务成功};\\ -\mu d(\tau), &\text{任务失败}, \end{cases} \tag{67}

其中 $d(\tau)$ 表示无效调用、偏离目标和危险动作。

长度惩罚尤其容易产生副作用。过强时，模型会省略必要推理、验证和错误恢复；没有长度控制时，模型又可能通过冗长搜索提高碰撞正确答案的概率。应分别监控：

成功率；
成功轨迹平均 Token；
成功轨迹平均工具调用；
Pass@1 与 Pass@k；
输出熵和截断率；
错误恢复成功率。

对高风险工具，成本不应只代表金钱或延迟，还应包括风险。只读搜索、草稿写入、真实发送和付款操作需要不同的权限和代价。硬权限仍应由规则 Gate 决定，而不是依靠负奖励让模型“尽量少犯”。

7. RLVR 与优化算法的组合#

PPO、GRPO 与 RLOO 结构对比

7.1 PPO：Actor、Critic 与裁剪目标#

PPO 使用 Actor 生成动作，Critic 估计状态价值。设回报为 $G_t$ ，价值模型为 $V_\psi(s_t)$ ，优势可以通过 GAE 估计：

\delta_t = r_t + \gamma V_\psi(s_{t+1}) - V_\psi(s_t), \tag{68}

\widehat A_t^{\mathrm{GAE}} = \sum_{l=0}^{T-t-1} (\gamma\lambda)^l \delta_{t+l}. \tag{69}

新旧策略比率为：

\rho_t(\theta) = \frac{ \pi_\theta(a_t\mid s_t) }{ \pi_{\theta_{\mathrm{old}}}(a_t\mid s_t) }. \tag{70}

PPO 裁剪目标为：

L_{\mathrm{PPO}} = \mathbb E_t \left[ \min \left( \rho_t\widehat A_t, \operatorname{clip} (\rho_t,1-\epsilon,1+\epsilon) \widehat A_t \right) \right]. \tag{71}

完整训练还包括 Value Loss、熵奖励与 KL 控制：

\mathcal L = -\mathcal L_{\mathrm{PPO}} + c_v\mathcal L_{\mathrm{value}} - c_e\mathcal H(\pi_\theta) + \beta D_{\mathrm{KL}}. \tag{72}

PPO 的优势是 Critic 可以为长轨迹提供状态级基线，理论上比单一序列奖励更细粒度；缺点是需要训练和部署额外 Value Model，还要同时维护 Actor、Critic、Reference Model 和优化器状态，显存与通信成本较高。

Critic 本身也可能失准。若训练任务和策略分布快速变化，Value Loss 下降不代表价值估计可用于新分布。应监控 Explained Variance、优势方差和 Value Clipping，而不能只看策略奖励。

7.2 GRPO：组内相对优势与无独立 Critic 训练#

GRPO 对同一道题采样 $G$ 个候选，使用组内统计构造优势。设奖励为 $R_1,\ldots,R_G$ ，则：

\overline R = \frac1G \sum_{i=1}^{G}R_i, \qquad \sigma_R = \sqrt{ \frac1G \sum_i(R_i-\overline R)^2 }. \tag{73}

标准化优势为：

\widehat A_i = \frac{ R_i-\overline R }{ \sigma_R+\varepsilon }. \tag{74}

策略目标通常对 Token 级比率进行裁剪：

L_{\mathrm{GRPO}} = \frac1G \sum_{i=1}^{G} \frac1{|y_i|} \sum_{t=1}^{|y_i|} \min \left( \rho_{i,t}\widehat A_i, \operatorname{clip} (\rho_{i,t},1-\epsilon,1+\epsilon) \widehat A_i \right) - \beta D_{\mathrm{KL}}. \tag{75}

GRPO 不训练独立 Critic，而是使用同题候选作为经验基线。它降低了模型副本和 Critic 训练成本，特别适合数学、代码等每题可采样多个候选的任务。

其局限包括：

每题必须生成多个 Rollout；
全对或全错组中 $\sigma_R=0$ ，正确性优势为零；
小组统计噪声较大；
组内标准化削弱跨题奖励尺度；
序列优势广播到每个 Token，仍不能定位关键步骤；
长度归一化方式会改变长短答案权重。

若奖励为二元值且组内全相同，不能人为随机制造正负优势。可以跳过正确性梯度、调整课程难度、增加采样多样性或引入可靠部分奖励。即便优势为零，KL、熵或其他辅助目标仍可能产生梯度，因此“该 Batch 完全没有任何更新”并不总是准确。

7.3 RLOO 与 REINFORCE 类估计器#

REINFORCE 的序列级目标可写为：

\mathcal L_{\mathrm{REINFORCE}} = - (R-b) \sum_{t=1}^{|y|} \log \pi_\theta(y_t\mid x,y_{<t}). \tag{76}

RLOO 对同一 Prompt 的第 $i$ 个候选，使用其他 $G-1$ 个候选的平均奖励作为基线：

b_i^{\mathrm{LOO}} = \frac1{G-1} \sum_{j\ne i}R_j, \tag{77}

\widehat A_i^{\mathrm{RLOO}} = R_i-b_i^{\mathrm{LOO}}. \tag{78}

留一基线避免当前样本自己的奖励进入自己的基线。与 Z-score GRPO 相比，RLOO 不除以组内标准差，因此保留了更多奖励尺度信息，但对不同任务的奖励量纲和方差更敏感。

REINFORCE 类方法不需要 Critic，系统实现简单，减少了 Value Model 拟合误差；它们仍然需要：

合理基线；
奖励归一化或裁剪；
KL 与熵控制；
梯度裁剪；
足够的候选数；
序列长度权重设计；
策略滞后控制。

当组大小较小时，留一基线方差可能较大；当奖励几乎全相同时，同样缺乏有效优势。算法简单并不意味着训练可以忽略数据与奖励设计。

7.4 算法选择对显存、采样量与稳定性的影响#

维度	PPO	GRPO	RLOO	REINFORCE
独立 Critic	通常需要	不需要	不需要	不需要
每题多候选	非强制	强依赖	强依赖	非强制
优势来源	Value/GAE	组均值与方差	留一均值	全局或运行基线
显存与模型副本	高	中	中	较低
Rollout 成本	中至高	高	高	取决于基线
长轨迹信用分配	相对更强	较弱	较弱	较弱
对同奖组的敏感性	较低	很高	很高	取决于基线
调参复杂度	高	中	中	中

算法选择不能只比较训练显存。RLVR 的主要成本可能来自推理与验证：

C_{\mathrm{RLVR}} \approx G \left( C_{\mathrm{generation}} + C_{\mathrm{environment}} + C_{\mathrm{verification}} \right) + C_{\mathrm{backprop}}. \tag{79}

不使用 Critic 但每题生成大量长轨迹的算法，整体成本可能高于 PPO。对于浏览器和软件工程 Agent，环境启动、执行和重置往往比反向传播更慢。

稳定性也不能用单一训练奖励判断。需要同时比较：

隐藏成功率；
KL 与输出熵；
Clip Fraction；
优势均值和方差；
全对、全错和混合奖励组比例；
平均长度与截断率；
每百万 Rollout Token 的收益；
每 GPU 小时和环境小时的收益。

8. Agent 场景中的 RLVR#

Agent 长轨迹信用分配

8.1 将完整 Agent 交互建模为环境轨迹#

Agent 的策略输入不仅是原始 Prompt，还包括历史动作和环境观察：

h_t = (x,a_{0:t-1},o_{1:t}), \tag{80}

a_t \sim \pi_\theta(\cdot\mid h_t). \tag{81}

动作可能是自然语言、工具选择、参数对象或控制指令。环境执行后返回：

s_{t+1} \sim P(\cdot\mid s_t,a_t), \qquad o_{t+1} = \operatorname{Observe}(s_{t+1}). \tag{82}

完整轨迹需要保留：

用户目标与约束；
每次模型输出；
工具名、参数和权限；
工具返回、异常和重试；
状态差异；
终止原因；
Token Log-probability；
策略、环境和 Verifier 版本。

Agent RLVR 的动作空间通常混合自然语言和结构化工具调用。训练时必须明确哪些 Token 属于策略动作，哪些观察来自环境；环境 Observation 不应被当作模型生成 Token 计算策略 Loss。

轨迹终止也需要分类：成功、模型主动失败、达到最大步数、超时、环境错误和安全 Gate 阻断具有不同语义。把它们全部映射为同一个零奖励会污染训练信号。

8.2 工具反馈、页面状态与执行结果作为奖励依据#

Agent 的验证应优先使用权威状态。可以把一次动作的验证拆成：

V_{\mathrm{schema}}(a_t), \quad V_{\mathrm{permission}}(s_t,a_t), \quad V_{\mathrm{execution}}(a_t,o_{t+1}), \quad V_{\mathrm{post}}(s_t,s_{t+1},g_t). \tag{83}

例如网页购物任务中：

工具调用格式正确，不代表商品 ID 正确；
页面显示“加入成功”，不代表后台购物车状态更新；
购物车有商品，不代表价格、数量和规格满足要求；
最终下单成功，不代表没有违反预算或确认规则。

可使用状态谓词：

\operatorname{Goal}(s_T)=1, \qquad \operatorname{Invariant}(s_t)=1\ \forall t, \qquad \operatorname{Minefield}(s_t)=0\ \forall t. \tag{84}

其中 Invariant 表示全程必须满足的约束，Minefield 表示一旦发生就构成硬失败的事件。

页面 DOM 只是一种观察，不一定是权威状态。对关键业务任务应读取后台数据库、API 或对象状态；若只能使用页面，应防止模型通过修改可见文本而绕过真实目标。

8.3 终局成功奖励与长时程信用分配#

终局奖励把整条轨迹压成一个结果：

R_T = \mathbf 1[ \operatorname{Goal}(s_T)=1 ], \qquad R_t=0,\ t<T. \tag{85}

一条失败轨迹可能只有最后一步错误；一条成功轨迹也可能包含重复搜索和无效调用。若同一序列优势广播到全部动作，前面行为会被一起奖励或惩罚。

改善信用分配的方法包括：

对可验证里程碑提供奖励；
对每次工具状态转移进行判定；
训练 Value Model；
使用 PRM 识别错误步骤；
对成功轨迹进行最短路径提取；
对失败轨迹定位首个不可恢复错误；
把复杂任务拆成局部子任务；
使用反事实重放比较关键动作。

但过程奖励不能简单模仿唯一参考轨迹。真实 Agent 任务通常存在多条合法路径，甚至需要失败恢复。评价的重点应是当前动作是否满足状态约束、是否推进目标以及是否造成副作用。

对于可恢复错误，可以单独记录：

r_{\mathrm{recovery}} = \mathbf 1[ \text{模型识别错误并恢复到可继续状态} ]. \tag{86}

恢复奖励应建立在真实状态变化上，而不是模型声称“我已修复”。

8.4 调用次数、执行成本与失败恢复奖励#

Agent 的成本可以表示为：

C(\tau) = \lambda_{\mathrm{token}}N_{\mathrm{token}} + \lambda_{\mathrm{call}}N_{\mathrm{call}} + \lambda_{\mathrm{time}}T_{\mathrm{wall}} + \sum_j \lambda_j N_{\mathrm{tool},j}. \tag{87}

不同工具应使用不同成本和风险系数。数据库只读查询、发送邮件、修改文件和付款不能视为同一种动作。

组合奖励可以写为：

R(\tau) = r_{\mathrm{success}} + \lambda_r r_{\mathrm{recovery}} - C_{\mathrm{norm}}(\tau) - \lambda_i N_{\mathrm{invalid}} - \lambda_v N_{\mathrm{violation}}. \tag{88}

失败恢复需要区分：

瞬时环境错误后的合理重试；
参数错误后的修正；
检测到错误后回滚；
重复相同失败动作；
在不可恢复状态中继续消耗资源。

过强的调用成本会让模型少用必要工具、提前结束或伪造完成；过弱则会鼓励无边界搜索。最合理的评估是绘制成功率—成本 Pareto 曲线，而不是只选择一个加权总分。

对于环境故障，系统应奖励正确的恢复策略，但不能把基础设施故障本身归因给模型。可以在有效试验中评价“模型面对工具错误是否采取正确动作”，同时单独报告环境错误率。

9. 工程实现与训练稳定性#

分布式 RLVR 工程架构

9.1 Rollout 服务、验证服务与训练服务解耦#

大规模 RLVR 通常拆分为三个主要服务。

Rollout 服务负责：

加载当前策略；
批量生成文本或 Agent 轨迹；
记录 Token Log-probability；
管理解码参数、最大长度和终止条件；
与环境服务交互。

验证服务负责：

数学解析与等价性检查；
代码沙箱与测试执行；
规则和 Schema 检查；
Agent 状态验证；
奖励分量和证据生成。

训练服务负责：

奖励聚合；
优势估计；
PPO、GRPO 或 RLOO Loss；
KL、熵和梯度控制；
Checkpoint 发布。

数据流可以表示为：

1
Task Queue
2
    ↓
3
Rollout Workers
4
    ↓
5
Trajectory Store
6
    ↓
7
Verifier Workers / Environment Pool
8
    ↓
9
Reward Store
10
    ↓
11
Policy Trainer
12
    ↓
13
Model Registry

解耦便于独立扩容，但会产生版本一致性问题。轨迹必须携带策略版本，奖励必须携带 Verifier 和环境版本，Trainer 只能消费满足版本策略的数据。

异步系统还需要背压控制。若 Verifier 比 Rollout 慢，轨迹队列会无限增长并变旧；若 Rollout 过慢，训练 GPU 会等待。应监控队列长度、样本年龄、验证 P95 延迟和训练数据版本差。

9.2 奖励缓存、超时处理与环境重置#

确定性验证结果可以缓存。缓存键至少包含：

K_{\mathrm{cache}} = H( x, y, \text{environment version}, \text{verifier version}, \text{reward config} ). \tag{89}

只使用输出文本作为缓存键是不安全的，因为同一代码在不同依赖、测试和环境快照下可能获得不同结果。

超时应区分：

模型生成超时；
工具调用超时；
候选程序自身超时；
Verifier 服务超时；
环境初始化失败；
基础设施不可用。

候选自身无限循环属于策略失败；Verifier 服务崩溃属于无效试验。两者必须使用不同状态码和训练 Mask。

环境重置要保证：

文件系统恢复；
数据库事务回滚；
浏览器会话和 Cookie 清理；
子进程全部终止；
远程对象无残留；
随机种子和虚拟时间恢复；
缓存不跨任务污染。

可通过环境快照哈希检查重置完整性：

H(s_0^{\mathrm{after\ reset}}) = H(s_0^{\mathrm{expected}}). \tag{90}

Agent 环境中的残留状态会让后一个候选继承前一个候选的进展，造成严重标签污染。

9.3 KL 系数、采样温度与奖励归一化#

RLVR 稳定性受多个耦合超参数影响。

KL 系数控制策略偏离参考模型。应同时监控平均 KL、Token 分位数和分领域 KL。少量极端样本可能在平均值正常时发生严重漂移。

采样温度控制探索。可以根据组内唯一候选率和奖励方差调整，而不是只看平均奖励。若候选重复率高，可适当提高温度；若格式错误和截断急剧增加，应降低温度或改善 SFT 初始化。

奖励归一化可以使用：

\widetilde R = \frac{ R-\mu_R }{ \sigma_R+\varepsilon }. \tag{91}

统计量可以按全局、任务类型、Prompt 组或训练批次计算。不同方式含义不同：全局归一化保留跨题差异，组内归一化只保留相对排序。对多维奖励，应先按分量标准化再组合，避免某个量纲主导。

需要持续监控：

平均奖励与标准差；
隐藏奖励；
KL 与熵；
Clip Fraction；
平均长度和截断率；
唯一候选比例；
全对、全错和混合组比例；
Verifier UNKNOWN 与 ENV_ERROR；
奖励各分量的相关性。

若训练奖励增长同时输出熵快速下降，可能是策略坍缩或利用单一高分模板。

9.4 无奖励样本、全正确批次与全错误批次处理#

对 GRPO 和 RLOO 等组内方法，如果同组奖励完全相同：

R_1=\cdots=R_G, \tag{92}

则正确性方向上的相对优势为零。

全正确组说明任务对当前策略过于简单。它仍可用于：

KL 稳定；
成功轨迹间的成本比较；
长度优化；
安全和格式辅助目标。

但若只使用二元正确奖励，它不会继续提高正确率。

全错误组可能表示：

任务过难；
采样多样性不足；
最大长度不足；
输出格式未学会；
Verifier 误判；
环境故障；
需要 SFT 或课程预热。

处理方式包括跳过正确性 Loss、调整任务难度、提高候选数、改善采样、增加可靠部分奖励或修复 Verifier。不能通过人为给其中一个失败候选正优势制造虚假信号。

奖励缺失样本与零奖励不同。若验证结果未返回或试验无效，应 Mask；零奖励表示有效试验中的明确失败，仍可能产生负优势。

数值实现中，即使 $\sigma_R=0$ ，也不应仅依靠 $\varepsilon$ 除法后继续训练，因为得到的优势仍应为零。应显式记录同奖组比例，并把它作为课程和采样质量指标。

10. 评估、风险与适用边界#

Verifier 奖励与真实目标分叉

10.1 Pass@k、任务成功率与训练样本效率#

若每道题生成 $n$ 个候选，其中 $c$ 个通过验证，则 Pass@ $k$ 的无偏估计为：

\operatorname{Pass@}k = 1- \frac{ \binom{n-c}{k} }{ \binom{n}{k} }. \tag{93}

Pass@1 反映单次部署成功率；Pass@k 反映多次采样中至少得到一个正确候选的概率。两者需要同时报告，因为 RLVR 可能提高 Pass@1，却降低多样性和高 $k$ 的覆盖。

Agent 还应报告：

终局任务成功率；
平均工具调用与 Token；
成功轨迹平均成本；
环境有效试验率；
错误恢复率；
安全违规率；
不同随机种子的均值和置信区间。

训练样本效率可以按多种预算计算：

\eta_{\mathrm{token}} = \frac{ \Delta \operatorname{Score} }{ N_{\mathrm{rollout\ token}} }, \tag{94}

\eta_{\mathrm{env}} = \frac{ \Delta \operatorname{Score} }{ N_{\mathrm{environment\ step}} }, \tag{95}

\eta_{\mathrm{compute}} = \frac{ \Delta \operatorname{Score} }{ \text{GPU hours} }. \tag{96}

只比较训练 Step 数没有意义，因为不同算法每步使用的候选数、长度和环境成本不同。

10.2 验证集泛化与隐藏测试评估#

评估至少应分为：

同分布未见样本；
新题型或新模板；
未见难度区间；
未见生成长度与推理风格；
新工具、环境或依赖版本；
使用独立 Verifier 的隐藏测试；
专门针对奖励投机的对抗集。

训练 Verifier 与评估 Verifier 必须隔离。若模型训练直接查询某套测试，最终仍用同一套测试评分，结果只能说明模型适应了该验证规范。

可以定义训练与隐藏奖励差：

\Delta_{\mathrm{gap}} = R_{\mathrm{train\ verifier}} - R_{\mathrm{hidden\ verifier}}. \tag{97}

当训练奖励持续上升而 $\Delta_{\mathrm{gap}}$ 扩大，应优先怀疑测试过拟合、Verifier 漏洞或数据泄漏。

隐藏评估还应冻结采样预算。若训练后模型允许更多 Token、更多候选或更多工具调用，性能提升可能来自测试时算力而不是策略质量。应在匹配预算和实际部署预算下分别报告。

10.3 Reward Hacking、测试用例过拟合与格式投机#

Reward Hacking 的操作性定义是：

\mathbb E_{\pi_\theta} [R_{\mathrm{proxy}}] \uparrow, \qquad \mathbb E_{\pi_\theta} [R_{\mathrm{gold}}] \not\uparrow \ \text{或下降}. \tag{98}

RLVR 常见投机包括：

硬编码公开测试答案；
利用解析器容错、Unicode、重复键或 NaN；
修改测试、日志或页面显示；
伪造工具执行结果；
利用超时和异常默认值；
用极长输出枚举答案；
只优化格式奖励；
在 Judge 输入中进行 Prompt Injection；
利用奖励组合中的尺度漏洞。

防御不能只依赖静态测试准确率。需要真实训练一个策略最大化 Verifier，再审计最高分尾部。有效手段包括：

独立 Shadow Verifier；
动态和隐藏测试；
规则、执行和状态多重验证；
最小权限沙箱；
对抗样本与 Fuzz；
查询预算限制；
高分异常检测；
人工抽样；
训练与评估验证器分离。

格式投机尤其容易在训练早期出现，因为格式奖励比正确奖励更容易获得。应监控每个奖励分量的增长速度，避免总奖励上升完全由格式项贡献。

10.4 错误 Verifier 对策略训练的系统性影响#

设真实成功标签为 $Y$ ，Verifier 标签为 $\widetilde Y$ 。假阳性率与假阴性率分别是：

\alpha = P(\widetilde Y=1\mid Y=0), \tag{99}

\beta = P(\widetilde Y=0\mid Y=1). \tag{100}

在普通监督学习中，标签噪声会降低准确率；在强化学习中，策略会主动寻找获得 $\widetilde Y=1$ 的区域，因此假阳性尤其危险。即使 $\alpha$ 在静态数据上很低，只要存在可被策略系统利用的错误模式，在线训练后该模式的概率质量可能显著增加。

假阴性则会造成：

正确等价表达被压制；
输出格式收缩；
新解法和多样性下降；
模型过拟合特定解析器。

Verifier 评估应覆盖：

Precision、Recall 与混淆矩阵；
按答案形式、长度、领域和模型来源分桶；
对抗测试；
策略优化后的分布；
高分尾部人工审计；
UNKNOWN 和环境错误处理。

可以使用多验证器交叉检查：

d = \operatorname{Aggregate} ( d_{\mathrm{rule}}, d_{\mathrm{exec}}, d_{\mathrm{model}}, d_{\mathrm{state}} ). \tag{101}

但 Ensemble 只有在错误不完全相关时才有效。多个共享相同解析器、训练数据和模型族的 Verifier，可能一起犯同一种错误。

10.5 RLVR 与人工偏好、过程监督的混合方案#

现实系统通常需要同时优化可验证正确性、表达质量、安全性和过程可靠性。可以组合：

R = R_{\mathrm{verified}} + \lambda_p R_{\mathrm{preference}} + \lambda_{\mathrm{proc}}R_{\mathrm{process}}, \tag{102}

同时对硬约束使用 Gate：

V_{\mathrm{hard}}(\tau)=1. \tag{103}

典型组合包括：

数学最终答案由规则 Verifier 检查，推理步骤由 PRM 辅助；
代码功能由测试验证，可维护性与解释质量由人工或 Judge 评价；
Agent 目标状态由环境验证，用户体验由偏好模型评价；
安全、权限和不可逆动作由规则约束；
开放式答案使用学习型评价器，但把引用存在性、格式和执行结果交给确定性 Verifier。

分阶段训练可以是：

\text{Pretraining} \rightarrow \text{SFT} \rightarrow \text{RLVR} \rightarrow \text{Preference/Safety Alignment}. \tag{104}

也可以交替进行 SFT 与 RL，防止能力漂移。混合奖励的关键不是分量越多越好，而是每个分量都要有明确语义、独立评估和冲突处理规则。

RLVR 的适用边界可以概括为：任务越容易用程序或环境定义成功，RLVR 越有优势；任务越开放、主观和价值敏感，就越需要人工偏好、过程监督和弃权机制。一个稳健系统不会把任何单一 Verifier 当作真实目标本身，而是把它视为可审计、可版本化且可能被利用的代理。