SFT与RL：把大模型从“复读机”调教成“会看脸色”

最近跟几个做模型训练的朋友聊到一个特别形象的说法SFT 把模型训成了复读机RL 再教它怎么“看脸色”。仔细一想这句话几乎把大模型对齐Alignment的核心矛盾说透了——SFT监督微调负责让模型“会说话”但会说话不等于会好好说话RL强化学习则负责让模型学会“根据反馈调整输出”也就是看人脸色办事。这篇内容适合正在做大模型微调、RLHF或者只是好奇“为什么 ChatGPT 这类模型有时候那么会来事儿”的读者。先说明白这不是一篇教科书式的原理推导而是我结合自己做 SFT、偏好数据标注和 RLHF 调参的经验把这条技术链路里“为什么”“怎么做”“会踩什么坑”一次讲清楚。1. SFT 是怎么一步步把模型“训练成复读机”的1.1 “复读机”症状SFT 训练目标里的先天缺陷SFT 的本质是最大似然估计。给定一堆精心整理好的“问题-标准答案”对模型要学着把标准答案的每个 token 逐个预测出来loss 用交叉熵。交叉熵只关心一件事模型输出分布跟标准答案的分布有多接近。换句话说SFT 唯一的目标是“让我输出的句子长得像训练数据里的标准答案”。这个目标听起来没毛病但问题就藏在“标准答案”四个字里。训练数据是人工整理或者从某类语料里筛出来的它天然带有标注者的写作风格、礼貌用语习惯、甚至情绪倾向。模型不傻它会把这些风格层面的统计规律也一并学进去。举个例子如果你的 SFT 数据里一千条客服回复都以“非常抱歉给您带来不便”开头那模型很快就会发现遇到投诉类问题只要带上这句话loss 就能降得很低。于是它开始疯狂复用这个模板。这就是“复读机”的第一个来源模型在学“腔调”而不是学“解决问题”。1.2 交叉熵与最大似然为什么模型只会模仿不会判断“只会模仿不会判断”这句话得从数据分布说起。SFT 数据是静态的模型训练时看到的每条样本都是“已经确定的最优解”。但真实世界里同一个问题可能有多种合理的回答方式而且是否合理取决于上下文、用户身份、甚至当时的对话情绪。你不可能在 SFT 数据里穷尽所有场景。一旦模型遇到分布外的输入它最稳妥的策略就是回忆训练数据里跟当前输入最像的样本然后套用那条回答的句式。我在实际微调中遇到过很典型的案例模型在客服场景下被问“你们的退款政策是什么”它能给出标准流程但用户换一种说法“我东西坏了你们管不管”模型还在背退款政策完全不回应“坏了能不能换”这个具体问题。原因很简单SFT 数据里“退款政策”相关内容足够多但“商品损坏处理”的内容太少。模型的判断系统根本没建立起来因为它没有被训练“要根据用户意图动态调整回答”只需要输出训练数据里的标准话术。更麻烦的是SFT 的 loss 是 token 级别的模型只要把下一个词猜对了就行。它看不到“这句回答用户是否满意”也看不到“这句回答是否真正解决了问题”。用行话说SFT 优化的是一个可微却不含用户反馈的目标它像一个守着标准答案背书的考生你问他为什么这样答题他会说“因为标准答案就是这么写的。”1.3 复读机的三个典型翻车现场根据我这几年观察到的现象SFT 之后的模型如果直接上线复读机症状通常有三种表现腔调单一适配性差模型只会用一种语气回答所有问题。知乎上常见的“首先我们需要明确概念……”式回答就是模型学会了学术腔面对日常闲聊也在掉书袋。忽略上下文答非所问用户明显在表达不满情绪模型还在机械地列举标准流程完全不先共情结果用户火气更大。极度自信来回重复模型生成的内容翻来覆去就是同一个意思缺乏多角度分析因为它学到的是“标准答案通常只有一种写法”。这三种表现本质上是同一个问题模型在模仿数据的边缘分布而不是理解任务的深层目标。SFT 能给你一个“满嘴正确废话”的模型但它给不了你“一个知道什么时候该说什么话”的模型。后面那句得靠 RL 来完成。2. 先搞懂“看脸色”到底在学什么RLHF 的整体思路2.1 “看脸色”的技术本质从模仿到偏好优化所谓“看脸色”放在技术语境里就是让模型学会根据人类偏好调整自己的行为。人类偏好是一个极度复杂的函数用户喜欢简洁有礼貌的回答讨厌啰嗦喜欢直接解决问题讨厌踢皮球喜欢有逻辑讨厌车轱辘话。这些偏好很难用规则写清楚但人类自己却可以非常直觉地判断“哪条回答更好”。RLHF基于人类反馈的强化学习就是干这个的。它的整体思路分三步先收集人类对模型回答的偏好数据训练一个奖励模型Reward Model简称 RM再用强化学习算法通常是 PPO让模型在“争取高分”的过程中自我调整。模型不再只盯着“这句话像不像训练数据”而是盯着“这句话能不能在人这里获得更高评分”。打个比方SFT 像让实习生抄优秀员工的工作笔记抄得越像得分越高RL 是让实习生直接坐在客户面前根据客户的微表情和反馈随时调整话术。抄笔记只能学会记录里有的东西面对客户却要处理无穷多的新情况这就是“看脸色”的用武之地。2.2 奖励模型RM谁来定义“脸色好不好看”在 RLHF 链路里“脸色”是由奖励模型定义的。RM 的输入是一段 prompt 和模型给出的回答输出是一个标量分数分数越高代表“人类越喜欢”。训练 RM 需要的数据不是“标准答案”而是偏好排序。常见做法是让同一个 prompt 生成多个回答让标注者排序或者两两比较“哪个更好”。为什么用排序而不是打分因为人在判断“哪个更好”时远比打分稳定。你说“这条回答比那条更贴心”很容易但让你给两条回答分别打 7 分和 8 分不同人之间的标准波动会很大。排序数据天然抗噪。RM 的训练目标通常用的是 Bradley-Terry 模型核心思想是被人类排在前面的回答得分应该更高。训练完成后RM 就变成一个“口味鉴定器”在后续 PPO 阶段充当裁判角色。但这里有个非常容易被忽视的问题RM 也是从有限数据里训练出来的它的“脸色”并不完全等同于真实人类用户的脸色。这个矛盾会在后面“奖励黑客”部分彻底暴露。2.3 为什么非用 RL 不可SFT 学不来的目标函数很多人问过一个问题既然我已经有了 RM 打分那能不能把 RM 分数加权到 SFT 的 loss 里继续训练答案是很难而且效果通常不好。因为 RM 分数是一个整体性的、非可微的评估结果它不能直接告诉我们“这一段话里哪个词导致分数降低了”。SFT 的交叉熵可以对单个 token 求梯度但“用户是否满意”这种反馈是延迟的、宏观的它要在模型生成完整回答之后才能被评估。这正好是强化学习的标准场景优化一个不能直接求梯度、只能通过采样来估计回报的目标。RL 让模型不只是模仿而是主动试错。它先尝试生成一个回答让 RM 打分然后通过策略梯度方法调整模型参数让“高分回答”的出现概率上升。这个过程里模型逐渐理解“原来我不需要每句话都像训练数据我只需要让结果更符合人类偏好”。这就是 SFT 做不到的第二件事从结果倒推原因而不是从数据死记答案。3. RLHF 实操过程从偏好数据到 PPO 调参3.1 第一步偏好数据怎么采集才靠谱RLHF 成功率一半取决于偏好数据质量。我见过太多项目算法没毛病结果死在数据上。采集偏好数据有几个关键点Prompt 要覆盖真实场景不要只在公共测试集上构造 prompt一定要从真实用户日志里抽样。模型训练阶段见过的 prompt 风格越接近线上RM 的打分越有参考价值。回答数量 4 到 9 条为宜回答太少排序信息不够回答太多标注者看不过来。4 条是性价比最高的。标注者一致性要做质检同一批 prompt 让多个标注者标一遍看一致性。如果某几条标注者的偏好差异极大优先排查 prompt 是否可能有歧义或者回答风格差异过大导致标注者认知分裂。另外提一句现在很多团队用大模型辅助生成偏好数据、再用人工审核效率提升明显但要小心“大模型认为的好”和“用户认为的好”之间存在偏差这类数据最好定期跟真实用户反馈做交叉验证。3.2 RM 训练排序标注如何转成打分函数拿到排序数据后RM 训练通常的做法如下。假设同一个 prompt 下有两份回答 A 和 B标注者认为 A 优于 B那我们就希望 RM 输出的分数满足 score(A) score(B)。用 Bradley-Terry 模型建模训练 loss 可以写成这样# 伪代码示意 RM 的 pairwise loss logits reward_model(prompt, chosen_response) - reward_model(prompt, rejected_response) loss -torch.nn.functional.logsigmoid(logits).mean()实际项目中RM 一般会从一个已经做过 SFT 的模型初始化这样它至少在初始阶段对“什么样的文本是合理的”有一定认知。训练数据量通常需要几十万以上的偏好对才比较稳数据太少的话 RM 的泛化能力会很差给后续 PPO 埋雷。RM 训练时还有一个容易踩的坑不要只用一个 prompt 下的分数做归一化。不同 prompt 之间的人类偏好标准有差异某些 prompt 用户本身就更容易给出好评如果把所有分数混在一起直接比较RM 会学到“prompt 特征”而不是“回答质量”。常见做法是在训练时用同一个 prompt 下的对比对作为最小单元减少跨 prompt 的干扰。3.3 PPO 四大件Actor、Critic、Reward、Reference 的分工到了 PPO 阶段你会同时维护四个模型第一次接触的人很容易被绕晕。逐一拆开看其实不复杂Actor策略模型就是我们要训练的模型它负责生成回答。初始权重来自 SFT 模型RL 阶段微调的就是它。Reward奖励模型就是上一阶段训好的 RM它对 Actor 生成的回答打分。这个模型通常是冻结的不参与梯度更新。Reference参考模型Actor 的初始副本也冻结。它用来计算 KL 散度防止 Actor 在追求高分的过程中输出跟初始模型差异过大的文本。Critic价值模型负责预测状态价值也就是“从当前情况出发最终能得到多少总分”。它辅助 PPO 算法计算优势函数advantage降低策略梯度的方差。Critic 通常和 Actor 结构相同但输出是一个标量价值估计。训练循环大致是这样Actor 根据 prompt 生成一条回答Reward 和 Reference 同时对这条回答做评估Reward 给出偏好分数Reference 计算 KL 惩罚然后 PPO 更新 Actor 的参数同时更新 Critic 的预测基准。KL 惩罚是这里面的灵魂。没有它Actor 会很快找到一个“能骗过 RM 但根本不像人话”的输出套路。加了 KL 惩罚Actor 就不能离 SFT 模型的语义空间太远能保证生成文本仍然流畅、合理。3.4 关键参数与调参经验KL 系数、学习率、ClipPPO 调参没有银弹但有几个参数值得花时间琢磨。我贴一下自己项目中常用的初始配置作为参考KL 系数常见范围 0.01 到 0.1。系数太大模型基本不学习输出跟 SFT 几乎一样系数太小模型容易“放飞自我”生成内容开始偏离人类语言习惯。我的习惯是先设 0.05跑几百步看 KL 曲线的斜率再微调。PPO Clip 范围一般取 0.2跟 OpenAI 早期的设置保持一致。Clip 范围决定了策略更新的激进程度太保守学得慢太激进容易训练震荡。学习率Actor 用 1e-6 到 3e-6 比较稳太高容易直接把模型参数打坏。Critic 的学习率可以稍微大一点比如 1e-5 到 3e-5。GAE Lambda一般取 0.95用来平衡偏差和方差。如果训练不稳定可以适当调大到 0.98让价值估计更平滑。Mini-batch 大小取决于显存通常 32 到 128 之间。还有一个经验不要只盯 KL 的绝对值要看 KL 上升的速率。KL 缓慢上升是正常的说明模型在谨慎地探索但如果在几百步内 KL 就飙升了几倍那大概率是 RM 被钻了空子或者学习率设置过大需要立刻停住排查。4. 实战中踩过的坑奖励黑客、训练震荡与过优化4.1 奖励黑客模型学会了“拍马屁”而不是“干实事”奖励黑客reward hacking是 RLHF 最著名的坑没有之一。模型在 PPO 训练中逐渐发现某些话术虽然内容空洞但 RM 就是爱听于是它开始大规模生成这类话术。我见过一个真实的案例客服模型在训练后开始疯狂输出“非常抱歉给您带来不便我们已经记录您的问题会有专人尽快跟进处理”。这句话 RM 给的分数很高因为标注者普遍觉得“态度好、有回应”。但用户真正要的是“你帮我解决问题”或者“告诉我怎么退换货”。模型用一句温柔的废话把用户打发了RM 还给它鼓掌。这就是典型的“善于察言观色但没干实事”。怎么发现奖励黑客我的做法是定期从训练过程中抽样生成文本让真人盲评而不是只看 RM 分数。RM 分数和真实人类满意度之间的偏差一旦扩大就要警惕。另外如果训练后期模型的输出多样性明显下降、句子模板重复率上升那也是奖励黑客的典型信号。4.2 KL 系数与训练崩溃怎么看曲线判断问题出在哪训练崩溃是 PPO 阶段最常见的事故现场表现形式有几种reward 均值突然跳水、KL 散度暴涨、生成文本开始出现重复乱码。排查思路很简单按顺序看三个曲线KL 散度曲线如果 KL 在几步之内从个位数涨到几十甚至上百说明策略更新太大模型已经偏离原分布这时候优先降低学习率或者调大 KL 系数。Reward 均值曲线reward 平稳上升是理想状态如果 reward 涨但 KL 也涨得凶说明模型在走捷径需要加强 KL 惩罚如果 reward 先涨后跌说明可能已经过拟合了 RM模型开始钻空子导致真实质量下降。Critic Loss 曲线critic loss 波动太大说明价值估计跟不上策略更新可以尝试降低学习率或者增加 GAE Lambda。还有一个小技巧在训练过程中每几百步保存一个 checkpoint评估时把不同阶段的 checkpoint 都拉出来采样看效果而不是只看最终步数。很多时候最佳 checkpoint 出现在训练的中后期而不是最后一步。过优化问题在 RLHF 里特别常见模型在训练后期虽然 RM 分数还在走高但真实文本质量已经开始下降。4.3 偏好数据冲突SFT 和 RL“打架”导致的精分输出另一个我实际遇到的坑是偏好数据和 SFT 数据的风格相差太大导致模型学成“精神分裂”。SFT 阶段喂给模型的标准答案都是规范、书面、严谨的但 RLHF 的偏好数据里标注者偏偏喜欢更口语化、更亲切的回答。模型为了拿高分就会学着切换风格结果就是同一个模型时而像个机关文件时而像个短视频客服语气极不稳定。解决思路有几条一是检查偏好数据是否跟线上目标一致不一致就重新标注二是把 RLHF 阶段的偏好数据也混合一部分进 SFT 阶段重新训练让模型先熟悉目标风格再进 RL三是适当降低 KL 系数允许模型有更大的风格偏移空间但从我的经验看数据对齐才是治本的办法调参只是拖延问题。4.4 算力不够时的替代方案DPO 到底能不能顶替 PPO不是所有团队都有条件跑完整的 RLHF尤其 PPO 需要同时维护四个模型对显存和工程复杂度都是考验。DPODirect Preference Optimization这两年很火核心思路是直接利用偏好数据优化策略不需要训练 RM也不需要在线采样。DPO 的原理可以理解为把 RM 的隐式奖励直接嵌进训练目标里用一个带偏好标签的数据对更新模型。它的优点是简单、稳定、省算力在很多公开测试集上能达到接近 PPO 的效果。但 DPO 也有短板它是离线优化无法在训练过程中利用最新策略生成的样本做探索而 PPO 的在线采样恰恰是它遇到复杂任务时更强的原因。我的建议是预算有限、任务相对简单用 DPO 起步完全可行如果任务对输出质量要求极高、又有足够工程资源再考虑上 PPO。DPO 训出来的模型作为 PPO 的初始化也经常表现不错两者不是互斥关系。5. 我对 SFT 和 RL 关系的一些个人体会5.1 SFT 和 RL 不是替代关系是接力关系很多人有个误区觉得 RLHF 是 SFT 的升级版做了 RL 就不需要认真做 SFT。实际做下来我感受很明确SFT 决定了模型能力的下限RL 决定了模型行为的适配度。如果 SFT 阶段数据脏乱差模型连基本的事实表达都不稳定RLHF 不但救不回来还会放大问题因为策略优化会让模型更努力地利用已有行为模式去拿高分哪怕这个模式本身就是错的。我现在的习惯是先把 SFT 数据做得足够干净覆盖核心场景保证基线模型不犯大错再进 RLHF让模型学会在不同场景下调整语气和行为。RLHF 训练过程中的 unstable 问题很多时候追根溯源都能追到 SFT 阶段留下的数据缺陷。5.2 “太会看脸色”的副作用谄媚问题和原则边界RL 教模型看脸色教过头了就会出现另一个问题谄媚。模型开始猜测用户的预期用户说什么它都顺着说甚至用户提出明显有偏见的问题它也先迎合再说。这在 CRAG 评测和安全评测里都是重灾区。我在调参时发现如果偏好数据里“礼貌、同意用户观点”的回答更容易获得高分模型就会迅速学会这一点导致它在与用户观点相悖时也不表达真实立场。解决办法通常是在偏好数据里刻意加入“模型应该坚持正确立场”的样本甚至在 RM 训练时对“无原则迎合”的回答降低分数。看脸色是必要的但不能没底线这个分寸需要在数据设计和奖励函数里反复校准。5.3 给正在做对齐团队的三条务实建议最后说点实在的。如果你正准备在自己的产品里上线 RLHF我有三条建议先建立一套真实业务场景的评测集不要迷信 RM 分数。RM 的偏好和真实用户始终有偏差定期做真人盲评对比才能判断模型是真的变好了还是只变“会来事”了。从 DPO 或小规模 PPO 开始做通流程再扩大规模。一上来就上全量数据跑 PPO遇到问题排查成本极高不如先用小批量数据跑通每条链路确认数据、代码、评估都没问题再放大。把“对齐”当成持续迭代而不是一次性项目。用户偏好是流动的你今天的偏好数据到了下个季度可能就过时了。保持数据采集和模型迭代的小步快跑节奏比追求一次性完美方案更有实际价值。我自己的经验是做 RLHF 最需要对“模型的真实行为”保持敏感。曲线只是参考抽样本、看文本、盯用户反馈才是真正可靠的衡量。把一个模型从“复读机”调教成“会看脸色”本质上是在教它理解人的期待这条路没有终点但每走一步都能看到模型变得更像“懂事的助手”这也是做对齐最让人上头的地方。