2025-11-15 Stanford CME295 : LLMの選好チューニング - RLHFからDPOへの進化

※本記事は、Afshine Amidi氏とShervine Amidi氏によるStanford University CME295「Transformers and Large Language Models」コースの2025年10月31日の講義「Lecture 5 - LLM tuning」の内容を基に作成されています。講義の詳細情報やシラバスは https://cme295.stanford.edu/syllabus/ でご覧いただけます。また、スタンフォード大学の大学院プログラムについては https://online.stanford.edu/graduate-programs でご確認いただけます。本記事では、講義内容を要約・再構成しております。なお、本記事の内容は原講義の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルの講義動画（https://www.youtube.com/watch?v=PmW_TMQ3l0I ）をご視聴いただくことをお勧めいたします。

登壇者紹介

Afshine Amidi氏は、Stanford Universityの非常勤講師（Adjunct Lecturer）を務めています。本講義では、イントロダクションからBest-of-Nまでの前半部分を担当し、Preference Tuningの基礎、RLHF、Reward Model、強化学習アプローチ、PPOとそのバリエーションについて解説しました。

Shervine Amidi氏は、Stanford Universityの非常勤講師（Adjunct Lecturer）を務めています。本講義では、DPO（Direct Preference Optimization）のセクションを担当し、RLの複雑さからの解放と教師あり学習によるPreference Tuning手法について解説しました。

1. イントロダクション

1.1 講義の概要と前回の復習

Afinen： 皆さん、こんにちは。CME295の第5回講義へようこそ。まず、先週中間試験を受けていただいた皆さん、お時間をいただきありがとうございました。試験は皆さんにとって妥当な難易度だったと思います。聴講生の方で試験に興味がある場合は、試験問題と解答の両方がウェブサイトに掲載されていますので、試験がどのような形式かご確認いただけます。

期末試験については、同じ形式になりますが、内容は第5回講義、つまり今日の内容から第9回講義までをカバーすることになります。それでは講義を始めましょう。今日はLLMチューニングについてお話しします。

いつものように、前回見た内容を振り返りましょう。前回はすでに2週間前になりますが、LLMをどのように訓練するかについて話しました。特に2つの重要なステップを見ていきました。最初のステップはPre-training（事前学習）と呼ばれるもので、基本的に初期化されたモデルを取り、そのモデルに言語やコードについて教えるプロセスです。

このステップは非常に時間がかかり、費用も高く、計算リソースを大量に消費します。大量のデータに対して実行されます。訓練最適化技術として、GPU間でどのように並列化するかを見てきました。データ並列化手法、特にZeROのバリアント0、1、2、3を見ました。また、モデル並列化についても簡単に見ました。

このステップの終わりに得られるのは、言語の構造やコードについて、つまり基本的に与えられたすべてのテキストについて知っているモデルです。しかし、このモデルができることは次のトークンを予測することだけです。素晴らしい自動補完機能ではありますが、まだ役立つモデルではありません。だからこそ第2のステップがあります。

第2のステップは通常Fine-tuning（ファインチューニング）、またはSFT（Supervised Fine-Tuning：教師ありファインチューニング）と呼ばれます。ここでは事前学習済みモデルを取り、特定のタスクのために訓練します。最近ではChatGPTやこれらすべてのチャットアシスタントがありますよね。これが1つのアプリケーションになります。つまり、モデルをアシスタントに変換するということです。

ここでの目標は、モデルにどう振る舞うかを教えることです。モデルはすでに言語が何か、コードが何かなどを知っています。そして、チューニングしようとしているユースケースのように振る舞うようにするだけです。典型的には、ここで持つのは規模ははるかに小さいが品質ははるかに高いデータセットです。基本的に事前学習済みモデルを取り、次トークン予測タスクで正確にどのトークンを予測すべきかを教えます。

そして、パラメータ効率的な手法であるLoRAを見ました。これはすべての重みをチューニングするのではなく、巧妙な方法で低ランク行列を導入し、それらがチューニングされるものです。そこで止まりました。

1.2 LLMトレーニングの3段階プロセス

Afinen： 今日見ていくのは、人間の好みと整合させるためにモデルをどのようにアライメントするかです。ここでは、特定のタスクのためにファインチューニングされたモデルを取り、人間が好むもの、または私たちが定義する何らかのメトリクスとより整合するようにモデルをアライメントしようとします。

例として、ステップ2の終わりにアシスタントがあるとしましょう。そのアシスタントは望むように振る舞っていますが、望むトーンではないという可能性は十分にあります。例えば、フレンドリーではないとか、安全ではないといったことです。そのような側面をこの第3のステップでチューニングしたいのです。

このステップはPreference Tuning（選好チューニング）と呼ばれ、それが正確に何であるかをこれから見ていきます。文脈として、SFTモデルがあると仮定しましょう。SFTモデルとは、事前学習段階とファインチューニング段階を経たモデルを意味します。例えば、テディベアと一緒にできる新しい活動を提案するようモデルに依頼するとします。するとモデルは「テディベアとあまり時間を過ごさないことをお勧めします」と応答したとします。

これはアシスタントの応答ですが、必ずしも私たちが望むものと整合していません。ここでのアイデアは、これらのいわゆる悪い出力を取り、代わりに持ちたい出力を見つけるか書き直すことです。このペアが私たちがPreference Pair（選好ペア）と呼ぶものです。言い換えれば、このプロンプトが与えられたとき、2つの応答があります。見たい応答が1つ、これから読む応答で、もう1つは見たくない応答です。

例えば、この例で見たい答えは「もちろん、テディベアは心地よい睡眠のための素晴らしい仲間になるだけでなく、楽しい活動のための素晴らしい仲間にもなります」といった感じで、いくつかの活動を提案します。このセットアップは理解できましたか？

長い話を短くすると、モデルを人間の好みに整合させたいということです。すでにファインチューニングステップがあるのに、なぜ第3のステップが必要なのかと疑問に思うかもしれません。第2のステップ、つまりファインチューニング段階では、覚えているように、モデルに特定の方法で振る舞ってほしいプロンプトの種類から、非常に高品質なデータセットを構築しました。

このようなデータセットを作成するのは、実際には非常に時間がかかり、非常に難しいことです。なぜなら、データセットは非常に高品質でなければならないからです。この場合、私たちがやっているのは、モデルに正確に何を生成すべきかを教えるのではなく、むしろモデルにどのような種類の出力を好むべきかを伝えることです。

つまり、「このようなものを生成してください」というよりも、「このオプションを好みます」という感じです。典型的には、詩を書くように頼まれたとき、ゼロから素晴らしい詩を書くのは、2つの詩、1つは悪い詩、1つは素晴らしい詩を見せて、どちらが良いかを言うだけよりもはるかに難しいでしょう。データセットを得るためには、すでにはるかに簡単です。

第2の理由は、SFT段階で非常に高品質のデータセットを作成するとき、正しく取得しようとする1つの側面があります。それはプロンプトの分布です。つまり、特定の種類のプロンプトが多すぎると、モデルはその特定の方法で応答することにより偏ってしまいます。

人々が試みることは、SFTデータにあるプロンプトの分布に注意を払うことです。ここで、モデルが誤動作した場合、SFTデータセットに1つの例を追加することを考えるとしたら、どのプロンプトを追加するか、そしてそれがモデルをその方向にあまりにも偏らせないかについて非常に注意する必要があります。これが第2の理由です。

そして第3の理由は、私が言及したことですが、SFTデータは通常非常に高品質です。したがって、モデルが行っているすべての誤ったステップを見て、それをSFTデータに入れようとすると、時間がかかるだけです。しかし、1つ注意すべきことは、SFTデータが大きく誤動作している場合、それはSFTデータセットに何らかの問題があることが原因である可能性もあります。

Preference Tuningはすべての答えではありません。場合によっては、SFTデータセットの問題を確認する方が良いこともあります。理解できましたか？

2. Preference Tuning（選好チューニング）

2.1 Preference Tuningの必要性

Afinen： それでは、Preference Tuning段階でそれを行うために何をするのか見ていきましょう。質問がありました。SFTでLoRAを見ましたが、Preference Tuningでは同等のものは何でしょうか？これについては講義の後半で見ていきますが、LoRAはチューニングする必要があるパラメータの数を減らす方法だと考えることができます。それはモデルの訓練に使用する目的関数とは少し異なります。

ここでのPreference Tuningは、異なる目的関数としてより考えることができますが、LoRAを使用することも十分に可能です。つまり、両者は互換性がないわけではありません。しかし、後でより明確になるでしょう。素晴らしい質問ですね。

もう1つここで付け加えることがあります。SFT段階との別の違いは、Preference Tuningは負のシグナルを注入することを可能にするということです。なぜなら、SFTはモデルに予測すべきことについて教えることがすべてだからです。しかし、予測すべきでないことについてはモデルに教えません。Preference Tuningでは負のシグナルを注入できることがわかります。

2.2 SFTとPreference Tuningの違い

Afinen： では、まず始めに、もちろんPreference Pairが必要です。このデータ収集ステップを最初に見ていきましょう。セットアップは次のとおりです。プロンプトがあります。例えば「詩を書いてください」とします。そして、モデルによって生成される特定の応答、つまり生成される詩があります。

Preferenceデータを構築するにはいくつかの方法があります。1つは、提案された各詩を何らかのPointwiseスコアで採点するという、Pointwiseの考え方から始めることができます。ここでPointwiseスコアとは、1つの観測に対する相対的なスコアを意味します。それを行うこともできますが、少し難しいと言わざるを得ません。

人間として、これは0.9、これは0.2というように言うのは、正確にどのようにスケーリングするかがあまり明確ではありません。2つ目のアイデアは、一度に2つの観測を取得し、どちらが良いかを言うことです。これはPairwise Preferenceデータと呼ばれ、はるかに簡単です。

そして3つ目はListwiseです。これは、例えばn個の詩のリストを取得し、どれが最良か、どれが最悪かなどをランク付けするものです。これはPointwiseよりも簡単だと思います。どれだけ良いかを指定する必要がないからです。しかし、それでも少し複雑です。それが人々が通常Pairwiseを使用する理由です。

彼らが行うのは、Pairwise Preferenceデータを収集することです。つまり、各プロンプトに対して2つの可能な答えがあり、どちらが良いかを指定するだけです。これが私たちがこの講義で続けていくものです。

では、Pairwise Preferenceデータを得たとして、どうやってそれを得るのかと尋ねるかもしれません。レシピは次のとおりです。応答のペアを生成するために、まずプロンプトが必要です。以前、おそらく第3回講義で見たと思いますが、温度がプラスの場合、異なる答えを生成できました。

典型的に人々が行うのは、このプロンプトをプラスの温度でモデルに2回入れることです。すると、2つの異なる答えを得ることができます。プロンプトは通常、ユーザーが典型的に尋ねるものの分布に従うことを望む何かです。したがって、プロンプトXはログから、または望ましいプロンプトのセットから得られる何かになります。

そして、2つの観測があります。1つ目はプロンプトと最初の応答です。2つ目はプロンプトと2番目の応答です。そして、それらを比較して評価します。もちろん人間の評価で比較できますが、他のメトリクスでも比較できます。

いくつか挙げましょう。LLM as Judgeというものを聞いたことがあるかもしれません。これはまだ見ていませんが、数回の講義後に見ます。これも典型的には、ある観測が別の観測よりもどれだけ良いかを比較するために使用されます。BLEUやROUGEなどの他のルールベースのメトリクスも使用できます。ただし、最近はあまり使用されていません。

これらの2つの観測を比較する最も簡単な方法は、バイナリ設定です。つまり、応答1が応答2より良いか悪いかを言うだけです。しかし、より微妙なスケールを考えることもできます。つまり、応答1がはるかに良い、良い、やや良い、やや悪い、悪い、またははるかに悪いと言うこともできます。

これも可能です。しかし、このアプローチにはいくつかの課題があります。例えば、人間の評価を考えると、多くのタスクは少し主観的です。したがって、多くの場合、実際に人々が行うのは、バイナリスケールでPairwise Preferenceデータセットを持つことです。つまり、良いか悪いかだけです。理解できましたか？

そのデータを得る別の方法は、ログの中で気に入らなかった応答を見つけて、その応答を取り、それを書き直すことです。これは基本的にここで行ったことです。ここで応答があったとき、私たちがしたのは応答を取り、良いものを書き直すことでした。これも人々が行うことですが、もちろんもう少し関与が必要です。生成する必要があり、生成はコストがかかり大変だと言いましたが、これも可能です。データ収集は理解できましたか？

2.3 Preference Tuningの3つの理由

Afinen： それでは、なぜSFTの段階がすでにあるのに第3のステップが必要なのか、改めて整理しましょう。Preference Tuningが必要な理由は3つあります。

第1の理由は、SFT段階で非常に高品質なデータセットを作成することが、実際には非常に時間がかかり、非常に困難だということです。データセットは非常に高品質でなければならないからです。この場合、私たちが行っているのは、モデルに正確に何を生成すべきかを教えることではなく、むしろモデルにどのような種類の出力を好むべきかを伝えることです。

つまり、「このようなものを生成してください」という形ではなく、「このオプションを好みます」という形です。典型的な例を挙げると、ゼロから素晴らしい詩を書くように頼まれたら、それは通常、2つの詩、1つは悪い詩、1つは素晴らしい詩を見せて、どちらが良いかを言うだけよりもはるかに難しいでしょう。データセットを取得する点では、すでにはるかに簡単なのです。

第2の理由は、SFT段階で非常に高品質のデータセットを作成するとき、私たちが本当に正しく取得しようとする1つの側面があります。それはプロンプトの分布です。つまり、特定の種類のプロンプトが多すぎると、モデルはその特定の方法で応答することにより偏ってしまいます。

そこで人々が試みるのは、SFTデータにあるプロンプトの分布に注意を払うことです。ここで、もしモデルが誤動作した場合、SFTデータセットに1つの例を追加することを考えたとしましょう。その場合、どのプロンプトを追加するか、そしてそれがモデルをその方向にあまりにも偏らせないかについて非常に注意する必要があります。これが第2の理由です。

そして第3の理由は、私が言及したように、SFTデータは通常非常に高品質だということです。したがって、モデルが行っているすべての誤ったステップを見て、それをSFTデータに入れようとすると、時間がかかるだけです。しかし、ここで1つ注意すべきことがあります。SFTデータが大きく誤動作している場合、それはSFTデータセット自体に何らかの問題があることが原因である可能性もあります。

したがって、Preference Tuningはすべての答えではありません。場合によっては、SFTデータセットの問題を確認する方が良いこともあります。これで理解できましたか？

2.4 負のシグナルの注入

Afinen： もう1つここで付け加えることがあります。SFT段階との別の違いは、Preference Tuningによって負のシグナルを注入できるということです。なぜなら、SFTはモデルに予測すべきことについて教えることがすべてだからです。しかし、予測すべきでないことについてはモデルに教えません。そして、Preference Tuningでは負のシグナルを注入できることがわかります。

つまり、SFTでは「このトークンを予測してください」「次にこのトークンを予測してください」と教えるだけです。しかし、「このトークンは予測しないでください」とは教えません。特定のものが生成されることを望まない場合、それを完璧な文に書き直さない限り、従来のSFTフレームワークでモデルにそれを生成しないように伝える方法はありません。

しかし、Preference Tuningを使えば、望ましくない出力と望ましい出力のペアを提供することで、モデルに「こちらの方向には行かないでください」というシグナルを送ることができます。これは非常に重要な違いです。この負のシグナルの能力が、Preference Tuningの重要な特徴の1つなのです。

3. データ収集

3.1 Preference Pairの構築方法

Afinen： では、まず始めに、もちろんPreference Pairが必要です。このデータ収集ステップを最初に見ていきましょう。セットアップは次のとおりです。プロンプトがあります。例えば「詩を書いてください」としましょう。そして、モデルによって生成される特定の応答、つまり生成される詩があります。

Preferenceデータを構築するにはいくつかの方法があります。データを評価し、どの出力が良くてどの出力が悪いかを判断する必要があります。このために、3つの異なるアプローチがあります。それぞれのアプローチには独自の特徴と課題があり、実践ではそれらの使いやすさが大きく異なります。

3.2 Pointwise、Pairwise、Listwiseの比較

Afinen： 1つ目は、Pointwiseの考え方から始めることができます。これは提案された各詩を何らかのPointwiseスコアで採点するものです。ここでPointwiseスコアとは、1つの観測に対する相対的なスコアを意味します。つまり、各出力を単独で見て、それに絶対的なスコアを付けるということです。それを行うこともできますが、正直に言って、少し難しいと言わざるを得ません。

人間として、「これは0.9です」「これは0.2です」というように言うのは、それほど明確ではありません。正確にどのようにスケーリングするかがわからないのです。0.9と0.2の差は実際にどれだけの品質の差を表しているのか？別の2つの詩が0.7と0.5だったら、それは同じくらいの差なのか？このような絶対的なスコアリングは、人間にとって非常に難しい認知タスクなのです。

2つ目のアイデアは、一度に2つの観測を取得し、どちらが良いかを言うことです。これはPairwise Preferenceデータと呼ばれ、はるかに簡単です。2つの詩を見て、「この詩の方が良い」と判断するだけです。絶対的なスコアを考える必要はなく、単純な比較判断だけで済みます。これは人間にとってはるかに自然で簡単なタスクです。

そして3つ目はListwiseです。これは、例えばn個の詩のリストを取得し、どれが最良か、どれが最悪かなどをランク付けするものです。このアプローチは、どれだけ良いかを指定する必要がないという点でPointwiseよりも簡単だと思います。しかし、それでも少し複雑です。複数の項目を同時に比較し、それらの間の相対的な順序を決定する必要があるからです。

これが人々が通常Pairwiseを使用する理由です。彼らが行うのは、Pairwise Preferenceデータを収集することです。つまり、各プロンプトに対して2つの可能な答えがあり、どちらが良いかを指定するだけです。これが最もシンプルで、人間の認知負荷が最も低く、最も一貫性のある判断が得られる方法なのです。これが私たちがこの講義で続けていくものです。

3.3 データ生成の具体的手順

Afinen： では、Pairwise Preferenceデータを得たとして、どうやってそれを得るのかと尋ねるかもしれません。具体的なレシピを見ていきましょう。応答のペアを生成するために、まずプロンプトが必要です。以前、おそらく第3回講義で見たと思いますが、温度がプラスの場合、異なる答えを生成できることを学びました。

典型的に人々が行うのは、このプロンプトをプラスの温度でモデルに2回入れることです。すると、2つの異なる答えを得ることができます。温度パラメータを正の値に設定することで、モデルは同じプロンプトに対しても毎回異なる応答を生成するようになります。これがデータ生成の核心的なメカニズムです。

プロンプトXは通常、ユーザーが典型的に尋ねるものの分布に従うことを望む何かです。したがって、プロンプトXはログから、または望ましいプロンプトのセットから得られる何かになります。実際のユーザーが実際に尋ねる質問の種類を反映することが重要です。なぜなら、モデルが実際に遭遇するであろう種類のプロンプトでPreference Tuningを行いたいからです。

そして、2つの観測があります。1つ目はプロンプトと最初の応答のペアです。2つ目はプロンプトと2番目の応答のペアです。同じプロンプトに対して、温度パラメータのおかげで2つの異なる応答が生成されます。この2つの観測を作成したら、次のステップは比較と評価です。

3.4 評価方法（人間評価、LLM as Judge、ルールベース）

Afinen： 生成された2つの応答をどのように比較し評価するかについて、いくつかの具体的な方法があります。

まず、人間の評価があります。これが最も直接的で信頼性の高い方法です。実際の人間の判断者が2つの応答を読み、どちらが良いかを判断します。人間の好みに基づいてモデルを調整したいのであれば、人間に直接評価してもらうのが最も確実な方法です。これがRLHF（Reinforcement Learning from Human Feedback）における「Human Feedback」の部分になります。

次に、LLM as Judgeというものがあります。これを聞いたことがあるかもしれません。これはまだ詳しく見ていませんが、数回の講義後に詳しく扱う予定です。これは別のLLMを判定者として使用し、2つの応答を評価させるというアプローチです。典型的には、ある観測が別の観測よりもどれだけ良いかを比較するために使用されます。これは人間の評価よりもスケーラブルで、コストを抑えることができます。

そして、BLEUやROUGEなどのルールベースのメトリクスも使用できます。ただし、これらは最近はあまり使用されていません。これらは主にテキスト生成タスクで使われてきた従来の自動評価メトリクスですが、現代のLLMが生成する複雑で多様な応答の品質を十分に捉えられないことが多いのです。

評価のスケールについても選択肢があります。最もシンプルなのはバイナリ設定です。つまり、応答1が応答2より良いか悪いかを判断するだけです。しかし、より微妙なスケールを考えることもできます。応答1が応答2と比べて「はるかに良い」「良い」「やや良い」「やや悪い」「悪い」または「はるかに悪い」といった6段階評価も可能です。

ただし、このアプローチにはいくつかの課題があります。多くのタスクは少し主観的であり、「やや良い」と「良い」の境界線がどこにあるのかは評価者によって解釈が異なる可能性があります。評価の一貫性を保つことが難しくなるのです。したがって、多くの場合、実際に人々が行うのは、バイナリスケールでPairwise Preferenceデータセットを持つことです。つまり、良いか悪いかだけの二択です。これが最も一貫性があり、評価者間の不一致が最も少ない方法として広く採用されています。

データを得る別の実践的な方法もあります。実際のシステムのログの中で気に入らなかった応答を見つけて、その応答を取り、それをより良いものに書き直すのです。これは基本的に私たちが最初のテディベアの例で示したアプローチです。悪い応答を特定し、それを望ましい応答に書き換えることで、Preference Pairを作成しました。これも人々が実際に行う方法ですが、もちろん人間が新しい応答を生成する必要があるため、もう少し労力が必要です。生成作業はコストがかかり大変だと前に述べましたが、高品質なPreferenceデータを得るためには有効な選択肢の1つです。データ収集の全体的なプロセスは理解できましたか？

4. RLHF概要

4.1 RLHFの2段階構造

Afinen： それでは、Preferenceデータを持っているとして、私たちが望むのは、評価で好まれた応答を好むようにモデルをアライメントすることです。そして、好まれなかった応答をダウンウェイトすることです。これを行うために、RLHFと呼ばれる手法を見ていきます。その詳細は後ほど見ていきます。

名前が示すように、RLHFは強化学習（RL）に依存しています。まず、強化学習の基礎から始めましょう。ここに強化学習の専門家はいますか？いませんね。大丈夫です。専門家である必要はありません。非常にゆっくり進めていきます。

その前に、RLHFが何であるかを理解しましょう。RLHFは「Reinforcement Learning from Human Feedback」の略で、典型的に2つの段階で構成されています。第1段階は、良い出力と悪い出力を区別する方法を理解することです。ここで、収集したすべてのPreference Pairが実際に使用されます。何が良くて何が悪いかを学習するために使われるのです。

この段階への入力は、プロンプトと応答の連結です。そして出力はスコアです。つまり、プロンプトと応答が与えられたとき、それがどれだけ良いかを知りたいのです。これが第1段階、つまりReward Modelの訓練です。

そして第2段階が強化学習ステップです。ここで報酬を使用して、モデルをPreferenceにアライメントします。ここでの入力はプロンプトです。そして、何らかの形で、報酬とより整合した応答y-hatを生成できるようにしたいのです。

ちなみに、1つ指摘しておきたいことがあります。RLHFは「Reinforcement Learning from Human Feedback」です。「Human Feedback」の部分は、Reward Modelが訓練されるラベルを指しています。したがって、Preference Pairが人間の評価に基づいている場合、人間のPreferenceに依存しているため、RLHFです。なぜなら、外の世界には「Reinforcement Learning from AI Feedback」、つまりRLAIFというものもあるからです。これは非人間のPreferenceに依存しているものです。

4.2 強化学習の基礎概念

Afinen： それでは、第1段階を自然に進めていく前に、強化学習の基本を理解する必要があります。強化学習の世界では、エージェント（Agent）があり、これは環境と相互作用します。ここで言うエージェントとは、強化学習用語でのエージェントを意味します。

このエージェントは何をするのでしょうか？時刻tにおいて特定の状態（State）にあります。時刻tにおいて行動（Action）を取ることができます。そして、その行動は何らかのポリシー（Policy）に従って取られます。ポリシーは通常、π(θ)と表記されます。具体的には、状態が与えられたときの行動のπ(θ)です。

このポリシーが意味するのは、単に状態が与えられたときに行動を取る確率を与えるということです。簡単ですよね？そして、エージェントが何らかの行動を取ると、報酬（Reward）も受け取ります。時には良い報酬、時には悪い報酬です。

この考え方を私たちのPreference Tuningの演習に活用していきます。これらの量をLLMの世界にどのように転換できるか、一緒に見ていきましょう。エージェントとは何でしょうか？エージェントはLLMです。

状態という観点では、それは単にこれまでの入力です。取りたい行動は、次のトークンを予測することです。つまり、基本的には常に「この入力が与えられたとき、次のトークンは何か」と考えています。この行動、つまり次のトークンは、そこにあるトークンのセットの中から選ばれます。

環境は語彙のトークンセットと考えることができます。そして、どのトークンが次に来るべきかを決定するために、LLMは次のトークンの確率を決定します。これは、フォワードパスを実行し、出力として確率分布を見ることで得られます。これが基本的に私たちのポリシーです。

したがって、ここでのポリシーは、次のトークンを決定するために入力が与えられたときのLLMの出力に等しいのです。ここまでは順調ですね。そして今、もう1つ追加します。2つの出力のうちどちらの出力が良いかを知りたいPreferenceデータセットを構成していると言いました。そして、報酬のためにそれを何らかの形で使用します。それをどのように使用するかは後で見ていきます。

4.3 LLMへのRL概念の適用

Afinen： それでは、この部分を要約しましょう。LLMがいくつかの入力を受け取り、次のトークンを予測したいとします。この行動を取りたいわけです。そのために、出力する確率分布を使用します。そして、予測するトークン、つまり生成する出力が、何らかの報酬を受け取ります。その報酬がエージェント、つまりLLMのチューニングにフィードバックされます。

ここで質問がありました。すべてのペアに対してこれを行うと高価になるのではないでしょうか？なぜ高価になるのでしょうか？はい、質問はコストの観点でどうするかということですね。そうですね、典型的には人々はバッチ処理を行います。確かに高価ですが、これを他の訓練手順と同じくらい高価な訓練手順と考えることができます。これを特別に高価にするものは何もありません。

しかし、正確に見ていきます。あなたが正しく触れている点がいくつかあります。通常の教師あり、例えばSupervised Fine-Tuning設定と比較して追加される部分がいくつかあり、それをこれから見ていきます。

次に質問がありました。ここから得られる報酬は、LLMを変化させるのに十分強力なのでしょうか？インターネット上では、この訓練手順をSFTから得られるシグナルと比べて、ほとんど同じくらいのシグナルがないと特徴づける表現を見かけることがあります。なぜなら、SFTでは文字通り常に部分的な入力を取り、LLMに次のトークンの生成方法を学習させているからです。

しかしここでは、完了ごとに大まかに1つのシグナルしか得られません。そうです、確かにより疎（スパース）です。それがRLHFがよりスパースなシグナルを持つアプローチとして見られる理由です。素晴らしい質問です。

さらに質問がありました。各トークンに報酬を適用するのか、それとも全体に適用するのか？これは後でより詳しく見ますが、全体に対してです。全体に対してですが、もう少し後で見ていきます。

4.4 報酬とポリシーの関係

Afinen： 状態STと行動ATについて質問がありました。念のため確認しておきますが、STは自分がいる状態で、ATは取りたい行動です。LLMのコンテキストでは、自分がいる状態はこれまでに持っている入力であり、行動はその入力が与えられたときにどのトークンを生成したいかということです。

ここまでは順調ですね。それでは、LLMベースの強化学習のメンタルモデルが少しわかったところで、もう一度強調したいことがあります。私たちが達成しようとしているのは、このポリシーを報酬と整合させる方法を学習することです。つまり、人間のPreferenceと整合するようにπ(θ)がθ、つまりLLMのパラメータを学習したいのです。そして、ここでRLHFが登場します。

RLHFがどのように機能するかを理解したので、2つの段階があることがわかりました。第1段階でReward Modelを訓練し、第2段階でそのReward Modelを使用してポリシーを訓練します。Reward Modelは第1段階で得られるモデルであり、良い出力と悪い出力を区別することができます。

一般的なレシピを見てみましょう。まず、プロンプトを入力として取ります。LLMが完了（Completion）を生成します。ここで完了とは、モデルからの完全な応答を意味します。ちなみに、完了という用語について、人々はロールアウト（Rollout）という用語も使います。つまり、完了、ロールアウト、完全な応答を生成し、その完全な応答はプロンプトとともにReward Modelに入ります。

Reward Modelは、すでに見たように、それが良いか悪いかを知っています。今は悪いとしましょう。実際には、サムズダウンを生成するのではなく、何らかのスコアを生成します。例えば、マイナス2だとしましょう。その報酬を考慮に入れ、この情報でLLMをチューニングします。

これはもっと複雑ですが、これをどのように行うかは後で見ていきます。しかし、これが一般的なアイデアです。念のため確認しておきますが、Reward Modelは第1段階で訓練したモデルであり、凍結（Frozen）されています。Reward Modelを訓練しているのではありません。Reward Modelはすでに訓練されています。訓練しているモデルはLLMです。

そして、私たちの目標は、より高い報酬を最適化することですが、初期モデルからあまり離れすぎないようにすることです。より高い報酬を最適化することについては、皆さん同意してくれると思います。しかし、初期モデルからあまり逸脱したくないという第2の声明を述べました。

5. Reward Model（報酬モデル）

5.1 Reward Modelの目的と役割

Afinen： それでは、RLHFには2つのステップがあることがわかったので、第1ステップを自然に進めていきましょう。ここでのアイデアは、どの出力が良くてどの出力が悪いかを知っているモデルを構築したいということです。そしてもちろん、ここで私たちが望むのは、出力だけでなく入力も考慮することです。なぜなら、その答えを何らかの形でコンテキスト化する必要があるからです。

5.2 Good OutputとBad Outputの識別

Afinen： 私たちのお気に入りの例で説明しましょう。次のようなプロンプトがあるとします。「テディベアと一緒にできる新しい活動を提案してください」。私たちが望むのは、ここでRMと表記するReward Modelを持つことです。このモデルは、良い答えに書き直した答えが良いということを教えてくれます。そして、何らかの形で、構築した、または構築しなかった出力、つまり見た出力が悪いことを教えてくれるモデルを持ちたいのです。

つまり、何らかの形で、プロンプトと良い応答を受け取って「これは良い」と言うモデルを持ちたいのです。そして、何らかの形で、プロンプトと悪い応答を受け取って「これは悪い」と言うモデルを持ちたいのです。

では、このようなモデルをどのように構築するのでしょうか？そのために、Bradley-Terry定式化と呼ばれる定式化を使用します。これは重要な式です。ここで少し時間を取りましょう。

6. Bradley-Terry定式化

6.1 Bradley-Terry式の数学的定義

Afinen： それでは、Bradley-Terry定式化について見ていきましょう。この式が言っているのは、出力yiが出力yjより良い確率は、あるスコアの指数関数に等しいということです。具体的には、iに関するスコアの指数を、iに関するスコアの指数とjに関するスコアの指数の和で割ったものです。

数式で表すと、P(yi > yj) = exp(R_i) / (exp(R_i) + exp(R_j))となります。これがBradley-Terry定式化と呼ばれるもので、モデルを構築するために使用する定式化です。

これはσ(R_i - R_j)とも等しくなります。σが何か知っている人はいますか？そうです、正解です。シグモイド関数です。念のため確認しておくと、シグモイドは1 / (1 + exp(-x))です。グラフはこのような形になります。マイナス無限大のとき0に近づき、プラス無限大のとき1に近づきます。

言い換えれば、もしiがjより良い場合、シグモイドへの入力をできるだけ高くしたいのです。なぜなら、確率を1にできるだけ近づけたいからです。したがって、何らかの形で、出力iが良い場合はR_iを高くしたいのです。そして、何らかの形で、出力が悪い場合はR_jを低くしたいのです。ここまでは順調ですね。

ここでやりたいことは、この定式化を使用してスコアR_iとR_jを出力できるモデルを何らかの形で訓練することです。この定式化には2つの量が含まれています。なぜなら、Pairwiseデータセットを持っているからです。ここまでは順調ですね。これからもう少し明確になります。

6.2 損失関数の導出

Afinen： 訓練のために、アイデアは次のとおりです。初期化したモデルがあり、一方ではプロンプトXと勝利出力を入力します。勝利と言っているので、y-hatのWです。これをモデルに入れると、スコアR(X, Y_W)が生成されます。そして、2番目の出力があります。XとY_L、Y_Lは敗北出力です。これをモデルに入れると、2番目のスコアが得られます。

そして今、何らかの形で、これら2つのスコアを考慮に入れた損失関数を持ちたいのです。この定式化に基づいて、どの損失関数を使用すべきか提案はありますか？損失関数はPairwiseになります。

提案された答えはバイナリクロスエントロピーです。もう少し詳しく説明してもらえますか？その場合、どうなるでしょうか？はい、はい、はい、素晴らしい答えです。あなたの答えは、この量の負の対数尤度を持つことだと思います。クロスエントロピーはこれの特殊なケースと見なすことができますが、この部分を確実に理解するために、もう一度この定式化を見てみましょう。

あなたが言及したその定式化を再度得るために、1つのアイデアは、データが与えられ、先ほど見たBradley-Terryの定式化が与えられたとき、そのデータが発生する確率を最大化するパラメータθを見つけることです。これは基本的にあなたが言及したことにつながります。

ここで、それが何を意味するかを書き出して、全員が理解できるようにしましょう。例えば、勝利例と敗北例が関連付けられたPreferenceデータセットがあるとします。このようなペアがたくさんあります。これらのペアが互いに独立して発生したと仮定しましょう。

私たちが望むのは、何らかの形でこれらの例を見る確率を最大化するパラメータを見つけることです。つまり、これらn個のPreference Pairの積を何らかの形で最大化したいということです。これは、ある出力wが別の出力lより良い確率です。そして、Bradley-Terry定式化でそれを見ました。

したがって、この定式化があります。これは基本的に、このシグモイドの積です。この報酬の、i=1からnまでのシグモイドの積です。これは基本的に入力プロンプトと出力の関数です。積の確率を見るときはいつでも、最初に考えるべきことは対数です。なぜなら、これは非常に小さくなる可能性があるからです。不安定性を引き起こす可能性があります。

したがって、対数を取ると、積を最大化するのは、その対数を最大化するのと同じです。その対数を取るとしましょう。対数を取るとしましょう。これは基本的に、勝利から得られる報酬のシグモイドの対数の和から、敗北から得られる報酬を引いたものに等しくなります。

これを最大化したいのです。しかし、機械学習では、人々は物事を最小化するのが好きです。したがって、前に負の符号を付けます。したがって、プラスの和の対数を最大化するのは、マイナスの和の対数を最小化するのと同じです。そして、これが私たちの損失関数になります。理解できましたか？

これはまさにあなたが言及したことです。そして、典型的には期待値を書き、これが私たちの損失関数になります。したがって、損失関数はマイナスの期待値、σ(R(x, y_w) - R(x, y_l))の対数のマイナスの期待値です。よろしいですか？

ここで損失関数はPairwiseですが、Reward Modelは、PairwiseですかPointwiseですか？予測を行うためにペアが必要ですか、それとも1つだけ必要ですか？ペアが必要ですか？さて、それが素晴らしいところです。ペアは必要ありません。Pairwiseで訓練していますが、実際にはPointwiseなのです。これは私が気づいた1つのことだと思います。この損失を見て、これは美しいことです。

Pairwiseで訓練していますが、結局のところ、1つのプロンプトとその出力を受け取り、1つの数値を出力するReward Modelを持っています。そして、勝利例に対しては高いスコアを出力しようとし、敗北例に対しては低いスコアを出力しようとすることがわかりました。これが私たちのReward Modelです。

6.3 Reward Modelの学習プロセス

Afinen： 時間を見ていますが、実際には予定通りではないので、先に進みます。典型的にここで必要なのは、データのセットです。通常、数万、あるいはそれ以上のデータが必要です。ここでのラベルはPreference評価になります。RLHFについて話している場合、このPreferenceは人間から来るべきです。

人間がこれら2つの出力を見て、どちらが良いかを判断するのです。数万以上のPreference Pairを集め、それぞれに人間の判断による「どちらが良いか」というラベルが付いています。このデータセットを使用して、先ほど導出した損失関数でReward Modelを訓練します。

訓練が完了すると、Reward Modelはプロンプトと応答のペアを入力として受け取り、1つのスコアを出力として返すことができます。良い応答には高いスコア、悪い応答には低いスコアを出力するように学習されています。このモデルは、数万のPreference Pairから、何が良い応答で何が悪い応答かのパターンを学習したのです。

6.4 モデルアーキテクチャの選択肢

Afinen： モデルの観点では、いくつかの異なる選択肢があります。すでに知っているように、次のトークンを予測するDecoder-onlyモデルが非常に人気があります。したがって、そのようなLLMを取り、考慮している文の最後に分類ヘッドを持つだけで、報酬を予測するために使用できます。

あるいは、クラスの最初に見たEncoder-onlyモデルを覚えているでしょう。例えばBERTです。CLSトークンの埋め込みを射影することもできます。これも選択肢の1つです。

典型的に最近人々が行うのは、LLMルートを取ることです。なぜなら、最近はすべてがLLMだからです。つまり、Decoder-onlyです。分類ヘッドを付けるだけです。したがって、人々はこのアプローチを採用しています。

そして、人々はどれだけうまくいっているかを評価するベンチマークも考案しています。参考として、興味があればRewardBenchというものがあり、これはかなり人気があります。この段階の最後には、プロンプトと特定の応答を受け取り、スコアを与えるReward Modelが得られます。

質問がありました。一部のタスクでは人間のPreferenceがあるものになり、他のタスクでは別のものになるのではないでしょうか？典型的に、これらの報酬は特定の次元に関するものです。出力が有用かどうか、あるいは出力がフレンドリーかどうか、出力が安全かどうかといった次元です。これらはすべて異なる次元です。したがって、異なるReward Modelを持つことができます。

全体的なスコアを持つこともできます。しかし、そうです、応答がどれだけ良いかを定量化する次元を定義する必要があります。私が言及したものは、見つけることができる一般的なものです。

ここにいる間にもう1つ言及すべきことがあります。人間の評価は、公開するガイドラインに非常に敏感です。ここで詳細には触れませんが、人間のPreferenceデータの重要な側面の1つは、評価者に伝えるガイドラインをできるだけ客観的にすることです。

時には完全に客観的にすることはできませんが、十分に明確にして、人間のPreferenceがノイズの多いものにならないようにするタスクがあります。なぜなら、ノイズが多くなる可能性があるからです。しかし、それも1つの課題です。

質問がありました。ここでの報酬は回帰問題ですか、それとも分類問題ですか？損失関数を見てみましょう。これは少し難しいと思います。報酬は、ある種のスコアとして解釈できるものですが、確率的な定式化があります。したがって、これを分類タスクとして位置づけるでしょう。Preferenceデータは良いか悪いか、つまり1か0なので。

しかし、最終的には報酬を使用するので、純粋な分類タスクではありません。1つ注意すべきことは、これらの報酬があるスケールは、典型的にはそれ自体がスケーリングされるものだということです。推論時には、バッチ全体で正規化する正規化手順がありますが、これを確率的なものとして特徴づけるでしょう。

質問がありました。スコアを正規化しますか？物事を正規化する多くの異なる方法があります。典型的には正規化します。回帰設定にいる場合、特定のスケールでスコアを予測しようとしていますが、ここではそれを行っていません。ここではある種の自由形式です。したがって、再スケーリングが行われます。

質問がありました。Reward Modelの出力についてもっと教えてもらえますか？これは後で少し見ますが、良い出力は例えば1、悪い出力はマイナス2やマイナス3といったものと考えることができます。基本的に連続的なスケールです。すぐに例を見ますので、うまくいけば明確になるでしょう。

7. 強化学習によるアライメント

7.1 RLを用いたポリシーの調整

Afinen： 私たちはReward Modelを訓練しました。今度は第2ステップ、このReward Modelを使用してモデルをアライメントすることです。ここで言うモデルとはLLMのことです。Pre-training段階とSFT段階を経たLLMが、人間のPreferenceと整合させたいモデルです。

これを強化学習を使用して行います。そして、構築したばかりのReward Modelを使用して行います。ここでのReward Modelは、ステップ1で得たモデルであり、良い出力と悪い出力を区別することができます。

モデルをどのように整合させるかの一般的なレシピを見てみましょう。まず、プロンプトを入力として取ります。LLMが完了（Completion）を生成します。ここで完了とは、モデルからの完全な応答を意味します。ちなみに、人々は完了に対してロールアウト（Rollout）という用語も使用します。つまり、完了、ロールアウト、完全な応答を生成し、その完全な応答はプロンプトとともにReward Modelに入ります。

すでに見たように、Reward Modelは今それが良いか悪いかを知っています。今は悪いとしましょう。実際には、サムズダウンを生成するのではなく、何らかのスコアを生成します。例えば、マイナス2だとしましょう。その報酬を考慮に入れ、そしてこの情報でLLMをチューニングします。

これはもっと複雑ですが、これをどのように行うかは後で見ていきます。しかし、これが一般的なアイデアです。念のため確認しておきたいことがあります。Reward Modelは、ステップ1で訓練したモデルであり、凍結（Frozen）されています。Reward Modelを訓練しているのではありません。Reward Modelはすでに訓練されています。訓練しているモデルはLLMです。

そして、私たちの目標は、より高い報酬を最適化することですが、初期モデルからあまり離れすぎないようにすることです。より高い報酬を最適化することについては、皆さん同意してくれると思います。しかし、初期モデルからあまり逸脱したくないという第2の声明を述べました。なぜベースモデルからあまり逸脱したくないのでしょうか？

7.2 Reward Hackingの問題

Afinen： 提案された答えの1つは、学習したことを壊滅的に忘れてしまうということです。なぜそれが問題になるのでしょうか？素晴らしい説明です。提案された答えは、初期モデルにはすべての知識があり、それはPre-trainedされ、Instruction TunedまたはTunedされているということです。あまりにも離れたくないのです。これはまさにその通りです。これが1つの理由です。

別の理由は何でしょうか？確かに1つ、非常に良い理由です。別の理由は何でしょうか？提案された答えは、そのデータに過適合することです。もっと詳しく教えてもらえますか？素晴らしい点です。第2の提案された答えは、あまりクリーンでないデータに過適合する可能性があるということです。そして、それが何を意味するかについてもう少し詳しく説明します。

追加したいことはありますか？あなたの2つの点は同じ方向性だと思います。つまり、Reward Modelがノイズを含んでいる可能性があるということです。まさにその通りです。これはReward Hackingと呼ばれる現象です。報酬を過度に最適化しようとすると、基本的に報酬が望むものを正確に定量化していると仮定していることになりますが、Reward Model自体が不完全であるため、そうではない可能性があります。

この点を全員が理解できるように、例で説明しましょう。私が講義をしていて、私の目的は講義をできるだけ有益にすることだとします。私の言っていることが有益かどうかを知るために定量化できるものを選択することができます。

講義の最後の拍手の大きさが報酬だとしましょう。拍手がたくさんあるかないか。問題は、最後の拍手の音量を過度に最適化しようとすると、皆さんがジョークを好むことがわかり、ジョークを作り始めて、最後に拍手をしてもらえれば、報酬は最大化されますが、目的は達成されていないということです。目的は講義を有益にすることでした。

実際には、このReward Hacking現象は、目的を達成していないにもかかわらず、モデルが不完全なメトリクスやスコアを過度に最適化することにつながるものです。したがって、報酬を最大化することは十分にできますが、望むことを達成できないのです。これがReward Hackingの背後にあるアイデアです。

ちなみに、もう1つの理由もあります。ベースモデルはすでに素晴らしいという理由が1つ。たくさんのことを知っています。2つ目の理由は、Reward Modelが不完全だということです。したがって、このReward Hacking現象があります。3つ目の理由は、訓練の不安定性も持つ可能性があるためです。とにかく、あまり逸脱したくない理由がたくさんあります。

7.3 ベースモデルからの逸脱を防ぐ理由

Afinen： ベースモデルからあまり逸脱したくない理由を整理しましょう。すでに3つの重要な理由が出てきました。

第1の理由は、初期モデルにはすべての知識があるということです。それはPre-trainedされ、Instruction TunedまたはTunedされています。あまりにも離れたくないのです。このモデルは膨大な量のデータでPre-trainingされ、高品質なデータでSFTされています。その過程で獲得した知識とスキルを保持したいのです。もし大きく逸脱してしまうと、モデルが学習したことを壊滅的に忘れてしまう可能性があります。これは非常に重要な点です。

第2の理由は、Reward Modelが不完全だということです。Reward Model自体がノイズを含んでいる可能性があり、完璧に人間の好みを捉えているわけではありません。これがReward Hacking現象につながります。報酬を過度に最適化しようとすると、基本的に報酬が望むものを正確に定量化していると仮定していることになりますが、実際にはそうではない可能性があります。

先ほどの講義の例を思い出してください。講義を有益にすることが目的なのに、拍手の音量を報酬にしてしまうと、ジョークばかり言って拍手を最大化できますが、本来の目的である情報提供は達成されません。同様に、Reward Modelのスコアを過度に最大化しようとすると、実際には人間が望んでいないような出力を生成してしまう可能性があるのです。

そして第3の理由は、訓練の不安定性です。モデルのパラメータを大きく変更しようとすると、訓練プロセスが不安定になる可能性があります。急激な変更は予測不可能な振る舞いを引き起こす可能性があり、モデルの性能が急激に悪化することもあります。

これらすべての理由から、ベースモデルから大きく逸脱しないようにすることが非常に重要なのです。

7.4 学習の不安定性への対処

Afinen： このセットアップでは、Reward Modelのケースよりも多くの観測データが必要です。典型的には少なくとも100,000の観測データが必要です。ここで得られるラベルはReward Modelから来ます。そして、SFT後に得られたモデルから始めます。これが訓練するモデルです。

損失関数は、報酬を最大化しようとするものになりますが、同時にベースモデルから逸脱しすぎないようにもします。これが損失関数の外観のアイデアです。2つの部分があります。理解できましたか？

すでに見たように、Reward Hackingと不安定性などの理由から、あまり逸脱したくありません。これを行うために、PPOと呼ばれる非常に人気のある強化学習アルゴリズムを聞いたことがあるかもしれません。PPOは「Proximal Policy Optimization」の略です。Proximal（近接）と名付けられている理由は、モデルがベースモデルから大きく逸脱しないようにしたいからです。これをどのように行うかを見ていきます。

損失関数は大まかにこのような形になります。最大化したいReward Modelの部分があり、そして訓練しているポリシーの分布がReference Modelまたはベースモデルにどれだけ離れているかを測定する別の部分があります。ここでReference Modelは、SFTモデルになります。したがって、これら2つの部分があります。損失の定式化は大まかに理解できましたか？理解できましたね。

KLダイバージェンス（Kullback-Leibler Divergence）について話したいと思いますが、それを知っていると仮定したくありません。KLダイバージェンスは、2つの確率分布がどれだけ離れているかの尺度です。距離と言いたくありません。距離にはたくさんの含意があるからです。距離ではありませんが、2つの確率分布がどれだけ離れているかの尺度です。

確率分布Pと別の確率分布Qを取り、この式を計算します。これはP_i × log(P_i / Q_i)の和です。これは、これら2つの確率分布がどれだけ離れているか、どれだけ遠いかの数値を与えてくれます。損失を最小化したいので、それらがどれだけ離れているかを最小化したいということです。これを使用することは理にかなっていますか？

ちょっとした質問があります。KLダイバージェンスは正ですか、負ですか、それとも何が言えますか？正です。なぜ正なのでしょうか？そうですね、Jensen's不等式を使えば証明できます。なぜなら、この式を見ると、対数は正の値も負の値も取ることができるので、あまり明確ではないからです。しかし、それが常に正または0に等しいことを証明する方法は、Jensen's不等式を使うことです。そして、この量はPとQが等しい場合にのみ0に等しくなります。

8. PPO（Proximal Policy Optimization）

8.1 PPOの基本概念

Afinen： これで、損失関数についてもう少し詳しく見ていきます。損失関数は報酬を最大化しようとしますが、同時にモデルがベースモデルから逸脱しないようにもすることを述べました。しかし、実際には少し嘘をついていました。報酬を最大化したいのではありません。実際にはAdvantage（優位性）と呼ばれる量を最大化したいのです。

Advantageとは何でしょうか？Advantageは、期待される結果と比較して出力がどれだけ良いかと考えることができます。人々は典型的にAdvantageを使用して、全体のプロセス、訓練をより安定させます。そして、このAdvantageをValue Function（価値関数）と呼ばれる関数で推定します。これについては後ほど詳しく見ていきます。

質問はありますか？質問はありませんね。2つの量があります。以前に見た報酬があり、これはプロンプトが与えられ、完了が与えられたときにどれだけ良いかです。プロンプトと完了がどれだけ良いかを計算する方法を見ました。そして、Value Functionは別の推定ですが、この推定は完了レベルではなく、実際にはトークンレベルです。

ここで行っているのは、プロンプトと部分的な生成を入力として取り、ポリシーに従って出力の生成を続けた場合の報酬がどうなるかを推定しようとしています。もう一度繰り返します。これは意味が詰まっているからです。

Value Functionは、部分的な入力を受け取り、報酬を予測する、報酬のトークンレベルの推定です。ポリシーに従って生成した場合の報酬を予測します。このValue Functionは、PPOを行うときに人々が訓練する必要があるものとして論文に見られるものです。典型的には、私が上で述べたAdvantageを計算するときにこのValue Functionが必要だからです。そして、このValue Functionは典型的にポリシーと共同で訓練されます。

8.2 KLダイバージェンスの役割

Afinen： 別の言い方をすれば、SFTモデルとして初期化されるLLMがあり、予測を生成します。典型的に行うのは、Value Headも持つことです。今回は分類問題ではなく、回帰問題です。ポリシーに従って生成を続けた場合の最終的な報酬を推定しようとします。

これは典型的にポリシーと共同で訓練する必要があるものです。このAdvantageがどのように定式化されるかについて、意図的にあまり詳しく触れていません。このクラスの範囲を超えています。しかし、興味がある場合は、このペーパーを読むことを強くお勧めします。これは数学的に関与している論文で、一般化されたAdvantage推定手法についてです。人々が典型的にこれに使用する方法です。

これは「High-Dimensional Continuous Control Using Generalized Advantage Estimation」という論文です。興味があれば見てみてください。しかし、これは人々がこれらのAdvantageを推定するために使用する典型的な方法です。では、これらのAdvantageがどこで使用されるかをすぐに見ていきます。しかし、高レベルとして、全員に理解できていますか？ここで達成しようとしていることは？

別の言い方をすれば、報酬を最大化したいのですが、ベースモデルから逸脱しすぎないようにしたいのです。しかし、私たちが望むのは、実際には報酬を、実際に期待されるものと比較してもう少し相対的にする方法を見つけることです。したがって、得られる報酬を、平均的なケースでの報酬のようなものと比較したいのです。アイデアは、素晴らしい報酬が得られている場合、平均的なケースでの報酬はどうなるかということです。それでもそれを最大化したいのです。

人々がこの報酬マイナスベースラインを使用する理由は、これらの推定の分散を減らし、訓練を典型的により速く進めるからです。それが人々がその部分を使用する理由です。しかし、Advantageを計算するために、人々が使用するのは一般化されたAdvantage推定と呼ばれる方法です。これは、ハイパーパラメータを含む大きな式だと考えることができます。

それは下の論文にあります。一般的なアイデアです。

8.3 複数モデルの必要性

Afinen： PPOについて話しましたが、それがどのように報酬を最大化し、Advantageを最大化し、モデルがベースモデルから大きく逸脱しないようにし、また前回の反復から逸脱しないようにするかを説明しました。しかし、問題は、PPOには多くのモデルが必要だということです。

訓練しているポリシー、つまりLLMが必要です。また、Advantage推定に使用されるValue Functionも必要です。もちろん、Reward Modelも必要です。そして、ベースモデルも必要です。ベースモデルは凍結されています。これは現在のポリシーと比較できるようにするためのSFTモデルです。

したがって、多くのモデルがあります。今、尋ねるかもしれない質問は、良いパフォーマンスを得るために本当にこれらすべてのモデルが必要なのでしょうか？答えは、おそらく必要ないということです。おそらくですが、おそらく必要ありません。そして最近では、より人気が出てきている他の多くの方法があります。

推論モデルのコンテキストでGRPOについて聞いたことがあるかもしれません。来週の第6回講義でGRPOをより詳細に見ていきます。しかし、多くのバリエーションがあることを知っておいてください。PPOは非常に人気があった1つのアルゴリズムですが、PPO内でも多くのバリエーションがあり、最近では使用されている他の多くの強化学習アルゴリズムがあります。

もし来週の講義を予習したい場合は、DeepSeekチームのこの論文も見ることができます。「DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models」で、GRPOアルゴリズムを紹介しています。しかし、見なくても大丈夫です。来週それについて話します。

9. Advantage（優位性）とValue Function（価値関数）

9.1 Advantageの定義と役割

Afinen： 損失関数についてもう少し詳しく見ていきましょう。損失関数は報酬を最大化しようとしますが、同時にモデルがベースモデルから逸脱しないようにもすることを述べました。しかし、実際には皆さんに少し嘘をついていた部分があります。報酬を最大化したいのではありません。実際にはAdvantage（優位性）と呼ばれる量を最大化したいのです。

Advantageとは何でしょうか？Advantageは、期待される結果と比較して出力がどれだけ良いかと考えることができます。別の言い方をすれば、得られる報酬を、平均的なケースでの報酬のようなものと比較したいのです。アイデアは、素晴らしい報酬が得られている場合、平均的な応答での報酬はどうなるかということです。そしてそれでもそれを最大化したいのです。

人々は典型的にAdvantageを使用して、全体のプロセス、訓練をより安定させます。人々がこの報酬マイナスベースラインという形式を使用する理由は、これらの推定の分散を減らし、訓練を典型的により速く進めるからです。それが人々がその部分を使用する理由です。

9.2 Value Functionのトークンレベル推定

Afinen： 私たちは2つの量を持っています。以前に見た報酬があり、これはプロンプトが与えられ、完了が与えられたときにどれだけ良いかを示すものです。プロンプトと完了がどれだけ良いかを計算する方法を見ました。そして、Value Function（価値関数）は別の推定ですが、この推定は完了レベルではなく、実際にはトークンレベルです。

ここで行っているのは、プロンプトと部分的な生成を入力として取り、ポリシーに従って出力の生成を続けた場合の報酬がどうなるかを推定しようとしています。もう一度繰り返します。これは意味が詰まっているからです。

Value Functionは、部分的な入力を受け取り、報酬を予測する、報酬のトークンレベルの推定です。ポリシーに従って生成した場合の報酬を予測します。したがって、もしあなたが文章の途中まで生成していて、「このまま私のポリシーに従って生成を続けたら、最終的にどんな報酬が得られるだろうか？」と問うのです。これがValue Functionが推定しようとしていることです。

このValue Functionは、PPOを行うときに人々が訓練する必要があるものとして論文に見られるものです。典型的には、私が上で述べたAdvantageを計算するときにこのValue Functionが必要だからです。そして、このValue Functionは典型的にポリシーと共同で訓練されます。

別の言い方をすれば、SFTモデルとして初期化されるLLMがあり、予測を生成します。典型的に行うのは、Value Headも持つことです。今回は分類問題ではなく、回帰問題です。ポリシーに従って生成を続けた場合の最終的な報酬を推定しようとします。これは典型的にポリシーと共同で訓練する必要があるものです。

9.3 Generalized Advantage Estimation（GAE）

Afinen： このAdvantageがどのように定式化されるかについて、意図的にあまり詳しく触れていません。このクラスの範囲を超えています。しかし、興味がある場合は、このペーパーを読むことを強くお勧めします。これは数学的に深く関与している論文で、一般化されたAdvantage推定手法についてです。これが人々が典型的にこれに使用する方法です。

論文のタイトルは「High-Dimensional Continuous Control Using Generalized Advantage Estimation」です。興味があれば自由に見てください。しかし、これは人々がこれらのAdvantageを推定するために使用する典型的な方法です。

Advantageを計算するために、人々が使用するのは一般化されたAdvantage推定（Generalized Advantage Estimation、GAE）と呼ばれる方法です。これは、ハイパーパラメータを含む大きな式だと考えることができます。それは下の論文にあります。ここではその詳細な数式には立ち入りませんが、一般的なアイデアとして理解しておいてください。

高レベルとして、全員に理解できていますか？ここで達成しようとしていることは？報酬を最大化したいのですが、ベースモデルから逸脱しすぎないようにしたいのです。そして、報酬を実際に期待されるものと比較してもう少し相対的にする方法を見つけることが重要なのです。

10. PPOの変種：ClipとKL-penalty

10.1 PPO Clipの仕組み

Afinen： 時間を見ていますので、PPO損失の2つの典型的なバリエーションを見ていきましょう。1つ目はPPO Clipと呼ばれます。ここでのアイデアは、ある反復から次の反復への更新が大きくなりすぎないようにすることです。

損失の定式化はこうなります。L = min(R(θ) × A, clip(R(θ), 1-ε, 1+ε) × A)です。これから詳細に入る前に、混乱するかもしれないいくつかの点を指摘したいと思います。私自身も混乱したからです。

まず第1に、この式はL =として表現されていますが、実際には最小化したいものではなく、最大化したいものです。人々が典型的にLと言うとき、損失を意味します。しかし、ここでは最大化したいのであって、最小化したいのではないことを知っておいてください。

第2に、R(θ)という項を導入しています。これはReward Modelではありません。典型的に人々はRを報酬を意味するために使用しますが、ここでは報酬ではありません。実際には確率の比率（Ratio）です。現在のポリシーと前のステップのポリシー、π_θ_oldと表記されるものとの間の確率の比率です。

これは、現在の段階でのポリシーが古いポリシーとどれだけ異なるかを定量化します。ここで古い（old）と言うとき、SFTモデルではありません。SFTモデルではありません。RL段階での前回の反復時のモデルです。なぜなら、ここで望むのは、ポリシーの更新が広すぎないようにすることだからです。ここまでは順調ですね。

10.2 更新の大きさを制限するクリッピングメカニズム

Afinen： Aは何ですか？AはAdvantageです。報酬とValue Functionの関数である複雑な式と考えることができ、基本的にどれだけ良いかを教えてくれます。

この複雑な式がなぜ意味をなすのか見ていきましょう。Advantageが正の場合、何らかの形で生成されたものを強化したいことを意味します。したがって、Aが正の場合、このL_clipはRの関数として線形関数のように見えます。R × Aですから、Rの関数として線形関数です。そして1 + εの後は平坦になります。

なぜこのような形のグラフが必要なのでしょうか？Rが何を意味するかを再度考える必要があります。Aが正の場合、つまり強化したいものである場合、典型的に起こったことの確率を増やしたいのです。したがって、Rを高くしたいのですが、あまりにも高くしたくありません。そのため、このクリッピングメカニズムがあります。

だからこのクリッピングがあるのです。Lを最大化したいので、Rを増やす方向に進みます。しかし、Rをあまりにも増やしたくありません。それがこの理論的根拠です。

しかし、Aが負の場合、何らかの形で行ったことは、あまりやりたくないことを意味します。したがって、Lを最大化するために、実際に生成したものの確率を減らしたいのです。Rを小さくしたいのです。それもLを増やすからです。しかし、あまりにも小さくしたくありません。あまり大きな更新を望まないため、ここにこのクリッピングメカニズムがあります。

別の言い方をすれば、この超複雑な式は、私が今述べたことで直感的に説明できます。正のAdvantageがある場合、この出力を生成することを強化したいのです。これはモデル、つまりReward Modelが好んだものだからです。しかし、あまりにも更新したくないため、このクリッピングがあります。

Advantageがゼロより小さい場合も同様です。この出力が起こる確率をダウンウェイトしたいのです。したがって、訓練しているポリシーに対する古いポリシーの比率である、より小さなRを持ちたいのです。しかし、あまりにも小さくしたくありません。これも大きすぎる更新をしないためです。

これは理解できますか？大まかに理解できますか？この式を読み直すことをお勧めします。私が述べたことを思い出してください。うまくいけばもう少し意味が通じるでしょう。しかし、質問があればお答えします。

質問がありました。連続でない部分はどうなりますか？ReLUと同じですよね？同じ手法を使用するでしょう。そうです、同じです。同じことです。

素晴らしい質問がありました。なぜベースモデルではなく前回の反復を使用しているのですか？実際には、ベースモデルからあまり離れないようにしたいだけでなく、ある反復から別の反復への更新があまり極端にならないようにもしたいのです。これは訓練の安定性を改善するためです。これは私たちが望む追加の制約です。

質問がありました。ベースモデルは考慮していますか？考慮しますし、正確にお伝えしますが、この定式化では考慮していません。この定式化では考慮していませんが、LLMベースのRLに典型的に使用する定式化では考慮しています。それは後で見ていきます。

質問がありました。Rをどのように定量化しますか？Rとは何を意味しますか？典型的には、入力に対してトークンが起こる確率です。LLMの出力で得られる確率分布と考えることができます。それを使用するでしょう。

10.3 KL-penalty方式

Afinen： これがPPOペーパーが言及している第1のバリエーションです。PPO Clipと呼ばれます。そして、私たちが持つ第2のバリエーションは、KLダイバージェンスを使用するもので、KL-penaltyと呼ばれます。これは比率とAdvantageの関数で、古いポリシー（前回の反復）と現在の反復の間のKLダイバージェンスを引いたものです。

数式で表すと、L = R(θ) × A - β × KL(π_θ_old || π_θ)となります。素晴らしい指摘がありました。なぜ古いもの（old）を使用しているのか？実際、oldは前回のRL反復を意味します。しかし、最近では、人々はreferenceを使用します。これは単なる変更です。なぜなら、このペーパーは2017年に発表されたもので、2025年のLLMは2020年代により一般的になったものだからです。

したがって、そこに入れるものに違いがあるだけです。そうです、実際には典型的にKLダイバージェンスに入れるのはreferenceです。もう1つ言及することは、最近誰かがPPOを使用してポリシーを訓練したい場合、典型的にはKLダイバージェンスを使用します。そして、古い反復とのクリッピングも混ぜるかもしれません。基本的に2つを混ぜます。

損失関数がどのようなものになり得るかについて、多くの異なる定式化があります。したがって、私が言っていることが常に真実というわけではありませんが、これが人々が時々行うことです。両方を混ぜるのです。

10.4 現代のLLMにおける実装の違い

Afinen： PPOについて話し、それがどのように報酬を最大化し、Advantageを最大化し、モデルがベースモデルから大きく逸脱しないようにし、また前回の反復から逸脱しないようにするかを説明しました。現代のLLMでは、この実装にいくつかの重要な違いがあります。

2017年のオリジナルのPPOペーパーでは、「old」という用語を使用していました。これは前回のRL訓練反復のポリシーを指していました。しかし、2020年代にLLMが普及するにつれて、実践者たちはこの用語を「reference」に変更しました。Reference Modelとは、SFT後のモデル、つまりベースモデルを指します。

したがって、KLダイバージェンスの項では、典型的には現在訓練しているポリシーとReference Model（SFTモデル）との間の距離を測定します。これは、ベースモデルから大きく逸脱しないようにするための制約です。

一方、クリッピングメカニズムでは、前回のRL反復（old iteration）との比較も併用することがあります。これは、各訓練ステップでの更新が大きすぎないようにするための追加の制約です。

現代のLLM訓練では、多くの実践者がこれら両方のメカニズムを組み合わせています。つまり、KLダイバージェンスでReference Modelとの距離を制約し、同時にクリッピングで前回の反復からの更新幅も制約するのです。両方を混ぜることで、より安定した訓練が可能になります。

損失関数がどのようなものになり得るかについて、多くの異なる定式化があります。研究チームや実装によって、さまざまな組み合わせが使用されています。したがって、私が言っていることが常に真実というわけではありませんが、これが現代のLLM訓練で人々が典型的に行っていることの一般的なパターンです。

11. 課題

11.1 2段階プロセスの複雑性

Afinen： RLベースのアプローチに関するいくつかの課題についても話したいと思います。第1の課題は、2段階プロセスが必要だということです。まずReward Modelを訓練する必要があり、次にReward Modelを使用してポリシーを訓練する必要があります。

しかし、問題は、ステップ1を実行し、ステップ2を実行してから、「ああ、待って、ステップ1に問題がある」と気づくことです。そうすると、すべてをやり直す必要があります。したがって、多くの依存関係があり、それが本当に人生を困難にする可能性があります。訓練レシピは最もシンプルなものではありません。これが1つのマイナス面です。

Reward Modelに何か問題があることがわかった場合、単にReward Modelを修正して再訓練するだけでは済みません。そのReward Modelを使用して訓練したポリシーも再度訓練し直す必要があります。この依存関係の連鎖が、開発サイクルを非常に長く、複雑にしてしまいます。さらに、各段階で異なるデータセット、異なるハイパーパラメータ、異なる訓練設定を管理する必要があるため、全体的な訓練パイプラインの管理が非常に煩雑になります。

11.2 ハイパーパラメータの調整困難性

Afinen： 第2のマイナス面は、チューニングする必要があるハイパーパラメータの数についてです。KLダイバージェンス定式化からのβがあります。それが1つです。PPO Clipバージョンからのεがあります。それが別の1つです。一般化されたAdvantage推定については、数式は見ていませんが、少なくとも2つのハイパーパラメータがあると思います。

とにかく、多くのハイパーパラメータがあります。もちろん、一部のハイパーパラメータは他のものよりも良いパフォーマンスを発揮します。そして、再訓練する必要がある場合、すべてを再度実行する必要があります。

これらのハイパーパラメータを適切に設定することは非常に重要ですが、同時に非常に困難です。例えば、βが大きすぎると、モデルはベースモデルから全く動かなくなり、Preference Tuningの効果がほとんど得られません。逆にβが小さすぎると、モデルがベースモデルから大きく逸脱してしまい、Reward Hackingや性能劣化のリスクが高まります。

εについても同様です。クリッピングの範囲が広すぎると更新が大きすぎて不安定になり、狭すぎると学習が遅くなります。さらに悪いことに、これらのハイパーパラメータは相互に影響し合います。βを変更すると、εの最適値も変わる可能性があります。

そして、ハイパーパラメータの設定が最適でないことがわかった場合、2段階プロセス全体を再度実行する必要があります。まずReward Modelを再訓練し、次にその新しいReward Modelを使用してポリシーを再訓練します。これは膨大な計算リソースと時間を消費します。したがって、ハイパーパラメータの探索空間が大きく、調整が非常に困難なのです。

11.3 学習の不安定性

Afinen： 次に、不安定性の課題があります。反復を制約しても、それでも十分でない場合があります。訓練プロセスを安定させるために、前回の反復からの更新を制限したり、ベースモデルからの逸脱を制限したりしていますが、それでも訓練が不安定になることがあるのです。

訓練を監視するために使用できるメトリクスについて考えてみましょう。ある意味で報酬を最大化しようとしているので、典型的に使用するメトリクスは平均報酬です。しかし、これは素晴らしい方法ではありません。つまり、訓練を監視する方法ではありますが、必ずしも最良の方法ではありません。

少なくともPre-trainingやSFTに関しては、監視していたクロスエントロピー損失があり、それはモデルが再現しようとしている振る舞いをどれだけ出力できるかを本当に教えてくれました。しかし、ここでは報酬を最大化しているだけで、その報酬が本当に望むものを捉えているかどうかは完全には確信が持てません。Reward Hackingの問題もあります。したがって、これは別の課題です。

平均報酬が上がっているように見えても、実際にはモデルが望ましい方向に進んでいない可能性があります。報酬が増加しているのに、実際の出力品質が悪化しているケースもあり得ます。これは、Reward Modelが不完全であり、実際の人間の好みを完全には捉えていないことを示しています。

さらに、訓練中に報酬が突然急激に変化したり、予測不可能な挙動を示したりすることがあります。これは、ポリシーの更新が大きすぎたり、Reward Modelの特定の領域でのエラーが増幅されたりすることが原因です。このような不安定性は、最終的なモデルの性能に悪影響を及ぼす可能性があります。

11.4 探索と多様性の必要性

Afinen： もう1つの重要な点は、RL世界では、どの完了をすべきでないか、どの完了をもっとすべきかを知るために、生成する際に多様性を持つ必要があるということです。RL訓練ループ中に、プロンプトがあるたびに何かを生成し、それから再試行してもう一度生成するとき、生成するものが近すぎると良くありません。

なぜなら、可能な完了のセットを探索していないからです。したがって、これは心に留めておく必要がある別の課題です。モデルに探索を行わせ、何が良いかを見させる必要があります。

これは非常に重要なポイントです。もしモデルが常に似たような応答ばかり生成していたら、どの種類の応答が良くてどれが悪いのかを学習する機会が限られてしまいます。探索が不足していると、モデルは局所的な最適解に陥ってしまい、より良い応答の可能性を見逃してしまう可能性があります。

一方で、あまりにもランダムに探索しすぎると、訓練が非効率になります。低品質な応答ばかり生成していても、学習の進展は遅くなります。したがって、探索と活用のバランスを取ることが重要です。十分に多様な応答を生成して、何が良いかを学習しつつ、同時に既に学習した良い応答のパターンも活用する必要があります。

温度パラメータやサンプリング戦略を調整することで、この多様性をある程度コントロールできますが、適切なバランスを見つけることは容易ではありません。探索が不足すると学習が停滞し、探索が過剰すぎると訓練が不安定になります。

12. On-policyとOff-policy

12.1 On-policy学習の定義

Afinen： そして最後のポイントは、皆さんの多くがRLに詳しくなかったということです。私もそうでした。そして、このステージを行うために必ずしもRLが必要な理由は明確ではありません。また、1つ言及したいことがあります。このRLベースの訓練では、「On-policy訓練」という用語をよく耳にします。それが何を意味するのかをお伝えしたいと思います。

これとSFTとの違いは何でしょうか。SFT中は、プロンプトと、モデルに生成して模倣してほしい応答がありました。しかしここで行っているのは、各反復でモデルに出力を生成させ、その出力がどれだけ良いかを使用してモデルを更新することです。したがって、両者には本質的な違いがあります。なぜなら、ここで行っているのは、モデルに何かを生成させることだからです。一方、SFTでは、必ずしもモデルによって生成されたわけではないデータを使用しているだけです。

On-policy訓練とは、現在のポリシーから生成し、それに基づいて最適化することを含む訓練を指します。これはOff-policy訓練とは対照的で、Off-policy訓練は訓練しているモデルによって生成されていない生成に依存します。これは理解できますか？

12.2 Off-policy学習との比較

Afinen： これはよく目にする用語なので、お伝えしています。PPOはOn-policyアルゴリズムです。On-policyとは、モデルが現在のポリシーから生成した出力で最適化するということです。各反復で、モデル自身が出力を生成し、その生成の良さに基づいてモデルを更新します。

一方、Off-policyは、学習中のモデルが生成していないデータに依存します。例えば、他のモデルが生成したデータや、過去のバージョンのモデルが生成したデータを使用することができます。Off-policy手法の利点は、古いデータを再利用できることです。新しい生成を毎回行う必要がないため、計算効率が良くなる可能性があります。

しかし、Off-policy手法には課題もあります。訓練しているモデルの現在のポリシーと、データを生成したポリシーの間に分布のずれがある可能性があります。このずれが大きくなると、学習の効果が低下する可能性があります。

12.3 SFTとの本質的な違い

Afinen： 質問がありました。なぜこのPreferenceデータでSFTをしないのか？SFTでは、モデルに「この入力が与えられたら、これを生成すべき」「その入力が与えられたら、それを生成すべき」と伝えます。しかし、生成すべきでないことについては伝えていません。

完璧な文に書き直さない限り、生成してほしくない何かがある場合、従来のSFTフレームワークでモデルにそれを生成しないように伝える方法はありません。しかし、それは素晴らしいプロンプトです。なぜなら、10分後に、RLで行ったことを教師あり方式で行う方法を見るからです。

しかしそれ以外では、大まかに理解できましたか？完璧です。SFTは基本的に「このように生成してください」と示すだけです。良い例だけを見せて、それを模倣するように教えます。負のシグナル、つまり「このようには生成しないでください」という情報を提供する方法がありません。

On-policyのRL訓練では、モデルは自分自身で出力を生成します。そして、その生成が良かったか悪かったかのフィードバックを受け取ります。悪い生成に対しては低い報酬が与えられ、モデルはそのような生成を避けるように学習します。これが、正と負の両方のシグナルを提供できる重要な違いです。

さらに、SFTではデータセット内の例を順番に見ていくだけですが、On-policy RLでは、モデルが生成するものが訓練の進行とともに変化します。モデルが改善されるにつれて、生成する出力も変わり、それに基づいて新しいフィードバックを受け取ります。これは動的な学習プロセスであり、SFTの静的なデータセットからの学習とは根本的に異なります。

13. Best-of-N

13.1 Best-of-N手法の概要

Afinen： それでは、次の数分で、実際にはRLよりも頻繁に使用される手法を見ていきます。これはReward Modelを持っているが、RLをしたくない人々のための手法です。なぜRLをしたくないのでしょうか？高価だからです。多くのモデルが必要だからです。

したがって、皆さんの指摘通り、確かに高価です。なぜなら、これらすべてのモデルが必要で、時にはその訓練をチューニングするのがあまりにも難しいからです。そこで、Best-of-NまたはBoNと呼ばれるこの手法があります。

アイデアは、得られたReward Modelを活用して、ユーザーに返す出力を選択することです。アイデアはこうです。プロンプトがあり、モデルに「実際にはいくつかの生成がほしい」と伝えます。したがって、4回または5回生成します。そして、各プロンプト完了にスコアを付け、最良のもの、最高評価のものを返すだけです。これがBest-of-Nと呼ばれる理由です。

n個の完了があり、それらすべてを評価し、最良のものを返すだけです。したがって、プロンプトがあります。お気に入りの例で、「テディベアと一緒にできる新しい活動を提案してください」。それをSFTモデルに入れます。SFTモデルを訓練しているのではありません。そのままです。そして、例えば3つの完了を生成するとしましょう。

13.2 Reward Modelを用いた選択プロセス

Afinen： 1つ目は素晴らしい答えです。2つ目は「いいえ、テディベアと時間を過ごさないでください」というもので、良い答えではありません。そして3つ目は、「テディベアをピクニックに連れて行ってください」というもので、これも良い答えだと思います。

これらすべてをReward Modelに入れます。ここで、Reward Modelの出力が何であるかについてお答えしたかったのです。このようなスコアになります。例えば、1つ目はかなり良い完了なので、0.8のようなものです。2つ目は全く良くありません。例えばマイナス2としましょう。そして3つ目はまあまあで、中間くらいです。

Best-of-N手法は、最高評価のものを選択します。それが1つ目です。そして、これが返すものです。このアプローチの問題は何でしょうか？

提案された答えは、モデルが悪ければ全体的に悪くなるということです。それは公平な指摘です。しかし、十分高い温度で十分な完了を行えば、多様性が得られるでしょう。これは公平な指摘で、問題になる可能性があります。しかし、問題ではないと仮定しましょう。別の問題は何でしょうか？

はい。正解です。提案された答えは、モデルに何度もクエリするということです。これが確かに問題です。RL訓練をスキップしていますが、基本的にすべての作業を推論段階に押し付けています。そして、これがすべてを非常にコストがかかるものにしているのです。

いつ悪くなる可能性があるでしょうか？例えば、多くのトラフィックにモデルを提供する必要がある場合、コストの観点から意味をなさない可能性があります。したがって、このルートを取る前に、推論トラフィックが何になるか、訓練コストがどうなるかを評価し、そこから判断するのが良いでしょう。このパートについて質問はありますか？

質問がありました。そのシグモイドはソフトマックスでしょうか？これについて話していますか？このアルゴリズムでは、Reward Modelが訓練されていると仮定しています。したがって、ここのシグマは、ペアワイズで訓練したためペアワイズです。しかし、Best-of-Nの場合、行うのはReward Modelを使用してn回スコアリングし、最高のものを選ぶだけです。

質問がありました。しかし、すべての応答が悪かったらどうでしょう？これは確かに公正な懸念です。これは確かに懸念です。したがって、モデルは少なくとも少しは良い必要があります。

正確に、その通りです。スケールに制約はありますか？スケーリングの方法によっては、実際にはスケールを気にしません。最良のもの、最高のものを取る限り、例えば正規スコアでスケーリングすると仮定すると、最高のものは依然として最高のままです。したがって、この場合、実際にはスケールを気にしません。それについても気にしません。

しかし、典型的にスケーリングが重要になるのは、損失関数に組み込まれる場合です。それがRLの場合であり、そこで人々がスケーリングメカニズムを使用します。それが重要な部分です。

13.3 コストとレイテンシのトレードオフ

Afinen： それでは、これで私からShervinにバトンタッチします。ありがとうございました。

Shervin： この最後のパートでは、DPOについて話していきます。しかしまだDPOが何を意味するかはお伝えしません。まず、RL世界での不満を聞いてから、それについて何ができるか、そして人々がどのように改善してきたかを見ていきます。

Afinenが取り上げた内容から繰り返しになりますが、PPOのRL定式化では、損失最適化中に多くのモデルの重みを保持する必要があります。この損失関数を見ると、現在のモデルのポリシーがあり、古いモデルまたはリファレンスモデルのポリシーがあります。そして、Advantageの中にはReward ModelとValue Functionも隠れています。したがって、これら4つすべて、これは多すぎます。

そして2つ目は、Best-of-Nのアプローチを取る場合です。RLを行わず、複数回生成して最良の完了を選ぶだけです。Afinenが述べたように、レイテンシとコストの問題があります。そして、思考実験のために、無限のお金があったと仮定しましょう。それでも問題ないでしょうか？

これらすべてを並列に生成すると仮定しましょう。それでも、答えの生成の最大時間を待つ必要があります。そして、レイテンシの分布を見ると、通常は単一の点に中心を置かない何らかの形状をしています。そして、n個の答えの最大値の確率分布を見ると、それは右にシフトする傾向があります。

したがって、無限のお金、無限の計算リソースがあったと仮定しても、単一パスの場合よりも長く待つ必要があります。これらの懸念は理解できますか？

13.4 実用上の制約と適用場面

Shervin： Best-of-N手法は、RLの複雑さを避けることができるという利点がありますが、実用上は大きな制約があります。まず、コストの観点から考えてみましょう。例えば、大規模なトラフィックにモデルを提供する必要がある場合を想定してください。ユーザーからのリクエストごとにn回の生成を実行する必要があるということは、計算コストがn倍になるということです。

n=5であれば、単一の推論に比べて5倍のコストがかかります。これは、特に商用アプリケーションでは持続不可能な場合があります。推論トラフィックが多い場合、このアプローチは経済的に現実的ではありません。

レイテンシの観点からも問題があります。並列化できたとしても、n個の生成の中で最も時間がかかるものを待つ必要があります。生成時間の分布を考えると、平均的には一定の時間で完了しますが、時々非常に長い時間がかかるケースがあります。n個の生成を行うと、そのような長いケースに遭遇する確率が高くなります。

統計的に言えば、n個の独立した生成の最大値の分布は、単一の生成の分布よりも右にシフトします。つまり、ユーザーはより長い待ち時間を経験する可能性が高くなるのです。リアルタイムのアプリケーションでは、これはユーザーエクスペリエンスを著しく低下させる可能性があります。

したがって、このルートを取る前に、いくつかの要因を慎重に評価する必要があります。推論トラフィックがどの程度になるか、訓練コストと推論コストのトレードオフはどうか、ユーザーのレイテンシ要件は何か、といった点です。そこから、Best-of-Nが適切なアプローチかどうかを判断することができます。

一般的に、Best-of-Nは以下のような場合に適している可能性があります。トラフィックが比較的少ない場合、レイテンシの要件がそれほど厳しくない場合、RLの複雑さを避けたい場合、迅速にプロトタイプを作成したい場合などです。しかし、大規模な本番環境では、コストとレイテンシの制約により、他のアプローチがより適切である場合が多いのです。

14. DPO（Direct Preference Optimization）

14.1 DPOの動機と背景

Shervin： では、「なぜずっと教師あり学習をしないのか？」という質問が出てきます。これがDPOの研究者たちが探求したルートです。DPOは「Direct Preference Optimization」の略です。最初にReward Modelを見つけ、次にモデルの重みを反復するという高価な2段階プロセスを行う代わりに、モデルの重みを直接最適化する単一の損失関数を最適化します。

見てわかるように、もはや報酬は関与していません。Rはありません。そして、Preference Pairの関数として気にすることを定式化する方法があります。この損失関数では、いくつかの変数とシグモイド関数がありますが、括弧の中には、特定の完了が起こる確率があります。そして、勝利完了が起こる確率と敗北完了が起こる確率を比較する減算操作があります。

見てわかるように、これはPreference Pairに関する直接的な表現です。これは非常に良いことです。そして、もう少し詳しく見ると、Bradley-Terry定式化について私が述べたことを認識できるでしょう。なぜなら、シグモイドの対数の期待値があり、そのシグモイド内には項の差があり、報酬項の等価物として認識できるものがあるからです。

14.2 RLの複雑さからの解放

Shervin： 一度に多くのことを見ているのはわかっています。数式はそれほど美しくありません。質問はありますか？それから、そのβが何であるか、そしてそもそもこの数式をどのように得たのかについて議論していきます。

このペーパーのタイトルが「Your Language Model is Secretly a Reward Model」となっている理由について、もう1つ言及したいことがあります。その理由は、この損失関数から特定できる報酬のプレースホルダーが、ポリシーの関数として表現されているからです。そこにはRがありません。しかし、報酬の等価物を表現すると、直接モデルの表現が見つかります。これは非常に興味深い洞察です。

さて、そもそもどのようにしてここに到達したのか、一緒に考えてみましょう。数スライド前に見たPPO目的を思い出してください。報酬を最大化し、得られたポリシーとリファレンスポリシーとの距離を最小化したいと考えていました。これは、報酬の最大化とKLダイバージェンス項の間のトレードオフです。

そして、ベースモデルからどれだけ離れたいかをペナルティ化するβ係数があります。このペーパーが行ったことは、この数式を書き出し、最適解が何になるかを解いたことです。最適ポリシーπ*を表現し、この表現を導出すると、rの関数として得られます。

これは目的関数にあった他の項です。したがって、これらすべてのステップには追加の仮定はありません。単に行われた一連の導出です。そして、ここで見ることができるのは、分配関数を表すZ項で、物事を正規化するだけです。しかし、これは新しいものではありません。すでにそこにあった項の関数です。

これらの項を再配置すると、このπ*の関数としてRを等価に表現できます。これは単にこれら2つの表現の間で項を再配置しただけです。特に派手なことは何もありません。そして、このペーパーが行った重要な部分は、この項を何らかの報酬として認識し、それをBradley定式化の一部として表現したことです。

覚えていますか、勝利完了が敗北完了より大きい確率があり、2つのR間の差のシグモイドがありました。基本的に、彼らはこの定式化を再び取り、得られた最適報酬の表現を代入しました。これはポリシーの関数だと見ました。

したがって、最終的には物事を代入すると、もはや報酬はなく、他のパラメータの関数だけです。βとポリシーだけがそこにあります。そして最後のステップは、Afinenが述べていたのと同じです。最大化したいこの確率があれば、それを損失関数に変えることができます。

そして、この損失関数が、ポリシーの重みをこのPreferenceデータと整合させるように調整するために、このペーパーが最適化することを提案しているものです。これらの少数のステップにこのペーパーのかなり重いステップを大幅に簡略化しました。理解できますか？

そして、ここで見るβは、PPO定式化で見たのと同じβです。したがって、典型的には、大きさの桁を知りたければ、約0.1程度に取られます。したがって、βはハイパーパラメータであり、最適化したいのはポリシーだけです。そして、Preference Pairは入力として持っています。理解できますか？素晴らしい。

14.3 DPOの損失関数の導出

Shervin： それでは、そもそもどのようにしてここに到達したのか、一緒に考えてみましょう。数スライド前に見たPPO目的を思い出してください。報酬を最大化し、得られたポリシーとリファレンスポリシーとの距離を最小化したいと考えていました。これは、報酬の最大化とKLダイバージェンス項の間のトレードオフです。

そして、ベースモデルからどれだけ離れることをペナルティ化するかを制御するβ係数があります。このペーパーが行ったことは、この数式を書き出し、最適解が何になるかを解いたことです。最適ポリシーπ*を表現しました。この表現を導出すると、rの関数として得られます。

これは目的関数にあった他の項です。したがって、これらすべてのステップには追加の仮定はありません。単に行われた一連の導出です。そして、ここで見ることができるのは、分配関数（partition function）を表すZ項で、物事を正規化するだけです。しかし、これは新しいものではありません。すでにそこにあった他の項の関数です。

これらの項を再配置すると、このπの関数としてRを等価に表現できます。これは単にこれら2つの表現の間で項を再配置しただけです。特に派手なことは何もありません。数学的な操作により、報酬Rを最適ポリシーπ、β、そして正規化項Zの関数として表現できることがわかりました。

14.4 Bradley-Terry式からDPO式への変換

Shervin： そして、このペーパーが行った重要な部分は、この項を何らかの報酬として認識し、それをBradley定式化の一部として表現したことです。覚えていますか、勝利完了が敗北完了より大きい確率があり、2つのR間の差のシグモイドがありました。

基本的に、彼らはこのBradley-Terry定式化を再び取り、得られた最適報酬の表現を代入しました。先ほど見たように、これはポリシーの関数として表現されていました。したがって、最終的には物事を代入すると、もはや報酬Rはなく、他のパラメータの関数だけです。βとポリシーだけがそこにあります。

報酬を明示的に計算する必要がなく、すべてポリシーπの項で表現されています。これが「Your Language Model is Secretly a Reward Model」というタイトルの意味です。Reward Modelを別途訓練する必要がなく、ポリシー自体が暗黙的に報酬を表現しているのです。

そして最後のステップは、Afinenが述べていたのと同じです。最大化したいこの確率があれば、それを損失関数に変えることができます。最大化したい確率の対数を取り、負の符号を付けることで、最小化する損失関数に変換します。

この損失関数が、ポリシーの重みをこのPreferenceデータと整合させるように調整するために、このペーパーが最適化することを提案しているものです。具体的には、-E[log σ(β log(π_θ/π_ref)(y_w) - β log(π_θ/π_ref)(y_l))]という形になります。

これらの少数のステップに、このペーパーのかなり数学的に重いステップを大幅に簡略化しました。理解できますか？そして、ここで見るβは、PPO定式化で見たのと同じβです。したがって、典型的には、大きさの桁を知りたければ、約0.1程度に取られます。

したがって、βはハイパーパラメータであり、最適化したいのはポリシーθだけです。そして、Preference Pairは入力として持っています。入力としてPreference Pairがあり、最適化対象はポリシーだけで、明示的なReward Modelは必要ありません。理解できますか？素晴らしい。

14.5 RLHFとDPOの比較

Shervin： それでは、この手法がRLHFと比較してどうなのか見てみましょう。RLHFは2段階の訓練プロセスで、まず報酬関数を適合させ、次にそれを使用してポリシー更新ステップを行います。Afinenが述べたように、これは非常に重いものです。訓練中にメモリに多くのモデルを保持する必要があることをすぐ前に述べました。そして訓練の安定性が懸念事項です。

直接的な監督はありません。現在のモデルのポリシーに依存して次の更新を生成します。したがって、多くの複雑さがあります。それに対して、このDPO定式化は、Preference Tuningについて考えるための教師あり方式を提供します。これらのPreference Pairを取り、それらに直接損失関数を適合させるだけです。

そして、4つのモデルの代わりに、2つのモデルだけが必要です。なぜなら、π_θとπ_refがあったからです。π_refはベースのSFTモデルでした。そして、他のモデルのコピーは必要ありません。したがって、DPOのメリットはシンプルさと効率性です。一方、DPOのデメリットは、実際の性能では、場合によってはPPOの方が優位であることです。

14.6 分布シフトの課題

Shervin： それでは、もしそれがはるかに簡単なら、なぜ全員が単純にDPOを使用していないのかと尋ねたくなるかもしれません。それほど簡単ではありません。実際には、各手法にはいくつかの長所と短所があります。そして、以下にリストされているペーパーは、ベンチマークの違いとそこに到達するためのステップについて非常に興味深い研究を提供しています。

主な要点だけを述べると、全体的にPPOはDPOよりも良いパフォーマンスを発揮します。そして、DPOの素晴らしい点の1つである、この監督、この直接的な監督は、時として訓練時にモデルが見た分布とは正確には異なるものを適合させるというコストを伴います。

このペーパーは、それについて少し話しています。Preference関連データでSFTで訓練すれば、より良いパフォーマンスが得られる可能性があります。しかし、この分布のシフトは、DPOに本質的な課題です。なぜなら、DPO手法が可能にすることの1つは、報酬モデリングを全く気にせず、そこにあるPreferenceデータセットを取得するだけでよいということだからです。

しかし、そうすることの問題は、まさにその分布シフトです。それに対してSFTで訓練するか、自分で生成してそれを評価することもできますが、それは支払う必要があるまた別のコストです。したがって、これはDPOに固有の課題です。Reward Modelingを完全にスキップできることは利点ですが、その代償として、訓練データの分布と実際にモデルが推論時に遭遇する分布の間にミスマッチが生じる可能性があるのです。

外部のPreferenceデータセットを使用する場合、そのデータは現在のモデルのポリシーから生成されたものではない可能性があります。おそらく別のモデル、あるいは人間によって生成されたものです。したがって、このデータに直接適合させると、モデルが実際に生成する分布と訓練データの分布の間にギャップが生じる可能性があります。

このギャップが大きくなると、モデルの性能に影響を与える可能性があります。モデルは、訓練中に見たようなデータを生成するように最適化されていますが、実際に生成すべきデータは異なる可能性があります。この分布シフトの問題は、DPOの直接的な教師あり学習アプローチに伴う根本的な課題の1つなのです。

14.7 実践における選択基準

Shervin： それでは、実践ではどちらを選ぶべきでしょうか？これは計算予算に依存します。パフォーマンス対訓練プロセスの手間をどれだけかけるかに依存します。PPOは、強化学習のバーが非常に調整が難しいものです。最高の結果をもたらしますが、訓練プロセスを細かく管理する必要があるかもしれません。しかし、ほぼそのレベルに達する結果を、はるかに少ない労力で得られる可能性があります。

したがって、クイックなPreference Tuningを行いたい場合、良い結果が示されているが、おそらく最良の結果ではないものを得たい場合、DPOがあなたの味方です。そして、強化学習の専門家で、何をしているかわかっていて、最後の1ビットのパフォーマンスまで求めるのであれば、PPOがより良い方法かもしれません。

具体的には、DPOは以下のような場合に適しています。迅速にプロトタイプを作成したい場合、限られた計算リソースで作業している場合、RLの専門知識がないチームの場合、または合理的に良い結果を素早く得ることが最優先の場合です。DPOのシンプルさにより、実装とデバッグがはるかに容易になります。

一方、PPOは以下のような場合により適しています。最先端の性能が必須の場合、RLの調整に専念できる専門チームがいる場合、大規模な計算リソースが利用可能な場合、または訓練の複雑さを管理するためのインフラがすでに整っている場合です。PPOは最高のパフォーマンスを提供しますが、そのためにはかなりの投資が必要です。

多くの実務者は、まずDPOから始めて、それが十分な結果を提供するかどうかを確認することを選択します。もしDPOで十分なパフォーマンスが得られなければ、その時点でPPOのような、より複雑だがより強力な手法に移行することを検討します。

14.8 実例：テディベアの質問への回答改善

Shervin： それでは、今日の私のお気に入りのパートに移りましょう。皆さん、お気に入りのプロンプトで得られた完了を覚えていますか？「洗濯機にテディベアを入れてもいいですか？」覚えていれば、前回のエピソードで、Instruction Tuning後の応答は「いいえ、損傷する可能性があります。代わりに手洗いしてみてください」でした。

では、この答えについて何か不満はありますか？ヒントを差し上げましょう。テディベアは確かに手洗いすべきです。したがって、事実的には正しいです。しかし、事実的に正しいとしましょう。それ以外に何が気に入らないでしょうか？

提案がありました。「代わりに試してください」と尋ねているということです。より広い点は、少し粗雑すぎる、あまりフレンドリーに聞こえないということだと思います。そして、この質問をした人はテディベアを愛しているかもしれません。だから、優しい方法でそれについて伝えたいと思うかもしれません。

そして、これがまさにPreference Tuning段階の目的なのです。新しい事実を学習したくありません。既存の完了の分布に焦点を当て、モデルが返すべきものを人間が好むものと整合させたいのです。この直感に基づいて、Preference Tuned後の答えはより優しいものになる可能性があります。

「それはやめた方が良いです。テディベアが傷ついてしまうかもしれません。優しく手洗いする方が安全です。」同じポイントを伝えていますが、トーンが人の耳にははるかに良く聞こえます。

この例は、Preference Tuningの核心を完璧に示しています。SFT後の応答は事実的に正確です。テディベアを洗濯機に入れるべきではなく、手洗いすべきだという情報は正しいです。しかし、配信の仕方が冷たく、潜在的に無神経に感じられます。

Preference Tuning後、応答は同じ事実情報を伝えますが、より共感的で優しいトーンで伝えます。「傷つく可能性があります」は「損傷する」よりも柔らかく聞こえます。「優しく手洗い」は「代わりに手洗いしてみてください」よりも思いやりがあります。「やめた方が良いです」は「いいえ」よりも丁寧です。

これがPreference Tuningが達成することです。新しい知識や能力をモデルに教えるのではなく、すでに知っていることを人間が好む方法で表現するように調整するのです。トーン、スタイル、感情的な配慮などの側面を微調整します。これらは、SFTデータだけでは捉えることが難しいものです。

DPOパートについて質問はありますか？これで終わりです。どうもありがとうございました。

Stanford CME295 Transformers & LLMs | Autumn 2025 | Lecture 5 - LLM tuning

For more information about Stanford’s graduate programs, visit: https://online.stanford.edu/graduate-education October 31, 2025 This lecture covers: • Preference tuning • RLHF overview • Reward modeling • RL approaches (PPO and variants) • DPO To follow along with the course schedule and syllabus, visit: https://cme295.stanford.edu/syllabus/ Chapters: 00:00:00 Introduction 00:04:50 Preference tuning 00:11:31 Data collection 00:17:43 RLHF overview 00:28:24 Reward model 00:29:46 Bradley-Terry formulation 00:46:02 Reinforcement learning 00:53:54 PPO 00:57:56 Advantage, value function 01:03:39 PPO variants: Clip, KL-penalty 01:16:20 Challenges 01:19:58 On-policy vs off-policy 01:22:43 Best-of-N 01:29:47 DPO Afshine Amidi is an Adjunct Lecturer at Stanford University. Shervine Amidi is an Adjunct Lecturer at Stanford University. View the course playlist: https://www.youtube.com/playlist?list=PLoROMvodv4rOCXd21gf0CF4xr35yINeOy

youtu.be