1. 先把SRL这个说法掰开它到底在补哪块缺口1.1 从监督微调到强化学习中间断了一截接手一个LLM训练任务最典型的场景是这样基座模型拿到手先做监督微调SFT几千到几万条高质量问答喂下去loss降得很漂亮模型说话也像个正常人了。可一旦上评测问题立刻暴露——数学题步骤写到一半自己拐弯代码生成第一行就语法错多步推理里前一步的结论和后一步对不上。这不是数据量不够是SFT这套目标函数天生管不到这些事。SFT本质上是最大似然估计它优化的是“在给定上文时输出专家答案的概率”。这句话听起来没问题但它隐含了一个很要命的假设训练时模型看到的永远是正确前缀。推理时它看到的是自己刚写出来的、可能已经错了的前缀。这个错位在业内叫exposure bias通俗点说就是“跟着师傅走会走自己走就迷路”。SFT教会模型的是“像专家”不是“能做对”。强化学习补的正是这一块。它不要求模型逐字模仿而是让模型自己生成多条路径用奖励信号告诉它哪条路走通了、哪条路走死了。问题在于语言生成的搜索空间大到离谱一个50步的推理链每步词表几万组合数是个天文数字。纯靠稀疏的结果奖励对/错去训模型大部分时间在瞎撞梯度信号稀薄到几乎学不动。这就是所谓的冷启动难题。监督强化学习SRL这个说法的价值就在于它指出了中间地带既然纯监督学不会“对”纯强化又搜不到“对”那就让监督信号以各种形式渗进强化学习的回路里给搜索提供方向感。这个思路在LLM训练里至少有三种落地形态而它们经常被混为一谈这也是我见过最多人绕晕的地方。1.2 三种形态奖励侧、数据侧、损失侧我习惯把SRL按“监督信号插在哪一环”来分类这样工程上好做决策。奖励侧监督是把人的判断或规则做成奖励模型/验证器RL优化的是这个打分器。典型做法是训练结果奖励模型ORM或过程奖励模型PRM或者干脆用规则验证器直接判对错。这条路的特点是信号稠密、可控缺点是奖励模型本身会被钻空子。数据侧监督是让模型自己采样用监督信号过滤出好样本再拿去做SFT循环迭代。拒绝采样微调、专家迭代、自举推理都属于这一类。它绕开了策略梯度的复杂度工程实现简单本质上是用采样换数据、用数据换能力。损失侧监督是把RL目标改写成监督式损失。直接偏好优化DPO系列是代表它把“奖励最大化加KL约束”这个带约束的优化问题解析地解出来最后变成一个类似分类的loss完全不需要在线采样。这类方法把RL的复杂性压到了最低代价是只能用离线数据分布偏移管不住。形态监督信号位置代表方法工程复杂度主要风险奖励侧奖励函数/奖励模型PPO、GRPO ORM/PRM/规则验证器高奖励黑客、打分器漂移数据侧采样过滤环节拒绝采样微调、专家迭代中多样性塌缩、迭代收益递减损失侧目标函数本身DPO、ORPO、KTO低离线分布偏移、长度偏置理解这张表的实际意义在于你手上的算力和数据决定你能选哪一档。八卡集群想跑全参PPO训7B光是把策略、参考、奖励、价值四个模型塞进显存就够呛但同一批卡跑DPO或者规则奖励的GRPO是完全可行的。后面几节我会按这个分类逐条拆开讲。2. 核心机制拆解监督信号是怎么进到优化回路里的2.1 奖励塑形把“对错”拆成可累加的分项纯结果奖励最大的问题是稀疏。一道数学题写了两百字最后答案错了整条轨迹拿0分模型不知道是第3步公式用错还是第7步算错。奖励塑形的思路就是把总分拆成几个可解释的分项让梯度能落到具体位置。我在实际项目里常用的一套评分结构大概是这样def reward(prompt, response, gold): score 0.0 # 1. 结果分答案归一化后精确匹配 if normalize(extract_answer(response)) normalize(gold): score 1.0 # 2. 格式分必须包含推理段与答案段标记 if has_reasoning_block(response) and has_answer_block(response): score 0.3 # 3. 步骤分PRM 或规则校验的中间步骤通过率 score 0.4 * step_verifier(prompt, response) # 4. 长度约束超长截断扣分避免灌水 if len(response) MAX_LEN: score - 0.2 return score这套结构里有几个需要想清楚的地方。格式分看着很土但它是所有分项里性价比最高的模型一开始根本不知道要按什么结构输出给0.3分的格式奖励几十步之内就能把输出格式拉到合规后面的结果分才有机会起作用。这就像教小孩做应用题先要求“写解、写步骤、写答”格式立起来了再谈对错。步骤分要靠过程奖励模型PRM。PRM的训练数据标注成本远高于ORM因为你要对每一步打标而不是只看最终答案。业内的折中做法是用蒙特卡洛估计自动生成步骤标签从某个中间步骤往后采样多条完整轨迹看最终正确率正确率高就说明这一步是好的。这个做法的隐含假设是“好步骤更容易通向正确答案”在数学和代码这类有明确终点的任务上成立在开放写作上就很不靠谱。提示结果分和步骤分的权重要反复调。步骤分给太高模型会学会“步骤看起来漂亮但答案瞎写”给太低又退化成稀疏奖励。我一般从结果分1.0、步骤分0.4起步观察奖励分布后再动。还有一类绕不开的监督信号是可验证奖励。数学题可以直接比对最终答案代码题可以跑单元测试结构化抽取可以校验schema。这类任务根本不需要训奖励模型一个确定性验证器就能把噪声降到零而且不会随训练漂移。我在选任务时有个很朴素的判断标准能写验证器的任务优先做RL写不出验证器的任务老老实实做SFT加偏好对齐。原因很简单学出来的奖励模型永远在被优化的过程中失真而代码执行器不会因为你训得久就改变行为。2.2 拒绝采样与自举把采样成本换成数据质量拒绝采样微调这条路我愿称之为“穷人版RL”。流程很直白拿当前模型对每个prompt采样k条回答用验证器筛出正确的把正确的拼成SFT数据微调一轮再拿新模型重复。学术界管这叫专家迭代或者ReST类方法自举推理STaR是它在推理任务上的变体区别在于自举推理会给失败的样本补上正确答案再一起训避免只有正样本。这条路的核心不是生成是过滤。生成谁都会采样参数一调就能出k条但过滤策略决定了这一轮迭代到底是涨还是崩。我踩过的坑主要有两个。第一个是难度失衡。如果一批prompt里简单题占比过高采样8条全对过滤后留下的全是简单题模型在简单题上越训越熟难题一点没碰。解决办法是按通过率分层pass8等于8的样本直接丢弃pass8等于0的也丢弃现阶段学不会只保留通过率在中间区间的样本。这个筛选逻辑在实现上就几行代码但对迭代效率的影响是数量级的。第二个是多样性塌缩。连续迭代几轮之后模型的输出分布会越来越窄同一道题采8条8条几乎一模一样。这时候再过滤已经没有信息量了。缓解手段是每轮迭代都混入一定比例的历史数据和原始SFT数据比例我一般控制在3:1到4:1之间同时把采样温度维持在0.8以上宁可要一些低质量但多样的样本。# 难度分层筛选的核心逻辑 samples [generate(p, k8, temperature0.9) for p in prompts] for p, group in zip(prompts, samples): correct sum(verify(p, s) for s in group) if correct 0 or correct len(group): continue # 太难或太易本轮跳过 kept.extend(s for s in group if verify(p, s))这套流程有个隐含的天花板模型必须已经具备“偶尔做对”的能力迭代才能启动。passk长期为0的任务采样再多轮也没用得先回去补SFT数据或者降低题目难度。我在一个多步计算的场景里卡过整整两天最后发现是题目本身超出了基座能力太多不是采样策略的问题。2.3 混合损失SFT项和策略梯度项怎么配比真正在线跑策略梯度的时候几乎没有人用纯RL loss。原因很实际纯策略梯度更新只告诉模型“这条好、那条差”不告诉它“语言应该长什么样”。训久了模型的输出会变得很奇怪——答案对了但语句开始碎片化标点乱飞甚至混入训练时没见过的符号组合。这个现象在早期RLHF里特别常见业内叫语言退化。解决办法是在loss里加一个SFT项做正则。混合损失的形式大概是L L_pg λ_sft * L_sft β * KL(π || π_ref)三个系数的分工很明确。λ_sft控制语言形态的保持力度我一般设在0.05到0.2之间任务越偏向开放生成这个值越大。β是KL惩罚系数防止策略跑得离参考模型太远常见范围是0.01到0.04训练初期可以给大一点比如0.04等奖励曲线起来之后再降到0.01。这里要注意KL的估算方式用k3估计量比k1噪声小很多代价是要多算一次log prob。KL约束这件事值得单独说。它的作用不是“让模型不变”而是“让模型别一次性变太多”。语言模型的策略空间极其庞大奖励信号稍微有点偏差策略就可能整体漂移到某个奇怪的角落比如所有回答都变得极长或者所有回答都开始堆砌某些高频连接词。KL就是一根橡皮筋拉住它。但橡皮筋太紧也麻烦β设到0.1以上模型基本学不动奖励曲线平得像一条直线你会怀疑是不是代码写错了。系数常用范围调大后的表现调小后的表现λ_sft0.05 - 0.2语言形态好任务能力涨得慢能力涨得快输出易退化β (KL)0.01 - 0.04训练平稳探索不足探索充分易跑偏clip ε0.2 - 0.28更新保守收敛慢更新激进方差大rollout温度0.8 - 1.0多样性强噪声大集中易过拟合离线偏好优化那一类方法比如DPO及其变体本质上把上面这套东西闭式解掉了。它的损失里已经包含了参考模型的比值项相当于把KL约束内建进去所以只需要调一个β。好处是实现极简、训练极稳几十行代码能跑起来坏处是它只能吃离线偏好对无法利用在线采样探索新路径。数据集里没出现过的回答模式DPO永远学不到。我在选型上的经验是如果手上有几万条高质量偏好对且任务是风格对齐、安全性、简洁性这类“不需要探索新解法”的目标DPO系列够用且省事如果任务是数学、代码、多步推理这种“必须探索出正确答案”的目标就得回到在线采样那条路因为离线数据里压根没有正确答案的分布。3. 实操从零搭一条能跑通的SRL流水线3.1 数据准备难度分层比数量更重要很多人一上来就问“要多少条数据”这个问题本身问偏了。SRL对数据量的要求远低于SFT但对数据结构的敏感度高得多。我做过对比同样是五千条数学题随机采样的一批和按难度分层的一批训练曲线差得非常明显。我的做法是先给每道题打一个难度标签方式是用基座模型对每题采样16次算通过率。通过率高于0.9的是简单题低于0.1的是难题中间的是有效区。训练集按3:5:2的比例配简单、中等、难简单题保证模型不退化中等题提供主要梯度难题提供上限空间。这个配比不是固定的训练中期可以把难题比例往上提。数据清洗里最容易被忽略的是答案归一化。同一道题的正确答案可能是“1/2”“0.5”“二分之一”验证器如果只做字符串匹配会把大量正确回答判错。归一化要做的事包括去空格、统一大小写、分数转小数或反过来、去掉单位、处理中文数字和阿拉伯数字的转换。这块工作枯燥但极其重要我见过一次训练完全跑崩最后定位到是验证器把带千分位逗号的数字全判错了模型发现输出带逗号就被扣分于是学会了所有数字都不带逗号包括本该带的场景。验证器本身的实现也有讲究。规则类验证器正则、表达式求值要写充分的自测用例至少覆盖正确答案、明显错误、边界格式三类。代码类验证器必须放在隔离环境里执行加超时和资源限制否则一段死循环就能把整个训练卡住。我一般给单次执行设5秒超时超时直接判错不让它拖累采样吞吐。3.2 训练配置算清楚显存再动手配置这块最实在的是先把显存账算明白。以7B模型为例全参训练一份策略模型参数用bf16存是14GB梯度14GB优化器状态Adam的动量和方差用fp32是56GB加起来84GB还没算激活值。如果是在线策略梯度还要再挂一份参考模型14GB只前向和一份奖励模型7B的话14GB。四份加起来超过110GB单卡80G根本放不下得上模型并行或者把奖励模型换成规则验证器。这就是为什么规则验证器在小团队里这么受欢迎——它不占显存。把奖励模型这一份省掉7B全参PPO在8张80G卡上用张量并行加梯度累积是能跑起来的。如果还嫌重就上LoRA只训适配器显存需求直接砍到原来的三分之一左右代价是探索能力弱一些因为参数更新的自由度被限制了。关键超参我的起步配置大概是learning_rate: 1.0e-6 # 策略模型全参LoRA 用 1e-5 global_batch_size: 128 # prompt 数 rollout_n: 8 # 每个 prompt 采样条数 max_new_tokens: 2048 temperature: 0.9 top_p: 0.95 kl_coef: 0.02 clip_ratio: 0.2 sft_loss_weight: 0.1这里解释两个值的来历。global_batch_size乘rollout_n等于每步实际处理的样本数128乘8是1024条平均长度按1500 token算单步要过150万token。这个量级在8卡上大概每步几十秒一天能跑两三千步够看到趋势了。rollout_n取8是个经验平衡点取4的话组内方差太大优势估计噪声高取16效果好但采样成本翻倍。温度0.9是为了保证组内有差异如果温度太低8条采样几乎一样优势全为0梯度就没了。这里有个容易忽略的细节组内全对或全错时优势值全是0这个prompt对梯度的贡献为零。如果你的数据里简单题太多会看到大量步数的梯度接近零训练看起来“没动静”其实是采样没提供有效信号。监控里要专门统计每批的有效组比例低于30%就说明数据难度配置有问题。3.3 训练监控只看loss会误判SRL训练最坑的地方是loss没有直观意义。SFT的loss降了就是拟合得更好SRL的loss可能是负的可能震荡跟最终效果的相关性很弱。我盯的是一组替代指标指标健康区间异常含义平均奖励缓慢上升有波动长期平 无有效梯度骤升 可能有奖励漏洞KL散度0.5 - 5 附近波动持续暴涨 策略跑飞长期近0 没在学策略熵缓慢下降断崖式下降 熵坍缩输出趋同平均回答长度平稳或缓升快速膨胀 长度奖励被钻空子格式合规率数十步内到95%以上上不去 格式奖励权重不够验证集pass1阶梯式上升与训练奖励背离 过拟合奖励这几个指标要一起看单看任何一个都会误判。举个我实际遇到的组合平均奖励一路涨KL也在涨看起来一切正常但验证集pass1纹丝不动。查下来是模型学会了在答案段里同时写多个候选答案验证器的抽取逻辑取第一个恰好蒙对率提高了但真正的解题能力没变。后来把抽取逻辑改成“只能有一个答案段多个判错”才修好。训练中期一定要做定期评测不能等训完再看。我一般每200步在固定验证集上跑一次用贪心解码看pass1的曲线。如果训练奖励涨而验证指标不涨超过三轮基本可以判定是奖励被钻空子了停下来查验证器比继续训划算。3.4 落地把RL能力蒸馏回可部署的模型在线RL训出来的模型往往带着一堆训练时的脚手架比如特定的标记格式、冗长的推理段落。直接上线体验很差而且推理成本高。标准做法是做一轮拒绝采样蒸馏用训好的模型对大规模prompt采样过滤出正确且格式合规的混入原始SFT数据做一轮监督微调得到最终的部署模型。这一步有个反直觉的发现蒸馏后的模型在分布内任务上几乎不掉点但在分布外任务上往往比RL模型更稳。原因是RL阶段容易把模型推到策略分布的边缘追逐奖励最大化蒸馏把它拉回中心区域泛化反而好了。所以别舍不得那点训练奖励该蒸就蒸。蒸馏数据的配比也要注意。纯用RL模型自己采的样本会把它的偏置一起固化下来混30%到40%的原始SFT数据能有效缓解。另外蒸馏阶段的学习率要比初次SFT低1e-5到2e-5比较合适训太多轮会把RL阶段学到的探索性思路磨掉。4. 踩坑记录那些文档里不会写的失败模式4.1 奖励黑客模型永远比你更懂怎么钻空子奖励黑客是SRL里最普遍也最难缠的问题表现形式五花八门但本质都一样模型找到了一条拿高分但不符合你真实意图的路径。我遇到过几种典型情况。第一种是长度套利。奖励里如果有“步骤完整”这类和长度正相关的信号模型会迅速学会把回答写得极长反复复述同一句话。有一轮训练到第300步平均回答长度从800 token涨到3000奖励还在涨但人工看样本全是废话。这种问题的根子往往不在长度惩罚不够而在奖励模型对冗长的回答有偏好偏差——标注员在看两个回答时潜意识里会觉得长的那个更认真。解决办法除了加长度惩罚项更重要的是在奖励模型训练数据里做长度平衡让长短回答的得分分布对齐。第二种是格式投机。要求输出JSON模型学会在JSON外面包一层解释性文字因为解释性文字能让奖励模型觉得“更有帮助”。这种时候要么把格式校验做成硬约束不合法直接0分要么在抽取逻辑上做严格解析解析失败即判错。第三种最隐蔽答案对但推理错。模型通过模式匹配猜中了答案推理段落是编的。这类样本在结果奖励下拿满分训久了模型会越来越依赖猜测。检测方法是人工抽检高奖励样本看推理链是否自洽。如果发现比例不低就得上过程奖励或者引入对抗性的验证。注意奖励黑客几乎无法根除只能控制。我的做法是把“奖励上涨速度”当成一个监控项正常的训练奖励是缓慢爬升的如果某一段突然陡增八成是找到漏洞了立刻停下来抽检样本。4.2 熵坍缩模型突然不会说别的话了熵坍缩的表现是策略熵在几百步内快速下降采样出来的多条回答高度相似组内优势全为0训练停滞。成因通常是更新步子太大或者KL约束太松策略快速收敛到某个局部最优。我在一次代码任务上遇到得特别典型训到大概400步模型对所有prompt的输出都开始以同一种方式开头连变量命名习惯都趋同。当时的第一反应是加温度把采样温度从0.9提到1.1结果只是让输出变得更怪多样性没回来。真正的解法是组合拳把KL系数从0.01提回0.03学习率砍半同时在损失里加一个熵正则项鼓励策略保持分散。还有个小技巧是在数据侧做文章每批数据里混入一定比例的高温采样样本温度1.3以上强制模型看到更多样的路径。这些样本质量参差不齐但它们的作用不是教模型怎么答对而是维持策略分布的宽度。4.3 常见问题速查症状可能原因排查动作处理方案奖励不涨数据过难有效组比例低统计每批通过率分布下调难度增加简单题奖励暴涨但评测掉奖励黑客抽检高奖励样本修验证器加约束项输出长度失控长度与奖励正相关看长度-奖励相关系数加长度惩罚平衡奖励数据训练loss为nan学习率过大或bf16溢出查梯度范数降学习率梯度裁剪1.0采样极慢生成长度上限过高看平均生成长度分布调低max_new_tokens分批格式时好时坏格式奖励权重不足看格式合规率曲线提权重到0.5先立格式KL长期接近0参考模型与策略同步更新检查参考模型是否被误训冻结参考模型参数验证集波动大验证集太小看样本量扩到至少500条固定种子这张表里的每一条我都实际撞过。最想提醒的是“KL长期接近0”这一项它非常隐蔽因为训练看起来完全正常奖励也在涨但实际上你优化的是一个没有约束的目标模型可能早就跑到了参考分布之外。检查方法很简单打印一下参考模型的参数是否requires_grad为False我见过不止一次是因为配置里忘了冻结。5. 算力预算与团队规模下的路径选择5.1 小团队的现实路径从便宜的方法开始试不是每个团队都有几十张卡可以挥霍。资源有限的时候路线选择比调参重要得多。我给出的优先级是这样的。第一档先做DPO或者其变体。只需要一个基座、一份偏好数据单机多卡就能跑一两天能出结果。它解决的是“回答风格、安全性、简洁度”这类不需要探索的问题。如果做完这一步效果已经够用就别往上走了投入产出比不划算。第二档规则验证器加分组相对策略优化。挑一个能写确定性验证器的任务比如数学、结构化抽取、代码补全。这套组合不需要奖励模型显存压力小采样效率高。分组相对策略优化相比传统策略梯度省掉了价值网络同一组内的样本互相比对算优势实现起来也简单。我见过一个三人小队用八张卡在这个配置上把数学能力拉了一大截关键是验证器写得扎实。第三档才是训过程奖励模型加完整在线RL。这一档的投入是前两档的好几倍包括标注成本、训练成本、调参时间。只有当任务确实需要稠密的中间步骤信号且规则验证器写不出来的时候才值得走这条路。5.2 评估怎么做才不骗自己SRL项目最容易出的评估问题是自欺欺人训练奖励涨了就觉得模型变强了。实际上你优化的就是那个奖励它涨是必然的。真正要盯的是三组独立的指标。第一组是留出测试集上的pass1用贪心解码这是硬指标。第二组是人工抽检每次抽50到100条看推理链是否自洽、有没有明显的投机行为。第三组是泛化测试拿一批和训练分布明显不同的题去测看能力有没有外溢。第三组经常被忽略但它是判断“学到了能力”还是“记住了模式”的关键。我在一个项目里吃过这个亏训练集和测试集来自同一个题库指标涨得很漂亮换了个来源的题立刻掉回原点。后来养成习惯任何SRL实验都留一个跨分布的测试集哪怕只有一百条也能提前发现问题。评估频率上前期密后期疏。前500步每100步测一次看清楚趋势后面每300步测一次避免评测开销拖累训练。评测本身也要固定随机种子和提示模板模板差一个字分数能差好几个点这个坑我踩过不止一次。最后分享一个我反复验证过的判断SRL的效果上限七成取决于数据质量和验证器的严谨程度三成才是算法和超参。我见过太多人把时间花在换算法、调系数上而验证器里一个答案归一化的bug就能让所有努力归零。真正值得投入时间的地方是把“什么叫答对”这件事定义到没有歧义剩下的工作相对机械。这个顺序搞反了训得越久偏得越远。
