为什么很多团队从 PPO 转向 DPO，却又离不开 PPO

如果你在纠结“选 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 就不会再让你纠结了。