大模型后训练与RLVR：从会说话到会干活的工程实践

在训练一个自研大模型的时候我曾经遇到过一种很“分裂”的状态预训练环节的 loss 已经降得很低模型也能把一句话补全得相当通顺但只要让它按指令办事比如“把这段话改写成表格”“只回答 Yes 或 No”它就开始失去控制——要么答非所问要么绕来绕去就是不给结论。当时团队里有人怀疑是预训练数据不够也有人建议继续调参但后来真正把问题解决的是后训练那一整套流程。尤其在接触了可验证强化学习RLVR之后我才意识到模型的“知识”和“能力”之间隔着一道后训练的鸿沟。这也是斯坦福大模型开发课 EP16 最值得反复咀嚼的地方之一——它用很清晰的方式拆开了后训练和 RLVR让人明白一个模型从“会说话”到“会干活”到底发生了什么。这篇内容我想顺着课程的思路把大模型后训练和 RLVR 的底层逻辑、完整流程、适用边界、工程坑点都说清楚。如果你正在做大模型微调、对齐或部署这篇内容应该能帮你减少很多试错成本。1. 为什么后训练才是大模型“能用”的分水岭1.1 预训练给了模型知识但没有给“任务感”大多数人理解大模型都是从预训练开始的给模型喂海量文本让它学习下一个词是什么。这个阶段确实决定了一个模型“知道多少东西”但它不决定模型“会不会按指令工作”。原因是预训练的目标函数是“补全”而不是“完成任务”。模型学到的是语言统计规律比如“今天天气”后面很可能接“怎么样”但它不知道用户问“今天天气怎么样”时期望得到一个结构化、简洁、符合人设的回答。这里可以用一个类比预训练像是一个人读了几万本书通晓了各种事实和表达方式但没人教过他怎么在职场会议里汇报、怎么做项目管理。他知道很多词汇却不知道不同场景下的行为准则。后训练做的事情就是把这些行为准则“内化”进模型参数里让模型在不同指令下表现出对应的协作方式。1.2 后训练的组成部分和定位后训练不是一个单一步骤而是一组方法的集合。常见路线包括有监督微调SFT用人工或模型生成的“指令-回复”对让模型学会基本输出格式和指令服从。偏好对齐RLHF / DPO基于人类偏好或AI反馈让模型学会“更符合人味”的表达减少有害内容。推理强化RLVR / 推理奖励针对有标准答案的任务用可验证奖励直接优化模型的推理正确性。上下文对齐context distillation 等把某些行为内化在上下文里减少重复输入。从学习路径看SFT 是后训练的第一步它解决“基础格式”问题RLHF 解决“偏好”问题RLVR 则更像是在数学、代码等“标准答案型”任务上的定向强化。很多团队在说明里只强调“我们做了微调”但实际落地时真正影响用户体验的往往是 SFT 之后那几步对齐和强化。课程里把后训练放在如此重要的位置原因也很简单预训练训练的是“世界的统计规律”后训练训练的是“人的意图和任务”。如果只做预训练模型更像一个博学的“接话机器”只有完成后训练它才能变成一个“办事工具”。2. 从 RLHF 到 RLVR可验证奖励解决了什么问题2.1 RLHF 的痛点奖励模型本身成为瓶颈传统强化学习对齐走的是 RLHF 路线先收集人类对多个回答的偏好排序训练一个奖励模型reward model再用这个奖励模型去指导策略模型更新。这个思路本身没有问题但它在工程上会带来几个很难绕开的痛点。第一标注成本高。要训练一个稳定可靠的奖励模型需要大量人类偏好数据。而且不同标注者对“好答案”的感知不一致很容易引入噪声。第二奖励模型会被“钻空子”。模型会学到讨好奖励模型的模式比如给出看似自信但实际错误的答案或者故意说得很长因为奖励模型偏好长文本。第三训练不稳定。奖励模型的误差会顺着策略梯度放大导致“奖励黑客”reward hacking——策略在奖励上越来越高但人类真实体验反而变差。这也是很多团队做对齐做到后期总觉得“客观效果提升不明显”的一个原因。奖励模型是人为构造的代理信号代理信号和真实目标之间的偏差最终会成为天花板。2.2 RLVR 的核心思路把奖励变为可验证RLVRReinforcement Learning with Verifiable Rewards的思路是不去学一个奖励模型而是用确定的规则或程序直接判断答案是否正确。比如数学题可以用最终答案是否等于标准答案来判断代码题可以用运行时是否通过测试用例来判断SQL 题可以用执行结果是否一致来判断。这个“验证器”不需要训练也不存在“被策略模型欺骗”的问题——只要验证规则足够严格模型得到的奖励就是客观、可复现的。和 RLHF 相比RLVR 的奖励信号更稳定训练更可控。这是 RLVR 最核心的价值把“主观偏好”去掉让强化学习在一个更干净的信号上进行。但这里必须强调一点RLVR 并没有完全替代 RLHF。它只适用于奖励可以被自动验证的任务。对于开放式写作、对话体验、风格迁移、情感判断这类没有唯一标准答案的任务你很难写出一个“验证器”——总不能写个程序判断“这段话是否更有同理心”。所以 RLVR 补充了 RLHF 的不足但不会消灭 RLHF。2.3 一张表格看清 RLHF 和 RLVR 的差异维度RLHFRLVR奖励来源人类偏好训练的奖励模型程序/规则验证结果标注成本高需要大量人工偏好数据低需要设计验证器客观性偏主观存在标注噪声客观可复现被攻击风险奖励模型可能被策略模型欺骗验证规则严格时不易被攻击适用任务开放式任务、对话、审美偏好数学、代码、逻辑推理等标准答案型任务训练稳定性依赖奖励模型质量奖励信号更稳定主要瓶颈奖励模型偏差验证器设计是否覆盖正确性这张表不是要说明谁更强而是要提醒后训练方案之间是“互补”的选哪种取决于你要优化的目标是什么。3. RLVR 的完整流程与关键设计3.1 RLVR 的完整循环RLVR 的循环并不复杂但每一步都有讲究。通常流程是从当前策略模型采样多个回答。对每个回答用验证器计算是否通过。把通过/不通过的结果转换成奖励信号。用强化学习算法如 PPO 或 GRPO更新策略模型。重复 1-4直到验证正确率达到目标。这里的奖励并不一定是“最后一步给分”可以细化到过程奖励。比如一道数学题不但看最终答案还判断每一步推理是否合法一段代码不只看是否通过测试还可以计算中间态的覆盖率。过程奖励通常能加速收敛因为模型能更早地知道哪一步出了问题。3.2 验证器怎么设计验证器是 RLVR 里最容易被低估的部分。它直接决定奖励信号的质量。如果验证器太松模型会找到绕过验证的捷径比如生成“答案是 42因为我随便算的”也能算对如果验证器太严又可能把一些合理但表达不同的答案判错导致训练数据减少。我的建议是验证器要尽量做到“表层形式无关逻辑结果等价”。在设计验证器时可以考虑几个原则对文本答案做归一化去除无关标点、空格、特殊符号统一大小写和格式。对数学答案做数值比对允许浮点数误差阈值避免严格相等导致误判。对代码答案按测试用例判分不要只看编译是否通过要设置覆盖度指标。对多步推理做过程检查如果资源允许可以设计逐步验证器而不只判断最终结果。用伪代码说明一个简单的数学答案验证器def verify_math_answer(pred, ground_truth, tolerance1e-6): # 去掉空白和常见符号 pred_clean normalize(pred) gt_clean normalize(ground_truth) # 尝试用等值比较兼容浮点误差 if is_equal_after_parse(pred_clean, gt_clean, tolerance): return 1.0 return 0.0这个例子看起来很简单但实际工程里你至少要处理模型输出里可能带解释、可能带单位、可能用不同格式验证器需要从输出中提取答案部分再和标准答案比对。这个“提取答案”的过程本身就是一段不小的工程。3.3 奖励、采样与更新的工程细节GPU 资源分配RLVR 需要同时跑策略采样、验证器判断、策略更新通常需要多卡协作。采样数量每一步从同一个 prompt 采样多个答案通常 4 到 16 个。采样太少奖励噪声大采样太多计算成本高。奖励密度如果大多数采样答案验证结果都是 0策略几乎得不到有效梯度。可以考虑用“部分奖励”或过程奖励来缓解稀疏问题。KL 系数策略更新时要用 KL 惩罚防止模型偏离原始分布太远。KL 系数太小模型可能越学越偏太大则优化效果不明显。学习率建议从比 SFT 阶段更小的学习率开始因为强化学习阶段非常容易震荡。注意不要一上来就把采样数量和并行数拉满。先用一条 prompt 跑通整个闭环确认验证器、奖励日志、策略更新都能正常完成再扩展到整个数据集。4. 哪些任务适合 RLVR不适合什么场景4.1 适合 RLVR 的任务类型RLVR 最适合的任务有三个特征有标准答案、答案可自动判断、判断维度清晰。数学题与逻辑推理最终结果可以标准化比较中间步骤也可以做规则检查。代码生成能不能通过单元测试是天然的可验证信号。SQL 生成在给定数据库中执行结果是否一致可以作为验证器。结构化信息抽取比如从文本中抽取日期、金额如果目标字段是确定值可以自动比对。竞赛类任务有明确的判分脚本或评测集可以直接作为奖励。这些任务的共同点是你不需要雇佣大量标注人员去判断好坏只需要一套验证脚本。这也是 RLVR 相比 RLHF 更容易规模化的重要原因。4.2 不适合的任务与判断标准不适合 RLVR 的任务也很明显开放式写作、情感分析、聊天体验没有“唯一正确答案”验证器很难定义。创意设计、绘画、营销文案质量维度主观自动验证最多只能做格式审查不能做内容评价。医疗诊断、法律建议等高风险场景即使有验证器也无法覆盖真实世界的评判维度过度依赖规则反而危险。判断一个任务适不适合 RLVR可以问自己一个问题如果我把两个答案放在程序面前程序能不能靠规则判断出哪个更好如果不能那么 RLVR 就不合适。这时候应该回到 RLHF 或 DPO或者用 LLM judge 做间接验证但那本质上已经不是在用“可验证奖励”而是在用另一个模型当奖励模型。另外要注意即使任务适合 RLVR也还要看验证器是否能覆盖“错误”的全部维度。比如代码生成如果测试用例太少模型输出一个只针对某个 test case 硬编码的答案也能得分这看似正确实际上并没有解决问题。5. 工程落地中的几个常见坑与排查思路5.1 从奖励曲线和输出样本里找问题RLVR 训练过程中只盯着 loss 或 reward 曲线是不够的。我一般会分三个层次观察第一层是奖励曲线如果奖励一直不上涨可能是采样质量、验证器问题或学习率太低。第二层是 KL 散度和熵如果 KL 很快变大说明策略偏离原始模型太远可能发生奖励黑客如果熵下降过快说明策略过早收敛到一个固定输出探索不足。第三层是实际输出样本每隔一段时间抽几条 prompt看模型生成的回答是否真的在变好而不是在“刷验证器”。很多问题在输出样本里比在指标里更容易暴露。比如模型学会了在答案里复制标准答案的一部分或者学会了输出“答案是 0因为任何数乘以 0 都是 0”这种话这在奖励指标上可能得分但明显不是我们想要的推理行为。5.2 一个可行的排查顺序如果你遇到 RLVR 训练不收敛或效果提升不明显可以按以下顺序排查先看验证器本身随便取一批预测结果人工核对验证器判定是否正确。验证器错了后面所有训练都是空中楼阁。再看采样质量当前策略采样出的答案有多高比例是验证器能判分的。如果大多数答案连格式都不对先要考虑用 SFT 或 prompt 约束格式。再看奖励分布如果绝大多数奖励为 0考虑使用过程奖励或降低任务难度。再看超参数采样数量、KL 系数、学习率、batch size 是否在合理范围。最后看数据分布训练 prompt 是否覆盖了多样化的表达式还是只集中在某一类模板上。这个排查顺序遵循“先底层后上层”的逻辑避免一开始就盲目调参。5.3 长期使用需要补哪些工程能力如果只是做一次小实验RLVR 可以很轻量。但如果要长期用于生产至少要补上以下能力验证器管理验证规则、版本、历史输入输出都要做记录便于回溯。数据管道采集 RLVR 训练中模型生成的失败样本重新进入 SFT 训练集形成“失败-纠正”闭环。模型评估RLVR 只优化可验证指标需要额外维护一套人类偏好评估集防止指标提升了但真实用户体验下降。稳定性监控定期检查 KL、熵、奖励分布避免模型在某个版本中悄悄退化成捷径学习。重要提醒RLVR 不是“自动修复一切”的魔法。它只是提供了一组更稳定的奖励信号真正决定上限的是任务定义、验证器质量和数据覆盖度。6. 从学习到实践如何把 RLVR 纳入自己的训练流程6.1 从课程到本地实验先跑通最小闭环很多人看完课程会想RLVR 这么复杂普通团队能不能自己复现其实可以但起点要小。建议选一个非常简单的任务比如小学难度的数学应用题或者一个简单的代码修复任务然后搭建最小闭环用一个小规模数据集比如几百条 prompt。用你已有的大模型做初始策略先跑一次 SFT让模型具备基本输出格式。写一个验证器判断答案与标准答案是否一致。用 GRPO 或 PPO 做策略更新先在单个 GPU 或小规模 GPU 环境下验证。这里有一个常见误区一开始就选用全量数据和完整任务导致问题被淹没在资源消耗里。最小闭环的目的是验证“验证器→奖励→策略更新”这条链路是正确的再逐步放大。6.2 我给学习者的建议把 RLVR 放在后训练路线图的哪一步如果你正在学习大模型后训练我的建议是不要一上来就碰 RLVR。先要做好以下几步先理解 SFT 为什么是一切的基础。没有稳定的指令遵循能力RLVR 采样出来的答案会乱到验证器无法处理。再理解 RLHF 的奖励模型是怎么训练的以及它的问题在哪里。这能帮你理解 RLVR 的针对性改进。接着在数学或代码任务上尝试 RLVR先用现成开源框架再自己写验证器。最后考虑混合方案比如“SFT RLVR DPO”让不同方法各司其职。这个顺序之所以有效是因为每一层都在为后一层铺路。SFT 让模型“会说”RLVR 让模型“算得准”DPO/RLHF 让模型“说得像人”。顺序反过来往往事倍功半。6.3 最终判断回到开头的问题为什么预训练 loss 很低模型还是不会完成任务答案已经清楚了——预训练负责知识后训练负责能力而 RLVR 是“能力”里针对可验证任务的那把专用扳手。它不负责审美不负责创造力也不负责闲聊的温度它负责的是把数学、代码、逻辑这些“有标准答案”的事情做到极致。如果你正在做一个大模型应用可以先想清楚你的核心任务有没有可验证的答案如果有RLVR 值得投入如果没有更合适的方向是 SFT RLHF/DPO。把方法用在对的场景里才是后训练真正的艺术。