这个问题之所以反复被问，是因为大家都在“补同一个洞”
在真实项目里，提出这个问题的场景，往往非常相似。
- SFT 已经做过
- 模型能力基本够用
- 行为有点不稳
- 安全、风格、边界总有零星问题
于是有人说：
“要不我们试试 PPO？”
PPO 跑了一轮，效果有提升，但又出现另一种不满意：
- 模型有点“保守”
- 表达不够顺
- 偏好不够贴近业务
这时候又有人说：
“那再加点 DPO，把偏好拉回来。”
于是问题自然就变成了：
PPO 和 DPO 能不能一起用？
会不会更强？
这个问题之所以危险，是因为它看起来非常合理。
但在工程里，“看起来合理”的组合，往往是事故高发区。
PPO / DPO 被引入的典型项目阶段示意图
先给一个不绕弯子的结论
在展开之前，我先把结论直接写出来：
PPO 和 DPO 在工程上“可以一起用”，
但绝大多数项目里，“不该一起用”。
不是因为算法冲突，
而是因为：
它们解决的是不同层次的问题，
一起用时，极容易把责任边界搅乱。
接下来这篇文章要做的事，不是告诉你“怎么一起用”，
而是帮你判断：
你现在这个项目，
有没有资格把它们一起用。
先把两件事说清楚：PPO 和 DPO 到底在“改什么”
很多工程误用，源头其实很简单：
大家对 PPO / DPO 的“作用对象”理解不够清晰。
PPO 改的是什么？
用工程语言说一句非常直白的话：
PPO 改的是“模型在犹豫点的选择倾向”。
它擅长做的是：
- 压低某些你不想看到的行为概率
- 拉高某些你更能接受的行为概率
注意关键词：概率。
PPO 不擅长教模型“什么是对的”，
而是擅长告诉模型：
“在这些情况下，你更该往这边走。”
DPO 改的是什么？
DPO 从工程角度看，本质上是在做一件事：
把一组“人类偏好排序”，
直接固化成模型的输出倾向。
也就是说：
- A 回答 > B 回答
- 那模型以后更像 A
DPO 的特点是：
- 信号更直接
- 收敛更快
- 对风格和取向影响非常明显
但它有一个非常重要的前提：
你提供的偏好，本身是稳定、可信的。
DPO 偏好排序 → 行为固化 示意图
为什么“理论上能一起用”，工程上却很危险
如果只从算法角度看：
- PPO：RL
- DPO：偏好优化
它们确实不存在数学上的直接冲突。
问题出在工程层面。
第一层危险：你开始用两种机制“同时拉模型”
PPO 和 DPO 一起用，最常见的结构是：
SFT → PPO → DPO
或者：
SFT → DPO → PPO
无论顺序如何，本质都是：
你在用两种不同的信号，
同时影响模型的行为选择。
而这两种信号：
- 一个是概率型、模糊的
- 一个是偏好型、强指向的
结果往往是：
模型行为变得“更像你想要的”，
但你自己却越来越说不清：
它到底为什么这么答。
第二层危险：你分不清“风险收敛”和“风格收敛”
在很多项目里，PPO 和 DPO 是被这样使用的：
- PPO：用来“安全对齐”
- DPO：用来“拉回体验”
这听起来非常合理。
但真实情况是：
安全和体验，在模型行为里并不是正交维度。
当你用 DPO 去“修正体验”时，
你很可能在无意中抵消 PPO 对风险的压制。
而这种抵消，不会在 loss 上明显体现，
只会在：
- 极端 case
- 长对话
- 真实用户输入
里慢慢冒出来。
这正是很多团队“不敢上线”的根源。
PPO 风险压制 vs DPO 偏好拉回 冲突示意图
真实工程里，三种常见“翻车组合”
翻车组合一：PPO 负责安全，DPO 负责体验
这是最常见，也最危险的一种组合。
问题在于：
- PPO 给的是“尽量别这样”
- DPO 给的是“这样更好”
当两者冲突时，模型会怎么选？
真实答案是：
看哪一个在训练中“更强势”。
而这个“强势”，你往往并没有精确控制。
结果就是：
- 表面看体验回来了
- 实际上安全边界被悄悄挪动
翻车组合二：先 DPO 定风格，再 PPO 修问题
很多人会觉得这个顺序更“理性”：
“先把模型调成我们想要的样子，
再用 PPO 修掉坏行为。”
但真实情况是：
你在用 PPO 修的，
往往正是 DPO 刚刚固化进去的偏好。
结果就是：
- PPO reward 越来越拧巴
- 模型行为越来越难预测
- 每一轮都像在“拆自己刚搭的积木”
翻车组合三：不同团队同时动 PPO 和 DPO
这是大组织里非常真实的情况。
- 安全团队在调 PPO
- 体验团队在做 DPO
- 两边都“有道理”
但系统层面：
模型正在被两个方向同时拉扯，
而没有任何一方对最终行为负责。
这种项目，几乎一定会走向：
- 上线犹豫
- 回滚频繁
- 最终冻结模型
那是不是意味着：PPO 和 DPO 永远不该一起用？
不是。
但前提非常苛刻。
唯一相对安全的一种组合方式
在我见过的项目里，勉强算“成功”的组合，都有几个共同特征：
- PPO 和 DPO 不在同一阶段生效
- 目标被严格拆分
- 中间有清晰的冻结点
一个更健康的结构是：
SFT
↓
DPO（仅用于风格 / 表达）
↓ 冻结
PPO（仅用于明确红线行为）
注意三个关键词：
- 仅用于
- 明确
- 冻结
一旦你允许：
- DPO 修正 PPO 的结果
- 或 PPO 去补 DPO 的偏好
系统复杂度会指数级上升。
一个非常关键、但很少被正面讨论的问题
在你决定“PPO + DPO 一起用”之前，你其实应该先回答一个问题：
如果模型出现一次严重事故，
你能不能明确说出：
这是 PPO 的责任，还是 DPO 的责任？
- 如果说不清 → 不该一起用
- 如果说得很清楚 → 你才有资格讨论组合
这个问题，比任何实验结果都重要。
为什么很多团队“越调越不敢上线”，和 PPO + DPO 有关
这和你上一篇文章是连着的。
当 PPO + DPO 一起使用时，团队往往会出现一种状态：
- 指标看起来不错
- demo 看起来顺
- 但心里总有点不踏实
原因很简单：
你已经无法用直觉理解模型行为的来源。
而一个你自己都说不清“为什么这样”的系统，
在工程上是不该上线的。
很多团队在 PPO + DPO 上反复试错，真正缺的并不是算法技巧，而是对不同行为来源的可追溯视角。用 LLaMA-Factory online 把 SFT、DPO、PPO 不同阶段的模型版本并行对照，更容易看清：行为变化是从哪一步开始引入的，从而避免把多种对齐手段混在一起用。
总结：PPO + DPO 不是“组合技”，而是“责任考题”
我用一句话，把这篇文章彻底收住：
PPO 和 DPO 能不能一起用，
从来不是算法问题，
而是你能不能为“模型行为的来源”负责。
如果你：
- 能清楚区分它们的职责
- 能接受阶段性冻结
- 能明确谁在为风险兜底
那它们可以一起用。
但如果你只是觉得：
“一起用，应该更强吧？”
那你很可能会得到一个结果：
- 模型确实更复杂了
- 指标确实好看了一点
- 但你再也不敢放心上线
而这，恰恰是工程里最危险的一种成功。
