第 14 章：偏好对齐：RLHF / DPO / RLAIF¶
1. 本章要解决的问题¶
第 12 章里，我们讲了 SFT：怎样把一个预训练底座塑造成“会按指令回答”的助手模型。
第 13 章里，我们又进一步讲了：当模型变大、预算有限时，怎样用 LoRA / QLoRA / PEFT 更省资源地完成这类微调。
但如果你真的把一个只做过 SFT 的模型拿来和人交互，很快还会遇到一个新的问题：
它虽然已经“会回答了”，但不一定“回答得让人满意”。
比如同样一个问题，模型可能会出现这些情况：
- 两个答案都基本正确，但一个更啰嗦、一个更清楚
- 都没有明显事实错误，但一个更有帮助，另一个像在敷衍
- 都完成了任务，但一个更安全、边界感更强
- 明明知道答案，却总喜欢过度自信地下结论
- 面对模糊问题时，不会先澄清，而是直接编下去
这说明一件很关键的事：
SFT 教会模型“模仿示范答案”，但很多真实偏好并不容易被单条标准答案完整表达。
用户真正关心的，常常不是“这个回答是否唯一正确”，而是：
- 哪个回答更有帮助
- 哪个更自然
- 哪个更符合人类预期
- 哪个更值得被产品采纳
这就是偏好对齐要解决的问题。
从全书结构上看，这一章有三个作用：
- 它承接第 12、13 章，把“监督微调”推进到“基于偏好的后训练”
- 它解释为什么现代助手模型通常不止做 SFT，还会继续做 alignment
- 它也为后面的应用工程打基础，因为 RAG、Agent、生产系统里很多体验差异，本质上都和模型有没有被良好对齐有关
如果第 12 章回答的是：
怎样让模型学会按示范回答。
那么这一章要回答的就是：
当“可回答”还不等于“更好回答”时，我们怎样把人类偏好进一步变成训练信号，让模型在多个可行答案之间更稳定地朝我们想要的方向靠拢。
2. 你学完后应该会什么¶
- 能解释为什么做完 SFT 之后，很多模型还要继续做偏好对齐
- 能理解
chosen / rejected这类偏好数据到底在表达什么 - 能说清 reward model 在 RLHF 流程里扮演什么角色
- 能理解 PPO + KL penalty 的核心直觉，而不是只记名词
- 能说清 DPO 为什么更简单，以及它和 RLHF 的关系
- 能理解 RLAIF 为什么更便宜、更可扩展，同时也更容易引入新的偏差
- 能知道什么时候该优先做 SFT，什么时候偏好对齐才真正值得投入
3. 为什么 SFT 之后还不够¶
先把这一章最重要的判断说清楚：
SFT 解决的是“会不会答”，偏好对齐解决的是“多个能答的答案里，哪种更好”。
3.1 单个标准答案往往不够表达真实偏好¶
在很多任务里，并不存在唯一标准回答。
例如用户问：
下面两个答案可能都对：
- 答案 A：强调 self-attention 去掉了时间步递归依赖
- 答案 B：同时解释了并行计算、mask 约束和训练效率提升
如果只是做 SFT，你通常只能给模型一个参考答案，让它去模仿。
但真实世界里，我们常常更想表达的是：
B 比 A 更好。
这个“更好”可能来自：
- 更完整
- 更简洁
- 更礼貌
- 更少幻觉
- 更符合系统风格
- 更安全
这类信息不是单条监督标签，而更像一种排序关系。
3.2 助手产品优化的很多目标，本质上是偏好优化¶
当模型进入产品环境后，你优化的通常不再只是“答对率”，还包括：
- 有帮助但不过度啰嗦
- 诚实，不知道时承认不知道
- 尽量减少危险建议
- 更稳定地遵守角色和风格约束
- 面对含糊任务时先澄清而不是乱猜
这些目标里，有些可以通过写更多 SFT 数据解决，但很多时候更直接的表达方式是：
给模型看两个候选回答，告诉它哪个更值得偏好。
3.3 这也是“对齐”这个词的含义¶
所谓 alignment，本质上不是一个神秘术语，而是：
让模型的输出行为更贴近我们真正想要的目标。
这里的“我们”可能是：
- 人类标注者的偏好
- 产品设计者的体验目标
- 安全规范
- 企业内部使用约束
所以偏好对齐并不是在替代 SFT，而是在 SFT 之后继续做一层更细粒度的行为塑形。
4. 偏好数据长什么样¶
和 SFT 的 instruction-output 数据不同，偏好对齐最常见的数据不是“唯一答案”，而是“成对比较”。
4.1 最常见格式：prompt + chosen + rejected¶
一个最典型的样本可以写成：
{
"prompt": "请解释什么是过拟合，并给出两个缓解方法。",
"chosen": "过拟合指模型在训练集上表现很好，但在未见数据上泛化较差。常见缓解方法包括增加正则化，以及使用更多样的数据或数据增强。",
"rejected": "过拟合就是模型效果不好。解决方法是多训练几轮，通常就可以了。"
}
这里最重要的不是 chosen 本身有多完美，而是：
在这个 prompt 下，chosen 比 rejected 更符合偏好。
4.2 偏好信号本质上是相对的¶
这一点非常重要。
偏好数据通常表达的不是：
这个答案绝对值是 9 分。
而是：
在这两个候选里，这个更好。
所以偏好学习更接近排序，而不是传统回归。
4.3 偏好数据从哪里来¶
常见来源包括：
- 人类标注者对多个候选回答做两两比较
- 从旧模型采样多个答案，再让人选最好或排顺序
- 基于规则或安全规范自动构造一部分偏好对
- 用更强模型充当评审器，产生 AI feedback
这也对应了后面几条主线：
RLHF：Reinforcement Learning from Human FeedbackRLAIF：Reinforcement Learning from AI FeedbackDPO：直接在偏好对上优化，不显式跑 RL
5. RLHF：经典偏好对齐流程到底在做什么¶
RLHF 是偏好对齐里最经典、也最常被提到的一条路线。
但很多初学者一听 RLHF，就会误以为：
是不是突然从语言模型训练跳到了游戏强化学习？
其实不是。它的核心仍然是：
先把“人类更喜欢哪个回答”变成一个可优化信号，再让模型朝高偏好方向调整。
5.1 RLHF 的三步主线¶
一个经典 RLHF 流程通常可以概括成三步：
- 先做 SFT，得到一个基础助手模型
- 用偏好比较数据训练一个 reward model
- 用强化学习继续优化策略模型，让它产出更高 reward 的回答
这里第 1 步非常关键。
因为如果模型连基本指令跟随都没学会，后面的偏好优化会非常不稳定。
所以现实里通常不是“预训练后直接 RLHF”，而是：
Pretraining -> SFT -> Preference Alignment
5.2 reward model 在学什么¶
reward model 可以理解成一个“可微的偏好打分器”。
它的输入通常是：
- prompt
- 候选回答
输出是一个标量分数，表示这个回答有多符合偏好。
训练时，它看到的是类似：
于是 reward model 学到的不是世界真理，而是：
什么样的回答更像是人类会偏好的回答。
5.3 为什么要先训练 reward model¶
因为人类偏好标注很贵，不可能在模型训练的每一步都实时请人打分。
所以 RLHF 的工程思路是：
先用一批人类比较数据训练一个近似评委，再让这个评委在大规模训练中持续给反馈。
这样你就把稀缺的人类偏好，变成了一个可以批量调用的学习信号。
6. PPO 和 KL penalty：RLHF 里的核心直觉¶
当我们有了 reward model，下一步就是继续训练语言模型，让它生成更高 reward 的回答。
经典做法里常见的是 PPO 一类强化学习算法。
这里不追求完整强化学习推导，而先抓住最重要的直觉。
6.1 策略模型在优化什么¶
把当前语言模型看成一个策略 pi(y | x)：
x是 prompty是生成的回答
我们希望它生成的回答既：
- reward 更高
- 又不要偏离原来的 SFT 模型太远
为什么不能只追求 reward 最大？
因为 reward model 本身只是一个近似器。
如果你放任模型疯狂钻 reward model 的空子，它可能学会：
- 过度模板化
- 迎合某些表面特征
- 输出非常长但没信息量的内容
- 出现 reward hacking
6.2 KL penalty 在防什么¶
这也是 RLHF 里经常会看到 KL 惩罚项的原因。
它的作用可以粗略理解为：
别为了追高 reward，一下子跑离原来的 SFT 分布太远。
所以 RLHF 优化的通常不是单纯 reward，而更像：
这里的参考模型通常就是 SFT 模型或它的冻结副本。
6.3 PPO 为什么常见¶
PPO 流行的原因，不是因为它和文本天然绑定，而是因为它在策略优化里相对稳定、工程上较成熟。
在 RLHF 语境下，你可以把它理解成：
一种在“提高奖励”和“别一次更新太猛”之间做折中的优化方法。
对于面试或入门理解来说，先抓住下面这层已经很够用了：
- reward model 提供偏好分数
- PPO 负责更新生成策略
- KL penalty 负责防止模型发散
7. RLHF 的价值与代价¶
RLHF 能让模型在很多体验维度上明显变好，但它并不是“白捡的提升”。
7.1 它的价值¶
RLHF 常见收益包括：
- 回答更像一个可用助手
- 更愿意遵守人类交互习惯
- 更少明显冒犯或失控回答
- 对“有帮助、诚实、无害”这类目标更敏感
很多现代聊天模型之所以“像助手”，很大一部分就来自这类后训练，而不只是预训练本身。
7.2 它的代价¶
但 RLHF 也有明显成本：
- 需要高质量偏好数据
- 人类标注昂贵
- reward model 本身可能带偏差
- RL 训练复杂，调参和稳定性要求更高
- 一不小心就会出现 reward hacking 或能力退化
所以很多团队后来会问：
有没有更简单的方法，既利用偏好数据，又少掉复杂的 RL 过程？
这就引出了 DPO。
8. DPO：为什么它这两年这么流行¶
DPO 是 Direct Preference Optimization。
它之所以流行，一个非常现实的原因是：
它把“偏好优化”这件事变得更像普通监督训练。
8.1 DPO 解决的核心痛点¶
传统 RLHF 需要：
- 训练 reward model
- 再跑强化学习
- 再处理策略稳定性和 KL 约束
这条链路有效，但工程复杂度高。
DPO 的出发点是：
如果我们的目标本来就是让模型更偏好 chosen、压低 rejected，那能不能直接在偏好对上优化，而不显式训练 reward model、也不显式跑 PPO？
答案是可以。
8.2 DPO 的直觉是什么¶
DPO 的核心直觉非常朴素：
在同一个 prompt 下，模型应该给 chosen 更高概率，给 rejected 更低概率；
同时，这种偏好不是无限放大，而是相对于一个参考模型来定义。
于是它优化的本质可以理解成：
- 提高模型对
chosen的相对偏好 - 降低模型对
rejected的相对偏好 - 不让模型脱离参考分布太远
如果你回忆第 12 章的 SFT，会发现这里依然没有离开语言模型的核心：
比较序列概率。
只是现在比较的不再是“标准答案 token loss 小不小”，而是：
chosen 相对 rejected 的对数概率差，够不够朝正确方向。
8.3 为什么很多团队更喜欢 DPO¶
因为它通常有这些优势：
- 流程更短
- 不需要单独训练 reward model
- 不需要完整 RL 管线
- 更容易复用现有 SFT 训练框架
- 在中小团队里更容易落地
所以这几年很多开源对齐实践，都会优先从 DPO 开始，而不是上来就完整 RLHF。
9. DPO 和 RLHF 的关系，不是“谁彻底淘汰谁”¶
这里很容易出现一个误解：
既然 DPO 更简单，是不是 RLHF 就过时了？
不能这么理解。
更准确地说：
- RLHF 是更经典、更完整的一类偏好优化框架
- DPO 是在很多场景下更简洁、更工程友好的替代路线
什么时候 DPO 特别合适？
- 你已经有较干净的偏好对数据
- 你想快速验证 alignment 效果
- 你团队不想维护复杂的 RL 训练链路
- 你更偏向研究或中等规模工程实验
什么时候 RLHF 仍然有价值？
- 你已经有成熟 reward modeling 基础设施
- 你需要更细的在线优化能力
- 你希望对奖励设计、探索策略有更强控制
所以在实践里，二者更像是不同成本结构下的工具选择，而不是简单替代关系。
10. RLAIF：把“人类反馈”换成“AI 反馈”¶
如果说 RLHF 的瓶颈之一是人类标注贵，那么一个自然想法就是：
能不能让一个更强的模型先帮我们做一部分偏好判断？
这就是 RLAIF，Reinforcement Learning from AI Feedback。
10.1 它在做什么¶
RLAIF 并不是说完全不需要人类，而是：
用 AI 评审器替代一部分人工偏好标注或人工奖励信号。
例如你可以：
- 让一个更强模型比较两个候选答案谁更有帮助
- 让它依据安全规则判断哪个回答风险更高
- 让它根据 rubric 给回答排序或打分
然后再把这些 AI 反馈用于 reward modeling、DPO 或其他偏好优化流程。
10.2 为什么它有吸引力¶
因为它通常更：
- 便宜
- 快
- 可扩展
- 容易覆盖长尾任务
很多团队之所以越来越依赖 AI feedback，不是因为它一定更准确，而是因为：
人类反馈太稀缺，而模型迭代速度太快。
10.3 它的风险在哪里¶
RLAIF 的核心风险是“把评委的偏差一起规模化复制”。
常见问题包括：
- 更强模型本身也会有偏见
- 它可能偏好某种固定话风，而不是真正高质量内容
- 如果 rubric 设计不好，AI 评审容易奖励表面形式
- 模型评模型，可能出现同类错误的自我强化
所以一个比较稳妥的现实原则是：
AI feedback 很适合放大数据规模，但最好仍然用一部分高质量人工评估做校准。
11. 三条路线怎么放在一起理解¶
学到这里，可以把 RLHF、DPO、RLAIF 放进同一个框架里看。
11.1 它们都在做同一件大事¶
共同目标都是：
利用偏好信号，让模型在多个可行回答中更稳定地选择更符合目标的那个。
11.2 它们的主要区别¶
RLHF 更像：
- 先学一个 reward model
- 再用 RL 优化策略
- 表达能力强，但训练链路更长
DPO 更像：
- 直接在偏好对上优化序列概率
- 省掉显式 reward model 和 RL
- 流程更简洁，工程门槛更低
RLAIF 更像：
- 不是一种单独损失函数
- 而是“反馈来自 AI 而不是主要来自人类”的数据来源策略
所以你完全可以看到这样的组合：
- 人类偏好数据做 DPO
- AI 偏好数据做 DPO
- AI 打分训练 reward model，再做 RLHF
它们并不是互斥关系。
12. 偏好对齐常见会把模型“调坏”吗¶
会，而且这恰恰是对齐工作最值得警惕的地方之一。
12.1 过度对齐可能压掉原始能力¶
如果偏好数据太单一，模型可能会学成：
- 什么都特别礼貌，但信息密度下降
- 什么都先说免责声明，回答效率很差
- 面对复杂问题过度保守
- 把“安全”误学成“少说、拒说、套话”
这类现象在社区里常被概括为“模型变钝了”。
12.2 训练信号会塑造风格，不只是塑造正确性¶
这也是为什么做 alignment 时，不能只问“安全没安全”，还要问：
- 是否仍然有帮助
- 是否仍然清晰
- 是否仍然保留推理与任务完成能力
换句话说，偏好对齐优化的不是单一维度，而是一个多目标平衡。
12.3 所以评估必须跟上¶
第 11 章讲过，评估不是最后补的成绩单。
到了 alignment 阶段，这句话更加成立。
你至少要同时关注：
- 偏好目标有没有提升
- 通用任务能力有没有掉
- 安全性是否真的提高
- 风格是否变得过度模板化
如果只盯某一类偏好分数，很容易把模型往错误方向推。
13. 一个最小可用的实践视角¶
如果你是初学者，或者你所在团队资源有限，一个比较现实的认知顺序通常是：
13.1 先别跳过 SFT¶
绝大多数情况下，SFT 仍然是第一步。
因为偏好对齐不是拿来补基础能力缺口的，而是拿来在已有助手行为上做进一步塑形。
13.2 有偏好数据时，优先理解 chosen / rejected¶
不管你最后跑 DPO 还是更复杂流程，先把数据想清楚：
- prompt 是什么
- 为什么 chosen 更好
- rejected 差在哪里
- 偏好标准是否一致
很多 alignment 失败，本质上不是算法不够先进，而是偏好数据本身不稳定。
13.3 中小规模实验通常可以先从 DPO 入手¶
因为它更容易接在已有的 SFT / LoRA 管线上。
特别是在开源模型实验、课程项目、求职作品里，DPO 往往比“完整 PPO-RLHF 系统”更现实。
13.4 别把“更对齐”误解成“万能更强”¶
alignment 会改善交互体验，但不自动等于：
- 知识更多
- 检索更准
- 工具调用更稳
- 事实性永远更好
很多能力问题仍然要靠：
- 更好的底座
- 更好的数据
- 更强的检索
- 更合理的系统设计
这也是为什么书的后半部分会继续进入 embedding、RAG、Agent 和部署。
14. 本章小结¶
这一章我们真正想建立的，不是几个缩写的死记硬背，而是一条清晰主线：
- SFT 让模型学会按示范回答
- 偏好对齐让模型在多个可回答的选项里，更稳定地朝“更好回答”靠近
- RLHF 的思路是：人类偏好 -> reward model -> RL 优化
- DPO 的思路是：直接在
chosen / rejected偏好对上做相对优化 - RLAIF 的思路是：让 AI 帮我们规模化产生反馈，但要警惕把偏差一起放大
所以如果有人问：
为什么现代聊天模型通常不止做 SFT？
一个比较完整的回答应该是：
因为“会答”不等于“答得更符合人类偏好”。SFT 更多是在学任务示范，而 alignment 则是在继续优化帮助性、稳定性、安全性和交互体验。
15. 下一章：为什么对齐还不能解决“知识不在上下文里”这个问题¶
讲完偏好对齐之后，很容易产生另一个误解：
既然我们已经能把模型调得更像助手了，是不是很多应用问题就都解决了？
还没有。
因为模型即使：
- 更礼貌
- 更听话
- 更符合偏好
也仍然可能不知道你公司私有文档里的内容，也不一定记得最新知识，更无法天然访问外部数据库。
这就引出了应用工程里另一条非常关键的路线：
不是只改模型参数，而是把外部知识通过向量表示和检索机制接进来。
所以下一章，我们会先补上这条链路的基础：
什么是 embedding，为什么语义检索需要向量表示，向量数据库到底在保存什么。