11. 对齐：SFT、Reward Model、RLHF 与 DPO

11.1 为什么预训练后还要对齐

Base Model 学的是“互联网文本接下来可能出现什么”，不是“用户真正需要什么”。预训练分布可能包含：

• 对话回答。
• 文章续写。
• 错误信息。
• 争论和攻击。
• 不安全操作。

对齐的目标是把条件分布调整到更符合帮助性、真实性、安全性和产品约束的行为。

11.2 经典 RLHF 流程

Base Model
  ↓ SFT
SFT Policy
  ↓ 生成多个回答 + 人类排序
Preference Data
  ↓
Reward Model
  ↓ 强化学习优化，同时限制偏离参考模型
Aligned Policy

Reward Model 学习给回答打分。强化学习阶段最大化奖励，同时使用 KL 惩罚避免模型离参考策略太远。

11.3 DPO 的直觉

DPO 使用：

prompt
chosen answer
rejected answer

直接提高模型相对偏好 chosen 的程度，并参考原模型控制偏移，不必先单独训练 reward model 再运行在线强化学习。

DPO 更简单，不代表数据和评估简单：

• chosen/rejected 差异必须代表真实偏好。
• 偏好可能相互冲突或带标注者偏差。
• 过强优化会损害多样性或知识能力。
• 离线偏好数据覆盖不到的行为仍可能失败。

当前 TRL 的 DPOTrainer 可直接使用 Qwen3-0.6B 和偏好数据做小规模实验。先理解 SFT，再进入 DPO；不要把 GRPO、PPO 等缩写当作学习起点。

11.4 SFT 与 DPO 解决不同问题

SFT：告诉模型“好答案长什么样”
DPO：告诉模型“两个可行答案中更喜欢哪一个”

DPO 不能代替基础知识数据；偏好优化也可能把 reward 或标注偏好中的漏洞放大。

11.5 安全不是一次微调

安全需要全链路：

• 数据来源与隐私治理。
• 安全 SFT/偏好数据。
• 系统提示与权限边界。
• 输入和输出策略。
• 工具调用最小权限。
• 运行时审计、限流和异常检测。
• 红队测试和事故回滚。

模型拒绝得更多不一定更安全；过度拒绝会损害正常任务。需要按风险场景分别评估正确帮助、适当拒答和越权行为。

11.6 Reward Model 到底学什么

对同一 prompt 的 chosen 与 rejected 回答，奖励模型输出标量 r(x,y)。常见成对目标鼓励：

r(x, chosen) > r(x, rejected)

对应的 logistic loss 可写成：

L_RM = -log σ(r_chosen - r_rejected)

奖励分数不是“答案质量的绝对刻度”。它只反映训练偏好数据和标注规则下学到的排序。若标注者把长度、礼貌模板或特定措辞当成好答案的代理，模型可能优化这些表面特征而不提高事实性。

训练 Reward Model 时至少分开检查：

• 成对排序准确率，而不是只看训练 loss。
• 按任务、安全类型、长度和语言分组的准确率。
• chosen/rejected 位置交换后结果是否一致。
• 对模板化、超长和迎合性回答是否存在异常高分。

11.7 DPO 目标中的参考模型

DPO 比较 policy 与 reference 对 chosen/rejected 的相对 log probability。简化写法：

margin_policy = log π(y_w|x) - log π(y_l|x)
margin_ref    = log π_ref(y_w|x) - log π_ref(y_l|x)

L_DPO = -log σ(β × (margin_policy - margin_ref))

其中 y_w 是 chosen，y_l 是 rejected，β 控制相对参考模型的偏好强度。参考模型不是多余副本：它提供“优化前策略”的锚点。实现时还要确认 log probability 是否按 token 求和或归一、padding 和 prompt token 是否被 mask，以及 chosen/rejected 是否使用同一 chat template。

配套实验：直接观察 DPO Objective Notebook。它不下载模型，只用序列 log probability 验证 margin、reference、β 和标签交换。

11.8 动手设计：先审计偏好数据

设计实验｜Preference Data Audit　资源：无需 GPU；产物：数据规范、20 对审计样本、分歧记录和 DPO 评估计划。

每条偏好数据建议包含：

{
  "id": "safety-001",
  "prompt": [{"role": "user", "content": "..."}],
  "chosen": [{"role": "assistant", "content": "..."}],
  "rejected": [{"role": "assistant", "content": "..."}],
  "criterion": "correctness",
  "annotator_notes": "chosen 修正了关键事实错误",
  "source": "human-reviewed"
}

审计顺序：

1. 隐去 chosen/rejected 标签，独立判断哪一个更好以及理由。
2. 检查差异是否只来自长度、格式或语气；若是，明确这是否正是目标偏好。
3. 把事实性、安全性、帮助性和风格拆开标注，避免一对样本同时表达互相冲突的目标。
4. 统计标注分歧；高分歧样本应复审或移出训练集。
5. 按 prompt 或语义簇切分 train/test，防止改写题泄漏。

训练前写出停止条件：目标偏好提高多少才值得接受？通用能力、安全拒答和回答长度允许退化多少？如果没有退出条件，DPO 很容易变成“只要 loss 下降就继续”。

11.9 常见失败与章节验收

章节验收：

1. 能用一张图解释 SFT、Reward Model、PPO/RLHF 和 DPO 的数据与目标差异。
2. 能说明 DPO 为什么仍需要 reference policy 以及 β 的作用。
3. 能发现至少三种偏好数据中的代理特征或标注偏差。
4. 能为帮助性、安全性和过度拒答分别设计指标。
5. 不运行大规模训练，也能提交一份可执行、可停止、可复查的 DPO 实验方案。