1. LLM强化学习为什么突然从RLHF转向了Reasoning RL

过去两年训练大模型的圈子里，有一个非常明显的变化：2023年我们在大量讨论RLHF、PPO、奖励模型过优化，2024年初大家还在为RLHF的成本和稳定性头疼，到了2025年，几乎所有做推理模型的团队都在聊GRPO、规则奖励、可验证奖励，也就是大家常说的Reasoning RL。

这种转变不是某个团队灵光一闪，而是整个LLM强化学习技术栈在被现实狠狠教育过之后，做出的务实选择。

先说清楚一个概念：RLHF（Reinforcement Learning from Human Feedback）和Reasoning RL（面向推理能力的强化学习）本质上是同一套强化学习范式在不同目标下的应用。区别在于，RLHF用人类偏好数据训练一个奖励模型来代理人类判断，而Reasoning RL直接用手写的、可验证的规则去评分，比如数学题答案对不对、代码能否通过测试、SQL查询结果是否符合预期。

早期GPT-4、Claude这类通用对话模型之所以必须用RLHF，是因为"这段回答是否令人满意"没有一个客观标准。你觉得回答态度好、结构清晰、信息密度高，我觉得啰嗦、避重就轻，谁对？只能让人类打分，或者训练一个模拟人类打分的奖励模型。

但到了数学推理、代码生成这类任务，事情发生了变化：一道AIME数学题的最终答案就是某个整数，一个LeetCode题目的解法要么通过全部测试用例要么不通过。这种场景下再花钱雇人去标注偏好、训练奖励模型，不仅浪费，而且会引入大量噪声。

我记得有个实际案例特别能说明问题：某团队做数学推理对齐，用RLHF训了一版，奖励模型认为"过程详细、步骤完整"的答案分数高，结果模型学会了把简单题目拆成一百多个步骤，每一步都写"Let's think step by step"，答案对了但推理链又臭又长。换成规则奖励只检查最终答案对错之后，模型立刻开始寻找简洁高效的解法路径。

这就是Reasoning RL崛起的最核心动机：当任务本身有客观正确性判据时，基于规则的奖励函数远比学习出来的奖励模型可靠。

另一个隐藏原因是训练稳定性。RLHF的PPO算法需要同时维护四个模型：Actor（策略模型）、Critic（价值模型）、Reward Model（奖励模型）、Reference Model（参考模型）。其中Critic的预测误差非常大，尤其在奖励模型本身就在不断变化的时候，价值网络经常学不稳，导致策略更新噪声大、训练曲线剧烈震荡。而Reasoning RL主流的GRPO算法直接把Critic干掉了，用组内采样的相对优势替代价值估计，训练开销和稳定性同时得到改善。

顺带一提，现在圈子里讨论LLM训练时，很多人会提到Karpathy维护的llm wiki知识库，里面把RLHF和RLVR（Reinforcement Learning with Verifiable Rewards）的发展脉络梳理得比较清楚。如果你刚开始接触这个领域，我建议把它当目录来用，先建立宏观认知再去读论文细节。

2. 从PPO到GRPO：四个模型变三个模型，反而更稳了

要理解Reasoning RL为什么能行，必须先理解PPO在RLHF阶段到底是怎么工作的、又痛在哪里。

2.1 PPO的四模型博弈和KL护栏

PPO（Proximal 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为什么敢砍掉Critic

DeepSeek在GRPO（Group Relative Policy Optimization）论文里做了一个非常大胆的简化：不要价值网络，用同一prompt下采样出的多个输出的相对优劣来估计优势函数。

具体做法是这样的：

1. 针对同一个prompt，从当前策略中采样G个输出（论文里通常G=8、16或32）
2. 用规则奖励函数给每个输出打分
3. 在组内对这些得分做归一化，得到每个输出的优势值
4. 用归一化后的优势值作为权重，执行带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模型在目标任务的pass@k上已经有一定基础。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做Pass@K离线评测，建立"奖励"与"真实指标"之间的回归关系。一旦发现两者背离，立刻停止训练检查奖励设计。
• 不要迷信单一规则奖励。工程上可以同时启用多个验证器，比如数学题用答案校验加抽查步间逻辑；代码任务用单测通过率加静态检查基础风格。

4. 实践踩坑记录：我的Reasoning RL训练全流程拆解

理论说了很多，接下来分享一次完整的实际训练过程。这个项目是一个帮助开发者自动推理LeetCode题目的场景化模型，基础模型选了Qwen2.5-14B，训练目标是提升模型在代码推理链上的质量。

4.1 数据准备比你想的更占时间

GRPO对提示词分布非常敏感。我第一轮实验直接用了竞赛数学题数据，结果发现采样输出里经常包含代码块残留、英文模板、非标准Unicode字符，奖励解析器在解析答案时常因字符编码报错。

后来数据处理加了三个步骤才稳定下来：

• 把提示词统一成"问题描述+要求格式+示例模板"的三段式结构，减少prompt格式变化带来的采样分布偏移
• 对输出文本做标准化清洗：全角转半角、LaTeX命令转换、去BOS/EOS token噪声
• 对答案进行多重格式解析（纯文本比较、数值比较、集合比较），至少三种解析器投票一致才给分

这一步大约花了一周，但它是我认为整个项目中最值得投入的时间。奖励函数写得再精细，如果解析环节不稳定，一切都是空中楼阁。

4.2 GRPO训练的超参数基线

我用HuggingFace的RL训练框架调通了整套流程，关键超参数如下：

采样组大小 G=16 Clip范围 epsilon=0.2 KL惩罚系数 beta=0.04 学习率 5e-6，使用线性warmup和cosine decay 每步生成max_token_len=2048 批次大小（按prompt数）8，累计梯度更新步数相当于batch=32 训练步数 1200，全程大约消耗8000张H100卡时

这里特别要提醒KL惩罚系数。GRPO虽然不像PPO那么依赖参考模型，但完全不设KL约束会让模型快速偏离SFT语义底座，表现为输出中频繁出现重复片段和格式混乱。0.04是我在这类任务上调出来比较平衡的值：太高策略更新幅度太小，训练效率低；太低模型会逐渐"说胡话"。

4.3 采样组数与显存的博弈

我做过一个简单实验，把组大小从16降到8，训练速度提升了约35%，但最终Pass@1指标下降了约4个百分点。这说明组内多样性对优势估计至关重要——组越小，相对排序越容易受偶然高分影响，策略更新方向噪声越大。

在8张80GB H100上，14B模型配G=16"正好卡在临界点"，生成阶段不需要梯度所以可以开大batch，更新阶段需要反向传播所以要缩小batch。优化的做法是把生成和训练解耦：先用当前策略离线批量采样大量的response组，存到磁盘队列，然后再用这些固定数据做策略更新。这样生成阶段可以拉满吞吐，更新阶段就有干净的数据批次。

4.4 奖励曲线的"三阶段"形态

GRPO训练的reward曲线通常不是一路向上的，而是经历三个阶段：

• 第一阶段（0到200步）：格式分率先上升，模型快速学会"按规则输出答案结构"，整体奖励曲线陡峭上涨
• 第二阶段（200到600步）：答案正确率开始波动上升，但奖励曲线的锯齿明显加大，这是因为模型开始尝试更复杂的推理路径，偶发失败增多
• 第三阶段（600步以后）：收敛放缓，如果奖励设计合理，正确率平稳提升；如果奖励设计有漏洞，进入奖励黑客模式，奖励持续上涨但真实指标平台化甚至下降

我当时在第三阶段发现reward和eval指标背离，排查后发现是解析器对"answer is (\d+)"这种格式的检查有bug，当数字位数超过6位时经常解析失败导致误判。修掉之后重新跑了约200步，模型指标恢复正常。

结论：这个阶段一定要建立独立的、不参与训练的评测管线，每个checkpoint跑一遍固定测试集。我连的评测集只有100道题，但每步都要计算P@1和P@8，这比任何训练曲线可视化工具都有说服力。

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在某些数学评测集上的Pass@1提升可达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教的是"把事做对"，两者都值得掌握，但能掌握的原因和成本完全不同。