上周帮朋友看他微调的一个 7B 对话模型过程特别典型DPO 训练跑了一夜loss 曲线漂亮得很从 0.69 一路滑到 0.1 以下训练日志里没有任何报错。第二天拿测试问题一问模型答得又长又啰嗦还把不该输出的东西往外吐比 SFT 刚结束时还差。他盯着屏幕愣了半天问了我一句loss 明明在降怎么会越练越差如果你也打算亲手给模型做偏好训练这个坑大概率会碰上。今天把这件事拆开讲讲。DPO 到底替你省了什么先交代背景。想让一个预训练模型听话主流路线一直是 RLHFReinforcement Learning from Human Feedback基于人类反馈的强化学习先训一个奖励模型来模拟人类的偏好打分再用 PPO 这类强化学习算法让模型去刷这个分数。这条路线效果是被验证过的但工程上出了名的难伺候——同一时间要在显存里装四个模型训练中的策略模型、算 KL 散度用的冻结参考模型、奖励模型外加 PPO 需要的价值网络。7B 模型起步就得好几张专业卡而且超参数一多调起来非常熬人。2023 年 5 月Stanford 的团队在论文《Direct Preference Optimization》里提出了 DPODirect Preference Optimization直接偏好优化思路相当于把上面这套流程合并同类项数学上可以证明奖励模型那一环可以被重参数化掉直接把偏好数据塞进一个类似分类任务的损失函数里优化。不需要单独训奖励模型不需要在线采样一个训练循环、一个损失函数跟做 SFT监督微调差不多省心。这个简化太诱人了。Hugging Face 的 TRL 库里一个DPOTrainer就能跑这两年开源社区的对齐微调大部分都换成了 DPO 或它的变体。但省掉的是工程复杂度不是思考——有些东西被简化掉了代价会在训练之后才冒出来。loss 降了模型为什么反而变差回到开头那个朋友的案例。我把他的训练配置要过来一看β 设了 0.5学习率用的是 SFT 阶段的原值偏好数据是拿 GPT 批量生成的好回答和坏回答——好回答一律长篇大论坏回答一律两三句话完事。问题就出在这几处。DPO 的损失函数里有个 βbeta控制着模型偏离参考模型的幅度。β 越大模型被拽得越紧不敢乱动偏好信号学不进去β 越小模型放飞自我为了讨好偏好数据什么都敢干。Zephyr 那篇工作用的 β 是 0.17B 级别常见参考范围在 0.1 到 0.3——0.5 明显偏大了。但这还不是最致命的真正的元凶是那批数据所有 chosen 回答都比 rejected 长模型从里面学到的不是什么回答更好而是长回答得分高。DPO 论文自己就承认了这个问题——损失函数对序列长度有隐式偏好模型会系统性地把回答变长。再叠加学习率没降SFT 学到的东西被一轮训练冲掉不少输出自然开始失控。还有一个反直觉的事实值得单独说loss 降到 0.1 以下不是好事。DPO 的理论初始 loss 是 -ln(0.5) ≈ 0.693意思是模型对偏好对五五开分不清。训练健康的状态是它稳步下降最后停在一个正值区间如果一路降到接近 0大概率说明模型把训练集里那点偏好对背下来了过拟合了。loss 是在你给的偏好数据上算的它降得漂亮只代表你的数据被拟合了不代表模型变好了。顺便说一个我第一次跑 DPO 时踩过的实现级错误计算序列的 log probability 时要把整个回答序列的概率加起来还要用 loss mask 把 prompt 部分遮掉——我当时没遮把 prompt 的 token 也算进去了训练照样在跑loss 照样在降模型却在学一些完全不对的东西。这种错误日志层面完全看不出来只有评测能兜底。数据层面还有个容易被忽略的坑偏好对内部的长度要对齐好也别用来自不同模型的回答拼数据。不同模型的文风差异本身就是一种强信号模型会先学会模仿文风而不是你真正想教的能力。另外 DPO 是从 SFT 模型出发做偏好优化的设计没做过 SFT 的 base 模型直接上 DPO效果通常很难看——此前有工作对比过 base 模型直接 DPO效果明显不如先 SFT 再 DPO。这套方法的边界在哪把镜头拉远一点看。DPO 不是更好的 RLHF它是不同的 RLHF——把灵活性换成了简单性。它省掉奖励模型的同时也失去了一些东西奖励信号只能来自离线偏好对没法接规则打分、外部分类器这类在线信号没有在线采样的探索模型只能学你给过的答案泛化能力受数据覆盖面限制。所以现在头部团队训练推理模型走的基本是 RLVR用可验证奖励做强化学习那类在线路线——代码能跑通、数学题答案对不对这些是可以程序化验证的不需要人工标注偏好。DPO 更适合的场景是主观偏好语气好不好、格式合不合意、符合不符合业务调性这类东西标不出对错只能两两比较。选择上我的个人判断是这样数据质量高、目标是主观偏好、工程资源有限DPO 是性价比最高的选项奖励可以被程序化验证、追求推理能力上限上在线强化学习两者不冲突很多流水线是 SFT 打底后面接什么看目标。数据质量是共同的命门——偏好数据混乱DPO 会更快地把混乱学进去RLHF 也不会好到哪里去。回到朋友那个模型最后是这样救回来的β 降到 0.1学习率砍到原来的十分之一偏好数据重标了一遍——chosen 和 rejected 控制在相近长度差异集中在内容质量上。重训之后评测分回来了长度也正常了。整个过程没有奇迹就是把每个环节该做对的事情做对。写这篇文章的动机其实是那个晚上的一个感受DPO 把 RLHF 的门槛从需要一套 RL 基础设施降到了一个训练脚本但训练脚本越容易跑起来人越容易跳过对数据和超参数的思考。工具降低的是操作成本降低不了理解成本。你跑 DPO 的时候踩过什么坑β 和学习率你是怎么定的还是跟我一样先盲跑再返工评论区聊聊我想看看大家的数据是怎么标的。