preference-optimization

偏好优化

此技能假设 finetuning-method-selection 已将任务路由至此，因为数据形态是 偏好对或未配对的点赞/点踩 反馈，而非演示（那是 lora-qlora-recipes）或可验证的奖励 信号（那是 grpo-rlvr-training）。以下内容 是 DPO 家族中的方法选择、 该选择实际重要程度的证据、生产 训练模式，以及最初如何构建这些配对。

输入： 一个路由决策（偏好 优化）加上偏好对或未配对 反馈，通常来自 SFT 检查点。 输出格式： 一个经过验证的方法选择加上 一个配置——references/method-configs.md 中的 kwarg 值，而非自由形式的 建议——供 llm-finetuning-training-engineer 直接使用。

方法选择

数据形态	方法	关键参数
偏好对，默认情况	DPO	β=0.1，LR 5e-7–1e-6，1–2 个 epoch
内存受限或没有 SFT 检查点	ORPO	无参考模型，将 SFT+偏好融合到单一损失中
未配对的点赞/点踩	KTO	每个样本一个二分类标签，无需配对
观察到长度偏差，有 sweep 预算	SimPO	无参考模型；见下方 sweep 网格

• DPO 是安全的默认选择。 使用 β=0.1 和 5e-7 至 1e-6 的学习率，训练 1–2 个 epoch。 该 LR 低于 生成被对齐检查点的 SFT LR——将 SFT 规模的 LR 移植到 DPO 运行中 是这里最常见的 错误配置，而非边缘情况。
• ORPO 在内存成为 约束时介入，或在没有独立的 SFT 检查点可作为起点时介入——它无需参考模型， 并将 SFT 和偏好目标融合为 单一损失，跳过独立的 SFT 过程以及 DPO 所携带的参考模型内存成本。
• KTO 在反馈是未配对的 二分类信号（点赞/点踩）而非 匹配的偏好对时介入——不要强行将未配对的 反馈合成配对以改用 DPO。
• SimPO 修复了 DPO 的长度偏差，但只有 在严格 sweep 的情况下才有收益——其已发表的 增益是在调优 sweep 下报告的上限， 而非任何单一配置都能复现的基线。 仅在有 sweep 预算时路由至此；如果没有， 则改用 DPO。
• 经典 RLHF（奖励模型 + PPO）已退役， 在前沿实验室之外不再使用。不要在生产 流水线中使用它——对于相同的数据 形态，上述每种方法都更便宜且支持更好。

示例

• "我们有一个 SFT 检查点和干净的配对 偏好数据，尚无长度偏差的抱怨。" → 默认情况 → DPO，β=0.1。
• "评审者对每条回复点击点赞/点踩； 没有任何配对。" → 未配对信号 → KTO，而非 DPO——不要合成配对以 强行将 DPO 用于未配对数据。
• "GPU 预算无法覆盖独立的 SFT 过程 加上 DPO 参考模型。" → 内存受限， 无独立检查点 → ORPO。
• "DPO 输出偏好更长的答案，不论 质量，且有 time 运行 sweep。" → 长度偏差加上 sweep 预算 → SimPO。如果 sweep 预算实际上不存在，则跳过它。

低杠杆的真相

一项 2026 年、240 次 H100 运行的研究（arXiv 2603.19335）是上表背后的关键证据： 损失函数的选择大约只值 1 个百分点的杠杆，而模型规模大约值 50 个百分点。 测试的 20 种 DPO 变体中，没有任何一种优于原版 DPO。排名还会随规模而反转——在小规模试点中胜出的变体，在部署规模上可能落败。

两个实际结论：

• 不要在一个路由决策上纠结于 DPO 变体的对比测试。上表已经足够；相比数据质量和规模，更深入的变体选择属于低杠杆。
• 在信任某个排名之前，先在部署规模上验证。 在小规模试点模型上运行的方法对比无法迁移到生产规模级别——一旦规模变化，就要重新检查胜出者。

这也是上文的 Method Selection 表故意做得很短的原因：它编码的是约 1pp 的杠杆，而不是同一项研究显示无法跨规模成立的 DPO 变体排名。凡是不在该表中的变体选择建议——包括声称某个特定变体“胜出”的建议——在目标部署规模上得到验证之前，都应视为未经证实。

生产模式：迭代式 On-Policy DPO

在静态偏好数据集上做一次离线 DPO 只是起点，不是生产模式。随着训练推进，策略会偏离这些配对采样的分布，而静态数据集会相对这种漂移而变得过时。生产流水线会迭代式、on-policy 地运行 DPO：

1. 从当前策略检查点采样补全。
2. 对补全进行评分或排名（奖励模型、评判器或任务评分器）。
3. 以当前检查点作为参考模型，运行一次 DPO。
4. 得到的检查点既成为新的策略，也成为下一轮的参考模型。

重复。每一轮的参考模型都是上一轮的输出，而不是固定的初始检查点——这正是让偏好信号保持 on-policy 的原因，而不是针对一个日益过时的分布进行评分。

单次 DPO 运行仍然是一个合理的第一轮迭代——它只是并非整个流水线。一旦第一个检查点存在，就应规划至少再进行一轮，而不是把第一轮当作最终成品。

配对构建

从同一任务的通过 vs 失败轨迹构建 DPO/ORPO 配对——即对同一底层任务的两次尝试，而不是从不同任务中抽取的互不相关的最佳与最差示例。在该轨迹集合内，以奖励分布的 μ−2σ、绝不用最小值来选择被拒绝的成员。朴素的最佳 vs 最差配对构建（最大奖励 vs 绝对最小值）会随规模增大而退化；μ−2σ 选择对上述低杠杆研究揭示的同一规模敏感性更为稳健。

sorted_by_reward = sort(trajectories, key=reward)
chosen   = sorted_by_reward[-1]                # highest reward
mu, sigma = mean(rewards), stdev(rewards)
rejected = closest(sorted_by_reward, mu - 2 * sigma)
# NOT sorted_by_reward[0] — the absolute minimum
# is the naive best-vs-worst construction that
# degrades as scale increases.

关于将评分轨迹转化为这些配对的机制——包括拒绝采样和评判器评分的差值选择——参见 trace-to-training-data。

参考资料

各方法的完整 TRL 配置块—— DPOConfig、ORPOConfig、KTOConfig 以及 SimPO 扫描网格——外加 Unsloth 封装和一个 灾难性遗忘的说明，都位于 references/method-configs.md。这些配置使用 与 lora-qlora-recipes 的 references/unsloth-trl-mapping.md 中确立的 相同的当前 TRL API 约定 （使用 processing_class，而非 tokenizer=）。

references/method-configs.md 还带有 灾难性遗忘的说明：当偏好微调的 检查点丧失通用能力时，学习率过高 是常见原因，而修复方法几乎总是 将学习率下调至上文“方法选择”表中 范围的低端，然后再考虑任何其他补救措施。

相关技能：一旦偏好对或无配对 反馈存在，finetuning-method-selection 就会路由到此处；lora-qlora-recipes 产出 DPO/KTO/SimPO 对齐所用的 SFT 检查点（ORPO 的融合路径可跳过它）；trace-to-training-data 将通过/失败的轨迹转换为 本技能“配对构建”部分所 消费的配对。