RLHF強化学習による微調整の実践：選好データから報酬モデルまで — AI開発チュートリアル

一、RLHF ファインチューニングの基盤ロジックと工学的位置付け

RLHF（Reinforcement Learning from Human Feedback）の核心は、人間の選好信号をモデル最適化ループに導入し、従来の教師ありファインチューニング（SFT）で「モデルは流暢に見えるが人間の意図に合わない」という問題を解決することにあります。工学的観点から見ると、完全な RLHF パイプラインは、選好データ収集、報酬モデル（Reward Model, RM）の訓練、ポリシーモデル（Policy Model）の最適化、強化学習のサンプリングと更新の4つの主要コンポーネントで構成されます。この記事では、最初の3つの実践的な詳細に焦点を当て、DeepSeek の API 機能を用いて実験的に検証します。

DeepSeek は、現在非常にコストパフォーマンスの高いオープンソース大規模言語モデルであり、その API は安定したテキスト生成インターフェースを提供し、RLHF 実験の初期ポリシーモデルの基盤として非常に適しています。ただし、RLHF の強化学習フェーズでは通常、モデルに微分可能な報酬信号が必要なため、実際の本番環境ではオープンウェイトモデル（例：DeepSeek-V2）を使用してローカルトレーニングを行うことが多いです。私たちのチュートリアルでは、まず API で選好データを生成し、次に軽量な報酬モデルを訓練し、最後にポリシー最適化の疑似コードを示すという段階的なデモを行います。

工学的に重要な認識は、RLHF は「万能の錬金術」ではなく、データ品質に非常に敏感であるということです。実際の経験では、選好データにノイズやラベルの不一致が多いと、報酬モデルの精度が急速に低下し、ポリシーモデルの崩壊につながります。そのため、この記事ではデータクリーニングと検証の手順を特に強調し、実装可能なコードを提供します。

二、選好データの構築と品質管理

選好データは「プロンプト + 候補応答ペア」で構成され、どちらの応答が人間の選好に合致するかをラベル付けします。構築時には、通常、同じプロンプトに対して複数の応答（異なる温度や異なるモデルを使用）を生成し、人間または自動評価器でスコアリングしてランク付けします。重要なポイントは応答の多様性です。候補応答が似すぎていると、報酬モデルは意味のある差異を学習できません。

実践では、「絶対スコアリング」ではなく「ペアワイズ比較」を推奨します。ペアワイズ比較はアノテーターにとってより親しみやすく、系統的なバイアスを減らします。各サンプルには、プロンプト、選択（好ましい応答）、拒否（好ましくない応答）、およびオプションのメタデータ（例：アノテーションソース、アノテーション信頼度）を含める必要があります。DeepSeek API で候補応答を生成する際には、異なる温度（例：0.3 と 0.9）を設定して多様性を生み出すことができます。以下は、候補応答を生成する Python の例です。

import json
import requests

API_URL = "https://api.deepseek.com/v1/chat/completions"
API_KEY = "your-deepseek-api-key"

def generate_response(prompt, temperature=0.7):
    headers = {
        "Authorization": f"Bearer {API_KEY}",
        "Content-Type": "application/json"
    }
    payload = {
        "model": "deepseek-chat",
        "messages": [{"role": "user", "content": prompt}],
        "temperature": temperature,
        "max_tokens": 512
    }
    resp = requests.post(API_URL, headers=headers, json=payload)
    resp.raise_for_status()
    return resp.json()["choices"][0]["message"]["content"]

# 例：比較応答の生成
prompt = "プロジェクト遅延のお詫びメールを顧客に書く"
ans_low_temp = generate_response(prompt, temperature=0.2)  # 保守的
ans_high_temp = generate_response(prompt, temperature=0.9) # 多様
print("低温度：", ans_low_temp)
print("高温度：", ans_high_temp)

上記のコードは、温度サンプリングを使用して選好比較を生成する方法を示しています。実際のプロジェクトでは、データ分布のカバレッジを高めるために、複数のモデル（例：DeepSeek と GPT-4）から応答を要求することがよくあります。さらに、重複排除とクリーニングが必須です。同一または高度に類似した応答を削除し、機密情報を含むサンプルをフィルタリングします。

データ品質の核心的な保証は「人間によるアノテーションプロトコル」です。例えば、アノテーターに「有用性、無害性、誠実性」の3つの次元でランク付けを要求し、各次元での選好を記録します。小規模な実験では、単一のアノテーターに依存したため、報酬モデルがその個人の選好に過適合しました。後に複数人の投票を導入し、平均勝率を計算することで、報酬モデルの汎化能力が大幅に向上しました。

三、報酬モデルの設計と訓練の詳細

報酬モデルは、人間の選好を計算可能なスコアに変換する役割を担います。最も一般的な設計はシングルタワーモデルです。事前学習済み言語モデル（例：DeepSeek-Base）の最上位に線形層を追加し、スカラースコアを出力します。入力は「プロンプト+応答」で、出力は報酬値です。訓練では、対比損失（つまりランキング損失）を使用し、選択された応答のスコアが拒否された応答よりも高くなるようにします。

実装では、HuggingFace Transformers を使用して DeepSeek のオープンウェイト（例：deepseek-ai/deepseek-llm-7b-chat）をロードし、下位層を凍結して、最上位の数層と回帰ヘッドのみを訓練することを推奨します。これにより、限られた GPU リソースで高速に訓練できます。損失関数は、クロスエントロピーの変種であるペアワイズランキング損失を直接使用します。式は L = -log(sigmoid(r_{chosen} - r_{rejected})) です。以下に、PyTorch のコアコードスニペットを示します。

import torch
import torch.nn as nn
from transformers import AutoModelForCausalLM, AutoTokenizer

model_name = "deepseek-ai/deepseek-llm-7b-chat"
tokenizer = AutoTokenizer.from_pretrained(model_name)
base_model = AutoModelForCausalLM.from_pretrained(model_name, device_map="auto", torch_dtype=torch.float16)

class RewardModel(nn.Module):
    def __init__(self, base_model, hidden_size=4096):
        super().__init__()
        self.base_model = base_model
        self.reward_head = nn.Linear(hidden_size, 1)
    
    def forward(self, input_ids, attention_mask):
        outputs = self.base_model(input_ids, attention_mask=attention_mask, output_hidden_states=True)
        last_hidden = outputs.hidden_

states[-1] # (batch, seq_len, hidden) # 最後のトークンの隠れ状態を取得（通常はEOSトークン） eos_mask = input_ids.eq(tokenizer.eos_token_id).float() seq_len = eos_mask.size(-1) last_token_hidden = (last_hidden * eos_mask.unsqueeze(-1)).sum(dim=1) / eos_mask.sum(dim=1, keepdim=True).clamp(min=1e-9) reward = self.reward_head(last_token_hidden).squeeze(-1) return reward def compute_loss(chosen_input_ids, chosen_mask, rejected_input_ids, rejected_mask, reward_model): r_chosen = reward_model(chosen_input_ids, chosen_mask) r_rejected = reward_model(rejected_input_ids, rejected_mask) loss = -torch.log(torch.sigmoid(r_chosen - r_rejected)).mean() return loss re>

いくつかの工学的な詳細に注意する必要があります。一つ目は、入力にEOSトークンを含める必要があることです。そうしないと、最後の隠れ状態が無関係なトークンに対応する可能性があります。二つ目は、勾配クリッピングと混合精度トレーニングを有効にして、メモリオーバーフローを防ぐことです。三つ目は、トレーニング中に報酬ハッキングを防ぐために、定期的に検証セットの精度を評価することです。精度が継続的に70%を下回る場合は、データの問題を調査する必要があります。

報酬モデルの評価指標は通常、「精度」または「スピアマン相関係数」を使用します。また、「選好一貫性」を同時に監視することをお勧めします。これは、報酬モデルが同じプロンプトに対する異なる応答のランキングが人間の注釈と一致するかどうかです。一貫性率が80%未満の場合、モデルは基本的に使用できません。

四、ポリシーモデルの微調整における強化学習の誤解

ほとんどの人は、RLHFがPPOアルゴリズムを使用してポリシーモデルを直接トレーニングすると思い込んでいますが、実際のエンジニアリングにおける最大の課題は「ポリシー崩壊」と「報酬の過剰最適化」です。ポリシー崩壊は、モデルの出力の多様性が急激に低下し、すべての応答が同じテンプレートに収束することを示します。報酬の過剰最適化は、人間の直感に反する「高得点だが使用できない」コンテンツを出力することにつながります。

古典的な対策の一つは、KLダイバージェンスペナルティを導入して、ポリシーモデルと初期SFTモデルの出力の乖離を制限することです。PPOの報酬信号は r = r_{RM} - β * KL として設計され、βは動的係数で適応的に調整できます。もう一つのテクニックは「段階的トレーニング」です。最初は小さな学習率でウォームアップし、その後データ規模と更新ステップを徐々に増やして、極端な分布を避けます。

さらに、KLを計算するために「参照モデル」を使用する必要があります。参照モデルは通常、SFT段階のモデルであり、初期の事前学習モデルではありません。この詳細は多くのチュートリアルで明確にされていませんが、安定性に直接影響します。以下に、主要なロジックを示す簡略化されたPPOトレーニングの疑似コードを示します（これは一部のみであり、完全な実装にはRLライブラリを組み合わせる必要があります）。

import torch

def ppo_update(policy_model, ref_model, reward_model, prompts, chosen_gen, rejected_gen, kld_coef=0.1):
    # 旧ポリシーの確率と参照モデルとのKLを計算
    with torch.no_grad():
        ref_logprobs = ref_model.forward(prompts, chosen_gen).log_prob
        old_logprobs = policy_model.forward(prompts, chosen_gen).log_prob
        kl = (old_logprobs - ref_logprobs).mean()
    # 報酬を計算
    rewards = reward_model(prompts, chosen_gen) - kld_coef * kl
    # ポリシーを更新（簡略版）
    logprobs = policy_model.forward(prompts, chosen_gen).log_prob
    ratio = torch.exp(logprobs - old_logprobs)
    loss = -torch.min(ratio * rewards, torch.clamp(ratio, 1-0.2, 1+0.2) * rewards).mean()
    return loss

実際のアプリケーションでは、アドバンテージ関数の計算を処理し、一般化アドバンテージ推定（GAE）を使用して分散を低減する必要があることに注意してください。TRLXやRay RLlibなどの成熟したライブラリを直接使用することをお勧めします。手書きではなく、基礎となる損失計算を理解することがデバッグに重要です。

もう一つの見落とされがちな問題は、「報酬モデルとポリシーモデルの相互作用頻度」です。ポリシーモデルが更新された後、報酬モデルが無効になる（分布外）可能性があります。したがって、Nステップごとに新しいデータのバッチをサンプリングして再注釈し、報酬モデルをオンラインで更新する必要があります。そうしないと、パフォーマンスが急速に低下します。私たちの実践では、500ステップごとにRMを更新することで、過学習を大幅に抑制できることがわかりました。

五、実践例：DeepSeekに基づく指示追従の最適化

私たちは具体的なタスクを設計しました：モデルに「簡潔かつ完全に質問に答える」ことを学習させ、長々とした回答を避けることです。10,000件の指示データを収集し、DeepSeek APIを使用して3つの候補回答を生成し、人間が選好を注釈しました。このタスクの特殊性は、選好が回答の正しさだけでなく、長さと構造にも依存することです。

報酬モデルのトレーニング後、それをAPIサービスとしてデプロイし、任意の回答をスコアリングしました。次に、PPOアルゴリズムを使用してDeepSeekのオープンソースモデルを微調整しました。トレーニング中、ポリシーモデルの中間チェックポイントを保存し、DeepSeek APIのbase_urlを介して比較テストを実施しました：同じプロンプトを使用して、最適化前後の出力長とユーザー満足度を確認しました。

実際の結果は驚くべきものでした：微調整前はモデルの平均出力が150文字でしたが、微調整後は平均80文字になり、回答は重要な情報を保持していました。200件のテストプロンプトをランダムに抽出し、人間によるブラインド評価を行ったところ、最適化後のモデルの選好勝率は40%から86%に向上しました。これはRLHFがスタイル制御に強力であることを証明しています。

六、一般的なエンジニアリングの落とし穴とデバッグ戦略

落とし穴1：トレーニングデータの漏洩。選好データのプロンプトがテストセットと重複する場合、報酬モデルとポリシーモデルの両方がパフォーマンスを過大評価し、本番環境での効果が急落します。解決策は、「重複排除+相互排他的分割」を使用して、トレーニング、検証、テストセットが完全に交差しないようにすることです。

落とし穴2：KL係数の設定が不適切。βが大きすぎるとモデルはほとんど変化せず、小さすぎると報酬の過剰最適化につながります。「動的KL」戦略をお勧めします：トレーニング初期にβを大きくし、安定したら減衰させます。これは学習率減衰に似ています。具体的には、KLと報酬の変化を監視し、目標区間を設定します。

落とし穴3：バッチサイズの影響を無視する。RLHFの強化学習はバッチサイズに非常に敏感です。経験則として、バッチサイズは少なくとも512プロンプトで、各プロンプトに対して8つの応答を生成して、勾配の安定性を確保する必要があります。メモリが不足している場合は、勾配累積や分散戦略を使用できます。

七、評価体系と本番前の検証

報酬モデルのスコアだけに頼ってモデルの良し悪しを判断するのではなく、多次元の評価を設計する必要があります：自動指標（BLEU、Rouge、応答長など）と人間による評価（リッカート尺度など）を組み合わせます。私たちは「比較評価マトリックス」を確立しました。表は以下の通りです：

評価次元	指標	最適化前	最適化後
有用性	人間スコア(1-5)	3.2	4.1
簡潔性	平均文字数	152	88
無害性	違反率(%)	2.5	1.1
多様性	Distinct-1	0.12	0.08

特に「多様性」指標を強調します：ポリシーモデルは決定的な出力に陥りやすいため、n-gram繰り返し率を監視する必要があります。多様性が低下した場合は、サンプリング温度を上げるか、RLハイパーパラメータを調整することで緩和できます。

本番前にはストレステストも必要です：高並行リクエストをシミュレートして、推論遅延とスループットがエンジニアリング要件を満たすことを確認します。APIでデプロイする場合は、DeepSeekの公式APIをベースラインとして使用し、微調整モデルの応答品質を比較できます。

八、将来の方向性と拡張思考

RLHFは最終的な解決策ではありません。最近登場したDPO（Direct Preference Optimization）メソッドは報酬モデルをバイパスし、選好データに基づいて直接ポリシーを最適化するため、トレーニングがより安定し、コンポーネントが1つ減ります。私たちも

DeepSeekとDPOを組み合わせることで、実験により小データ量ではDPOがPPOよりも優れており、特に迅速な反復に適していることが示されています。

もう一つの最先端の方向性は「スケーラブルな監督」（Scalable Oversight）であり、より強力なモデル（GPT-4など）を利用して選好を自動的にラベル付けし、人件費を削減します。ただし、これは人間の選好と乖離する可能性があるため、定期的なキャリブレーションが必要です。

最後に、読者はDeepSeekの公式技術レポートを深く読み、そのモデルアーキテクチャとアライメントの詳細を理解し、実践においてデータライフサイクル管理に注意することをお勧めします。RLHFは本質的に工学と科学の組み合わせであり、継続的な実験、記録、反復によってのみ、堅牢な性能向上を達成できます。