Skip to content
Published on

DPOからKTOまで：人間フィードバックアラインメント技法の最新論文レビューと実践実装

🇰🇷KO🇺🇸EN🇯🇵JA
Authors
  • Name
    Twitter
DPOからKTOまで：人間フィードバックアラインメント技法の最新論文レビューと実践実装

なぜRLHF以降のアラインメント技法が必要なのか

LLMを人間の好みに合わせる作業、すなわちアラインメントは、ChatGPT以降すべてのプロダクションLLMの必須パイプラインとなった。OpenAIがInstructGPT（Ouyang et al., 2022, arxiv:2203.02155）で確立したRLHF（Reinforcement Learning from Human Feedback）パイプラインは3段階で構成される。SFT（Supervised Fine-Tuning）で基本能力を植え付け、報酬モデル（Reward Model）を別途学習し、PPO（Proximal Policy Optimization）でポリシーを最適化する。

この3段階パイプラインは強力だが運用コストが大きい。報酬モデルの学習に別途GPU資源が必要で、PPO学習時にpolicy model、reference model、reward model、value modelの4つのモデルを同時にメモリに載せる必要がある。70Bモデル基準で最低A100 80GB 8枚以上が必要になる。学習の安定性も問題だ。PPOのクリッピング比率、KLペナルティ係数、GAE lambdaなど敏感なハイパーパラメータが多く、一発で収束するケースは稀だ。

2023年下半期から、この複雑性を根本的に減らす研究が相次いだ。DPOが報酬モデルなしで選好データから直接ポリシーを最適化できることを示し、IPOがBradley-Terry仮定の危険性を指摘し、KTOがペアワイズ（pairwise）選好データなしで二値信号のみでアラインメントできることを証明した。2024-2025年にはSimPO、ORPO、GRPOなどが登場し、アラインメント技法の選択肢が急速に広がった。

本記事では、RLHFからDPO、IPO、KTO、そして最新技法までの論文をレビューし、Hugging Face TRLライブラリを活用した実践実装コードとハイパーパラメータチューニング戦略、失敗事例と復旧手順を扱う。

RLHFパイプラインの構造と限界

3段階パイプラインの詳細

RLHFの全体フローを数式で整理すると以下のとおりである。

第1段階 - SFT：高品質なinstruction-responseペアでベースモデルをファインチューニングする。

第2段階 - Reward Model学習：同一プロンプトに対して2つの応答を生成し、人間の評価者が好む応答（chosen）とそうでない応答（rejected）をラベリングする。Bradley-Terryモデルに基づいて報酬関数r(x, y)を学習する。

L_RM = -E[log sigma(r(x, y_w) - r(x, y_l))]

ここで、y_wはchosen、y_lはrejected応答である。

第3段階 - PPO最適化：報酬モデルのスコアを最大化しつつ、reference policyとのKL divergenceで制約する。

max E[r(x, y)] - beta * KL(pi_theta || pi_ref)

RLHFの実務的限界

限界説明
メモリコストPolicy、Reference、Reward、Valueの4モデル同時ロード
学習不安定PPOクリッピング、KL係数、learning rateなど敏感なハイパーパラメータ多数
Reward hacking報酬モデルの脆弱性を悪用するポリシー学習の可能性
データコストペアワイズ比較データ収集に人間評価者のコスト発生
再現性同一設定でもseedによって結果が大きく変動

これらの限界が、DPOなどRL-freeアラインメント技法の登場背景である。

DPO：報酬モデルなしの直接選好最適化

主要論文レビュー

Direct Preference Optimization: Your Language Model is Secretly a Reward Model (Rafailov et al., 2023, NeurIPS 2023, arxiv:2305.18290)

DPOの核心的洞察は簡潔だ。RLHFの報酬関数最適化問題にはclosed-form解が存在し、これを利用すれば報酬モデルを明示的に学習しなくても選好データから直接ポリシーを最適化できる。

RLHFの最適ポリシーは以下の形式をとる：

pi*(y|x) = (1/Z(x)) * pi_ref(y|x) * exp(r(x, y) / beta)

これを逆に解くと、報酬関数をポリシーの比率で表現できる：

r(x, y) = beta * log(pi_theta(y|x) / pi_ref(y|x)) + beta * log Z(x)

この関係をBradley-Terryモデルに代入するとZ(x)項が相殺され、最終的なDPO損失関数が導出される：

L_DPO = -E[log sigma(beta * (log(pi_theta(y_w|x)/pi_ref(y_w|x)) - log(pi_theta(y_l|x)/pi_ref(y_l|x))))]

重要な点は、DPOが報酬モデルを「除去」したのではなく「暗黙的に含んでいる」という事実だ。ポリシー自体が報酬モデルの役割を兼ねるため、別途の報酬モデル学習とPPOステージが不要になる。

DPOの長所と限界

長所：実装がシンプルだ。cross-entropy lossと類似した形式であるため、SFTとほぼ同一の学習コードで実装可能だ。メモリ使用量もpolicy + referenceの2モデルのみで、RLHF比約半分の水準だ。Hugging Face TRLのDPOTrainerを使えば、数十行のコードで全パイプラインを構成できる。

限界：DPOはBradley-Terryモデルの仮定に依存する。人間の選好が常にこのモデルに従うとは限らない。また、SFTなしでベースモデルに直接DPOを適用すると、応答が冗長になったり（rambling）、ハルシネーション（hallucination）が増加する現象が報告されている。chosen/rejectedペアデータの品質が低い場合、学習が収束しないか、性能がかえって低下する可能性がある。

TRLベースのDPO実装

from datasets import load_dataset
from transformers import AutoModelForCausalLM, AutoTokenizer
from trl import DPOConfig, DPOTrainer

# 1. モデルとトークナイザーのロード
model_name = "Qwen/Qwen2.5-1.5B-Instruct"
model = AutoModelForCausalLM.from_pretrained(model_name, torch_dtype="bfloat16")
tokenizer = AutoTokenizer.from_pretrained(model_name)

# 2. 選好データのロード（prompt, chosen, rejected構造）
dataset = load_dataset("trl-lib/ultrafeedback_binarized", split="train[:5000]")

# 3. DPO学習設定
training_args = DPOConfig(
    output_dir="./dpo-qwen2.5-1.5b",
    per_device_train_batch_size=2,
    gradient_accumulation_steps=8,
    learning_rate=5e-7,       # DPOでは非常に低いlearning rateが必須
    beta=0.1,                 # KL制約の強度
    max_length=1024,
    max_prompt_length=512,
    num_train_epochs=1,
    bf16=True,
    logging_steps=10,
    save_strategy="steps",
    save_steps=500,
    warmup_ratio=0.1,
    gradient_checkpointing=True,
)

# 4. DPO Trainerの作成と学習
trainer = DPOTrainer(
    model=model,
    args=training_args,
    train_dataset=dataset,
    processing_class=tokenizer,
)
trainer.train()
trainer.save_model("./dpo-qwen2.5-1.5b-final")

上記コードで最も重要なハイパーパラメータはbetaとlearning_rateだ。betaが高すぎるとreference modelに過度に近づきアラインメント効果が微弱になり、低すぎるとポリシーが不安定になる。learning rateはSFT比10倍以上低く設定するのが一般的だ。

IPO：Bradley-Terry仮定の危険性

主要論文レビュー

A General Theoretical Paradigm to Understand Learning from Human Preferences (Azar et al., 2024, AISTATS 2024, arxiv:2310.12036)

IPO（Identity Preference Optimization）は、DPOの核心的仮定であるBradley-Terryモデルに疑問を呈する。Bradley-Terryモデルはペアワイズ選好をpointwise報酬値に変換するが、この変換過程で情報損失が発生し、過学習（overfitting）のリスクが高まるというのがIPOの核心的主張だ。

IPOはより一般的なフレームワークであるPsiPO（Psi-Preference Optimization）を提案し、その特殊ケースとしてidentity関数を使用するIPOを導出する。IPOの損失関数は以下のとおりだ：

L_IPO = E[(log(pi_theta(y_w|x)/pi_ref(y_w|x)) - log(pi_theta(y_l|x)/pi_ref(y_l|x)) - 1/(2*beta))^2]

DPOがlog-sigmoidを使用するのと異なり、IPOはsquared lossを使用する。この違いが過学習に対する頑健性を高める。DPOではchosenの確率を無限に高め、rejectedの確率を無限に低くする方向に最適化が進む可能性があるが、IPOではtarget margin（1/2beta）に収束するよう制約される。

IPOの推奨beta値はDPO（0.1〜0.5）よりはるかに低い0.01水準だ。これはIPOのloss構造がDPOと根本的に異なるためであり、同一のbeta値を使用してはならない。

KTO：ペアワイズデータなしで二値信号によるアラインメント

主要論文レビュー

KTO: Model Alignment as Prospect Theoretic Optimization (Ethayarajh & Jurafsky, 2024, ICML 2024, arxiv:2402.01306)

KTOの最大の革新はデータ要件の変化だ。DPOとIPOは同一プロンプトに対するchosen/rejectedペアが必要だが、KTOは個別応答に対する二値ラベル（「良い」または「悪い」）のみで十分だ。これは実務で大きな違いを生む。ペアワイズ比較データの収集コストは二値ラベリングの5〜10倍に達するためだ。

KTOの理論的基盤はKahnemanとTverskyのプロスペクト理論（Prospect Theory）だ。人間は利得より損失に敏感に反応するという損失回避（loss aversion）現象を、アラインメントの目的関数に直接反映する。

KTOはHALO（Human-Aware Loss Objective）フレームワークを提案し、既存のアラインメント技法が暗黙的にプロスペクト理論の偏りを含んでいることを示す。DPOの成功も部分的にはこうした人間の認知バイアスを反映しているためだという分析だ。

KTOの損失関数はdesirable応答とundesirable応答に対して非対称に定義される：

L_KTO = E_desirable[1 - sigma(beta * (log(pi/pi_ref) - z_ref))]
      + lambda * E_undesirable[1 - sigma(beta * (z_ref - log(pi/pi_ref)))]

ここで、z_refはKL divergenceの推定値であり、lambdaは損失回避係数（デフォルトは約1.33で、プロスペクト理論の実験結果に由来）である。

KTOの実験結果

KTOは1Bから30Bスケールまで、DPOと同等以上の性能を示した。特にSFTなしでベースモデルに直接適用した場合、DPOで見られるrambling現象がKTOでは発生しなかった。これはKTOの非対称loss構造が不良応答に対してより強いペナルティを課すためと解釈される。

TRLベースのKTO実装

from datasets import load_dataset
from transformers import AutoModelForCausalLM, AutoTokenizer
from trl.experimental.kto import KTOConfig, KTOTrainer

# 1. モデルのロード
model_name = "Qwen/Qwen2.5-1.5B-Instruct"
model = AutoModelForCausalLM.from_pretrained(model_name, torch_dtype="bfloat16")
tokenizer = AutoTokenizer.from_pretrained(model_name)

# 2. KTOデータのロード（prompt, completion, label構造）
# label: True(desirable) / False(undesirable)
dataset = load_dataset("trl-lib/kto-mix-14k", split="train")

# 3. KTO学習設定
training_args = KTOConfig(
    output_dir="./kto-qwen2.5-1.5b",
    per_device_train_batch_size=4,
    gradient_accumulation_steps=4,
    learning_rate=5e-7,
    beta=0.1,                       # KL制約の強度
    desirable_weight=1.0,           # desirable応答の重み
    undesirable_weight=1.0,         # undesirable応答の重み
    max_length=1024,
    max_prompt_length=512,
    num_train_epochs=1,
    bf16=True,
    logging_steps=10,
    gradient_checkpointing=True,
)

# 4. KTO Trainerの作成と学習
trainer = KTOTrainer(
    model=model,
    args=training_args,
    train_dataset=dataset,
    processing_class=tokenizer,
)
trainer.train()
trainer.save_model("./kto-qwen2.5-1.5b-final")

KTOデータ形式の核心は、ペアワイズデータではなく個別応答ラベルという点だ。既にthumbs-up/thumbs-downフィードバックを収集しているなら、データ変換なしでそのままKTO学習に活用できる。

最新アラインメント技法：SimPO、ORPO、GRPO

SimPO (Simple Preference Optimization)

SimPO: Simple Preference Optimization with a Reference-Free Reward (Meng et al., 2024, arxiv:2405.14734)

SimPOはreference modelを完全に除去する。DPOではreference modelがポリシーの逸脱を防ぐ役割を果たすが、SimPOは応答長で正規化された平均log probabilityを報酬信号として使用することでこの問題を解決する。AlpacaEval 2とArena-HardでDPOを有意に上回る性能を示した。

reference modelが不要なため、メモリ使用量がDPO比半分に削減される。単一GPUでも7Bモデルのアラインメント学習が可能になった。

ORPO (Odds-Ratio Preference Optimization)

ORPOはSFTとアラインメントを単一目的関数に統合する。SFT lossにodds-ratioベースの選好lossを追加することで、別途のSFTステージなしに1回の学習でinstruction followingと選好アラインメントを同時に達成する。KLペナルティも除去したため、betaチューニングが不要だ。

GRPO (Group Relative Policy Optimization)

DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models (Shao et al., 2024, arxiv:2402.03300)

DeepSeekが提案したGRPOは、PPOのvalue network（critic model）を除去してRLHFのメモリ要件を約50%削減する。1つのプロンプトに対して複数の応答をグループとしてサンプリングし、グループ内の相対的報酬でadvantageを推定する。別途のcritic modelが不要で、実装と学習がシンプルになる。

DeepSeek-R1の学習でもGRPOが重要な役割を果たし、特に数学やコーディングのようなverifiableなタスクで強力な性能を示している。

アルゴリズム比較テーブル

項目RLHF (PPO)DPOIPOKTOSimPOORPOGRPO
報酬モデル明示的学習が必要暗黙的（ポリシーに内在）暗黙的暗黙的不要不要明示的/ルールベース
Reference Model必要必要必要必要不要不要必要
データ形式ペアワイズペアワイズペアワイズバイナリペアワイズペアワイズルールベース報酬
メモリ使用量非常に高い（4モデル）高い（2モデル）高い（2モデル）高い（2モデル）中程度（1モデル）中程度（1モデル）高い（2モデル）
主要ハイパーパラメータKL coeff, clip ratio, GAE lambdabeta, lrbetabeta, lambdagamma, betalambdaclip ratio, KL coeff
学習安定性低い中程度高い中〜高高い高い中程度
実装難易度高い低い低い低い非常に低い非常に低い中程度
推奨beta-0.1〜0.50.010.1〜0.32.0〜2.5--
SFT事前学習の必要性はい強く推奨推奨任意推奨不要（統合）はい

ハイパーパラメータチューニングガイド

Betaパラメータチューニング

betaはすべてのDPO系技法で最も重要なハイパーパラメータだ。reference policyとの距離を制御するKL制約の強度を決定する。

# beta値別の学習挙動分析スクリプト
import torch
import matplotlib.pyplot as plt

def dpo_loss_landscape(beta_values, log_ratio_range):
    """beta値別のDPO loss曲面を可視化"""
    fig, axes = plt.subplots(1, len(beta_values), figsize=(5*len(beta_values), 4))

    for idx, beta in enumerate(beta_values):
        log_ratios = torch.linspace(-log_ratio_range, log_ratio_range, 200)
        # DPO loss: -log(sigma(beta * (log_ratio_w - log_ratio_l)))
        # ここではlog_ratio_w - log_ratio_lを単一変数として扱う
        loss = -torch.log(torch.sigmoid(beta * log_ratios))
        gradient = -beta * (1 - torch.sigmoid(beta * log_ratios))

        ax = axes[idx]
        ax.plot(log_ratios.numpy(), loss.numpy(), label="Loss", color="blue")
        ax.plot(log_ratios.numpy(), gradient.numpy(), label="Gradient", color="red")
        ax.set_title(f"beta = {beta}")
        ax.set_xlabel("log(pi/pi_ref)_w - log(pi/pi_ref)_l")
        ax.legend()
        ax.grid(True)

    plt.tight_layout()
    plt.savefig("dpo_beta_analysis.png", dpi=150)
    plt.show()

# betaが大きくなるほどloss曲面が急峻になり、学習がより攻撃的になる
dpo_loss_landscape([0.05, 0.1, 0.3, 0.5], log_ratio_range=5.0)

実践チューニング戦略：

  • モデルサイズが小さいほど（1B〜3B）betaを低く（0.05〜0.1）設定する。小さなモデルはreference policyから逸脱しやすいためだ。
  • モデルサイズが大きいほど（7B〜70B）betaを高く（0.1〜0.5）設定しても安定的だ。
  • 選好データの品質が高いほどbetaを下げ、より攻撃的に学習させることができる。
  • データ品質が不確実な場合はbeta=0.1から始め、validation lossを基準に調整する。

Learning Rateチューニング

DPOではlearning rateをSFT比5〜20倍低く設定するのが標準だ。

モデルサイズSFT LRDPO LR推奨範囲備考
1B〜3B2e-51e-6〜5e-7過学習リスクが高い
7B〜13B1e-55e-7〜1e-7最も安定的な区間
30B〜70B5e-61e-7〜5e-8gradient accumulationが必須

learning rateが高すぎるとreference policyから急激に逸脱し、out-of-distribution応答が増加する。低すぎるとchosen/rejectedの識別能力が十分に学習されず、win rate改善が微弱になる。

選好データ構築実践ガイド

DPOデータ形式変換

def convert_to_dpo_format(raw_data):
    """様々な元データをDPO学習形式に変換

    DPOはprompt、chosen、rejectedの3フィールドが必要。
    各フィールドはconversation形式（list of dict）を推奨。
    """
    dpo_dataset = []

    for item in raw_data:
        prompt = item["instruction"]

        # 方法1：人間評価者による直接比較
        if "chosen_response" in item and "rejected_response" in item:
            entry = {
                "prompt": [{"role": "user", "content": prompt}],
                "chosen": [{"role": "assistant", "content": item["chosen_response"]}],
                "rejected": [{"role": "assistant", "content": item["rejected_response"]}],
            }
            dpo_dataset.append(entry)

        # 方法2：スコアベースの自動変換（rating >= 4: chosen, rating <= 2: rejected）
        elif "responses" in item:
            responses = sorted(item["responses"], key=lambda x: x["rating"], reverse=True)
            if len(responses) >= 2 and responses[0]["rating"] >= 4 and responses[-1]["rating"] <= 2:
                entry = {
                    "prompt": [{"role": "user", "content": prompt}],
                    "chosen": [{"role": "assistant", "content": responses[0]["text"]}],
                    "rejected": [{"role": "assistant", "content": responses[-1]["text"]}],
                }
                dpo_dataset.append(entry)

    return dpo_dataset

KTOデータ形式変換

def convert_to_kto_format(raw_data):
    """既存のフィードバックデータをKTO形式に変換

    KTOはprompt、completion、labelの3フィールドが必要。
    labelはTrue（desirable）またはFalse（undesirable）。
    ペアワイズデータが不要なので、thumbs-up/downデータを直接活用可能。
    """
    kto_dataset = []

    for item in raw_data:
        prompt = item["instruction"]

        # 方法1：thumbs-up/downフィードバックの直接活用
        if "response" in item and "thumbs_up" in item:
            entry = {
                "prompt": [{"role": "user", "content": prompt}],
                "completion": [{"role": "assistant", "content": item["response"]}],
                "label": item["thumbs_up"],  # True or False
            }
            kto_dataset.append(entry)

        # 方法2：ratingベースの二値変換
        elif "response" in item and "rating" in item:
            entry = {
                "prompt": [{"role": "user", "content": prompt}],
                "completion": [{"role": "assistant", "content": item["response"]}],
                "label": item["rating"] >= 4,  # 4点以上：desirable
            }
            kto_dataset.append(entry)

        # 方法3：DPOペアワイズデータからKTOデータを生成
        if "chosen_response" in item and "rejected_response" in item:
            kto_dataset.append({
                "prompt": [{"role": "user", "content": prompt}],
                "completion": [{"role": "assistant", "content": item["chosen_response"]}],
                "label": True,
            })
            kto_dataset.append({
                "prompt": [{"role": "user", "content": prompt}],
                "completion": [{"role": "assistant", "content": item["rejected_response"]}],
                "label": False,
            })

    return kto_dataset

DPOデータをKTO形式に変換するのは簡単だが、その逆は不可能だ。これがKTOの実用的な利点である。ペアワイズ比較なしで収集された二値フィードバックデータが既に存在する組織では、KTOが唯一の選択肢となり得る。

実践トラブルシューティング：よくある失敗事例と復旧

失敗事例1：DPO学習後の応答品質低下

症状：DPO学習後、モデルが短く不誠実な応答を生成するか、逆に極端に冗長な応答を生成する。

原因分析：chosenとrejectedの品質差が不明確なデータが多数含まれている場合に発生する。特にrejected応答が実際には合理的な回答で、chosenより「やや劣る」程度の場合、モデルが正しい方向を学習できない。

復旧手順：

  1. データフィルタリング：chosenとrejectedの報酬モデルスコア差が閾値（例：0.5）未満のペアを除去する。
  2. betaを上げて（0.3〜0.5）reference policyに近い状態を維持する。
  3. learning rateをさらに下げる（現在値の1/2）。
  4. SFTチェックポイントが十分に学習されているか確認する。

失敗事例2：KTOでのdesirable/undesirable比率の不均衡

症状：学習が収束しない、またはdesirable応答の確率のみ上昇し、undesirable応答の確率が変化しない。

原因分析：desirableデータがundesirableデータの5倍以上多い場合、undesirableに対するgradient信号が希釈される。KTO論文ではdesirable:undesirable比率を1:1〜4:1の間で推奨している。

復旧手順：

  1. undesirable_weightを上げる（例：1.0から2.0へ）。
  2. undesirableデータをオーバーサンプリングする。
  3. 比率が極端な場合（10:1以上）はDPOへの切り替えを検討する。

失敗事例3：学習初期のloss爆発

症状：学習開始後数十ステップ以内にlossが急激に増加し、NaNが発生する。

原因分析：reference modelと学習モデルの初期差が大きすぎるか、learning rateが過度に高い場合に発生する。SFTチェックポイントの代わりにベースモデルをreferenceとして使用すると、特にこの問題が顕著になる。

復旧手順：

  1. learning rateを1/5に削減する。
  2. warmup_ratioを0.1以上に設定する。
  3. reference modelと学習モデルを同一のSFTチェックポイントから開始する。
  4. bf16の代わりにfp32に切り替えて数値安定性を確認する。
  5. gradient clippingを1.0に設定する。

失敗事例4：過学習 - validation lossが上昇しtrain lossのみ低下

症状：train lossは減少するがvalidation lossがエポック中盤から上昇する。生成品質がトレーニングデータのchosen応答をそのままコピーする様相を示す。

復旧手順：

  1. validation lossが最低のチェックポイントで学習を中断する（early stopping）。
  2. データ量に対してエポック数が適切か確認する。通常1〜3エポックで十分だ。
  3. IPOへの切り替えを検討する。IPOはsquared loss構造のため過学習により頑健だ。

UNA：RLHF/DPO/KTOを統合するフレームワーク

最近の研究で注目すべきものにUNA（Unifying Alignments）フレームワーク（arxiv:2408.15339）がある。UNAはRLHF（PPO）、DPO、KTOを一般化された暗黙的報酬関数で統合する。核心的洞察は、3つの技法すべてが「暗黙的報酬と明示的報酬の差を最小化するsupervised learning」として再解釈できるということだ。

この観点から見ると、pairwiseフィードバック（DPO）、binaryフィードバック（KTO）、scalarフィードバック（RLHF）は同一の目的関数の異なる特殊ケースに該当する。実務的には保有データの形態に応じて適切な技法を選択すればよく、複数の形態のフィードバックデータが混在する場合、UNAフレームワークがこれらを統合的に活用できる。

アラインメント技法選択チェックリスト

アラインメント技法を選択する際、以下のチェックリストを順番に確認する。

データ形態の確認

  • ペアワイズ比較データ（AがBより良い）があるか？ -> DPO、IPO、SimPOが使用可能
  • 二値フィードバックデータ（良い/悪い）のみあるか？ -> KTOを使用
  • 数値スコア（1〜5点）があるか？ -> 閾値ベースでDPOまたはKTO形式に変換
  • 検証可能な正解が存在するタスクか？ -> GRPOを検討

インフラの確認

  • GPUメモリが48GB以上か？ -> DPO、IPO、KTOすべて可能
  • GPUメモリが24GB以下か？ -> SimPOまたはORPO推奨（reference model不要）
  • 別途のSFT学習を行う余裕があるか？ -> DPO + SFTパイプライン
  • SFTとアラインメントを一度に済ませたいか？ -> ORPO

品質要件の確認

  • 過学習が懸念されるか？ -> IPO（squared lossで過学習防止）
  • SFTなしでベースモデルに直接適用する必要があるか？ -> KTO（rambling現象が少ない）
  • データ品質が不確実か？ -> betaを高く設定してIPOを使用
  • 最大性能が目標か？ -> DPO + 高品質ペアワイズデータの組み合わせ

運用上の注意事項

  • 学習前にreference modelチェックポイントを必ず別途保存したか？
  • validation setを分離したか？（最低でも全データの5%）
  • gradient checkpointingを有効化したか？（メモリ節約）
  • wandbなどの学習ロギングを設定したか？
  • chosen/rejected（またはdesirable/undesirable）データの品質を手動で検査したか？

評価パイプライン：アラインメント結果の検証

アラインメント学習後のモデル品質を定量的に評価することは必須だ。単にlossが下がったからといってアラインメントが成功したわけではない。

# アラインメントモデル評価のためのwin rate計算スクリプト
import torch
from transformers import AutoModelForCausalLM, AutoTokenizer

def calculate_win_rate(model_path, ref_model_path, eval_prompts, tokenizer_name):
    """アラインメントモデル vs referenceモデルのwin rateを報酬モデルで評価"""
    model = AutoModelForCausalLM.from_pretrained(model_path, torch_dtype=torch.bfloat16)
    ref_model = AutoModelForCausalLM.from_pretrained(ref_model_path, torch_dtype=torch.bfloat16)
    tokenizer = AutoTokenizer.from_pretrained(tokenizer_name)

    wins, total = 0, 0

    for prompt in eval_prompts:
        inputs = tokenizer(prompt, return_tensors="pt")

        # アラインメントモデルの応答生成
        with torch.no_grad():
            aligned_output = model.generate(
                **inputs, max_new_tokens=512,
                temperature=0.7, do_sample=True
            )
            ref_output = ref_model.generate(
                **inputs, max_new_tokens=512,
                temperature=0.7, do_sample=True
            )

        aligned_text = tokenizer.decode(aligned_output[0], skip_special_tokens=True)
        ref_text = tokenizer.decode(ref_output[0], skip_special_tokens=True)

        # ここにjudge modelまたはreward modelによる比較評価ロジックを追加
        # 例：GPT-4をjudgeとして使用、または学習済みreward modelを活用
        # win = judge(prompt, aligned_text, ref_text)
        # wins += win
        total += 1

    return wins / total if total > 0 else 0.0

評価時の注意点は、self-evaluation（アラインメントモデルが自分自身を評価すること）を避けることだ。別途のjudge modelや人間の評価を併用することが、信頼性のある結果を得る方法だ。AlpacaEval、MT-Bench、Arena-Hardなどの標準ベンチマークの活用も推奨される。

2025-2026年のアラインメント研究の方向性

現在のアラインメント研究はいくつかの方向に急速に進化している。

Verifier-driven RL：GRPOの成功に続き、数学・コーディングなど正解検証が可能なタスクでルールベース報酬を活用する方向が強化されている。人間のフィードバックなしでもアラインメントが可能な領域が拡大している。

Online DPO / Iterative DPO：学習中のモデルが直接応答を生成し、それに基づいて選好データを更新するオンライン方式が、オフラインDPO比で性能向上を示している。ただし学習コストが増加するトレードオフが存在する。

Multi-objective alignment：単純に「良い応答」ではなく、helpfulness、harmlessness、honestyなど複数の軸を同時に最適化する研究が活発だ。Mo-KTO（Multi-Objective KTO）のような拡張も提案されている。

Synthetic preference data：人間の評価者の代わりに強力なLLM（GPT-4、Claudeなど）で選好データを生成する技法が普及している。コストは大幅に削減されるが、judge modelのバイアスがそのまま転移される危険があり注意が必要だ。

まとめ

RLHFからDPOへ、DPOからKTOへの進化は、単なるアルゴリズムの改善ではなく、「アラインメントに必要な最小条件とは何か」という根本的な問いに対する答えを探す過程だ。RLHFは明示的報酬モデルとRLループが必要だったが、DPOは報酬モデルを除去し、KTOはペアワイズ比較データさえ不要にした。

実務での選択は、理論的優越性よりも保有データの形態、インフラ制約、チームの経験レベルによって決定される。ペアワイズ比較データと十分なGPUがあればDPOが実証済みの選択肢であり、二値フィードバックデータのみであればKTOが唯一の選択肢だ。メモリが限られていればSimPOやORPOを検討し、verifiableなタスクであればGRPOが強力な代替案だ。

どの技法を選択するにしても、データ品質がすべてを決定する。1万件の高品質選好データは10万件の低品質データより優れている。学習前のデータ検査、学習中のvalidationモニタリング、学習後の体系的評価を省略しないことが、成功するアラインメントの鍵だ。

References

  1. DPO - Rafailov et al., "Direct Preference Optimization: Your Language Model is Secretly a Reward Model", NeurIPS 2023. arxiv:2305.18290
  2. KTO - Ethayarajh & Jurafsky, "KTO: Model Alignment as Prospect Theoretic Optimization", ICML 2024. arxiv:2402.01306
  3. IPO - Azar et al., "A General Theoretical Paradigm to Understand Learning from Human Preferences", AISTATS 2024. arxiv:2310.12036
  4. GRPO - Shao et al., "DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models", 2024. arxiv:2402.03300
  5. SimPO - Meng et al., "SimPO: Simple Preference Optimization with a Reference-Free Reward", 2024. arxiv:2405.14734
  6. UNA - "UNA: Unifying Alignments of RLHF/PPO, DPO and KTO by a Generalized Implicit Reward Function", 2024. arxiv:2408.15339
  7. DPO Comprehensive Survey - "A Comprehensive Survey of Direct Preference Optimization: Datasets, Theories, Variants, and Applications", 2024. arxiv:2410.15595
  8. Hugging Face TRL - DPO Trainer Documentation. https://huggingface.co/docs/trl/main/en/dpo_trainer
  9. Hugging Face TRL - KTO Trainer Documentation. https://huggingface.co/docs/trl/main/en/kto_trainer
  10. InstructGPT - Ouyang et al., "Training language models to follow instructions with human feedback", NeurIPS 2022. arxiv:2203.02155
Discuss on Twitter • View on GitHub