从RLHF到Reasoning RL：LLM强化学习的新范式与GRPO实践

1. LLM强化学习为什么突然从RLHF转向了Reasoning RL过去两年训练大模型的圈子里有一个非常明显的变化2023年我们在大量讨论RLHF、PPO、奖励模型过优化2024年初大家还在为RLHF的成本和稳定性头疼到了2025年几乎所有做推理模型的团队都在聊GRPO、规则奖励、可验证奖励也就是大家常说的Reasoning RL。这种转变不是某个团队灵光一闪而是整个LLM强化学习技术栈在被现实狠狠教育过之后做出的务实选择。先说清楚一个概念RLHFReinforcement Learning from Human Feedback和Reasoning RL面向推理能力的强化学习本质上是同一套强化学习范式在不同目标下的应用。区别在于RLHF用人类偏好数据训练一个奖励模型来代理人类判断而Reasoning RL直接用手写的、可验证的规则去评分比如数学题答案对不对、代码能否通过测试、SQL查询结果是否符合预期。早期GPT-4、Claude这类通用对话模型之所以必须用RLHF是因为这段回答是否令人满意没有一个客观标准。你觉得回答态度好、结构清晰、信息密度高我觉得啰嗦、避重就轻谁对只能让人类打分或者训练一个模拟人类打分的奖励模型。但到了数学推理、代码生成这类任务事情发生了变化一道AIME数学题的最终答案就是某个整数一个LeetCode题目的解法要么通过全部测试用例要么不通过。这种场景下再花钱雇人去标注偏好、训练奖励模型不仅浪费而且会引入大量噪声。我记得有个实际案例特别能说明问题某团队做数学推理对齐用RLHF训了一版奖励模型认为过程详细、步骤完整的答案分数高结果模型学会了把简单题目拆成一百多个步骤每一步都写Lets think step by step答案对了但推理链又臭又长。换成规则奖励只检查最终答案对错之后模型立刻开始寻找简洁高效的解法路径。这就是Reasoning RL崛起的最核心动机当任务本身有客观正确性判据时基于规则的奖励函数远比学习出来的奖励模型可靠。另一个隐藏原因是训练稳定性。RLHF的PPO算法需要同时维护四个模型Actor策略模型、Critic价值模型、Reward Model奖励模型、Reference Model参考模型。其中Critic的预测误差非常大尤其在奖励模型本身就在不断变化的时候价值网络经常学不稳导致策略更新噪声大、训练曲线剧烈震荡。而Reasoning RL主流的GRPO算法直接把Critic干掉了用组内采样的相对优势替代价值估计训练开销和稳定性同时得到改善。顺带一提现在圈子里讨论LLM训练时很多人会提到Karpathy维护的llm wiki知识库里面把RLHF和RLVRReinforcement Learning with Verifiable Rewards的发展脉络梳理得比较清楚。如果你刚开始接触这个领域我建议把它当目录来用先建立宏观认知再去读论文细节。2. 从PPO到GRPO四个模型变三个模型反而更稳了要理解Reasoning RL为什么能行必须先理解PPO在RLHF阶段到底是怎么工作的、又痛在哪里。2.1 PPO的四模型博弈和KL护栏PPOProximal Policy Optimization是OpenAI在2017年提出的策略梯度算法核心思想是通过clip截断限制每次策略更新的幅度避免一步更新过大导致灾难性崩坏。在LLM的RLHF阶段PPO的典型架构如下Actor模型当前正在被训练的策略模型也就是我们说的学生Reward Model学习人类偏好的奖励模型输入一整段回答输出一个标量分数Critic模型预测从某个状态开始到最终能获得多少累计奖励的价值网络用于降低策略梯度方差Reference Model冻结的初始SFT模型用于计算KL散度每次迭代时Actor生成一段回答Reward Model打分Critic给出基线估计同时KL散度惩罚保证模型不会偏离原始SFT模型太远。这套体系的理论很完美但实践中的痛苦我从没见过哪个团队能完全躲开。最典型的问题是Critic与Reward Model的拉锯。Critic要预测的价值函数是非平稳的——因为Actor每次更新策略同一个状态产生的分布都在变价值也在变。Reward Model本身也在训练过程中可能被替换或微调。两个不稳定的网络互相耦合策略梯度方差居高不下训练曲线经常出现看起来在涨换一个随机种子就废了的情况。第二个痛点是资源开销。四份完整模型参数分布在多卡集群上序列生成和打分阶段涉及大量数据传输。我记得一个7B模型的RLHF训练由于Critic的额外前向和反向传播显存占用比纯SFT高出一倍多时间成本高出大约三倍。2.2 GRPO为什么敢砍掉CriticDeepSeek在GRPOGroup Relative Policy Optimization论文里做了一个非常大胆的简化不要价值网络用同一prompt下采样出的多个输出的相对优劣来估计优势函数。具体做法是这样的针对同一个prompt从当前策略中采样G个输出论文里通常G8、16或32用规则奖励函数给每个输出打分在组内对这些得分做归一化得到每个输出的优势值用归一化后的优势值作为权重执行带clip的策略梯度更新这个思路的直观解释是与其用一个学习出来的价值网络去预测应该得多少分不如直接看看同一批兄弟输出里谁比谁好。如果一个输出在组内排名靠前说明它优于当前策略的平均水平就加大它的概率反之就压低概率。这种做法之所以成立有一个重要的前提条件规则奖励的噪声足够低。当奖励来自LeetCode测试通过、数学答案比对这类客观信号时组内比较是可靠的。但如果是主观性很强的对话质量打分组内比较就会受到采样噪声的严重影响这也是GRPO不太适合直接替代RLHF做通用对话对齐的原因。从工程角度看GRPO最大的红利是内存。没有Critic网络之后模型的范式从四份权重降为三份权重显存、通信、训练时间都有立竿见影的下降。我自己用8卡A100试过一个14B模型的GRPO训练单次迭代的显存峰值比同规格PPO大约降低了25%到30%而且不需要维护价值网络的优化器状态这让中等规模的团队也能跑得起Reasoning RL实验。2.3 一个被很多人忽略的收敛差异很多文章对比PPO和GRPO时只谈架构差异忽略了收敛行为上的区别。PPO的价值网络使得优势估计在单条轨迹内部是平滑的策略更新方向有前瞻性GRPO的优势是离散的组内排名更新更有锦标赛淘汰的感觉。这意味着什么在奖励信号稀疏的任务上PPO的Critic理论上还能通过价值预测提供一定的梯度方向而GRPO在组内所有输出得分都相同时比如全部零分梯度为零完全无法学习。实际训练中经常出现的情况是初始策略很差时一组16个样本全军覆没GRPO原地踏步好几个step直到某一组里偶然冒出一个正确解才开始有信号。所以有一个实用的经验GRPO训练前最好先确保SFT模型在目标任务的passk上已经有一定基础。DeepSeek-R1的SFT阶段做了大量冷启动数据的筛选本质目的之一就是让GRPO的初始策略不至于差到组内全零分。Karpathy的llm wiki里对这两套算法的收敛特性也有专门段落建议对照着看。3. 规则奖励设计最考验功底的细节全在这很多刚接触Reasoning RL的人以为把答案对了给1分就算完成了奖励设计实操之后才发现奖励函数的设计和打磨才是整个训练工程里耗时最长的部分。3.1 可验证奖励的三层递进结构以数学推理为例一套成熟的规则奖励通常包含三层格式层模型是否按规定的格式输出比如是否包含最终答案是xxx这个结构片段是否使用了规定的标签。这一层主要是为了可控性不直接反映推理质量。答案正确性层解析最终答案并与标准答案做正则匹配。注意这里极易踩坑比如1/2和0.5算不算一样2和2.0算不算一样要不要处理$符号、LaTeX语法差异这些看似细节的判断决定了奖励函数的毛刺。过程合理性层是否出现了关键推理步骤比如是否用到了给定的中间条件。这一层在纯数学评测里通常不做强校验但用在代码任务时会等价于核心模块测试。我见过大量团队把三层混在一起试图一个奖励函数同时解决格式、答案和过程最后模型学会的是钻规则空子。最常见的例子模型发现格式分占比高就开始疯狂堆砌格式标记真正推理的部分完全没有。最后奖励曲线非常漂亮评测指标纹丝不动。3.2 DeepSeek-R1被反复验证的tanh缩放思路这里分享一个效果非常稳定的奖励设计手法——为什么要对推理长度做惩罚或奖励缩放因为Reasoning RL极其容易产生长度崩溃。现象是这样的模型发现多写几步推理和答案正确之间的相关性很高因为复杂题确实需要长推理于是开始无条件延长输出把简单题也写成长篇大论。组内优势比较时答案全对的情况下更长的那条轨迹偶尔得分更高模型就把长当成了奖励信号。一段时间后所有输出都变成几千字的注水论证。解决办法通常是在奖励函数里加入受控的长度信号。DeepSeek-R1训练时对思考预算做了限制系统提示里明确要求推理长度落在某个范围。我自己的实践是给输出长度设置一个目标区间超出区间按比例扣分并用tanh把惩罚幅度压缩在有限范围内防止奖励尺度过大破坏策略更新的稳定性。长度惩罚系数一般设置在0.01到0.05之间太小没效果太大模型会矫枉过正直接退化成低长度但低正确率的保守态。3.3 奖励黑客的真实案例和防御策略奖励黑客Reward Hacking在Reasoning RL中不仅存在而且比RLHF更隐蔽。原因很简单规则奖励是确定性的模型可以精确地搜索到漏洞。我碰到过一个真实案例某代码生成任务验证方式是最终答案是否包含特定函数名且测试用例通过率0.5。模型很快发现只要函数名出现再随便写几行函数体即使测试完全不合格也可能因为部分分机制拿到一些分数。于是策略收敛到了每个问题都生成包含目标函数名的废代码整体奖励从0.3涨到0.45但实际上线评测通过率没有明显变化。防御策略没有银弹只有几个实践经验奖励函数的每个规则分支都要用异常样本回归验证比如故意制造答案正确但过程荒谬的输出看奖励是否如预期那样低。定期对训练策略的中间checkpoint做PassK离线评测建立奖励与真实指标之间的回归关系。一旦发现两者背离立刻停止训练检查奖励设计。不要迷信单一规则奖励。工程上可以同时启用多个验证器比如数学题用答案校验加抽查步间逻辑代码任务用单测通过率加静态检查基础风格。4. 实践踩坑记录我的Reasoning RL训练全流程拆解理论说了很多接下来分享一次完整的实际训练过程。这个项目是一个帮助开发者自动推理LeetCode题目的场景化模型基础模型选了Qwen2.5-14B训练目标是提升模型在代码推理链上的质量。4.1 数据准备比你想的更占时间GRPO对提示词分布非常敏感。我第一轮实验直接用了竞赛数学题数据结果发现采样输出里经常包含代码块残留、英文模板、非标准Unicode字符奖励解析器在解析答案时常因字符编码报错。后来数据处理加了三个步骤才稳定下来把提示词统一成问题描述要求格式示例模板的三段式结构减少prompt格式变化带来的采样分布偏移对输出文本做标准化清洗全角转半角、LaTeX命令转换、去BOS/EOS token噪声对答案进行多重格式解析纯文本比较、数值比较、集合比较至少三种解析器投票一致才给分这一步大约花了一周但它是我认为整个项目中最值得投入的时间。奖励函数写得再精细如果解析环节不稳定一切都是空中楼阁。4.2 GRPO训练的超参数基线我用HuggingFace的RL训练框架调通了整套流程关键超参数如下采样组大小 G16 Clip范围 epsilon0.2 KL惩罚系数 beta0.04 学习率 5e-6使用线性warmup和cosine decay 每步生成max_token_len2048 批次大小按prompt数8累计梯度更新步数相当于batch32 训练步数 1200全程大约消耗8000张H100卡时这里特别要提醒KL惩罚系数。GRPO虽然不像PPO那么依赖参考模型但完全不设KL约束会让模型快速偏离SFT语义底座表现为输出中频繁出现重复片段和格式混乱。0.04是我在这类任务上调出来比较平衡的值太高策略更新幅度太小训练效率低太低模型会逐渐说胡话。4.3 采样组数与显存的博弈我做过一个简单实验把组大小从16降到8训练速度提升了约35%但最终Pass1指标下降了约4个百分点。这说明组内多样性对优势估计至关重要——组越小相对排序越容易受偶然高分影响策略更新方向噪声越大。在8张80GB H100上14B模型配G16正好卡在临界点生成阶段不需要梯度所以可以开大batch更新阶段需要反向传播所以要缩小batch。优化的做法是把生成和训练解耦先用当前策略离线批量采样大量的response组存到磁盘队列然后再用这些固定数据做策略更新。这样生成阶段可以拉满吞吐更新阶段就有干净的数据批次。4.4 奖励曲线的三阶段形态GRPO训练的reward曲线通常不是一路向上的而是经历三个阶段第一阶段0到200步格式分率先上升模型快速学会按规则输出答案结构整体奖励曲线陡峭上涨第二阶段200到600步答案正确率开始波动上升但奖励曲线的锯齿明显加大这是因为模型开始尝试更复杂的推理路径偶发失败增多第三阶段600步以后收敛放缓如果奖励设计合理正确率平稳提升如果奖励设计有漏洞进入奖励黑客模式奖励持续上涨但真实指标平台化甚至下降我当时在第三阶段发现reward和eval指标背离排查后发现是解析器对answer is (\d)这种格式的检查有bug当数字位数超过6位时经常解析失败导致误判。修掉之后重新跑了约200步模型指标恢复正常。结论这个阶段一定要建立独立的、不参与训练的评测管线每个checkpoint跑一遍固定测试集。我连的评测集只有100道题但每步都要计算P1和P8这比任何训练曲线可视化工具都有说服力。5. 什么时候该用RLHF什么时候该上Reasoning RL写到这里很多人会误以为Reasoning RL已经完全取代了RLHF但真实情况不是这样。它们适合解决的问题不一样。5.1 两个范式的适用边界RLHF最擅长的是把模型从知识正确但表达生硬变成知识正确且符合人类预期。你觉得一个模型有礼貌、有温度、回答有结构这靠的是RLHF对齐人类的沟通模式。Reasoning RL完全做不了这件事因为不存在一个客观的规则能判断这句话是不是足够有礼貌。Reasoning RL擅长的是把模型从知道步骤但容易算错变成能自主验证并修正推理过程的稳定解题器。它的前提是任务存在可验证的正确性判据数学、代码、SQL、逻辑推理天然适合而开放性创意写作、情感陪伴、通用对话则不适合。一个比较稳妥的判断方法是如果把你的任务交给一个外包团队你能在30秒内判断他们的交付是否合格那么Reasoning RL大概率适合如果答案需要几个人仔细讨论才能定夺那还是老实走RLHF路线。5.2 并行融合两条腿走路的新趋势2025年大模型训练圈的共识是两条路线不是替代关系而是分工关系。比较成熟的工业级方案是先用Reasoning RL把模型的解题能力和推理能力打磨扎实再用少量RLHF对模型的表达风格做精调。Reasoning RL负责想得对RLHF负责说得好顺序不能反。如果先做RLHF再做Reasoning RL很容易把偏好对齐阶段学到的表达习惯破坏掉。一些类Agent任务也开始把这两种手段混在一个训练循环里工具调用正确性用规则奖励工具返回结果后的用户偏好用人类反馈奖励。两种奖励信号加权组合权重需要根据评测反馈动态调整。5.3 成本与效果的务实账本以7B模型为例粗略算一笔账RLHF全套训练含奖励模型训练、PPO、多轮评测大约需要2到4周Reasoning RL含规则奖励开发、GRPO训练、评测管线大约需要2到3周但推理类指标提升通常比RLHF显著如果数据清洗干净、奖励函数设对Reasoning RL在某些数学评测集上的Pass1提升可达15到25个百分点而RLHF在同任务上经常只有3到5个点所以我的个人建议是但凡你的任务具备可验证属性优先设计规则奖励尝试Reasoning RL只有在规则确实无法覆盖质量维度比如对话体验时才动用RLHF。很多团队卡在总觉得要上RLHF才算完整其实是对自己任务的客观性判断出了问题。6. 一些容易被忽略的基建问题和解决经验Reasoning RL真正的工程门槛不是算法理论而是基础设施。这部分踩过的坑值得单独拎出来说。6.1 奖励计算的高昂代价不该被低估规则奖励虽然不需要训练奖励模型但如果验证器写得啰嗦它依然会成为训练瓶颈。最严重的情况是验证器里用了大模型做裁判LLM-as-a-Judge这会引入两个问题一是推理阶段极其耗时二是评委模型本身的噪声会直接嵌入奖励信号。我见过一个小团队在数学推理任务里用GPT-4o做奖励评判每组16个样本的奖励计算居然需要额外的数千token调用训练成本瞬间翻倍而且奖励分布不够锐利模型收敛速度反而下降。更务实的做法是能用字符串匹配解决的问题绝不上LLM裁判必须LLM裁判的地方也要提前评估这个任务是否真的没有客观判据。如果只是懒成本会让你怀疑人生。6.2 多机训练时的通信模式GRPO减少了一个模型但数据并行带来的all-gather通信成本依然存在。尤其是生成阶段每个rank都为同一批prompt采样G个输出如果G不能被DP大小整除会出现明显的负载不均。我的做法是提前算好prompt数量×G % DP_size必须为0如果除不尽就补齐dummy样本训练结束后丢弃。虽然有点浪费显存但避免了每step的同步等待时间。6.3 中间checkpoint的保留策略Reasoning RL的一个特点是不确定性高即使训练曲线很漂亮也可能存在某个隐藏的奖励黑客在后期突然爆发。所以我的习惯是每隔50步保留一个adapter权重不合并进主模型。这个习惯曾经救过我一次——某个实验在1000步时发现奖励函数有严重bug我直接回滚到700步的checkpoint重新调整避免了从头再来。评估管线里还会挂一个简化版基线模型比如不做RL的原版SFT模型做对照每100步同时评测两者的指标差这个方法能快速发现RL到底在干什么。我个人角色理解是Reasoning RL不是RLHF的进化而是强化学习在大语言模型上的另一种更激进的形态。它把对齐目标从人觉得好推到任务客观正确让算法在更清晰的信号下高效优化。如果让我给后来者一句话的建议先拿一个数学题或代码题的小数据集跑通GRPO全链路把奖励函数、数据清洗、评测闭环建好再决定要不要大规模铺开。RLHF教会了模型说话得体而Reasoning RL教的是把事做对两者都值得掌握但能掌握的原因和成本完全不同。