区分格式死与验证死：RLVR训练中rollout失败修复指南

某天我盯着一条训练日志发呆：同一批 32 条 rollout 里，有 12 条得 0 分，其中 4 条连<answer>标签都没输出，8 条输出了答案但数值对不上。它们的分数一模一样，但前者是格式死了，后者是验证死了。如果不把这两类样本分开处理，RLVR 的学习信号就会一直漏——越训练，模型越是“看起来在配合奖励，实际上什么都没学会”。

我一开始接触 RLVR（基于可验证奖励的强化学习）时，也被这个现象坑了很久。奖励函数设计得没毛病，验证器也按标准写法做了，训练曲线起起伏伏就是不到预期。后来我把每一条失败 rollout 拆开看，才发现两种失败在日志里长一个样，但对梯度的影响完全不是一回事。这篇文章就把这个经验完整拆开：先讲两种死法分别是什么，再讲信号漏在哪，最后给出我在实操中验证过的修复路径。

1. 先把这个题目的坑挖清楚：rollout 的“死”到底死在哪儿

1.1 先对齐基本术语：RLVR 与 rollout、验证器的链路

RLVR 的完整链路其实不长：提示数据进来，策略模型为每个提示采样一组 rollout，然后验证器给每条 rollout 打分，最后在组内做优势归一化，用策略梯度更新模型。这里的“rollout”就是一次完整生成，从输入提示一直到最终回答结束。

和传统 RLHF 不同，RLVR 不用训练一个偏好奖励模型，而是用一组“可验证”的规则去打标。数学题用答案比对器，代码题用单元测试跑结果，SQL 题用执行结果对比，这些都是典型做法。规则判定有一个很大的优势：奖励函数是确定性的、可解释的，不随奖励模型迭代而漂移。

但确定性也带来了副作用：验证器只认它定义好的“答案形态”。一旦 rollout 不在这个形态里，无论模型推理过程写得多么漂亮，拿到的都是同一个数字：0。

很多人在这一环节就踩坑了。不是奖励函数写错了，而是把“无法解析”和“答案错误”混在一起打标。这两者在日志里明明可以用两个字段区分开，但绝大多数训练脚本只记录一个reward值。这个坑不填，后面所有分析都是盲人摸象。

1.2 两种典型死法的现场画像

我把 RLVR 训练里最常见的失败 rollout 分成两类。第一类是“格式死”，第二类是“验证死”，你也可以叫它“内容死”。两者的表现差异非常明显。

看一个具体例子。任务是解方程：

输入：solve for x: x^2 - 5x + 6 = 0

模型 A 的生成结果：

<thought>先尝试因式分解，找到两个数相乘为 6、相加为 -5……</thought> <output>x=2 和 x=3</output>

这条 rollout 的问题是什么？内容是对的，但输出标签是<output>，不是约定好的<answer>。验证器按规则找<answer>标签，找不到，直接判 0。这就是格式死。

模型 B 的生成结果：

<thought>……</thought> <answer>x=2</answer>

标签对齐了，但解不完整，正确答案应该是x=2 或 x=3。验证器解析<answer>成功，比对失败，判 0。这是验证死。

两条 rollout 拿到的奖励完全一样，但我相信你已经感觉到了：它们对模型的意义完全不同。格式死意味着模型没有理解“输出协议”；验证死则意味着模型推理链条有问题。用同一个 0 分去更新模型，等于把两种完全不同的错误混为一谈。

更麻烦的是，这两类样本在训练不同阶段出现的概率也不一样。早期格式死占比高，可能是 30% 甚至 50%；后期格式死慢慢降下来，验证死接棒成为主要的失败模式。如果你只看总准确率，会看到一条“先升后平”的曲线，然后莫名其妙卡住。这个平台期很多时候不是模型学不动了，而是验证死带来的学习信号太稀薄。

1.3 学习信号是在哪个环节漏掉的

要理解信号怎么漏的，得先搞清楚 RLVR 的梯度更新逻辑。以 GRPO 这类组内相对优势算法为例，一条 rollout 的优势值大致可以写成：

advantage = (reward - group_mean) / group_std

也就是说，模型学到的东西并不取决于绝对分数，而是取决于这条 rollout 在同一个提示的多个采样结果里的相对位置。

格式死在这个机制下的破坏力很大。假设一组 8 条 rollout 里，6 条因为答案错误得 0 分，2 条因为格式错误得 0 分。它们的 reward 完全一样，但模型无法区分“格式错”和“答案错”。于是梯度会同时压低所有得 0 分样本的生成概率，其中包括那些推理过程其实不错的样本。

这就造成了一个典型现象：模型为了规避格式惩罚，会快速收敛到“规规矩矩输出标签”的行为，但对内容质量的提升非常缓慢。为什么？因为格式错误本来就是随机散布在好的和坏的回答之间的，把格式错的样本和答案错的样本放在同一个惩罚桶里，模型只能学到“不要输出非约定格式”，学不到“要把答案算对”。

验证死则是另一层漏法。验证器给出的是二元信号：正确得 1，错误得 0。这个信号有信息量，但信息量极其稀疏。它只告诉模型“最终结果不对”，没告诉模型“哪一步开始错的”。

我曾经统计过一批数学题 rollout，发现很多验证死样本的中间步骤其实是完整的，甚至能走到倒数第二步，只在最后一步符号写反。但二元验证器完全不看这些，直接把整条 rollout 归零。这种样本参与梯度更新时，模型被迫把整条生成序列的概率都往下压，包括那些正确的推理片段。

打个比方：这就好比学生交了一份卷子，前面 8 道题都对，最后一道题结果写错了，老师直接给 0 分。学生能从这个分数里知道自己哪道题对了吗？不能。他只知道“整份卷子都不行”。

这就是学习信号漏掉的核心机制：不是奖励错了，而是奖励粒度太粗，把有用的过程信息全部丢掉了。

2. 格式死法的补救：让格式不依赖模型的“自觉”

2.1 格式死为什么会带崩后续训练

很多团队对格式死不够重视，理由是“模型多训几个 step 自然就学会输出格式了”。这句话部分正确，但代价往往被低估。

格式死最典型的破坏是拉低全组的平均奖励，压缩组内优势的区分度。假设一组 8 条 rollout，其中 7 条由于格式错误得 0，1 条格式正确但答案错误得 0。这时候组内所有样本分数都是 0，group_std等于 0，优势值直接失去意义。某些实现里会给标准差加一个极小 epsilon，但计算出来的优势仍然是噪声。

更隐蔽的问题是，格式错误的分布并不是完全随机的。模型可能在某个特定 prompt 模板上总是漏掉结束标签，在另一个模板上总是多加一个括号。这些格式错误和任务难度、提示措辞产生了相关性。一旦相关，模型就会把“格式错误导致低分”和“这个提示比较难”错误关联起来，表现为对特定提示的生成概率异常波动。

所以格式死不是一个“忍一忍就过去”的问题。它是奖励信号里的结构性噪声，会持续污染梯度。

2.2 硬约束：把格式写进采样过程

我实践下来最有效的方法，不是靠 RL 去“教会”模型遵守格式，而是在采样阶段就把格式焊死。

具体做法是把生成过程拆成两段。第一段先让模型输出推理过程，不做过多的格式限制；第二段进入答案生成阶段时，用语法约束解码，只允许模型生成符合答案格式的 token 序列。

举个例子，在数学任务里，我们约定的格式是<answer>标签包裹最终答案。那么在生成<answer>之后的第一个 token，就可以用掩码把“无法构成合法答案”的候选 token 全部屏蔽掉。模型想写废话都写不了，只能从数字、符号、运算符这些 token 里选。到了</answer>结束标签附近，再强制加入结束 token，保证标签闭合。

这种做法的优势是格式正确率直接从 99% 起步，而不是靠模型自己摸索。RL 算法只负责优化答案质量，不需要为格式兜底。

代价是推理吞吐会下降，因为每次解码多了一步约束判断。我的方案是只对答案段做约束，推理段保持自由解码，这样可以把吞吐损失控制在可接受范围。如果你用的是带引导解码的推理服务，在解码参数里配置好格式模板，效果差不多。

2.3 软兜底：解析失败后的重采样与回溯

即使加了硬约束，生产环境里依然会有一小撮样本格式不对。可能是生成被截断，也可能是推理服务连接异常导致输出被切断。这时候不要直接把这条样本丢进 reward 为 0 的桶里，应该做标记并触发兜底逻辑。

我常用的做法是维护一个“解析失败缓存区”。同一个提示，如果一条 rollout 解析失败，就从策略里重新采样一条补上，而不是直接用 0 分参与训练。重采样的数据也保留原始失败样本，但会标成invalid，不参与优势归一化，只留作离线分析。

为什么不能直接参与训练？因为解析失败的生成序列本身可能是残缺的，把残缺序列的概率压下去没有意义，模型甚至可能因为惩罚某些前缀 token 而在后续生成中产生奇怪的行为。把这类样本从训练信号里摘除，比强行给 0 分要干净得多。

这里有一个重要提醒：重采样会增加数据偏置。如果某个提示反复采样都失败，说明这个提示本身可能有问题，或者当前策略对它极不稳定。需要单独记录失败次数，超过阈值就把该提示标记为高风险，暂时移出训练集，人工检查后再放回来。

2.4 奖励拆分：format 别和正确性混在一起

格式约束做好了，下一步就是把奖励函数拆开。我现在的标准做法是定义两个独立的奖励分量：

r_format：0 或 1，判断是否成功解析出合法答案 r_answer：0 或 1，判断答案是否正确

最终奖励是两者的加权和：

r_total = α * r_format + β * r_answer

权重我一般给α=0.1、β=1.0。格式分只占很小比重，因为硬约束已经解决了大部分格式问题，无需通过奖励再去强化。但保留这一小份格式奖励，可以防止模型往“能解析但格式很脏”的方向漂移。

更重要的是，在记录训练日志时，这两个分量必须分开落库。这样你随时可以统计format_fail_rate和verify_fail_rate，快速判断当前训练卡在哪个环节。

我见过一些团队的实现里只保留r_total，导致格式问题在某个版本悄悄反弹，但大家盯着总曲线看了两天都没发现原因。奖励拆分不只是工程习惯，它本身就是信号保真的第一步。

3. 验证死法的补救：把稀疏二元信号改造成可用信号

3.1 二元验证器的信息瓶颈在哪里

格式死修完之后，训练会进入一个新阶段：格式正确率 99%，但验证死占比可以高达 80%。这时候你再去看每条失败 rollout，会发现它们都能被验证器解析，最终答案也确实不对。但把它们全判 0 就够了吗？

问题在于，0 分不携带过程信息。在短答案任务里，答案往往由一两步推理决定，0 分的影响还勉强可控。但在长链推理任务里，一条 rollout 可能包含十几个推理步骤，最终答案只是整个链条的最后节点。模型需要知道是第一步的假设错了，还是倒数第二步的计算坏了，还是最后一步的符号丢了。

二元验证器对这些情况是瞎子。它只告诉你“最终状态错了”，然后梯度沿着整条生成序列均匀传播。长序列均匀传播意味着每个位置的损失信号都被稀释了。结果就是模型在长链任务上进展缓慢，甚至陷入“尝试生成更长的推理过程”来对冲不确定性，但答案依旧不对。

我形容这种状态是“模型在用长度掩盖错误”。这是二元验证器训练后期最典型的死法：rollout 没有格式问题，但学习信号已经被稀释到接近噪声。

3.2 做法一：过程奖励与逐步打分

顺着上面的思路，最自然的修复方案就是引入过程奖励信号。核心思想是：不要等最终答案出来了才给一个 0/1，而是把 rollout 切分成若干步骤，对每个步骤单独验证。

过程奖励的难度在于：怎么获得步骤级别的验证信号？

在代码生成任务里相对容易。你可以把整个解题过程拆成多个中间代码片段，每个片段单独跑一组测试用例，按通过的测试比例给分，再汇总成整条 rollout 的过程奖励。

在数学题任务里也可以做。很多数学题本身就有可分解的中间结论：设未知数、建立方程、化简、求根。每个中间结论都可以和参考答案的中间状态做比对。如果参考答案是有详细步骤的，就能按步骤建立对齐，给每一步打个 -1、0、1 的信号。

我自己的训练配置里，过程奖励的最终形式是：

r_process = average(step_signals) * 0.6 + correct_signal * 0.4

这里的correct_signal仍然是最终答案的验证结果。这样既保留了最终答案的客观约束，又引入了过程信息，避免模型“过程歪了但答案碰对”的情况。

需要注意一个度：过程奖励调得太多，模型可能只优化过程不优化结果。尤其当你对步骤信号的验证规则定义得不够严格时，模型会倾向于产出“看起来每一步都对但最终答案错误”的 rollout。所以过程奖励应该作为辅助信号，不能完全替代结果验证。

3.3 做法二：结果验证的语义容错

很多验证死不是推理错了，而是验证器太死。我曾经遇到过模型输出x=2,3，正确答案写的是x=2 或 x=3，结果被字符串比对判错。这就是典型的“假阴性”。

修复这类问题，需要把验证器从“字符串相等”升级为“语义相等”。具体手段有三层：

第一层是规范化。把空格、大小写、标点全部都归一化，数学公式里的\times和*统一转成同一个符号。这能解决大部分格式差异。

第二层是数值容差。如果答案本身是浮点数，可以定义一个相对误差范围，比如abs(predicted - expected) <= 1e-6 * max(1, abs(expected))。对于带约束的整数题，只比对化简后的数值相等即可。

第三层是符号计算。当答案是一个代数表达式时，直接比对字符串没有意义。可以用符号计算库对两个表达式做差，然后化简，判断结果是否为 0。这是处理“表达式不同但数学等价”问题的标准办法。

expected_expr = parse("(x-2)*(x-3)") predicted_expr = parse("x^2 - 5*x + 6") if simplify(expected_expr - predicted_expr) == 0: reward = 1

这套语义容错验证器上线后，有一组实验的验证死占比直接下降了十几个百分点。这些样本不是模型突然变聪明了，而是验证器以前误杀了它们。

3.4 做法三：GenRM 与验证器组合

规则验证器处理不了的是更开放的任务，比如生成结果没有标准答案，但有一个可判断的语义条件。这时候可以考虑让一个判别式语言模型来做验证，但要注意，不能直接让模型“打分”，而是要把它当成一个可解释的验证器。

我的做法是把规则验证器和语言模型验证器组合成一个两级结构。第一级仍然跑规则验证，能判断就立刻出分；第二级才把规则验证器判不出的样本交给语言模型验证器，并要求它输出“判断理由”而不是单纯一个分数。

这个组合有一个好处：语言模型验证器给出的理由可以被再次规则清洗一遍，如果理由里出现了明显的矛盾词，就把这条验证结果降级为不确定，并重新采样一次 rollout。这能有效防止模型从验证器那里学出“钻空子”的行为。

我见过一个典型翻车案例：某个任务里正确答案要求输出“是”或“否”，但策略模型很快发现了验证器只看最后一个字符的漏洞，于是生成了一长串思维过程加一个碰巧对的尾字符。这种 rollout 在奖励上得高分，但没有任何实用价值。组合验证器配合规则检查之后，这类“假阳性”样本会被识别出来，直接打回重采样，训练信号才恢复干净。

3.5 一个需要克制的问题：别把 RL 做成监督学习

过程奖励和逐步打分引入后，很容易掉进另一个坑：把 RL 训练改成了带标签的监督学习。

区别在哪？监督学习要求每个 token 都有目标标签，模型只需要模仿那些“正确”的 token 路径。而 RL 的核心能力是探索：模型应该有机会尝试不同的中间步骤，然后通过奖励信号得知哪些尝试更好。

如果你把过程奖励定义得太细、太确定，比如每一个 step 都有唯一正确答案，模型就会失去探索空间，退化成一个“按步骤模仿”的模型。长链推理里恰恰需要探索多样化路径，过度的步骤标注会抹掉这个优势。

我的经验是：过程奖励只给“部分正确”的模糊信号，不要给“逐 token 精确匹配”的强信号。允许模型在某个步骤用不同的方法得到同一个中间结论，只要中间结论最终能导向正确答案，就给这个步骤高分。这样 RL 的探索性还在，同时信号密度明显提升。

4. 训练框架层面的信号保鲜措施

4.1 采样组的设计：一份 rollout 的“保质期”

除了奖励函数本身，采样策略也会影响两种死法的占比。我在实践中发现，很多验证死样本其实是“过期样本”——策略已经更新到新版本了，但采样缓存里还留着旧版本生成的 rollout。

在 GRPO 这类算法里，所有组内样本理论上应该来自同一个策略版本。如果混入了老版本策略的样本，奖励分布会产生偏移。格式死在新老版本之间的表现差异尤其大：老版本可能格式错误率 20%，新版本已经降到 5%，但混合采样会把整个组的标准差拉大，造成优势估计失真。

我现在的做法是给训练数据加一个版本字段，每当策略 checkpoint 更新，就给新的采样缓存打上新的版本号。训练时只认当前版本号一致的 rollout，过期的一律丢弃。虽然这会损失一些采样效率，但信号质量提升非常明显。

采样数量也需要根据任务动态调整。一个 group 内采样数太少，格式死或验证死可能会吃掉整个组，导致优势无法计算；采样数太多又会降低训练吞吐。数学题任务我用 8 到 16 条，代码任务因为验证成本高，用 4 到 8 条比较合理。

4.2 基线处理与优势归一化对两种死法的影响

组内归一化是 RLVR 训练里最容易被忽视的参数。标准 GRPO 在组内做减均值、除标准差，但如果这个组的失败模式太过单一，归一化后的优势会很不稳定。

举个例子：一个组里 16 条 rollout，14 条验证死，2 条验证通过。这时候通过样本的 reward 是 1，失败样本是 0，组均值很低，通过样本的优势会被放大到一个很大的值。模型会认为“只要稍微改变一下生成策略，就能从失败变成功”，但实际上这 2 条通过样本可能是碰巧撞对的，没有任何可复制性。

解决这个问题，我一般会加一个局部优势截断，限制单个样本的优势绝对值范围。如果某条 rollout 的优势超出阈值，就按阈值截断，防止极端样本主导梯度。这不会完全消除噪声，但能避免单次更新被偶然成功样本带偏。

另外，如果格式死占比仍然较高，我会选择暂时把格式死的样本排除在优势计算之外，只让它们在日志里保留标记。等格式死降到 5% 以下，再把它加回奖励函数。这是我在冷启动阶段常用的“两阶段策略”。

4.3 用日志指标实时观察两种死法的占比

修复信号的前提是能够看见信号。我在训练循环里固定记录下面几个指标，每天收工前都会扫一遍：

光看总 reward 曲线是远远不够的。总曲线上升可能只是因为模型学会了 format，并不代表推理能力增强。如果verify_fail_rate一直在高位徘徊，说明过程信号或验证器设计还有问题。

我甚至会给每个任务单独生成一份“死因分析表”，把格式死和验证死在日志里做成两个独立字段。这样配合奖励拆分，任何一次训练异常都能快速定位到具体环节。

5. 我自己实际踩坑后的体会

这几轮实验做下来，我最大的感受是：RLVR 的难点经常不在算法原理，而在“把观察做到位”。两条得 0 分的 rollout，可能一条死于格式，一条死于验证，但日志里都只有一个数字。如果不能区分它们，后续所有修复都没有方向。

我在实际训练中养成的一个小习惯是：每个实验版本都会随机抽 50 条失败 rollout，人工复查一遍原始生成结果。这个动作成本不高，但经常能发现验证器误杀、奖励拆分失效、采样缓存混入老数据这类问题。有一回我只复查了十来条，就发现某个提示下的模型总是把</answer>多写一遍，导致标签闭合失败。如果只看日志里的 reward 字段，这个问题可能要浪费一整个训练周。

最后再分享一个和标题直接相关的经验：两种死法的修复优先级不一样。格式死要优先靠工程手段硬堵，不要指望 RL 自己学会；验证死要优先靠信号密度改造，不要只增加采样数量。把这两条顺序搞反了，训练曲线就会长期在低位徘徊，怎么调超参都补不回来。这条道理，我是在连续几轮实验被 0 分刷屏之后才真正理解的。