preference-optimization

選好最適化

このスキルは、データの形がデモンストレーション（それは lora-qlora-recipes）でも検証可能な報酬シグナル（それは grpo-rlvr-training）でもなく、選好ペアまたはペアになっていないサムズアップ/サムズダウンのフィードバックであるために、finetuning-method-selection がすでにここへルーティングしたことを前提としています。以下では、DPO ファミリーの中での手法選択、その選択が実際どれほど重要かについてのエビデンス、本番の学習パターン、そしてそもそもペアをどのように構築するかを扱います。

入力: ルーティングの判断（選好最適化）に加えて、通常は SFT チェックポイントからの選好ペアまたはペアになっていないフィードバック。 出力形式: 検証済みの手法の選択と設定 — references/method-configs.md にある kwarg の値であり、自由形式の助言ではありません — を llm-finetuning-training-engineer が直接消費します。

手法の選択

データの形	手法	主要パラメータ
選好ペア、デフォルトのケース	DPO	β=0.1、LR 5e-7～1e-6、1～2 エポック
メモリ制約がある、または SFT チェックポイントがない	ORPO	参照モデル不要、SFT と選好を 1 つの損失に融合
ペアになっていないサムズアップ/サムズダウン	KTO	例ごとの二値ラベル、ペアリング不要
長さバイアスが観測され、スイープの予算がある	SimPO	参照モデル不要、以下のスイープグリッドを参照

• DPO は安全なデフォルトです。 β=0.1 と 5e-7～1e-6 の学習率を 1～2 エポック使用してください。この学習率は、アラインメント対象のチェックポイントを生成した SFT の学習率よりも低いものです — SFT スケールの学習率をそのまま DPO 実行に持ち込むことは、ここではエッジケースではなく、最もよくある誤設定です。
• ORPO は、メモリが制約となる場合、または出発点となる別個の SFT チェックポイントがない場合にルーティングされます — 参照モデルが不要で、SFT と選好の目的関数を 1 つの損失に融合し、別個の SFT パスと DPO が抱える参照モデルのメモリコストを省きます。
• KTO は、フィードバックがマッチした選好ペアではなく、ペアになっていない二値シグナル（サムズアップ/サムズダウン）である場合にルーティングされます — DPO を使うために、ペアになっていないフィードバックを合成ペアに押し込めないでください。
• SimPO は DPO の長さバイアスを修正しますが、規律あるスイープがあって初めて効果を発揮します — 公表されている改善幅は、調整されたスイープの下で報告された上限であり、単一の設定で再現できるベースラインではありません。スイープの予算がある場合にのみここへルーティングし、なければ DPO を使用してください。
• 従来の RLHF（報酬モデル + PPO）は廃止されています — フロンティアラボの外では。本番パイプラインでこれに手を伸ばさないでください — 同じデータの形に対して、上記のどの手法もより安価で、よりよくサポートされています。

具体例

• 「SFT チェックポイントとクリーンなペア選好データがあり、長さバイアスの不満はまだない。」 → デフォルトのケース → β=0.1 の DPO。
• 「レビュアーは応答ごとにサムズアップ/サムズダウンをクリックし、何もペアになっていない。」 → ペアになっていないシグナル → KTO、DPO ではない — DPO をペアになっていないデータに無理に適用しようとペアを合成しないでください。
• 「GPU 予算が、別個の SFT パスに加えて DPO の参照モデルを賄えない。」 → メモリ制約、別個のチェックポイントなし → ORPO。
• 「DPO の出力が、品質にかかわらずより長い回答を好む。しかもスイープを実行する時間がある。」 → 長さバイアスとスイープ予算 → SimPO。スイープの予算が実際にない場合は見送ってください。

低レバレッジという真実

2026年の240 H100実行による研究（arXiv 2603.19335）は、 上記の表を支える根拠となる証拠です： 損失関数の選択はおよそ1パーセントポイントの レバレッジしか持たず、モデルの規模はおよそ50の 価値があります。 テストされた20種類のDPO バリアントのうち、バニラDPOを上回ったものは ゼロでした。順位はまた規模とともに反転します ——小規模なパイロットで勝つバリアントが、 デプロイ規模では負けることがあります。

実践上の2つの帰結：

• DPOバリアントの比較検討にルーティングの判断を 費やして悩まないでください。上記の表で十分です； より深いバリアント選択は、データ品質や規模と 比べて低レバレッジです。
• 順位を信頼する前にデプロイ規模で検証してください。 小規模なパイロットモデルで実行した手法比較は、 本番の規模クラスにはそのまま当てはまりません ——規模が変わったら勝者を再確認してください。

これがまた、上記の手法選択表が意図的に短い理由でも あります：それは約1ppのレバーを表しており、同じ 研究が規模をまたいで成り立たないことを示している DPOバリアントの順位ではないのです。あの表にない バリアント選択の助言——特定のバリアントが「勝つ」と 主張する助言を含め——は、目標とするデプロイ規模で 検証されるまで、未証明として扱ってください。

本番パターン：反復的なオンポリシーDPO

静的な選好データセットに対する単一のオフラインDPO パスは出発点であり、本番パターンではありません。 学習が進むにつれて、ポリシーはペアがサンプリング された分布から離れていき、静的なデータセットは そのドリフトに対して陳腐化します。本番パイプライン は、DPOを反復的かつオンポリシーで実行します：

1. 現在のポリシーチェックポイントから完了を サンプリングします。
2. 完了をスコアリングまたはランク付けします （報酬モデル、ジャッジ、またはタスクグレーダー）。
3. 現在のチェックポイントを参照モデルとして 使用し、DPOパスを実行します。
4. 得られたチェックポイントは、新しいポリシーかつ 次のラウンドの新しい参照の両方になります。

繰り返します。各ラウンドの参照モデルは、固定された 初期チェックポイントではなく、前のラウンドの出力です ——これにより、選好シグナルがますます陳腐化する分布に 対してスコアリングされるのではなく、オンポリシーに 保たれます。

単一パスのDPO実行は、依然として妥当な最初の イテレーションです——ただし、それはパイプライン全体 ではありません。最初のチェックポイントが存在したら、 少なくとももう1ラウンドを計画し、パス1を完成した 成果物として扱わないようにしてください。

ペアの構築

DPO/ORPOのペアは、同一タスクの成功対失敗の トラジェクトリから構築してください——同じ 根底にあるタスクへの2つの試行であり、異なるタスクから 引っ張ってきた無関係な最良と最悪の例ではありません。 そのトラジェクトリの集合内で、棄却されるメンバーは 報酬分布のμ−2σ、決して最小値ではないように 選択してください。素朴な最良対最悪のペア構築 （最大報酬対絶対最小値）は、規模が大きくなるにつれて 劣化します；μ−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 の慣例 （tokenizer= ではなく processing_class）を そのまま使用しています。

references/method-configs.md には 破滅的忘却に関する注記も含まれています。選好チューニングされた チェックポイントが一般的な能力を失う場合、通常の原因は 学習率が高すぎることです。そして修正方法は、ほぼ常に、 他のあらゆる対処に手を伸ばす前に、上記の「手法の選択」表にある 範囲の下限に向けて学習率を下げることです。

関連スキル: finetuning-method-selection は、選好ペアまたはペアになっていない フィードバックが存在するようになると、ここへルーティングします。lora-qlora-recipes は、 DPO/KTO/SimPO がアラインメントする SFT チェックポイントを生成します（ORPO の 融合パスではこれをスキップできます）。trace-to-training-data は、合格/不合格のトラジェクトリを、このスキルの「ペア構築」セクションが 消費するペアへ変換します。