如果你在纠结“选 PPO 还是 DPO”，问题往往不在算法
在最近一两年里，只要聊到大模型对齐，几乎绕不开一个问题：
“现在还用 PPO 吗？DPO 不是更简单、更稳定吗？”
这种问题，在技术社区里出现得非常频繁。
而且你会发现一个现象：
问这个问题的人，往往已经默认 DPO 是“更先进的替代方案”。
但如果你真的做过几轮对齐项目，会慢慢意识到：
PPO 和 DPO 之间，根本不是“新旧关系”，
而是解决不同阶段问题的工具。
如果你在不合适的阶段，用了“看起来更简单”的方法，
那失败几乎是必然的。
在对比之前，先把一个误区掰正：PPO 和 DPO 解决的不是同一类问题
很多对比文章，一上来就讲：
- PPO：强化学习
- DPO：偏好优化
但在工程实践中，这种分类其实没什么帮助。
更有用的区分方式是：
- PPO：用来“塑形”的
- DPO：用来“定型”的
也就是说：
- PPO 更像是“行为分布的重塑工具”
- DPO 更像是“偏好排序的稳定压缩器”
一旦你用“塑形 vs 定型”的视角去看这两个方法，
它们的适用边界会非常清晰。
PPO vs DPO 的阶段定位示意图
为什么 PPO 会最先出现，而 DPO 后来才被大量采用
这个顺序本身，就已经说明了问题。
PPO 最早被大规模使用，是因为在那个阶段，大家面对的是：
- 模型行为极不稳定
- 安全边界模糊
- 风格不可控
在这种情况下，你需要的是一种强干预手段，
哪怕它复杂、危险、调试成本高。
PPO 恰好满足了这一点。
而 DPO 出现并被广泛采用，是在一个前提之上：
模型的基础行为，已经大致“在轨道上”了。
如果模型本身行为分布就很混乱，
DPO 并不能“救你一把”。
PPO 的核心优势：它能“推着模型走”
这是 PPO 到今天依然不可替代的地方。
在 PPO 中，你可以非常明确地做一件事：
不管模型现在想干嘛，
我都要用 reward 把它往某个方向推。
这种“推力”，在以下场景中极其重要：
- 安全边界收紧
- 风险行为压制
- 风格从激进转向保守
PPO 允许你：
- 主动设定方向
- 接受短期不稳定
- 换取长期行为变化
但这也是 PPO 最大的风险来源
因为你“推得动”，
所以你也很容易推过头。
在真实工程里，PPO 常见的问题包括：
- reward 被模型 hack
- 行为变得极端
- 某些能力被压扁
而且更危险的是：
这些变化，往往是不可逆的。
这也是为什么，PPO 更适合：
- 行为尚未稳定
- 风险容忍度较高
- 有足够评估能力的阶段
DPO 的出现，本质上是在“约束野心”
DPO 的一个核心设计思想是：
不再直接优化 reward，
而是只做偏好排序。
从工程角度看，这意味着：
- 不再需要显式 reward model
- 不再需要 KL 系数调参
- 行为变化更平滑
你可以把 DPO 理解成：
“我不再试图改变模型的世界观，
我只是在它已有的认知里，帮它排个序。”
DPO 偏好排序机制示意图
DPO 为什么看起来“更稳定”，但也“更保守”
这是很多工程师在用过 DPO 后的共同感受。
你会发现：
- 模型不容易崩
- 行为变化可预期
- 训练过程简单
但与此同时：
- 行为提升幅度有限
- 很难做大尺度调整
- 对边界问题影响有限
这是 DPO 的设计结果，而不是缺陷。
它的目标从一开始就不是“重塑行为”，
而是在已有行为空间里做精细选择。
一个非常重要的判断点：模型现在“乱不乱”
这是决定你该用 PPO 还是 DPO 的第一个问题。
你可以问自己：
“如果我不给模型任何约束，它会不会经常做出明显不合适的行为？”
- 如果答案是 会 → PPO 更合适
- 如果答案是 不会，只是细节不理想 → DPO 更合适
这是一个非常工程化、也非常实用的判断方式。
第二个判断点：你能不能接受“行为震荡”
PPO 的一个显著特征是：
- 前几轮训练，行为变化很大
- 输出不稳定
- 甚至短期效果变差
如果你的业务环境：
- 容错率低
- 上线节奏紧
- 不允许反复试错
那 PPO 带来的风险，可能大于收益。
而 DPO 的行为变化，更接近“微调”，
更适合这种环境。
从工程成本角度看，两者的真实差异
很多文章会说：
“DPO 比 PPO 简单。”
这句话本身没错，但它隐藏了前提。
DPO 简单，是因为：
- 它默认你已经有高质量偏好数据
- 模型行为已经比较稳定
如果你连“什么是好输出”都还没想清楚，
那 DPO 的“简单”，只会变成无从下手。
一个简化的对比代码示意（非教学）
PPO 核心思路（极简）：
loss = -reward + kl_coef * kl(policy, reference)
DPO 核心思路（极简）：
loss = -logsigmoid(score(preferred) - score(rejected))
你可以非常直观地看到：
- PPO 是“拉扯式”的
- DPO 是“排序式”的
这两种优化目标，天生就服务于不同阶段。
为什么成熟团队，往往是“先 PPO，后 DPO”
在真实项目中，一个非常常见、但很少被系统性总结的路径是：
- 早期：PPO 强力收敛行为
- 中期：行为稳定后，减少 PPO 使用
- 后期：用 DPO 做精细对齐
这不是“技术演进”，
而是风险管理策略。
PPO 解决“大方向问题”，
DPO 解决“细节一致性问题”。
对齐阶段演进路径示意图
一个常见误解：DPO 能完全替代 PPO
这个误解，正在导致不少项目直接“选错工具”。
如果你的模型：
- 安全边界经常失守
- 行为高度不稳定
- 输出风格摇摆
那 DPO 很可能：
- 学不到有效信号
- 或者只在表层做修饰
因为 DPO 的前提是：
模型本身已经“差不多对了”。
反过来，什么时候你应该从 PPO 转向 DPO
这也是一个非常重要的问题。
一个非常实用的判断信号是：
你发现 PPO 的收益，开始明显小于它带来的风险和成本。
比如：
- 行为变化越来越小
- reward 设计越来越难
- 副作用越来越多
这往往意味着：
你已经进入了“精修阶段”。
在实际工程中，判断“当前阶段更适合 PPO 还是 DPO”，往往需要快速对比两种方法在同一评估集上的行为差异。使用LLaMA-Factory online这类工具并行跑小规模 PPO / DPO 实验，对比输出风格和稳定性，会比单靠经验判断更安全，也更容易说服团队做阶段性切换。
总结：PPO 和 DPO，解决的是“不同阶段的焦虑”
如果要用一句话总结这篇文章，那应该是：
PPO 和 DPO 的区别，不在算法先进性，
而在你现在最害怕什么。
- 害怕模型乱来 → PPO
- 害怕模型不一致 → DPO
真正成熟的技术选择，从来不是“跟风”，
而是清楚自己现在在哪个阶段，要解决哪类问题。
当你把这两个问题想清楚，
PPO 和 DPO 就不会再让你纠结了。
