05-01 偏好对齐选型 解决「用哪种对齐算法」;本篇解决「偏好数据从哪来、怎样才够用」。DPO 对偏好对质量的敏感度高于对数量级的盲目堆叠。
段末注释:chosen / rejected 指同一 prompt 下,人类或规则判定「更好 / 更差」的两条 assistant 回复;DPO 学习增大两者对数似然差。
系列索引:微调技术路线导读
一、偏好数据在流水线中的位置
1 | SFT checkpoint |
二、数据来源
| 来源 | 优点 | 缺点 |
|---|---|---|
| 人工并排标注 | 质量高、可控 | 成本高、吞吐低 |
| 用户隐式反馈 | 真实分布 | 噪声大;需 KTO 或清洗 |
| AI 评判(LLM-as-judge) | 可扩展 | 偏见与位置偏差;需抽检 |
| 拒绝采样(best-of-N) | 自动化 | 需可靠 scorer / 单元测试 |
| 规则 / 程序校验 | 客观(代码、格式) | 仅适用可验证任务 |
三、构造流程示例(拒绝采样)
适用于有明确评分函数的任务(格式合规、单测、答案键):
1 | def build_preference(prompt, generate_fn, score_fn, n=4): |
对话质量任务可用 GPT-4 评判 或 人工 Rubric(有帮助、无害、真实、简洁各 1–5 分)。
四、TRL 数据格式
1 | { |
prompt在 chosen/rejected 间必须相同(仅 assistant 段不同)。- 多轮时 prompt 含完整 history,chosen/rejected 通常只含最后一轮 assistant(依 TRL 版本文档为准)。
- 与 01-01 Chat Template 共用 tokenizer。
五、质量要求
| 要求 | 说明 |
|---|---|
| 可区分度 | chosen 明显优于 rejected;近似对会引入噪声 |
| 长度平衡 | 避免 chosen 系统性更短/更长(长度偏见) |
| 多样性 | prompt 覆盖业务场景,防过拟合少数模板 |
| 与 SFT 一致 | system prompt、风格与 SFT 阶段对齐 |
| 安全 | rejected 可含违规示例,但勿过度强化有害模式 |
经验量级:数千至数万高质量对常已有效;先 1k 人工金标 + AI 扩展,再迭代。
六、与 KTO / ORPO 的数据差异
| 方法 | 数据形态 |
|---|---|
| DPO | 成对 chosen / rejected |
| KTO | (prompt, completion, label_good/bad) 单边 |
| ORPO | SFT 样本 + 偏好对可混在同一训练流 |
七、常见踩坑
| 现象 | 原因 | 对策 |
|---|---|---|
| DPO 后更啰嗦 | chosen 平均更长 | 长度归一化;重标 |
| 对齐无效 | chosen/rejected 差异太小 | 提高标注指南区分度 |
| 安全性下降 | rejected 毒性过强 | 过滤 rejected 中的极端有害内容 |
| 格式崩 | prompt 与 SFT 不一致 | 统一 system 与 template |
八、小结
偏好数据 = 同源 prompt + 可区分的 chosen/rejected + 与 SFT 格式一致。代码任务优先拒绝采样 + 单测;对话任务优先人工金标 + AI 扩展。
下一步:06-01 DPOTrainer 详解。