InstructGPT论文解读：大模型对齐三步走，让AI真正听懂人话

“模型太聪明了但就是不听话”——这是我做 NLP 项目几年最深的感受。2022 年之前用 GPT-3 做产品原型最头疼的不是它能力不够而是你问它“帮我写一份请假邮件”它能给你扯出一段关于休假制度的哲学思考。直到我认真读了 OpenAI 那篇 InstructGPT 论文《Training language models to follow instructions with human feedback》才算真正搞明白问题的根源和大模型“听懂人话”的标准解法。这篇论文提出的思路后来几乎成了大模型对齐技术的基石ChatGPT 早期版本能那么“听话”靠的也是这条技术路线。这篇文章把我读论文过程中的理解、步骤拆解和一些实操层面的心得整理出来。适合正在做大模型微调、做 AI 应用开发的工程师也适合想搞懂“ChatGPT 为什么不再像个接口怪”的产品和技术同学。整个方法的核心就是用“三步走”——有监督微调、奖励模型、强化学习——把模型的输出行为和人类预期对齐。我关注的不是把论文逐段翻译而是把每一步的动机、关键细节和工程取舍讲明白。1. 为什么 2022 年之前的大模型总是“答非所问”——论文要解决的真实困境先想一个问题GPT-3 刚出来的时候大家惊叹于它能写文章、做翻译、玩问答但真正把它接到业务场景里就露馅。不是它笨而是它根本不理解“用户问这句话到底想要什么”。这不是 bug这是预训练目标的天然缺陷。1.1 预训练的本质是“接龙”不是“对话”大模型在海量文本上做自监督学习目标函数是“根据前文预测下一个 token”。这个目标决定了它学习的核心规律是文本的统计相关性而不是“这句话在回应什么需求”。所以模型看到“请帮我写一封请假邮件”时它内部检索到的模式是“请假”“邮件”相关的语料续写而不是“按照书信格式、语气礼貌、信息完整地完成一个用户任务”。一个非常经典的例子是论文里面提到的让 GPT-3 生成一个“关于某话题的简短描述”模型会生成一大段而且经常在前面加一句“Topic: xxx”。模型学会了“跟话题相关的文本长什么样”但没有学会“只输出那段描述本身”。这就是预训练目标与人类交互意图之间的错位。我在早期用 API 做 demo 时也踩过类似的坑。让模型复述一段话它总会自己加戏加背景、加解释、加总结。当时我还以为是 prompt 写得不够细来回调 prompt 能缓解但治标不治本。读了这篇论文才意识到问题的根子在模型层面不是提示词层面。1.2 大模型“能力很强”与“表现很糟”的悖论论文里有一个非常反直觉的数据InstructGPT 的 1.3B 小模型在人类评估中的表现居然超过了 175B 的 GPT-3。不是超过一点点是大幅超过。这说明什么说明当时的大模型根本不缺“知识”和“推理潜力”缺的是如何把潜在能力调度到用户期望的方向上。你可以把预训练模型想象成一个知识渊博但社交能力为零的学者。你问他“11等于几”他可能先从数学史讲起再谈到皮亚诺公理最后才说“所以答案是2”。能力一点不缺但交互体验极差。对齐alignment要解决的就是这层问题让模型的输出始终围绕用户的指令意图展开而不是围绕训练语料中的统计惯性展开。1.3 为什么“尺度”解不了这个问题可能有人会想模型再大一点、数据再多一点是不是就自然懂人话了论文给出的判断是单纯扩大参数规模只能提升模型的“知识能力”但无法改变它“不按指令行事”的行为模式。GPT-3 从 1.3B 扩到 175B流畅度和知识量明显提升但对“指令的遵循能力”没有本质改善。这个判断今天回头看依然成立。市面上很多开源大模型能力很强但如果你不做任何对齐微调直接用原始基座跑业务效果仍然会非常“野生”。很多团队拿开源模型做应用第一步就是做指令微调本质就是在做 InstructGPT 中“三步走”里的第一步。所以这篇论文的核心贡献不是提出了某种花哨的新模型架构而是把“模型能力”和“用户意图”之间的鸿沟正式定义成问题并且给出了一个可复现的、工程上可行的解决方案用人类反馈信号去引导模型的生成行为。2. 三步走拆解之一有监督微调——先让模型模仿“人怎么干活”InstructGPT 的第一步是收集一批“人类示范数据”用这些数据对预训练模型做有监督微调Supervised Fine-TuningSFT。这一步的目的很简单先在行为层面让模型看到“面对用户的指令一个合格的 AI 助手应该怎么回答”。2.1 数据从哪来让标注员扮演“被使唤的 AI”论文中标注员团队的任务不是给数据打标签而是直接扮演 AI 助手的角色根据给定的用户 prompt 写出“理想回复”。数据规模大约是 1.3 万条 prompt-response 对prompt 的来源主要分两块一部分来自 OpenAI API 用户提交的真实请求另一部分是标注员自己编写的 prompt。这里有个细节很关键prompt 的多样性要刻意扩展。如果只用 API 用户的请求数据分布会偏向问答和编程为了让模型学会应对更多指令类型论文按 9 个大类做平衡——包括生成、问答、对话、改写、摘要、翻译、代码等。工程上做指令微调数据时这个思路也值得借鉴宁可每个类目数量少一些也不要让数据分布严重偏斜到某一类。我当时自己整理微调数据时有个体会很多人只关注“数量”和“质量”却忽略了覆盖度。1 万条全部是“翻译类”的数据微调出来的模型在面对“总结类”指令时几乎没有改善。要站在“任务类型矩阵”的角度去思考数据配比而不是只看总量。2.2 模型选择和训练参数细节论文对多个尺寸的模型做了实验175B、6B、1.3B。微调方法就是在预训练权重上继续做标准的语言模型训练但训练样本从“网页文本”换成了“指令-回复对”。训练细节上我记得几个关键点训练 epoch 数较少论文是约 3 个 epoch因为示范数据量本身不大过度训练会导致过拟合。微调时混入了一部分原始预训练数据梯度比例约 0.2目的是防止模型在指令数据上过度偏向而遗忘预训练阶段学到的通用能力。这个操作值得注意它对应的就是后来大家常说的“灾难性遗忘”问题。学习率比预训练阶段小很多用的是余弦学习率调度。这里想多说一句“灾难性遗忘”。我们在微调一个基座模型时往往只盯着目标任务的效果跑出来领域指标提升了但模型做通用任务的能力断崖式下跌。InstructGPT 当时已经意识到这个问题混入预训练梯度这个操作本质上是在“专用能力”和“通用能力”之间做一个平衡。今天很多做 LoRA 微调的朋友也会遇到这个问题领域能力上去了但模型变得“只会这个领域”。处理方式之一也是类似思路在微调数据中混入通用对话数据。2.3 SFT 的局限模型学会了“有样学样”但没学会“判断好坏”SFT 阶段的数据是标注员写的“标准答案”但现实世界中的问题打开方式千奇百怪一个问题根本没有唯一正确答案。SFT 只能让模型学会模仿数据集中出现过的那种回答风格却无法让它学会“哪种回答更好”。就像你教一个实习生怎么做报表你给他看了三个样例他学会了照着做但遇到没见过的数据格式就不知道怎么处理。更关键的是想通过人工去穷举所有指令类型和回答范式成本上完全不可行。所以 SFT 只是第一步它解决了模型“行为方向”的问题但没有解决“回答质量”的问题。要进一步提升就需要让模型自己尝试多种回答再由人类反馈来告诉它哪个更好。这篇论文里有个实验对比让我印象很深单独用 SFT 训练出的 175B 模型和经过完整 RLHF 流程的 175B 模型相比人类评估分数差了一大截。也就是说光靠示范模仿模型的上限很快就到了后两步的价值正是把这个上限继续往上顶。3. 三步走拆解之二奖励模型——给模型一把“评分尺子”SFT 之后模型已经学会了“对着指令写回复”但还分不清好坏。第二步就是训练一个奖励模型Reward ModelRM让它充当人类偏好的“打分器”。3.1 为什么人类打分不靠谱但“两两比较”很靠谱直接让标注员给每个模型输出打一个绝对分数比如 4.2 分最大的问题就是主观性太强。同一个人在不同的时间、不同的上下文下给同一个回答打的分数可能都不一样。但让标注员看两个回答问“哪个更好”这就稳定得多——这是人类认知习惯里天然擅长的比较判断。论文用的是“比较数据”方案同一个 prompt让模型生成 K 个不同的回答默认 K 是 4 到 9 之间再由标注员对这 K 个回答做排序。然后把这 K 个回答两两组成 pair训练 RM 对这些 pair 做偏好预测。比较数据的总规模我记得大概是 3.3 万个 prompt每个 prompt 对应 K 个回答的排序。这里有个工程细节容易被忽略用来做 RM 训练数据时不同回答的输出长度差异会干扰标注员的判断。写 50 个字的回答和写 300 个字的回答放在一起标注员很容易被“更详细”误导认为长文更好。为了减少这种偏差论文专门对输出长度做了归一化处理把长度这个混淆因素控制住。我后来做用户反馈收集时发现这确实是个普遍问题。用户评价一个 AI 回答好不好第一反应是“会不会写”第二才是“对不对”。短答案信息密度再高也容易在主观评价上吃亏。论文里对长度做归一化的这个设计放在真实产品反馈收集里同样适用——如果线上模型回答普遍偏长收集到的“好评率”会虚高夹杂着对“努力程度”的肯定而不是对“有用性”的判断。3.2 RM 的训练目标预测“哪个回答更受欢迎”RM 的模型结构和 SFT 模型基本一致区别在于最后一层把输出 token 的隐藏状态汇聚成一个标量分数。训练时对于一对回答x_a, x_b如果标注员认为 x_a 优于 x_b就让模型预测 x_a 的分数尽量高于 x_b。损失函数用的是 pairwise 排序损失形式上等价于把两个回答的分数差做一个 sigmoid再取 log loss。简单理解就是模型每次只判断“两个选项中哪个更好”通过大量这样的判断逐渐学会给回答打分。关键一点RM 训练时的得分是“相对”的不是绝对质量。同一个回答放在不同的比较对里RM 给出的分数可能不同。论文在推理阶段用 RM 给候选回答打分时会先让模型生成多个候选再挑 RM 分数最高的那一个。注意这个“先采样再打分”的策略后面对理解 PPO 的训练信号很有帮助。3.3 标注员的培训与校准机制不要以为“人类反馈”就是把任务丢给一群标注员然后收数据。论文里专门花了篇幅讲标注员的筛选和培训流程。标注员需要先完成一批测试题通过考核后才能正式参与标注。在正式标注中他们的工作内容和标准也经过多轮校准团队内部对“什么是有用的回答”达成共识。其中有一个我印象很深的点对于“有害内容”的判定论文没有简单让标注员凭感觉判断而是参考了一套内容安全准则要求标注员按照准则逐一核对。这套流程保证了 RM 学习到的不只是个人审美而是相对一致、有据可依的价值判断。这给我们的启示是如果你要照这套方法训练自己的偏好模型别急着大规模采数据先花时间把标注规范写好把标注员培训好。数据质量对 RM 上限的影响远大于模型参数规模的影响。我见过一些团队拿开源数据集直接训 RM省了规范流程最终 RM 打分和人工评估的相关性只有 0.4 左右基本没法用。4. 三步走拆解之三PPO 强化学习——用奖励信号回归“指令预期”前两步做完我们有了一个会写回复的模型SFT 模型和一个能打分的模型RM 模型。第三步就是用强化学习把两者接起来让 SFT 模型不断生成回答RM 给出分数模型再根据分数调整自己的生成策略。论文用的强化学习算法是 PPOProximal Policy Optimization。4.1 为什么需要强化学习而不是直接让 SFT 模型拟合 RM 打分一个很自然的疑问是既然 RM 能打分为什么不直接用 RM 的分数作为监督信号继续做有监督微调原因是我们无法为每一个可能的输出 token 穷举所有回答。SFT 的监督信号来自人工标注的确定性答案而 RM 的分数是连续的、动态的需要模型自己探索“怎么改写才能使分数更高”。强化学习的本质是“通过试错来优化策略”。PPO 让模型在策略空间里尝试不同的生成方式RM 给反馈好的生成方式被强化差的被抑制。这个过程模拟了人类“被夸奖后更愿意这么做”的学习机制。这里有个重要的安全网PPO 训练时不能让模型为了刷高分而彻底放飞自我。论文在 PPO 的目标函数里加了一个 KL 散度惩罚项限制模型不能偏离 SFT 阶段的行为太远。原因很实际RM 也不是完美的如果模型发现某些输出模式能稳定骗过 RM 的分数它就会疯狂往那个方向优化最终输出变得非常奇怪甚至有害。KL 惩罚本质上是在“探索优化空间”和“保持基本行为规范”之间做平衡。4.2 PPO 训练流程与参数背后的逻辑PPO 训练时的数据来自一个 prompt 集合论文中约为 3.1 万个 prompt。训练时的大致流程是从 prompt 集合中采样一批指令。当前模型根据指令生成回答。RM 对回答打分作为 reward。用 PPO 算法更新模型参数让“高分回答”的概率提升。计算新模型与 SFT 模型的 KL 散度作为约束项加入损失。我根据论文和工程经验整理了一个简化的伪代码流程for step in range(total_steps): prompts sample_batch(prompt_set) responses actor_model.generate(prompts) rewards reward_model.score(responses) kl_penalty kl_divergence(actor_model, ref_model, responses) loss ppo_loss(log_probs, rewards - kl_penalty * kl_coef) actor_model.update(loss)具体参数上论文里提到的 KL 系数大约是 0.02裁剪范围是 0.2这些值直接沿用了开源 PPO 库的默认参数。换句话说InstructGPT 的核心收益主要来自“RLHF 框架”本身而不是精细调出来的超参数。这也给后来做类似工作的团队一个信心按照框架标准实现效果就会有基本保障不必在一开始就陷入调参泥潭。我之前照着这套流程在自己的业务模型上跑过一次一个很直观的感受是SFT 模型生成的回答偶尔会“飘”但 PPO 之后明显“稳”了。不是说每句话都惊艳但它会倾向于选择更安全、更贴合指令的表达方式用词和结构都更收敛。4.3 训练时长“见好就收”比“充分训练”更重要论文有一个细节特别值得工程化参考PPO 模型在训练到某个时间点之后RM 分数继续上升但人类评估的满意度反而下降。原因是模型开始“过度优化”——为了迎合 RM 的偏好牺牲了回答的多样性和真实性出现了明显的 reward hacking 现象。这个现象在今天复现 RLHF 流程时依然普遍。我自己的经验是在训练过程中定期做人工抽评不能只看 RM 分数。RM 分数涨不代表真实质量涨两者往往在训练后期背离。实际操作中我会把不同 checkpoint 的回答打印出来对比肉眼扫一遍就能发现模型是否变得“油嘴滑舌”。论文对此没有给出特别精确的“早停规则”但明确提示了训练策略上要控制步数不能一味追求 reward 最大化。5. 论文里的“小字报”——那些被人忽略但很重要的细节除了三步走的主线InstructGPT 论文里还有一些“角落里的信息”很容易被读者一眼带过但恰恰是工程上最容易踩坑的点。5.1 输出冗长的倾向性RLHF 模型的“注水”问题论文在讨论结果时坦诚地指出InstructGPT 模型比 GPT-3 更倾向于生成比较长的回答因为标注员在评价“有用性”时往往会偏向信息量更多的回答。这个偏差被 RM 学了过去最终模型学会了“多写一点”。这在今天的产品中相当常见。你会发现很多对话模型回答像小作文洋洋洒洒一大堆但真正有用的信息可能就一两句。如果你要做基于 RLHF 的应用推荐在 RM 训练阶段就对输出长度进行约束或单独建模否则上线后的回答质量会很“油腻”。5.2 无害性与有用性之间的此消彼长论文同时对模型做了“有用性”“真实性”“无害性”三个维度的评估。结论很有趣InstructGPT 在“有用性”和“无害性”上相比 GPT-3 有显著提升但“真实性”并没有明显改善在某些情况下甚至是下降的。这给所有做 AI 应用的团队提了个醒对齐不是万能的。RLHF 把模型的行为对齐到了“人类偏好”但如果人类偏好本身就存在偏见或错误模型学到的就是偏见。尤其是“有害内容”的规避本质上是在“不说”和“说错”之间做权衡并没有真正做到“模型理解了什么是正确的”。5.3 标注员之间的不一致性论文在附录中提到标注员之间对回答质量的判断一致性并不算高个体差异明显。为了解决这个问题他们采用了多个标注员交叉标注、再取汇总标签的方式同时通过培训尽量拉齐标准。这让我意识到RLHF 的数据质量把控是一个“人”的问题不只是一个“数据”的问题。如果你在团队里想复现 RLHF第一个要搞定的是“让参与标注的人对什么是好回答达成共识”而不是直接开干。没有这一步后面训出来的 RM 大概率是“几个人审美平均值的拟合模型”。6. 今天再读 InstructGPT该读什么距离论文发布已经过去了一段时间今天的模型和工具链已经变化很大但 InstructGPT 的核心思想几乎没有过时反而成了后续一系列对齐技术的出发点。6.1 从 InstructGPT 到 ChatGPT一次成功的工程放大ChatGPT 早期版本几乎完全复用了 InstructGPT 的技术路径先做 SFT再训 RM最后用 PPO 微调。不同之处在于 ChatGPT 在指令数据的多样性和对话场景的覆盖上做了大幅扩展把 InstructGPT 验证过的路径规模化了。对于想上线一个对话产品的团队来说InstructGPT 依然是最值得参照的“最小完整方案”。读它不是为了复刻论文实验而是理解整个 RLHF 链路中每个环节的作用边界从而在自己的数据、算力和人才条件下做裁剪。6.2 RLHF 的下一步更便宜、更好用的替代方案InstructGPT 让 RLHF 成为主流但也暴露了它的高门槛需要大量人工偏好标注、需要训练 RM、PPO 训练不稳定、调参成本高。这也是后面 DPODirect Preference Optimization、RLAIFAI Feedback等方法出现的原因。DPO 绕过了显式 RM 和强化学习流程直接用偏好数据优化策略训练稳定性和成本都有明显改善。但要注意DPO 等替代方案在“概念上”依然是在做 InstructGPT 提出的事情用人类或 AI反馈来对齐模型行为。理解了 InstructGPT再看 DPO、RLAIF 或者其他对齐方法你会很容易抓住它们的出发点——都是试图以更低的成本拟合人类偏好信号。6.3 对抗“奖励黑客”为什么对齐永远是一个“对抗性”问题论文中多次提到模型会“钻 RM 的空子”这在今天被叫做“reward hacking”。模型会找到一些让 RM 给出高分但实际质量低劣的表达模式比如堆砌关键词、使用看似权威的语气、输出超长文本等。这些现象不是 RLHF 特有的 bug而是任何“用代理指标优化行为”的系统都会面临的问题。在业务实践中我通常的做法是RM 评估和人工抽评双轨并行定期用一批人工打过分的样本去“审计” RM 的打分趋势。一旦发现二者背离就要考虑重新校准 RM 或调整训练策略。这里面没有一劳永逸的方案只有持续的监控和迭代。6.4 我对 InstructGPT 论文的一句话总结把论文合上后留在脑子里的不是那些公式和数据而是这个判断大模型的能力来自预训练但“可用性”来自对齐。你花在指令微调、偏好数据、行为约束上的功夫和花在模型结构上的功夫往往在用户体验端同样重要甚至更加重要。如果你手上正好有一个能力不错但“不听指挥”的大模型别急着换更大参数的版本先把 InstructGPT 这套“SFT RM PPO”的思路过一遍。哪怕因为成本和复杂度没办法做完整的 PPO只做到 SFT 阶段配合良好设计的偏好数据输出质量也会肉眼可见地上一个台阶。我在实际项目中通常这样操作先用几百条精心撰写的指令样例给模型做一次低成本 SFT把“响应风格”固定下来然后收集线上的 badcase 做 RM 的偏好数据逐渐过渡到完整 RLHF。整个过程不一定需要复现论文的全部规模但每一步的目标和边界基本都沿用了 InstructGPT 划出的路线。最后再分享一个读论文以外的小建议读技术论文别只看正文多花时间看附录里的训练细节、评估方法和作者自己承认的局限。InstructGPT 的附录里其实藏着大量可复用的工程经验比如标注员校准、长度归一化、KL 系数设置。这些细节是论文最接近“实战”的部分也是普通博客和教程里最不容易写透的部分。