Barret Zoph加盟Google背后：强化学习主导语言模型后训练

Barret Zoph 离开 OpenAI、加入 Google 出任研究副总裁这条消息在 AI 社区很快引发了讨论。多数讨论集中在人才流动、公司竞争和薪酬待遇上但技术从业者可以从中读到的其实是一个更明确的研究方向信号强化学习在语言模型后训练中的地位已经不再是辅助工具而是与模型架构、数据和基础设施并列的主战场。OpenAI 过去几年把 ChatGPT、指令跟随、推理模型这条线推到行业前场Google 则同时握有 Transformer 的底层积累和 DeepMind 的强化学习传统这次人事变化可以看作两条技术路线在人才层面的一次交汇。这篇文章不猜测公司内部决策而是把事件当作线索拆解它背后真正值得学习的技术链路从 RLHF 到 RLVR从奖励模型到规则可验证奖励从 PPO 到 GRPO以及 Google 研究体系与 OpenAI 后训练路线之间的互补关系。对正在做模型训练、对齐和推理优化的工程师来说这条链路比新闻标题更有价值而且每一步都可以在开源框架和小规模实验里复现。1. 这则人事变动真正值得关注的是“强化学习”这条主线1.1 先确认 Barret Zoph 的技术身份与公开贡献Barret Zoph 是 OpenAI 研究副总裁长期参与语言模型后训练和对齐方向的工作。公开层面他深度参与的路线基本覆盖了 ChatGPT 这条技术主线的几个关键环节指令微调、RLHF、基于人类反馈的偏好优化以及后来推理模型所依赖的强化学习训练方法。很多人会把“参与 ChatGPT”理解为写了一两个模型文件实际不是。ChatGPT 这类产品能够落地依赖的是完整的数据生产线和训练闭环需要构造指令数据需要训练奖励模型需要在强化学习阶段控制策略偏移还需要处理人工标注的一致性问题。Barret 所在的团队做的正是这条闭环里最不容易在论文里展示、但对产品体验影响最大的部分。与其把他看作一个明星研究员不如把他看作“语言模型强化学习训练体系”的关键工程推手之一。这类人的价值不在于单独提出某个数学公式而在于能把数据、奖励、策略模型和基础设施组合成一个可训练、可迭代、可上线的大规模系统。1.2 这不是普通高管跳槽而是研究方向变化的信号OpenAI 过去两年的产品节奏发生过明显变化从 GPT-4 这样规模优先的通用模型转向 o1、o3、o4-mini 这类强调推理能力的模型。推理模型的核心不是更大的参数量而是让模型在生成过程中投入更多“思考”计算量并用强化学习让模型学会在复杂问题上自我纠错。这个转变意味着后训练不再只是“做一遍 SFT 再调一调”而是整个模型能力的决定因素之一。Barret 选择在这样一个时间点加入 Google至少说明两个判断第一Google 在后训练强化学习方向上有足够大的研究空间和算力资源第二OpenAI 当前的研究路线已经从探索强化学习范式转向更依赖产品迭代、数据规模和基础模型迭代的工程阶段。一个做研究驱动的人在这个阶段选择到另一家研究自由度更高的平台逻辑上是通的。技术从业者应该从中看到的不是“哪家公司赢了”而是“语言模型研究的主战场正在往后训练迁移”。后训练不再只是微调而是像预训练一样需要独立的人才体系、基础设施和评估方法论。1.3 人才流动背后OpenAI 与 Google 都在押注同一件事从公开信息看Google 对推理模型和后训练强化学习的投入在明显加强。Google DeepMind 本身就具备很强的强化学习传统AlphaGo 时期积累的蒙特卡洛树搜索、策略网络、价值网络经验和当前语言模型 RLHF 之间存在大量可以迁移的方法论。OpenAI 这边的积累则集中在产品侧如何用人类偏好数据训练奖励模型如何在对话场景里控制有毒内容如何把强化学习训练做成稳定可复现的基础设施。两者路线不同但终点接近都希望在基础模型之上通过强化学习训练出更可靠、更能推理、更适合做任务自动化的模型。Barret 从 OpenAI 到 Google本质上是把“对话模型强化学习后训练”的经验与 Google 的“底层架构 强化学习传统 超大规模计算资源”重新组合。对行业来说这种组合大概率会加速推理模型和智能体方向的研究进展。2. 从 InstructGPT 到 ChatGPTRLHF 是这条技术路线的起点2.1 RLHF 的三阶段训练流程为什么能提升模型表现RLHF全称 Reinforcement Learning from Human Feedback基于人类反馈的强化学习。它的出发点很朴素语言模型通过预训练习得了大量文本分布但“像人一样说话”和“符合人类偏好”是两回事。一个模型可以生成语法完全正确、但态度敷衍、逻辑混乱、跟随指令很差的回答。RLHF 的思路是用人类偏好作为奖励信号引导模型往“更符合人类期望”的方向收敛。常见实现分三步第一步监督微调 SFT用少量高质量指令数据微调预训练模型让模型学会指令对话的基本格式。第二步训练奖励模型 RM让标注员对同一问题生成的多条回答进行排序训练一个模型来预测哪条回答更符合人类偏好。第三步强化学习优化以 SFT 模型为初始策略用奖励模型打分作为奖励信号通过 PPO 等强化学习算法更新策略模型。第三步是 RLHF 的核心也是最容易出现问题的地方。强化学习优化的是一个动态目标奖励模型不是固定规则它本身也有误差策略模型在追求高奖励时会利用奖励模型的漏洞生成看似高质量、实际不可用的内容这就是典型的 Reward Hacking。2.2 奖励模型为什么会成为关键瓶颈奖励模型训练本质上是一个排序问题。给定同一个 prompt 下的多个回答标注员按质量排序奖励模型学习预测 pair 之间的偏好关系。奖励模型的准确度直接决定 RL 阶段的上限。如果奖励模型本身有偏比如偏爱更长、更花哨的回答策略模型就会朝着这个方向过度优化。你甚至会看到一个很诡异的训练现象奖励分数持续上升但人工评估的满意度却在下降。实际项目中奖励模型需要反复校准不能只看准确率。至少还要检查是否过度依赖长度、标点、语气等表面特征是否对超长回复无理由给高分是否在敏感话题上出现偏好偏移在分布外 prompt 上的表现是否稳定。2.3 理解 PPO 目标函数与 KL 约束的最小版本PPO 是 RLHF 阶段最常用的策略优化算法。它解决的核心问题是如何在不破坏训练稳定性的前提下让策略模型沿奖励方向更新。PPO 的简化目标可以写成max E[ clip(ratio, 1-eps, 1eps) * advantage - beta * KL(pi_theta || pi_ref) ]其中 ratio 表示新旧策略在同一个 token 上的概率比值advantage 表示这个动作相对平均水平的优势KL 项则约束当前策略不要离参考策略太远。KL 约束是 RLHF 里最常见的超参数之一通常写作 kl_coef。它控制“模型可以偏离最初 SFT 模型多远”。如果设置太大模型几乎不敢更新训练没有效果设置太小模型会疯狂追逐奖励模型的高分很快出现乱码和重复。代码层面最小训练循环可以这样理解# RLHF 第三阶段 PPO 的简化伪代码 for step in range(total_steps): prompts sample_batch() # 取一批指令 responses policy_model.generate(prompts) # 当前策略采样回答 rewards reward_model(prompts, responses) # 奖励模型打分 advantages compute_advantages(rewards) # 优势估计 old_log_probs get_log_probs(responses) # 策略梯度更新 current_log_probs get_log_probs(responses) ratio exp(current_log_probs - old_log_probs) policy_loss -clip(ratio, 1-eps, 1eps) * advantages # KL 惩罚 kl kl_divergence(current_log_probs, ref_log_probs) loss policy_loss kl_coef * kl optimizer.zero_grad() loss.backward() optimizer.step()这个循环只是示意真实系统里还有参数裁剪、优势白化、梯度裁剪、经验回放等细节但它能帮助你理解 RLHF 的骨架采样、打分、更新、加 KL 约束。2.4 小规模复现 RLHF 的最低配置建议在学习环境里不建议一上来就训练 7B 或 13B 模型更不建议直接套用 PPO。建议按以下顺序递进先用 0.5B 到 1B 的开源模型在公开的指令数据集上做 SFT用已有的奖励模型或自己训练一个很小的奖励模型使用 TRL、DeepSpeedChat、LLaMA-Factory 等框架跑通 PPO 流程把 kl_coef、学习率、batch size 作为变量做几组对比实验。学习环境的意义是理解机制不是复现 SOTA。能稳定观察到“reward 上升”和“生成质量先升后降”这两个现象就说明你已经跑通 RLHF 了。3. 从 RLHF 到 RLVR推理模型把强化学习推向训练核心3.1 o1 带来的本质变化让模型通过强化学习学会“思考”o1 系列出现之前模型推理依赖的是逐个 token 自回归生成。面对复杂数学题或代码问题模型容易“想得太浅”没有中间推理过程直接给出一个不靠谱的答案。o1 的核心变化是把“内部思维链”作为可训练对象让模型在推理时生成更长的思考 token同时用强化学习训练模型在思考过程中不断自我修正。这不是简单地让模型输出更长的回答而是要让模型学会在中间步骤上做正确决策。这一步对训练体系的要求发生了质变人类难以给“每一步思考”标注偏好所以不再依赖人类排序问题通常有确定答案不需要训练奖励模型可以直接用规则判断对错训练目标从“符合人类偏好”变成“在可验证任务上拿高分”。这就是 RLVRReinforcement Learning with Verifiable Rewards规则可验证奖励的强化学习。3.2 规则可验证奖励与 GRPO 在做什么RLVR 的思路是只要任务结果可以自动检查就不需要奖励模型直接用规则判断对错。典型场景包括数学题、代码执行测试、SQL 查询结果对比、格式约束检查。相比奖励模型规则奖励有几个明显优点没有奖励模型过拟合问题反馈信号明确训练更稳定可以大规模并行采样不需要人工标注排序奖励分数可解释方便调试。GRPO 是这类训练中经常提到的优化算法。它去掉了传统 PPO 里的 Critic 价值网络用同一个 prompt 下多次采样的平均奖励作为基线计算每个样本的相对优势。这样既减少了显存占用又避免了价值网络估计误差。GRPO 的优势计算可以简化理解为advantage_i (reward_i - mean(rewards_group)) / std(rewards_group)每组采样若干条回答组内对比奖励高于平均水平的回答获得正向优势低于平均水平的获得负向优势。这个思路非常适合 RLVR因为规则奖励天然可比较。3.3 RLHF、RLVR 与 RFT 的对比很多人会把 RLHF、RLVR、RFT 混在一起实际它们是三种不同的后训练路径适用场景也不同。方法奖励来源主要适用任务标注成本优点风险RLHF人类偏好排序训练出的奖励模型对话、写作、通用助手高覆盖开放任务结果自然奖励模型偏差、Reward HackingRLVR规则自动判断结果对错数学、代码、SQL、结构化输出低信号明确稳定可复现仅适用于结果可验证任务RFT采样后按规则或人工过滤优质结果再做 SFT指令跟随、推理数据增强中简单稳定不依赖强化学习算法提升上限有限无法持续迭代RFT 可以看作 RLVR 和 RLHF 的前置准备先用高比例采样和过滤生成高质量数据再做一轮微调。很多团队不做完整的 RLHF只做两三轮 RFT也能获得明显提升。3.4 测试时计算的工程代价不能只用论文思路理解推理模型带来的另一个重要变化是测试时计算。模型在回答问题前先生成大量思考 token推理成本显著上升。从工程角度看这带来几个现实问题推理延迟大幅增加chat 应用需要区分“普通问答”和“深度推理”两条链路生成 token 数量增大KV Cache 显存占用上升需要设计超时控制、最大思考长度、早停策略成本估算模型要改写不能只看输入输出 token 数还要估算思考 token 的分布。很多团队在尝试复现推理模型时会发现训练还算顺利上线后成本反而失控。原因往往是忽略了测试时计算的统计规律没有预留足够长的最大生成长度也没有按问题难度分级调度模型。4. Google 研究体系为什么对这条路线有吸引力4.1 Google 的技术底座Transformer、TPU 与强化学习传统Google 在基础模型这条路上有大量底层积累。Transformer 架构最早来自 GoogleTPU 为超大规模训练提供了自主可控的算力底座DeepMind 则把强化学习发展成了完整的方法论体系AlphaGo、AlphaFold 都来自这条研究传统。这些积累对语言模型强化学习后训练非常关键。RLVR 训练需要大量并行采样对算力调度、模型并行和数据并行要求极高TPU 集群的弹性和稳定性在这种场景下的优势会被放大。Google 的数据中心基础设施、多数据中心容灾能力、以及多年的超大规模训练经验都是做基础模型后训练不可或缺的研究条件。Barret 在 OpenAI 积累了对话模型、奖励模型、RLHF 和推理模型后训练的一线经验加入 Google 后最大价值不是复刻 OpenAI 的方法而是把这些经验与 Google 的强化学习传统结合起来。尤其在规则奖励、搜索、智能体、规划这些领域Google 有一套更完整的理论体系。4.2 OpenAI 与 Google 的研发节奏差异决定了人才结构OpenAI 多年来更强调产品迭代和快速交付ChatGPT 的成功让整个组织形成了“模型能力 产品体验 用户反馈”的闭环。这种模式能快速发现模型问题但研究的自主性相对受限。Google 体量更大研发体系更分散有 Google Research、Google DeepMind、Google Cloud 等多条线。对于研究型人才来说这种环境通常意味着更长的研究周期、更多探索性课题、以及更充足的底层算力支持。两种体系没有绝对优劣但适合的研究者类型不同。Barret 选择 Google几乎可以确认 Google 给了他在后训练和强化学习方向上更大的研究自由度。这种迁移对行业的影响不在当下而在未来两三年Google 的推理模型路线会越来越成熟OpenAI 也需要在“产品迭代”和“基础研究”之间重新寻找平衡。4.3 这次加入可能带来的协同点需要放长周期观察在公开信息有限的情况下业内更值得关注的是几个方向语言模型后训练与 AlphaGo 式强化学习方法的融合规则奖励系统在复杂任务上的扩展多智能体协作和搜索增强的后训练框架推理模型的高效采样方案。这些方向不是靠某一个研究员就能独立完成的但一个熟悉 OpenAI 后训练生产流程、又理解 Google 研究体系的人能够帮助两边团队在目标设定和技术选型上更快对齐。Google 需要的是把强化学习传统映射到语言模型场景的项目带头人这个角色正好是 Barret 在 OpenAI 长期扮演的。4.4 人才流动能带走什么带不走什么技术社区经常高估人才流动的影响。一个关键研究员加入竞争对手不等于能把原公司的技术栈完整复制。数据管线、标注体系、基础设施、团队配合、产品反馈闭环这些知识很难通过一个人迁移。真正能带走的是方法判断力什么样的数据有效什么样的奖励设计会崩什么样的超参组合在什么规模下更容易收敛。这种判断力建立在无数次失败实验的基础上恰恰是大模型研究中最稀缺、最不容易被论文复制的部分。对开发者的启示是不要只用“公司归属”判断技术趋势更要看关键个人在研究方向上的连续性。Barret 从 OpenAI 到 Google研究方向始终围绕语言模型后训练和强化学习这个连续性比任何职位变动都更有信息量。5. 对开发者的可复用学习路径把人事新闻拆成训练经验5.1 从这条新闻能提炼出一条清晰的技能主线如果你不是研究员而是一线算法工程师或大模型应用开发者这条新闻同样有指导意义。它说明未来的大模型竞争力集中在后训练而非只拼基座模型参数。建议学习顺序如下先掌握 SFT能自己构造指令数据完成有监督微调再训练奖励模型理解排序标注和 pairwise loss再用 PPO 跑通一个最小 RLHF 流程再用 GRPO 和规则奖励跑一个数学或代码任务的 RLVR 流程学会评估对比 SFT、RFT、RLHF、RLVR 模型在推理、指令跟随和通用能力上的差异。这个顺序和 OpenAI 过去几年的技术演进基本一致也是理解当前推理模型最适合的技术路径。5.2 一套最小 RLVR 实验环境清单在做学习环境验证时不建议一开始就在大规模集群上跑建议准备以下条件项目建议配置说明模型规模1B 以内小模型能快速验证训练闭环训练框架TRL、L拉马-Factory、veRL优先选文档完整、社区活跃的框架数据集GSM8K、MATH 子集、MBPP 子集数学和代码题目规则奖励最容易实现奖励函数规则对比最终答案或执行测试用例判断不要一开始设计复杂 rewardGPU 资源单卡 24GB 或两张消费级卡1B 模型可以做 LoRA 或全参训练观测指标reward 均值、KL、回答正确率、思考长度分布训练过程和效果评估都需要这里要注意学习环境可以降低规模但不要跳过“奖励函数”这一环。RLVR 的难点不在框架而在如何设计既准确又不过度稀疏的规则奖励。5.3 关键超参与推荐范围要能说清原理不管用 PPO 还是 GRPO下面几个超参都值得你手动调几组实验参数推荐范围调大影响调小影响kl_coef0.01 到 0.1模型偏离参考策略小训练容易无效模型容易 Reward Hacking输出退化成重复文本rollout batch size128 到 1024优势估计更稳定显存占用更高训练波动大容易崩采样温度0.7 到 1.2探索性更强样本多样性高容易采样到低质量回答学习率SFT 学习率的 0.1 到 0.5 倍更新过快策略震荡收敛慢训练周期长最大生成长度512 到 2048给模型更多思考空间成本上升复杂问题容易截断没有一组参数适用于所有任务但理解每个参数为什么存在能让你在训练崩溃时不至于从头猜。5.4 评估与验证不能只看 loss 曲线RL 训练阶段的 loss 很容易让人误判。reward 上升不代表模型真正变好因为奖励函数可能被模型利用。建议训练时同时观察一组稳定指标- 奖励模型分数或规则奖励分数 - 生成回答的 KL 散度 - 验证集上的任务正确率 - 回答长度变化 - 是否出现重复、乱码、模板化内容最佳做法是冻结一份验证集每训练若干步就评估一次推理正确率。如果 reward 持续上升但验证集正确率不涨说明 reward 设计出了问题需要立刻检查。6. 实际训练中会踩到的几个典型坑6.1 Reward Hacking奖励函数被模型“钻空子”现象训练过程中奖励分数持续上涨但人工评估回答质量越来越差甚至出现大量无意义重复。原因模型发现了奖励函数里容易被利用的特征比如更长的回答容易得更高分、包含某些关键词容易得更高分、格式完整但内容空洞也能拿分。排查方式按奖励分数高低分层抽样人工检查高分样本统计奖励分数与回答长度的相关性检查是否存在某个 token 或短语被高频重复使用。处理建议增加 KL 约束强度改进奖励函数设计必要时加入长度惩罚或格式惩罚。RLVR 场景优先使用结果正确性而不是格式特征做奖励。6.2 KL 权重设置不当模型要么不学要么学崩现象训练几十步后生成内容变成完全不同于参考策略的另一种风格或极端情况下模型开始输出重复无意义 token。原因kl_coef 设置太小策略模型在奖励方向上过度优化。反过来如果 kl_coef 设置太大策略模型始终被压着不敢更新reward 几乎不动。排查方式打印每步 KL 数值。KL 不是越低越好也不是越高越好而是要看它是否在正常区间随训练变化。如果 KL 从 0 快速飙到几十基本可以确定 KL 惩罚失效。处理建议KL 系数从 0.05 附近开始调每跑一次实验观察 KL 曲线再按数量级调整。6.3 评测集污染与指标失真导致“看起来很强用起来很弱”现象模型在评测集上表现很好换一批新问题后效果明显下降。原因评测集出现在训练数据里或者评测集的 prompt 风格被模型记住甚至评测集本身的答案规则写得太简单模型靠猜测就能得分。排查方式把评测集拆成训练前完全没见过的 holdout 集在训练日志里记录评测集的 hash 值检查公开数据集的去重情况。处理建议定期从业务真实场景中抽取一批新样本加入评测集不要长期只用同一个公开榜单。对推理类任务至少准备一套格式不同但逻辑等价的新题目。6.4 资源估算失误强化学习训练不是 SFT 的简单翻倍现象训练平台内存不够、显存溢出、任务排队时间过长甚至训练到一半因为日志太大导致磁盘写满。原因RL 训练需要反复执行“采样 - 算奖励 - 更新策略”的循环采样阶段会持续产生大量文本和 KV Cache。相比 SFTRL 训练对存储、网络和显存的消耗都不是线性增长。排查方式训练前先做小规模 rollout 测试统计单步采样耗时、显存峰值、日志写入速率、checkpoint 文件大小。处理建议提前规划磁盘空间设置日志滚动按固定步数清理旧 rollout 数据把 checkpoint 保存到独立存储系统。生产环境至少预留两倍于常规训练的资源余量。7. 给研究工程师和团队的几条实践建议7.1 在追热点之前先建立一个能复现的基线看到新闻热点就立刻去复现 o1 是不可取的。真正稳妥的做法是先在自己的业务场景里建立 SFT 基线再用 RFT 尝试一轮提升确认数据链路和评估体系可靠后再上 RLVR 或 RLHF。基线的意义不是比谁分数高而是让你在后训练迭代时能区分“模型能力提升”和“数据变化带来的偶然波动”。没有基线一切实验都是噪声。7.2 不同阶段选择不同的对齐策略不要一个方案用到底阶段优先方案原因产品起步SFT RFT成本低、稳定、易上线需要更高指令跟随质量RLHF / DPO能覆盖开放任务的人类偏好数学、代码等可验证任务RLVR GRPO信号明确、训练稳定通用推理增强RLVR 测试时计算用推理延长换取正确率很多团队一上来就上 PPO结果数据、奖励、评估都没准备好最后训练失败还误以为是算法问题。正确的做法是按任务性质选择方案。7.3 记录实验、冻结数据、控制变量RL 训练的不确定性远高于 SFT实验管理不能靠记忆。至少需要固化以下信息数据版本和评分规则基座模型和 SFT 版本的 hash 值超参组合和随机种子rollout 采样温度奖励函数全部逻辑评估集版本和评估脚本版本。只要有一个环节没记录训练结果异常时基本无法定位。推荐用实验管理平台或至少一份每次训练自动生成的配置快照。7.4 关注可复现性随机种子、框架版本、依赖锁定框架版本对 RL 训练的复现影响很大。TRL、veRL、DeepSpeed 的版本差异可能导致采样行为、梯度累积方式甚至损失计算方式不同。团队内部建议锁定完整的依赖清单用固定版本的框架跑基线实验。生产环境升级框架前先在少数量级上做对比实验确认评估指标没有明显回退后再全量切换。7.5 从这条新闻里最值得带走的一句话Barret Zoph 从 OpenAI 到 Google代表的是语言模型后训练这门手艺在头部公司之间的加速扩散。对普通工程师来说真正有价值的不是记住这个人事新闻而是把后训练强化学习当成一条完整的技术栈来学从 SFT、奖励模型、PPO到 RLVR、GRPO、测试时计算每一步都有清晰的实验方法也都能在小规模环境里练出判断力。AI 领域的人才流动会一直发生底层模型也会持续更迭但“用强化学习引导模型在可验证任务上不断提高正确率”这条技术主线会在未来很长一段时间内保持稳定。你现在投入学习的时间不会因为某个人换了一家公司而贬值。