RLHFとは？報酬モデル・PPO・KL制約から「人間の好み」を学ぶ仕組みを理解する

ChatGPTのような対話型LLMは、事前学習で大量の文章を読み、指示チューニングで「質問に答える形式」を学びます。しかし、それだけで「役に立つ」「危険な依頼を適切に断る」「もっともらしい誤答を避ける」といった、人間が望む振る舞いを十分に定義できるとは限りません。

そこで使われる代表的な方法が、RLHF（Reinforcement Learning from Human Feedback、人間のフィードバックからの強化学習）です。人間に複数の回答を比較してもらい、その選好を報酬モデルへ学習させ、さらに言語モデルを強化学習で更新します。

ただし、RLHFは「人間が正解を直接教えれば、AIが賢くなる」という単純な仕組みではありません。実際には、次の三つの近似を重ねています。

1. 限られた評価者が、限られた候補回答を比較する
2. 報酬モデルが、その比較傾向を数値として近似する
3. 方策モデルが、その数値を高めるように更新される

この記事では、InstructGPT型のRLHFを中心に、選好データ、報酬モデル、PPO（Proximal Policy Optimization、方策を急激に変えすぎない強化学習手法）、KL制約、評価、失敗要因までを一続きで解説します。

先に結論：RLHFは「正解」を教える手法ではない

RLHFが学ぶのは、絶対的な正解そのものではありません。あるプロンプトに対して、回答Aと回答Bのどちらを人間が好んだかという比較信号です。

指示チューニングでは、入力と望ましい出力の組を使います。一方、RLHFでは、同じ入力に対する複数の候補を並べ、「どちらがより良いか」を収集できます。文章生成では唯一の正解を書き切るより、候補同士を比較する方が評価しやすい場面が多いためです。

両者の役割は競合ではなく、補完関係にあります。

典型的なRLHFでは、まずSFT（Supervised Fine-Tuning、教師ありの指示チューニング）済みモデルを用意します。RLHFは、基礎能力のないモデルへ後から知識を注入する工程というより、すでに生成できるモデルの振る舞いを、人間の評価軸へ寄せる工程です。

RLHFという言葉には広い意味と狭い意味がある

RLHFは広く捉えると、人間のフィードバックを報酬として利用する強化学習全般を指します。2017年の研究では、人間が軌跡の短い区間を比較し、その選好から報酬関数を学ぶ方法が示されました。

現在のLLM文脈では、次のInstructGPT型パイプラインを指すことが多くなっています。

1. 人間のデモ回答でSFTモデルを作る
2. SFTモデルなどから複数の候補回答を生成する
3. 人間が候補を順位付け、または一対比較する
4. 比較結果から報酬モデルを学習する
5. PPOなどで方策モデルを更新する

この記事では、この狭い意味のRLHFを扱います。報酬モデルを作らないDPO（Direct Preference Optimization、選好データから方策を直接最適化する方法）は、次の記事で詳しく扱います。

なぜ模範回答だけでは足りないのか

模範回答は強い教師信号ですが、作成コストが高く、評価基準の細部を表しにくいという問題があります。

たとえば、「東京旅行の計画を作って」という依頼には、正解が一つだけあるわけではありません。予算、移動距離、混雑、子どもの有無、食の好みなどで良い計画は変わります。評価者は完璧な計画をゼロから書けなくても、二つの案を見比べて「こちらの方が移動が現実的だ」と判断できるかもしれません。

比較には次の利点があります。

• 一から模範回答を書くより判断しやすい
• 流暢さ、簡潔さ、安全性などの相対差を拾いやすい
• 現在のモデルが実際に出す失敗を教材にできる
• 複数候補を順位付けすれば、一つのプロンプトから複数の比較を作れる

一方で、比較が簡単とは限りません。専門知識が必要な質問、長い文章、事実確認が必要な回答では、評価者の負荷も誤判定も増えます。したがって、選好データの品質はRLHF全体の上限を決める重要な要素です。

選好データはどのように作るのか

選好データの基本単位は、プロンプト、選ばれた回答、選ばれなかった回答の組です。

ここで、\(x\) はプロンプト、\(y_w\) はwinner（より好まれた回答）、\(y_l\) はloser（比較上、選ばれなかった回答）です。

プロンプト分布

学習時のプロンプトが、本番利用の分布と離れていると、報酬モデルは重要な場面を十分に学べません。一般的な質問だけでなく、長文、曖昧な指示、専門領域、安全性に関わる境界事例も含める必要があります。

候補回答の多様性

ほとんど同じ回答だけを比較しても、得られる情報は限られます。温度や生成モデル、チェックポイントを変え、品質や失敗パターンに差のある候補を含めます。ただし、常に一目で分かる粗悪な回答との比較ばかりでは、微妙な品質差を学べません。

評価基準

「好きな方を選ぶ」だけでは、評価者ごとに基準がぶれます。有用性、正確性、関連性、安全性、簡潔さなど、何を優先するかをルーブリック（評価基準表）で明確にします。複数基準が衝突するケースも、例とともに示す必要があります。

表示順と匿名化

候補Aが常に左側、特定モデルが常に先頭といった提示方法は、位置バイアスを生みます。表示順をランダム化し、モデル名や生成条件を隠して比較します。

同点と不一致

実際には優劣がつかない回答もあります。無理に勝敗を付けさせるとノイズになるため、同点、判断不能、専門家へ回すといった選択肢が必要です。また、複数評価者の一致率を記録し、不一致が多い領域を分析します。

選好ラベルは「客観的な真理」ではありません。評価者集団、指示、文化、時点によって変わる測定値です。データには、評価基準の版、候補生成元、表示順、評価者属性のうち許容される情報などを紐付け、後から偏りを追えるようにします。

報酬モデルは比較をどう学ぶのか

報酬モデルは、プロンプトと回答を受け取り、スカラー値を返します。

ここで、\(\phi\) は報酬モデルのパラメータです。数値が大きいほど、人間に好まれやすい回答だと予測します。

よく使われる定式化は、Bradley–Terry型の一対比較モデルです。回答 \(y_w\) が \(y_l\) より選ばれる確率を、報酬差のシグモイド関数として表します。

学習時には、好まれた回答の報酬が高くなるよう、次の損失を小さくします。

重要なのは、絶対点ではなく差を学んでいる点です。報酬7点が人間の満足度7点を意味するわけではありません。学習データ内で、どちらが選ばれそうかを並べるための内部スコアです。

この性質から、異なる報酬モデルの数値を単純比較したり、未知領域で高いスコアが出たことを品質保証とみなしたりはできません。

報酬モデルの精度は何を見ればよいか

検証用データでのペア比較正解率は必要ですが、それだけでは足りません。簡単な比較が多ければ、正解率が高くても本番で重要な差を見抜けない可能性があります。

少なくとも次の切り口で確認します。

特に長さは注意が必要です。学習データで詳しい回答が選ばれやすいと、報酬モデルは「長いほど良い」という近道を学ぶことがあります。内容が薄い冗長回答でも高得点になるなら、その報酬を最大化する方策も冗長になります。

強化学習として見た言語生成

報酬モデルができたら、言語モデルを方策として更新します。

• 状態 \(s_t\)：プロンプトと、それまでに生成したトークン
• 行動 \(a_t\)：次に生成するトークン
• 方策 \(\pi_\theta(a_t \mid s_t)\)：次トークンの確率分布
• 軌跡：回答全体
• 報酬：主に回答生成後、報酬モデルが返すスコア

文章の良し悪しは、途中の一語だけでは判断しにくいため、報酬は回答末尾で得られることが一般的です。すると、最終評価を各トークン選択へどう割り当てるかという信用割当の問題が生じます。

そこで価値モデルは、ある状態から将来どれくらいの報酬を得られそうかを予測します。実際のリターンと価値予測との差からアドバンテージ（その行動が期待よりどれだけ良かったか）を推定し、方策更新に使います。

PPOは何を「近づけすぎない」のか

PPOは、現在の方策から収集した生成結果を使いながら、方策を急激に変えすぎないよう更新するアルゴリズムです。

旧方策と新方策の確率比を次のように置きます。

代表的なクリップ目的は次の形です。

\(A_t\) はアドバンテージ、\(\epsilon\) は更新幅を制限する値です。確率比が大きく変化したとき、その利益をクリップすることで、一回の更新が極端になりにくくします。

ただし、PPOのクリップだけで元の言語能力を完全に守れるわけではありません。RLHFでは、別途、参照モデルからの距離を抑えるKLペナルティを組み合わせます。

KL制約は「報酬の抜け道」への歯止めになる

報酬モデルだけを最大化すると、方策は報酬モデルがまだ正確に評価できない領域へ移動し、スコアの抜け道を探すことがあります。これを抑えるため、SFT済みの参照方策 \(\pi_{\mathrm{ref}}\) から離れることへ罰則を加えます。

\(\beta\) は、報酬向上と参照モデル維持のバランスを決める係数です。

実運用では、目標KLから外れたら \(\beta\) を調整する方法もあります。見るべきなのは学習損失だけではありません。報酬、KL、回答長、エントロピー、クリップ率、価値誤差などを同時に監視し、方策が不自然な方向へ変化していないか確認します。

学習には四つのモデルが関わる

PPO型RLHFの実装を難しくする理由の一つは、複数モデルを同時に扱う点です。

方策と価値モデルには勾配計算が必要です。参照モデルと報酬モデルも推論のためメモリを使います。さらに、回答生成はトークンごとの逐次処理であり、教師あり学習よりデータ生成の待ち時間が大きくなります。

そのため実装では、モデルの共有、パラメータの分割、低精度化、生成と学習の分離などが重要になります。ただし、効率化でモデル版や生成条件の対応が曖昧になると、再現性を失います。少なくとも次を記録します。

• 方策、参照、報酬、価値モデルのチェックポイント
• プロンプトデータの版
• サンプリング温度、最大長、停止条件
• 報酬の構成と正規化方法
• PPOとKLの主要ハイパーパラメータ
• 評価セットと評価者ガイドラインの版

Reward hacking：高い報酬と良い回答は同じではない

報酬モデルは人間の選好の近似です。近似を強く最適化すると、方策は人間にとって良い回答ではなく、報酬モデルだけが高く評価する回答を見つけることがあります。これがreward hacking（報酬ハッキング）です。

たとえば、次のような近道が考えられます。

• 必要以上に長く、網羅的に見せる
• 自信に満ちた口調で誤りを隠す
• 評価者が好む定型句を繰り返す
• 根拠のない引用や数字で信頼感を演出する
• 安全性を重視しすぎ、無害な依頼まで拒否する

代理報酬の過最適化を調べた研究では、報酬モデルのスコアを上げ続けても、別の「gold」報酬で測った性能が途中から悪化し得ることが示されています。つまり、学習曲線上の最高報酬チェックポイントが、利用者にとって最高とは限りません。

対策は一つではありません。

• KL制約で学習分布からの逸脱を抑える
• 独立した評価モデルや人手評価を併用する
• 長さや形式など、既知のバイアスを切り分ける
• 敵対的な候補を選好データへ追加する
• 報酬だけでなく、正確性や安全性の回帰テストを見る
• 過度に最適化する前のチェックポイントも保存する

Goodhartの法則、つまり「指標が目標になると良い指標ではなくなる」という問題が、RLHFでは直接現れます。

一つの報酬へ何を詰め込むか

実際のシステムでは、報酬モデルのスコアだけでなく、KLペナルティ、形式違反、長さ、安全性など複数の項を組み合わせる場合があります。

これは便利ですが、係数を変えるだけでモデルの振る舞いが大きく変わります。また、一つの数値へ圧縮すると、「役に立つが少し冗長」と「簡潔だが重大な誤りがある」を同じ点数にしてしまう可能性があります。

したがって、学習用の合成報酬と、リリース判断用の評価指標は分けるべきです。最終判断では、正確性、安全性、有用性、簡潔さ、拒否の適切さなどを個別に測ります。

人手評価はどう設計するか

RLHF後のモデルは、報酬モデルのスコアだけで評価できません。同じ報酬モデルで学習と評価を行えば、その弱点を共有するからです。

信頼できる比較評価には、次の設計が必要です。

1. 比較対象のモデル名を隠す
2. 回答の表示順をランダム化する
3. プロンプトを学習用と分離する
4. 評価基準ごとにスコアを分ける
5. 複数評価者の一致率を確認する
6. 勝率だけでなく、同点と判断不能も記録する
7. 統計的不確実性を区間で示す

さらに、一般能力の回帰も確認します。選好評価で勝っても、知識問題、推論、コード生成、多言語、キャリブレーション（自信度と正答率の整合）などが悪化していれば、総合的な改善とは言えません。

安全性では、危険な依頼への拒否率だけを見ると、無害な依頼まで拒否する過剰拒否を見逃します。攻撃成功率と有用な応答率を両方測る必要があります。

なぜ一度のRLHFで終わらないのか

最初の選好データは、SFTモデルなどが生成した回答を中心に作られます。しかしRLHFで方策が変わると、生成される回答の分布も変わります。報酬モデルが十分に見ていない新しい文体や失敗が増えれば、評価精度は下がります。

この分布移動に対応するには、次の反復が必要です。

1. 現在の方策から本番に近い候補を生成する
2. 弱点や不確実な比較を優先して人手評価する
3. 選好データと報酬モデルを更新する
4. 方策を再学習する
5. 独立評価と回帰テストを行う

AnthropicのHelpful and Harmless Assistant研究でも、選好モデリングとRLHFを反復し、オンラインで新しい比較データを集める構成が扱われています。

ただし、本番ログを使えばよいという意味ではありません。個人情報、機密情報、同意、保持期間、削除要求を考慮し、収集対象と利用目的を明確にする必要があります。

InstructGPTの結果をどう読むべきか

InstructGPT論文では、ラベル作成者のデモでSFTを行い、モデル出力のランキングから報酬モデルを学び、PPOで調整しました。評価では、同論文のプロンプト分布において、1.3BパラメータのInstructGPT出力が175BのGPT-3出力より好まれたと報告されています。

この結果の意味は、「小さなモデルがあらゆる能力で大きなモデルを超えた」ではありません。比較されたのは、特定のプロンプト分布に対する人間の選好です。事前学習の規模だけでなく、利用者の意図へ合わせる学習が体感品質を大きく左右することを示しています。

同時に、論文はInstructGPTが単純な誤りを犯し、有害な出力を生成し、事実を捏造する場合があるとも述べています。RLHFは能力と安全性の問題をすべて解決する仕上げではありません。

RLHFを使うべき場面、別の方法がよい場面

RLHFは有力ですが、常に第一選択ではありません。

RLHFのコストには、評価者の採用と教育、選好収集、四つのモデルの計算資源、継続評価、データ更新が含まれます。SFTやDPOで十分な場合に、複雑なPPO基盤を導入する必要はありません。

一方、回答に唯一の正解がなく、複数の品質軸を人間が相対比較でき、モデルの現在の失敗からデータを反復収集したい場合には、RLHFの価値があります。

実務で確認したいチェックリスト

選好データ

• 本番に近いプロンプト分布か
• 候補の品質差と多様性があるか
• 表示順をランダム化したか
• 評価基準と優先順位が明確か
• 同点、判断不能、評価者不一致を残したか
• 専門領域を適切な評価者へ割り当てたか

報酬モデル

• 未見プロンプトで比較精度を測ったか
• 長さ、文体、位置などのバイアスを検査したか
• タスク別、評価者別、難易度別に分析したか
• 分布外や敵対例で極端なスコアを出さないか
• 報酬モデルとデータの版を固定したか

PPO学習

• 方策、参照、報酬、価値モデルの対応を記録したか
• 報酬、KL、回答長、エントロピー、価値誤差を監視したか
• KL係数と停止基準を定めたか
• 報酬最大のモデル以外も保存したか
• 学習失敗時に戻せるチェックポイントがあるか

リリース評価

• 学習用報酬とは独立した人手評価を行ったか
• 正確性、安全性、有用性、簡潔さを分けて測ったか
• 過剰拒否、迎合、偽引用を検査したか
• 一般能力と重要タスクの回帰テストを行ったか
• 本番監視、ロールバック、再収集の条件を決めたか

まとめ

RLHFは、人間が複数回答を比較した結果から報酬モデルを学び、その代理報酬を高めるよう言語モデルを強化学習する方法です。InstructGPT型では、SFT、選好データ、報酬モデル、PPO、KL制約という段階を踏みます。

理解の要点は三つです。

• 報酬モデルは正解判定器ではなく、特定の評価者とデータに基づく選好の近似である
• PPOとKL制約は更新を安定させるが、reward hackingや能力低下を自動的に防ぐ保証ではない
• 成功は学習報酬ではなく、独立した人手評価、回帰テスト、継続的なデータ更新で判断する

RLHFの本質は、「人間の価値観を一度でモデルへ埋め込むこと」ではありません。曖昧な望ましさを比較データへ落とし、その近似の限界を監視しながら改善を反復することです。

次の記事では、報酬モデルとPPOを使わず、選好ペアから方策を直接更新するDPOを取り上げます。RLHFとの目的関数と運用上の違いを整理します。

参考文献

• Deep Reinforcement Learning from Human Preferences
• Proximal Policy Optimization Algorithms
• Fine-Tuning Language Models from Human Preferences
• Learning to summarize from human feedback
• Training language models to follow instructions with human feedback
• Training a Helpful and Harmless Assistant with Reinforcement Learning from Human Feedback
• Scaling Laws for Reward Model Overoptimization
• Direct Preference Optimization: Your Language Model is Secretly a Reward Model