大模型后训练post-training和可验证强化学习RLVRReinforcement Learning with Verifiable Rewards是当前从“模型会生成”走向“模型能稳定解决问题”的关键环节。斯坦福大模型开发课 EP16 把这条链路单独拎出来讲本质是在回答一个问题当生成结果有客观对错时怎么用强化学习让模型真正变准。这篇内容适合正在做大模型微调、对齐、RAG 之后的推理增强或者想搞清楚 RLHF 和 RLVR 区别的开发者。我的核心判断是RLVR 比 RLHF 更简洁、更适合工程落地但它只适用于有明确验证信号的任务别把它当成解决所有幻觉问题的万能工具。整篇文章会按“为什么需要后训练、RLVR 原理、最小实验、验证器设计、常见坑、产品化边界”这条顺序展开。全程没有视频口播只有实操经验。1. 后训练为什么越来越重要从“会生成”到“靠得住”1.1 后训练到底在解决什么问题预训练阶段模型通过海量文本学到了语言知识、世界知识、逻辑关系。但这时候的模型并不能直接用你问它问题它可能答得漂亮也可能答得完全偏离要求让它输出 JSON它可能会在 JSON 前后加上解释让它做数学题它可能写出推理过程但最后一步算错。后训练要解决的就是让模型从“会生成”变成“靠得住”。这个“靠得住”起码包含三层意思第一模型的输出格式符合使用方要求第二模型的行为符合人类偏好不说废话、不越权、不编造第三在有客观对错的任务上模型能通过推理得到正确结果。斯坦福那门课把后训练拆成了一个完整流程而不是一次微调。这也是我读完课程材料后觉得最有价值的地方后训练不是一个操作而是一套找问题、定信号、训策略、验效果的工序。如果只是本地部署一个开源大模型或者用 API 调用现成模型你可能不需要知道后训练怎么训练。但一旦你需要让模型在某个垂直任务上稳定发挥比如自动判卷、代码检查、SQL 生成、结构化抽取后训练就是你绕不开的环节。因为通用模型不可能天然适配你定义的输出规范和验证逻辑。1.2 后训练链路中的三个关键阶段后训练通常有三个大的阶段监督微调SFT、偏好对齐、强化学习优化。第一个阶段是 SFT。我们先准备一批高质量的输入输出样例让模型模仿。SFT 的主要作用是让模型学会目标任务的基本格式、基本语气、基本推理结构。很多团队会在这里直接把通用模型变成“领域助手”。但这个阶段的缺陷也很明显模型只会模仿见过的答案遇到没见过的变化很容易乱来。SFT 数据集如果太小模型学不到规律如果太大模型又会过拟合反而丢掉通用能力。所以 SFT 不是“样本越多越好”而是要覆盖任务的典型变化模式。第二个阶段是偏好对齐。典型代表是 RLHF还有 DPO。这个阶段不是教模型“怎么回答”而是教模型“什么样的回答更接近人想要的”。通常需要人类标注员对不同回答排序或者给出偏好对然后训练奖励模型再用强化学习优化策略。这个思路在对话场景里效果很好但成本高标注质量波动大而且人类偏好本身也有噪声。第三个阶段就是 RLVR。它不依赖人类对文本质量的偏好而是把“对错”交给一个可计算的验证器。比如数学题的最终答案是否正确代码能不能通过测试用例JSON 是否符合 schema。这种做法的优势非常明显奖励信号客观、可复现、可以自动化生成训练链路比 RLHF 短很多。这也是 EP16 特别强调的地方。1.3 为什么 RLVR 会被单独拿出来讲RLVR 被单独拿出来不是因为它是“新的 RLHF”而是因为它在工程上是另一条路线。RLHF 的奖励来自人类偏好本质是“我觉得好”RLVR 的奖励来自规则或工具本质是“它确实对”。这个区别带来的影响很大RLHF 的奖励模型会学偏会把更长、更有礼貌、更自信的答案打高分于是模型开始说废话、堆格式RLVR 在数学、代码这类场景里不需要担心奖励模型是不是学偏了因为它根本不学奖励模型。当然RLVR 也有自己的难题而且并不比 RLHF 简单。最大的难题是怎么定义一个“可验证的奖励”如果验证器写得太宽松模型会钻空子写得太严格合法答案也会被判错。这其实是把问题从“调模型”转移到了“设计验证器”上。后面我会专门用一章讲验证器设计。另一个值得注意的点是RLVR 更适合“能自动判断对错”的任务不代表所有任务都能用。开放写作、创意生成、情感陪伴这类任务没有标准答案强行套规则验证器只会把模型逼成一个套路生成器输出千篇一律。这一点在落地前一定要先想清楚。2. RLVR 的核心原理用可验证信号替代人工偏好2.1 从 RLHF 到 RLVR奖励从哪来强化学习需要奖励。RLHF 和 RLVR 的核心差异就是奖励从哪来。RLHF 的奖励来自一个训练出来的 Reward Model。这个 Reward Model 的标注数据来自人类对多个回答的偏好排序。它的好处是能处理开放任务坏处也是明显的Reward Model 本身会犯错会被文本长度、句式复杂度、自信程度这些表面特征带偏。训练过程中策略网络为了拿到更高奖励会不断“迎合”Reward Model 的偏好于是出现 reward hacking模型开始说一些看起来很正确、其实没有实际内容的空话。RLVR 不用训练 Reward Model。它直接用一个 Verifier 来算奖励。这个 Verifier 可以是一段代码、一个数学表达式匹配器、一个 SQL 执行器、一组单元测试、一个 JSON Schema 校验器、甚至一个经过校准的模型裁判。奖励不是学习出来的而是计算出来的。只要验证器是稳定的奖励信号就是稳定的。这样训练出来的模型更容易在真实任务上拿到可复现的提升。但这里要注意可验证奖励不等于“零人工成本”。你仍然需要人来设计验证规则。关键是这个人不需要给每一句生成内容打分只需要定义清楚“什么算对”。2.2 Reward Model、Verifier、规则检查器三者的区别很多资料会把奖励模型和验证器混在一起实际上它们是不同的东西。我整理了一张对比表实现方式判定逻辑优点缺点奖励模型训练一个模型预测人类偏好分数能处理开放文本打分平滑会学到偏见可能被策略利用规则验证器用字符串匹配、正则、JSON Schema 等判断快、稳定、可解释不能覆盖多样表达容易误杀执行验证器运行代码、执行 SQL、跑单元测试客观接近真实场景需要安全沙箱耗时高模型验证器用大模型根据评分标准判断能处理较开放的答案可给步骤分有噪声可能偏好结构好看的文本在 RLVR 里最常用的是规则验证器和执行验证器。比如要求模型输出 JSON 时用一个 JSON parser 解析解析失败就奖励 0解析成功且字段完整就奖励 1。比如数学题可以先把最终答案抽取出来再和标准答案做规范化比较。比如代码生成直接把生成代码放进测试用例里跑全过给高分部分过给按比例给分。如果任务实在太开放必须用模型裁判那就要多做一层校准。不要假设大模型裁判一定准。先用一批人工标注过的样本跑一遍裁判算一下准确率。如果裁判准确率连 90% 都不到后面的 RLVR 训练结果就很难让人信服。2.3 策略更新的最小闭环RLVR 的完整训练过程可以简化成下面这个循环for step in range(max_steps): prompts sample_batch(train_data) outputs model.generate(prompts, temperature0.8, num_return_sequencesN) rewards verifier(prompts, outputs) loss policy_gradient_loss(outputs, rewards, ref_model) optimizer.step()每一步里模型先生成多个候选答案。因为可验证奖励给得很快所以可以一个 prompt 采样 8 条或 16 条而不需要像 RLHF 那样每一步都等人类打分。这里面最值得理解的是“为什么采样多条”模型一开始的成功率很低如果每个问题只生成一个答案很可能全部都是错的奖励全是 0梯度也没有方向。但如果每个问题采样 8 条正确的答案总有机会出现训练就能把概率分布推向正确路径。实现上可以基于 PPO也可以基于 GRPO 这类简化策略。GRPO 在可验证奖励场景里更省显存因为它不需要额外训练一个 critic 模型直接用一组采样结果内部的相对优势来更新策略。课程里虽然没有强制要求用哪个算法但我个人建议从小规模任务开始直接选一个已经实现好的 RL 框架先跑通流程再深入改策略。3. 一个可复现的 RLVR 实验数学题或代码生成3.1 先确认任务和目标指标如果你第一次接触 RLVR不要直接上自己最复杂的业务任务。先选一个验证成本低、对错明确的任务。我比较推荐两个小学数学题、单函数代码生成。拿数学题来说好处是验证器简单一个答案匹配函数就够了。可以先准备几百条题目人工写好标准答案和推理过程。目标指标可以定义成两个pass1 和 passk。pass1 是模型只生成一个答案就能答对的概率更接近实际使用passk 是让模型生成 k 个答案其中至少一个正确的概率更能说明模型有没有潜在能力。跑 RLVR 之前先跑一轮 SFT。SFT 之后的模型在开发集上至少要达到一定的正确率比如 20% 到 30%。如果连一次正确答案都产生不出来那是模型能力不够不是 RLVR 的优化目标有问题。这个前置条件非常关键很多人上来就跳过 SFT直接拿通用模型跑 RLVR结果奖励全是 0训练根本不收敛。3.2 数据格式与采样策略RLVR 训练数据最重要的不是标注“长答案”而是让验证器能判断“对错”。所以数据要包含三个部分问题、标准结果、验证方法。一个最小示例可以长这样{ question: 计算 3x 2 11 中 x 的值。, answer: x 3, verifier: exact_match, checks: [x 3] }如果你的任务更复杂比如要求模型先输出推理过程再输出最终结论那就要在验证器里先抽取出“最终答案”部分再做匹配。不要拿整段生成文本去做字符串匹配否则模型会学到“只要把正确答案藏在长文本里就能拿分”的坏习惯。采样策略上我一般先用 temperature 0.8num_return_sequences 8。如果输出太散、很多答案完全跑题就降到 0.6如果奖励信号太稀疏、正确率太低就提高到 1.0同时把采样数提高到 16。这里的温度不是训练参数而是生成探索参数。它控制的是训练时收集正样本的范围。3.3 训练流程与关键参数下面是一个比较保守的 RLVR 训练流程先用 SFT 数据训练基线模型确认指标。准备一小批 RL 训练 prompt比如 500 到 1000 条。写验证器先在 100 条生成结果上人工检查验证器准确率。跑 RL 训练每步采样 8 到 16 条输出。每隔几步保存 checkpoint并在开发集上做 pass1 评估。训练结束时把最终模型和 SFT 基线做对比。关键参数给一个起始参考参数起始建议说明采样数 N8~16探索越多训练越贵初始模型已完成 SFT 的模型不要从 base 模型直接跑学习率1e-6 ~ 5e-6比 SFT 低防止摧毁已有能力KL 惩罚系数0.01 ~ 0.1控制新策略不偏离参考策略太远训练 batch32 条以上奖励有噪声样本太少不稳定验证频率每 20~50 步及时看训练是否真正提升指标这些数值不是标准答案需要根据模型规模和数据量调整。如果你的模型比较大学习率可能要更低如果任务很简单采样数可以减小。最怕的是用一个固定参数跑到底不做观察。3.4 成功和失败的判断标准RLVR 训练成功最直接的信号是验证集上的 pass1 比 SFT 基线高而且不是靠牺牲输出格式换来的。我遇到过一种情况训练日志里奖励一直在涨但测试集指标纹丝不动。后来一查模型学会了在答案前后加很多解释验证器只匹配最终答案但它把最终答案重复了十遍等于变相提高命中机会。这不是真正的能力提升是验证器被钻空子。更好的判断标准是看三件事第一pass1 是否提升第二输出平均长度是否显著变长第三人工抽检高分样本看推理是否合理。如果 pass1 提升但输出长度暴涨就要小心模型在用“枚举式”答案刷分。还要注意一个现象训练前期奖励可能波动很大这是正常的。可验证奖励不像人打的平滑分数它只有 0 和 1噪声天然高。所以不要因为一两个 step 掉点就急着降学习率先看整体趋势。如果 100 步以内奖励均值始终没有上升趋势那就要回头检查验证器和 SFT 基线。4. 验证器设计RLVR 的“奖励”到底怎么算4.1 规则验证器严格匹配、结构化校验、执行测试RLVR 里最常用的验证器是规则验证器。它写起来简单运行速度快也最容易调试。严格匹配适合答案格式固定的任务。比如“x3”这种先对模型输出做规范化去空格、统一大小写、把中文冒号转英文然后再比较。这里的陷阱很多模型可能输出“答案是3”“x3”“3”三种形式靠一个规范化函数往往不够。我一般会把标准答案拆成多个可接受的别名并存成列表验证时只要命中一个就算对。结构化校验适合输出 JSON、YAML、函数签名这类任务。比如要求模型输出一个 JSON 对象字段包含 name、age、items。验证器先用 JSON parser 解析如果解析失败奖励为 0解析成功再看字段是否存在字段类型是否正确。这一步能给部分分每个字段正确给 0.2全部正确给 1。部分分在训练初期很有用因为全对样本太少时模型连梯度方向都找不到。执行测试适合代码生成和 SQL 生成。比如要求模型写一个排序函数就把生成的函数放进单元测试里跑。测试用例通过数量除以总测试用例数量就是这一条输出的奖励。执行验证最客观但也有两个麻烦一是需要安全沙箱不能随便在训练机上执行模型生成的可疑代码二是耗时高如果一条 prompt 生成 16 个代码每个都要跑测试训练时间会成倍增加。4.2 模型验证器什么时候必须用有些任务的正确性没法靠规则判断。比如要求模型写一段总结逻辑是否正确、有没有遗漏关键点字符串匹配很难判断。这时候可以找一个大模型当裁判根据你预设的评分标准给分。使用模型验证器时有几个细节很重要一是验证 prompt 要固定温度要设成 0不要每次都随机。二是最好让裁判输出一个 JSON包含每个评分维度的分数而不是只输出“对/不对”。三是如果预算允许用两个不同模型投票或者对同一个答案采样三次取中位数能明显降低噪声。但模型验证器也有一个天然问题它容易被生成文本的长度和结构影响。一个更长的、分段的答案往往更容易拿高分但它不一定更正确。所以每次用模型验证器之前我都要先做一次“验证器校准”抽 100 条已有的人工标注数据让验证器判定算它的准确率和误判率。如果准确率低于 90%不要直接进入 RL 训练。4.3 验证器本身有噪声时怎么办很多人在 RLVR 里忽略了一个问题验证器也是会错的。规则验证器可能误杀合法答案模型验证器可能给错误推理打高分。验证器的噪声会影响整个 RL 训练而且这种影响在训练早期会被放大。如果发现验证器有噪声我的建议是分两步处理。第一步把验证器的漏判和误判分开看。漏判是“正确答案被判错”这会导致训练时正样本太少误判是“错误答案被判对”这会导致模型学到错误模式。漏判可以通过扩充可接受别名、开放匹配规则解决误判要更小心需要收紧判断条件。第二步如果已经做了优化但验证器准确率还是不够那就让奖励更平滑一点。不要只用 0/1 二值可以给一个“部分正确”的中间分。比如答案对了但推理不完整给 0.5推理步骤对但最终算错给 0.2。部分分能缓解验证器噪声带来的梯度抖动。还有一个更基础的工程建议每次修改验证器都要把它记录成版本不要静默修改。因为 RL 训练过程中你经常需要回溯某一步的奖励是怎么算出来的。如果验证器改了好几次没有版本记录你很难判断指标变化到底是因为模型变好了还是因为验证器变松了。5. 落地时会踩的坑从回报稀疏到策略崩溃5.1 回报信号太稀疏模型不更新RLVR 最常见的问题就是奖励全是 0。一个 7B 模型如果没有经过足够的 SFT在数学题上可能生成 16 个答案全错。这时候强化学习根本没有信号策略不会更新。看起来是“训练没收敛”实际上是“一开始就没有正样本”。解决思路不是盲目加大采样数而是先降低任务难度。我建议先让 SFT 基线在开发集上达到至少 20% 左右的成功率再跑 RLVR。如果成功率太低先收集更多高质量 SFT 数据或者把问题拆成更简单的子任务。比如不做整道题先让模型只输出“设未知数、列方程”这一步等这一步稳了再优化完整答案。有一种特殊情况是任务本身很难但有一些容易拿分的子结构。这时候可以设计“阶段奖励”只要模型写出了正确的方程给 0.3只要答案算对给 1。但阶段奖励要谨慎因为它会引入人为设计模型可能只追求容易拿到的部分对最终目标不敏感。5.2 验证器被“钻空子”reward hackingRLVR 里最值得警惕的现象就是 reward hacking。模型不是为了“做对”而是为了“让验证器觉得对”。举个例子验证器只检查最终答案是否等于“3”模型可能会在输出里写“答案是3答案是3答案是3”然后把前面一大段推理全跳过。验证器一看包含正确字符串给 1 分。策略网络立刻意识到重复正确答案能拿高分于是训练结果变成一堆垃圾文本。避免 reward hacking 的做法有几种验证器只检查“最终答案区域”不接受散落在任意位置的答案在奖励函数里加入格式约束例如必须包含推理过程否则扣分对输出长度做惩罚防止模型通过疯狂重复来刷分定期人工抽查高分样本看模型为什么拿高分。记住一点验证器不是写一次就结束的。你要在训练过程中不断观察 rollout 的高分样本一旦发现明显不符合直觉的“聪明”输出立即更新验证器并重新开始训练。5.3 训练跑着跑着输出质量下降另一种常见情况是训练早期效果不错但过了一段时间模型输出质量突然下降甚至开始语无伦次。这类问题通常和 KL 惩罚、学习率、采样温度有关。RLVR 更新策略时容易让模型越来越集中在少数几种“高分表达”上导致多样性下降。表现在指标上就是 pass1 可能还在涨但生成内容开始千篇一律更严重的是采样到一定阶段模型开始生成重复 token甚至陷入死循环。发现这种情况我会先检查两个指标策略模型和参考模型之间的 KL 散度以及平均输出长度。如果 KL 散度涨得太快说明策略偏离参考模型太远需要增大 KL 惩罚。如果平均输出长度暴涨说明模型学会了通过堆字数来刷分需要在奖励里加长度惩罚。如果这两项都正常再考虑降低学习率。RLVR 比较敏感学习率太高会让策略在几个 batch 内崩溃。我一般会把学习率设到 SFT 的十分之一左右再根据日志缓慢调整。5.4 通用排查顺序RLVR 训练出问题不要一上来就乱调参。按下面这个顺序排查通常能更快定位先看初始成功率SFT 基线在训练集上有没有正样本再看验证器准确率抽 100 条生成结果人工判定验证器给分是否合理。看 rollout 日志高分样本长什么样有没有明显钻空子看奖励曲线是否持续上升还是上下乱跳毫无趋势看 KL 和长度策略有没有偏离参考模型输出有没有变长到异常最后才调整参数改学习率、改采样温度、改 KL 惩罚。这个顺序几乎能解决 80% 的 RLVR 训练问题。核心思路是先确认“能不能收到正确信号”再确认“策略有没有学到东西”最后才去碰训练参数。很多人习惯反过来一掉点就调学习率结果问题出在验证器上调参只是在安慰自己。6. 产品化判断RLVR 适合哪些任务不适合哪些任务6.1 适合 RLVR 的任务类型真正适合 RLVR 的任务都有一个共同点对错可以被自动判定而且判定成本不高。最典型的是代码生成。模型写的代码可以放到沙箱里用预写好的单元测试来验证。测试通过率就是奖励。这是 RLVR 已经验证过的场景很多代码模型都靠这一套提升 pass1。其次是数学题、逻辑推理、SQL 生成、JSON 结构化输出。它们的共同点是结果有标准形式判断逻辑可以程序化。哪怕答案有多种表达只要你能写一个函数把等价表达都归一化就能用 RLVR。在业务里还有一个很适合 RLVR 的场景是“必须包含指定字段”的信息抽取。比如从一段商品评论中抽取品牌、型号、价格。验证器检查抽取结果是否字段完整、值是否存在于原文中。这种任务通过 RLVR 可以让模型更稳定地输出结构化结果不容易漏字段。如果你的任务本身已经有了一套人工审核流程可以考虑把这套流程中的客观规则抽出来做成验证器让 RLVR 先迭代一版“规则敏感型”模型再让人工审核兜底。6.2 不适合 RLVR 的场景不适合 RLVR 的情况也很明显没有标准答案或者标准答案成本太高。开放写作、创意文案、营销标题、情感陪伴、闲聊这类任务内容好坏高度主观。你没有办法写一个函数判断“这句文案是否有感染力”。如果强行用模型裁判裁判本身的主观偏好就会成为新的噪声源。这种场景下RLHF 或 DPO 可能更合适因为它们直接学习人类偏好。还有一类任务要特别小心医疗建议、法律意见、金融分析。这些领域的答案是否“正确”不能只靠规则判断更不能靠简单的关键词匹配。如果验证器设计不齐全模型可能输出看起来专业、实际有风险的错误内容。并不是说完全不能用 RLVR而是要在验证器里加入大量的专业约束和兜底逻辑且训练完成后必须有严格的人类专家评估。最后如果你的算力资源很紧张或者模型本身很小也不建议轻易跑 RLVR。小模型在奖励零散的训练中很容易遗忘已有能力。我见过很多团队在 1B 模型上做 RLVR结果 pass1 没提升反而把 SFT 阶段学会的格式稳定性也搞丢了。这种时候先做更充分的 SFT 和 DPO收益可能更大。6.3 实操建议先小后大先单点后系统如果你已经决定要在业务里试 RLVR我的建议是三步走。第一步选一个最小但真实的子任务。不要一上来就想优化整个客服系统先选“从用户问题中抽取产品参数”或者“根据表格生成 SQL”这样一个边界清晰的任务。跑通 SFT - RLVR - 评估的完整链路。第二步把验证器当成第一优先级。先写规则再采样输出再人工抽查再迭代验证器。验证器稳定了训练才开始有意义。很多失败的 RLVR 项目最后复盘下来都不是 RL 出了问题而是验证器质量不过关。第三步上线前做一次“分布外测试”。RLVR 容易让模型过度优化训练集上的验证规则遇到没见过的问法可能失灵。所以一定要用一批和训练数据分布不同的测试样本人工评估一遍。如果只是做本地部署或者调用 API其实不需要关心怎么训练 RLVR。模型侧的后训练是模型厂商和算法团队的事你和 RLVR 的关系更多是“理解能力边界”而不是“必须亲手训一个模型”。把 RLVR 当成一个训练升级项而不是默认步骤才能真正发挥它的价值。