土法炼钢兴趣小组的算法知识备份

【强化学习与大模型后训练】13｜RLVR：可验证奖励如何训练推理能力

2026-05-29 · rl-posttraining · #RLVR #verifiable rewards #reward hacking #DeepSeek-R1 #rule-based reward #reinforcement learning #reasoning models #reward model #alignment #safety

文章导航

分类入口
rl-posttraining
标签入口
#RLVR#verifiable rewards#reward hacking#DeepSeek-R1#rule-based reward#reinforcement learning#reasoning models#reward model#alignment#safety

目录

奖励模型把人类偏好压缩成一个可优化的标量，但这个标量并不等于真实目标。

RLVR（Reinforcement Learning with Verifiable Rewards）把问题换成另一种形式：如果任务本身有可判定答案，就不要先训练一个裁判，而是直接用规则、测试或形式化验证器给策略反馈。

这篇文章接在 GRPO 之后，讨论可验证奖励怎样成为推理模型训练的关键燃料。

核心结论很简单：RLVR 的优势不在于奖励更复杂，而在于奖励更难被模型用风格、长度和话术绕过。

它适合数学、代码、形式化证明、结构化问答等存在客观 ground truth 的任务，不适合审美、开放写作和价值判断占主导的任务。

本文只引用公开论文和技术报告中的结论；涉及 DeepSeek-R1-Zero 时，边界以 DeepSeek-AI 2025 技术报告为准。

一、RLVR 解决的不是“奖励稀疏”，而是“奖励可信”

在传统 RLHF 中，奖励通常来自奖励模型（reward model, RM）。

RM 由偏好数据训练，输入 prompt 和回答，输出一个标量分数。

这个分数可以指导 PPO、GRPO 或其它策略优化算法，但它仍然是代理目标。

代理目标一旦被强优化，就会暴露训练数据、模型容量和标注偏差留下的漏洞。

第 8 篇 奖励模型 已经讨论过：RM 分数不是无限可优化的真值。

RLVR 的出发点是：如果答案可以被外部规则判定，就用外部规则替代学习出来的偏好裁判。

数学题可以检查最终数值、符号表达式或等价变形。

代码题可以运行单元测试、静态检查或隐藏测试。

形式化证明可以交给 Lean、Coq、Isabelle 等证明检查器。

这些奖励仍然可能有覆盖不足和规则设计问题，但它们不再依赖 RM 对自然语言质量的主观猜测。

因此 RLVR 的关键问题不是“怎样让奖励更密集”，而是“怎样让奖励足够可信、足够便宜、足够可扩展”。

二、可验证奖励的定义

给定 prompt \(x\)、模型回答 \(y\)、验证器 \(V\)，RLVR 可以把奖励写成：

\[ R(x,y)=V(x,y) \]

其中 \(V\) 不是从偏好样本中学习出来的标量模型，而是一个确定性或近确定性的检查过程。

最简单的 \(V\) 是二值函数：回答通过检查给 \(1\)，失败给 \(0\)。

稍复杂的 \(V\) 可以把格式、最终答案、推理步骤、运行时间和安全约束拆成若干项。

但只要奖励来自可审计规则而不是可被语言风格诱导的 RM，它就保留了 RLVR 的核心特征。

维度 学习奖励模型 可验证奖励
来源 人类偏好数据训练出的模型 规则、程序、测试、证明检查器
输出 连续标量，常带主观偏好 二值或规则组合分数
可解释性 需要解释 RM 学到什么 通常能定位哪条规则失败
被优化风险 容易被长度、格式、话术 exploit 主要被测试覆盖和规则漏洞限制
适用任务 开放式写作、聊天、安全偏好 数学、代码、可判定任务

这个表不是说 RLVR 总是优于 RM。

它只是说明两者服务的任务边界不同。

偏好模型擅长覆盖人类难以形式化的质量判断。

可验证奖励擅长处理“答案对不对”可以被外部系统判定的任务。

三、二值奖励为什么常常够用

很多人第一次看到 RLVR 会觉得二值奖励太粗糙。

数学题只有对或错，代码题只有测试通过或失败，似乎没有告诉模型错在哪里。

但在大规模采样和组相对优化中，二值奖励可以产生足够清楚的比较信号。

对同一个 prompt 采样 \(G\) 条回答，只要其中既有正确样本又有错误样本，GRPO 就能把正确样本的 log-prob 往上推，把错误样本往下压。

这正是 GRPO 中组内相对优势的自然用法。

设同题采样的奖励为 \(r_1,\ldots,r_G\)，组内优势为：

\[ \hat A_i=\frac{r_i-\mathrm{mean}(r_1,\ldots,r_G)}{\mathrm{std}(r_1,\ldots,r_G)+\epsilon} \]

如果奖励是 \(0/1\)，那么优势只表达“这条回答在同题样本里相对更好还是更差”。

这个信号不细，但很难被“写得更像高质量答案”伪造。

DeepSeekMath 和 DeepSeek-R1 技术报告都把规则奖励放在数学推理训练的重要位置。

Cobbe et al. 2021 的 GSM8K 工作则从另一个角度说明，在数学任务上，引入可执行验证器会影响模型选择哪条解题路径。

"""二值可验证奖励示意，不代表某个论文的完整实现。"""
from fractions import Fraction

def normalize_answer(s: str) -> str:
    return s.strip().replace(' ', '')

def math_reward(model_answer: str, gold_answer: str) -> int:
    try:
        return int(Fraction(normalize_answer(model_answer)) == Fraction(normalize_answer(gold_answer)))
    except ValueError:
        return int(normalize_answer(model_answer) == normalize_answer(gold_answer))

真实数学验证器通常比这段示意代码复杂得多。

它要处理等价表达式、单位、区间、矩阵、集合、近似数值和多答案问题。

但思想相同：奖励来自可复查的判定逻辑。

四、确定性验证器带来的透明度

可验证奖励的一个直接收益是可审计。

RM 给出 \(8.7\) 分时，工程师还要追问：它为什么给高分，是因为答案正确、格式漂亮，还是因为回答更长。

规则验证器给出 \(0\) 分时，通常可以进一步返回失败原因。

例如数学答案抽取失败、最终答案不等价、代码编译失败、单元测试失败、证明检查器拒绝。

这种失败原因可以进入数据清洗、prompt 改写、验证器调试和课程学习。

RLVR 的训练日志也更容易解释。

如果 reward 上升，至少说明通过规则检查的比例上升。

如果通过率上升但人工评审下降，问题往往落在验证器覆盖不足或任务设计偏差，而不是 RM 黑箱分数本身。

这并不意味着验证器没有漏洞。

测试集覆盖不全时，模型仍可能写出投机代码。

答案抽取规则过宽时，模型可能输出多个互相矛盾的答案并碰巧包含正确值。

格式规则过窄时，模型可能学会迎合格式而不是提升推理。

可验证不等于完美，但它把问题从“裁判模型学到了什么”转移到“规则是否覆盖目标”。

五、为什么 RLVR 更抗 reward hacking

Reward hacking 的本质是策略利用奖励函数漏洞获得高分，却没有满足真实目标。

对学习出来的 RM 来说，漏洞可能是长度、礼貌、列表格式、确定语气、拒答模板或训练集中偶然相关的短语。

对 RLVR 来说，最重要的奖励项通常是外部判定。

数学答案不等价，写再多解释也不给分。

代码不能通过测试，Markdown 再漂亮也不给分。

证明无法通过检查器，语气再自信也不给分。

这就是 RLVR 抗 reward hacking 的主要来源。

它不是让模型无法 hack，而是让常见语言层面的捷径不再直接提高奖励。

模型要获得高分，必须满足验证器约束。

当验证器足够接近真实目标时，优化奖励就更接近优化任务本身。

这也是 DeepSeek-R1-Zero 能以纯 RL 方式激发推理行为的重要前提：数学和代码奖励可以给出客观训练信号。

六、DeepSeek-R1-Zero：没有 SFT bootstrap 的纯 RL 案例

DeepSeek-AI 2025 技术报告把 R1-Zero 描述为一个关键实验：直接在基础模型上进行强化学习，不使用监督微调作为冷启动。

报告指出，R1-Zero 在 RL 过程中出现了长推理链、自我反思和重新检查等行为。

这些行为不是从人工 CoT 数据中模仿来的，而是在可验证奖励和策略优化压力下逐步显现。

这里需要谨慎表述：公开报告并没有公开所有训练细节和完整数据配方。

我们能确定的是技术路线：使用规则奖励支持数学、代码等可验证任务，并用 GRPO 进行策略优化。

不能把未公开的采样规模、过滤阈值或内部评测细节写成事实。

R1-Zero 的意义在于证明“先 SFT 再 RL”不是推理能力出现的唯一途径。

只要奖励信号足够可靠，RL 本身可以塑造长思维链行为。

但报告也指出 R1-Zero 存在可读性差、语言混杂等问题。

这说明纯 RL 追求正确性时，不一定自然得到人类喜欢的表达形式。

完整 DeepSeek-R1 因此加入了冷启动数据、多阶段 RL、拒绝采样和蒸馏，目标是在能力、可读性和稳定性之间折中。

七、数学任务：答案等价比表面字符串更重要

数学是 RLVR 最自然的应用场景。

很多题目有明确答案，且答案可以通过数值、符号或形式规则判定。

但数学验证并不等同于字符串匹配。

\(1/2\)、\(0.5\)、\(\frac{2}{4}\) 在许多题目里等价。

\(x=2\) 和 \(2\) 在某些题目里等价，在另一些题目里不等价。

区间答案、集合答案和多根方程还需要考虑顺序无关和表示规范。

因此数学 RLVR 通常需要三个组件。

Shao et al. 2024 的 DeepSeekMath 把数学推理、规则奖励和 GRPO 放在同一条训练路线中讨论。

Cobbe et al. 2021 的 verifier 工作则说明，即使最终使用模型验证器，数学任务也能通过候选解生成和答案评估提升性能。

两条线共同指向一个事实：数学任务的结构让“生成多个候选，再用外部信号选择或强化”变得特别有效。

八、代码任务：单元测试是奖励，也是规格

代码任务中的 RLVR 通常使用测试通过率作为奖励。

这比数学答案更接近软件工程现实：程序的正确性往往由一组可执行规格刻画。

最简单做法是把模型生成的函数放进沙箱，运行公开测试和隐藏测试。

所有测试通过给 \(1\)，否则给 \(0\)。

也可以按通过用例比例给连续奖励，但要小心模型过拟合易测用例。

代码验证器通常比数学验证器更昂贵。

它需要隔离执行环境、限制时间和内存、处理非确定性、避免恶意代码副作用。

但它提供了非常明确的训练信号。

编译错误、运行时错误、断言失败和超时都能被记录。

这些错误类型可以用于课程学习，也可以用于后续数据过滤。

代码 RLVR 的边界在于测试不是完整规格。

如果隐藏测试覆盖不足，策略可能学会利用输入分布或硬编码。

因此工程上常把测试奖励与静态检查、随机测试、样例去重和人工审查结合。

note: "代码 RLVR 评测任务的结构化输入示意"
prompt: "实现 gcd(a, b)，返回非负最大公约数。"
entry_point: "gcd"
time_limit_seconds: 2
memory_limit_mb: 256
public_tests:
  - "assert gcd(12, 18) == 6"
  - "assert gcd(0, 5) == 5"
hidden_tests: "由评测系统保存，不进入训练样本正文"

九、形式化验证：最硬的奖励，也最难扩展

形式化证明任务提供了更强的可验证性。

如果模型生成的证明脚本能被证明助手检查通过，那么奖励就非常明确。

这类奖励的优势是几乎没有语义灰区。

证明检查器不会因为回答更长、语气更好或格式更漂亮而放宽判断。

困难也同样明显。

形式化语言门槛高，搜索空间巨大，错误反馈可能离自然语言推理很远。

一个证明失败，并不告诉模型下一步该选哪个 lemma。

因此形式化 RLVR 往往需要检索、策略搜索、过程反馈和环境交互。

它代表了可验证奖励的上限形态：奖励非常可靠，但获得一个正样本很难。

对大模型后训练来说，它更像未来方向，而不是所有团队都能直接采用的通用方案。

十、RLVR 与学习 RM 的取舍

问题 更适合 RLVR 更适合学习 RM
答案是否客观 有标准答案或可执行规格 质量由人类偏好决定
反馈成本 验证器运行便宜且稳定 规则难写但偏好可标注
错误解释 规则失败可定位 需要解释 RM 或做人评
覆盖风险 测试集和规则可能不完整 偏好分布可能偏移
优化风险 主要 hack 验证器漏洞 可能 hack 语言风格捷径

二者也可以组合。

DeepSeek-R1 报告中，数学和代码使用规则奖励，一般任务仍可能依赖其它奖励信号。

Tülu 3 报告讨论了后训练配方中的偏好优化、RLVR 和多类数据组合，说明开源后训练并不是单一目标函数能覆盖的工程。

实际系统通常把 RLVR 用在能验证的核心能力上，把 RM 或偏好优化用于风格、安全和开放式帮助性。

把所有问题都强行改写成可验证任务，反而会丢掉真实用户场景。

十一、奖励设计：二值、分段还是组合

RLVR 不要求奖励永远是纯二值。

二值奖励最干净，但也最稀疏。

分段奖励可以把格式正确、答案抽取成功、最终答案正确分开。

组合奖励可以同时考虑正确性、可读性和安全限制。

关键是不要让辅助项压过核心可验证目标。

如果格式分太高，模型可能学会写固定模板却不提升正确率。

如果长度惩罚太强，模型可能过早给答案，牺牲必要推理。

一个常见设计是把最终正确性作为主奖励，把格式作为门控或小权重项。

\[ R=R_{correct}+\alpha R_{format}-\beta R_{unsafe} \]

其中 \(\alpha\) 和 \(\beta\) 必须通过验证集和人工抽样检查，而不是只看训练 reward。

在推理模型训练中，奖励设计会直接改变模型学到的思维链长度和表达习惯。

因此 RLVR 的“规则简单”不等于“工程简单”。

十二、采样难度决定训练信号密度

RLVR 的训练效率强烈依赖题目难度和模型当前能力。

如果题太简单，同题采样全部正确，组内优势接近零。

如果题太难，同题采样全部错误，组内优势也接近零。

最有价值的是“模型有时做对、有时做错”的题。

这会推动课程学习和数据调度。

训练早期需要较容易题目产生正奖励。

模型变强后，需要引入更难题保持探索压力。

采样温度也影响信号密度。

温度太低，候选高度相似，组内差异不足。

温度太高，候选质量过差，正确样本太少。

因此 RLVR 训练不是把验证器接到任意题库上就结束。

它需要题目难度、采样参数、组大小和奖励统计共同调参。

十三、过程级验证是下一步

RLVR 常用最终答案奖励，但推理错误往往发生在中间步骤。

只看最终答案，模型可能通过错误路径碰巧得到正确值，也可能在前面已经走偏但直到最后才被惩罚。

过程级验证试图把每一步都变成可检查对象。

数学中可以检查每个等式变形是否成立。

代码中可以检查中间补丁是否通过局部测试。

形式化证明中可以检查每个 tactic 后的 proof state。

这条路线和第 15 篇 过程奖励模型 相连。

区别在于，PRM 可以是学习出来的步骤评分器，也可以由规则或验证器产生步骤级标签。

未来更理想的训练信号可能是 outcome-level RLVR、process-level verification 和搜索算法的结合。

十四、多模态任务的可验证奖励

多模态 RLVR 仍处在早期。

一些视觉任务有客观答案，例如图表读数、OCR、几何测量和屏幕操作结果。

但许多图像理解任务涉及开放描述、审美判断或上下文推断，难以写成稳定验证器。

可行方向是把多模态任务拆成可验证子任务。

例如让模型输出结构化 JSON，再用字段级规则检查。

例如让模型控制浏览器完成任务，再用环境状态判断成功。

例如把视觉数学题转成符号表达式，再进行等价验证。

这些方法都要求任务设计足够严谨。

如果验证器只检查表面字段，模型就可能优化字段而忽略真实语义。

十五、实践核对清单

这些检查比单纯调大学习率或采样数更重要。

RLVR 的训练失败，很多时候不是优化器失败，而是验证器和数据分布没有提供有效信号。

参考资料

RLVR 的价值在于把强化学习的优化压力接到可信任务反馈上。

当任务可验证时，它能减少 RM 漏洞带来的 reward hacking，并让推理能力在采样和正确性反馈中被强化。

当任务不可验证时，RLVR 不应被神化；这时仍需要偏好模型、人类评审和安全评测。

← 上一篇：12｜GRPO　|　下一篇：14｜推理模型训练 →

同主题继续阅读

把当前热点继续串成多页阅读，而不是停在单篇消费。

By .