RLHF・DPO入門――人間のフィードバックでモデルを改善する手法

RLHFとDPOは、人間の「好み」をLLMに反映させるためのアライメント技術で、ChatGPTのような自然で有益な応答は、これらの手法なしには実現されません。RLHFは強力ですが実装が難しく、DPOはシンプルで安定した学習が可能なため、現代の実務ではDPOが第一選択になっています。とはいえ、どちらの手法も本質は「良質な選好データの確保」であり、「手法を変えればモデルが賢くなる」という期待は、データの質の前では無力であることを忘れてはなりません。

RLHFとは

RLHF(Reinforcement Learning from Human Feedback)は、人間のフィードバックを報酬として強化学習でLLMを最適化する手法です。通常のファインチューニングが「正解例の模倣」を目指すのに対し、RLHFは「より好ましい応答の強化」を目指します。InstructGPTやChatGPTの開発で中核的に使われ、生成AIの実用化を一気に進めた立役者と言ってよいでしょう。

RLHFは典型的には3段階で構成されます。第一段階は教師あり学習(SFT: Supervised Fine-Tuning)で、人間が作成した指示追従データでベースモデルを整えます。第二段階は報酬モデル(Reward Model)の学習で、人間のランキング評価から「応答の良さを数値化する関数」を学習します。第三段階はPPO(Proximal Policy Optimization)による強化学習で、報酬モデルをシグナルとしてLLMをさらに最適化します。

【RLHFの学習フロー】

Stage 1: Supervised Fine-Tuning (SFT)
  [Base LLM] + [指示追従データ]
       |
       v
  [SFT Model]

Stage 2: Reward Model Training
  [SFT Model] --複数応答生成--> [人間ランキング]
                                       |
                                       v
                                [Reward Model]

Stage 3: PPO Optimization
  [SFT Model] --応答--> [Reward Model] --報酬--> PPO
       ^                                          |
       +------------- 重み更新 -------------------+
                                                  v
                                          [RLHF Model]

RLHFの効果は絶大ですが、実装難易度は極めて高いのが実情です。PPOは報酬ハッキング、学習の不安定性、KLダイバージェンスの調整など、職人的なチューニングが必要で、研究チームでも失敗する手法です。MLOpsの基盤がしっかりしていないと、実験管理だけで力尽きます。

DPO(Direct Preference Optimization)とは

DPOは2023年にスタンフォードから発表された手法で、RLHFの複雑さを根本から見直しました。その核心は「報酬モデルを明示的に学習する必要がない」という発見です。選好データ(chosen / rejected のペア)から直接、モデルの尤度比を最適化するだけで、理論的にRLHFと等価な結果が得られることが示されました。

DPOの学習は、基本的には通常のファインチューニングと同じ感覚で扱えます。強化学習ループが不要なため、学習が安定し、実装コードも大幅に簡素化されます。HuggingFaceのTRLライブラリには`DPOTrainer`が実装されており、データセットを用意すればすぐに動かせます。

さらに派生手法として、ORPO(Odds Ratio Preference Optimization)、KTO(Kahneman-Tversky Optimization)、SimPO、IPOなどが登場しています。ORPOはSFTとDPOを単一ステージに統合し、KTOは「勝ち負けのペア」ではなく個別の良否判定データで学習できるため、データ収集の柔軟性が向上します。

項目	RLHF	DPO	ORPO	KTO
報酬モデル	必要	不要	不要	不要
強化学習ループ	必要(PPO)	不要	不要	不要
SFT前処理	必要	推奨	不要(統合)	推奨
必要データ形式	ランキング	chosen/rejected	chosen/rejected	個別良否判定
学習安定性	低	高	高	高
実装難易度	高	低	低	中

現代の実務シナリオでは、DPOまたはORPOが第一選択です。KTOは、ペアデータの収集が困難なユースケース(1件ずつ「良い/悪い」だけを記録するサービス改善データなど)で有力な選択肢になります。

実装の流れ

DPOの実装は、SFTモデルと選好データが揃っていれば驚くほど短いコードで実現できます。TRLライブラリの`DPOTrainer`を使えば、10数行で学習ループが記述可能です。以下はLlama-3-8BをベースにDPOを実施する最小コード例です。

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

model_id = "./sft-llama3-8b"  # SFT済みモデル
tokenizer = AutoTokenizer.from_pretrained(model_id)
model = AutoModelForCausalLM.from_pretrained(model_id, torch_dtype="bfloat16")
ref_model = AutoModelForCausalLM.from_pretrained(model_id, torch_dtype="bfloat16")

dataset = load_dataset("json", data_files="preferences.jsonl", split="train")

lora_config = LoraConfig(r=16, lora_alpha=32, task_type="CAUSAL_LM")

training_args = DPOConfig(
    output_dir="./dpo-output",
    num_train_epochs=3,
    per_device_train_batch_size=2,
    learning_rate=5e-7,
    beta=0.1,  # KL 正則化係数
    bf16=True,
    logging_steps=10,
)

trainer = DPOTrainer(
    model=model, ref_model=ref_model,
    args=training_args, train_dataset=dataset,
    tokenizer=tokenizer, peft_config=lora_config,
)
trainer.train()

`beta`は元モデルからどれだけ離れることを許容するかの係数で、0.1〜0.5程度が一般的です。大きすぎると元のモデル能力を失い、小さすぎると選好が反映されません。ファインチューニング実践で作ったSFTモデルをベースに、本記事の手法でさらにアライメントを行う流れが標準的です。

選好データの設計と収集

アライメント手法の品質は、選好データの品質に完全に規定されます。データ収集には複数のアプローチがあり、それぞれコスト、品質、スケーラビリティに違いがあります。人手アノテーションが品質的にはベストですが、コストが高くスケールしません。LLM-as-a-Judgeは、GPT-4oなどの強力なLLMに評価させる手法で、人手の1/100以下のコストで大量データを生成できますが、ジャッジ側のバイアスが混入します。

方法	コスト	品質	スケーラビリティ	適した場面
人手アノテーション	非常に高	最高	低	最終仕上げ・品質検証
LLM-as-a-Judge	低	中〜高	高	大量生成・初期学習
サービスログの暗黙フィードバック	低	中	非常に高	継続改善・本番運用
ルールベース合成	非常に低	低〜中	非常に高	安全性フィルタ等
ハイブリッド	中	高	中	実務の大半

実務的には、ハイブリッドアプローチが王道です。LLM-as-a-Judgeで大量の初期データを生成し、重要部分だけ人手でレビュー・修正するワークフローが費用対効果に優れます。サービスが稼働していれば、ユーザーの「いいね」「やり直し」ボタンから暗黙的な選好データを収集する仕組みを組み込むのも極めて有効です。LLM評価の枠組みと統合しておくと、運用負荷が下がります。

ビジネスでの活用場面

RLHF・DPOのビジネス活用で最も典型的なのは、カスタマーサポート用AIのトーン調整です。同じ内容でも「丁寧で共感的な表現」「簡潔で業務的な表現」では、顧客満足度が大きく変わります。選好データを積み上げれば、自社のブランドボイスを体現する応答にモデルを近づけられます。

社内LLMのトーン調整にも有効です。技術文書では簡潔で正確に、マーケティング資料では熱量と表現力を、といった具合に、利用シーンごとにアライメントされたモデルを用意することで、ユーザー体験が大きく向上します。選好データの形式は、通常以下のようなJSONL形式で管理します。

{
  "prompt": "返品ポリシーを教えてください。",
  "chosen": "ご購入いただきありがとうございます。商品到着後30日以内であれば、未使用品に限り返品を承ります。お手続きはマイページの注文履歴から進められます。ご不明な点があればいつでもお知らせください。",
  "rejected": "30日以内、未使用なら返品可。マイページから。"
}

上記のような数千ペアのデータで、モデルのトーンは明確に変わります。LLMとはやモデルレジストリの運用と組み合わせて、バージョン管理と評価を徹底するのが成功の鍵です。GPU基盤選定も合わせてご検討ください。

まとめ

RLHFは現代LLMの品質を決定づけたブレイクスルーですが、実装の難しさから広く普及するには至りませんでした。DPOとその派生手法の登場により、アライメントは中小規模のチームでも実践可能な技術になりつつあります。重要なのは手法選びよりも選好データの質で、そこへの投資が成功の9割を決めます。自社サービスの応答品質を一段引き上げたいなら、まずは数千ペアの選好データ収集から始めてみてください。

よくある質問

Q. RLHFとは?

A. Reinforcement Learning from Human Feedbackの略で、人間のフィードバック(どちらの回答が良いか)を使ってLLMの出力品質を向上させる手法です。ChatGPTの開発でも中核的な役割を果たしました。

Q. DPOとRLHFの違いは?

A. RLHFは報酬モデルの学習とPPOによる強化学習の2段階が必要ですが、DPOは選好データから直接モデルを最適化できます。DPOの方が実装が簡単で、学習が安定するため、実務では第一選択になります。

Q. 選好データはどのくらい必要ですか?

A. 一般的には1,000〜10,000ペア程度が目安です。ただし、高品質な500ペアの方が低品質な10,000ペアより効果的な場合もあるため、まずは少量から始めて効果を確認することを推奨します。