SFT：まずは「良いお手本」を真似る

SFTは、指示と回答のペアを大量に用意し、「この指示にはこの回答が望ましい」という例を学ばせる。学習目的自体は事前学習と似ていて、次トークンを当てるだけだが、データの形式が違う。会話形式で、役割（system、user、assistant）を明示し、望ましい口調や構成を含む回答を与える。これによりモデルは、指示を読んだときにどう返すのが“それっぽいか”を身につける。

ただしSFTだけでは限界がある。お手本がカバーしていない状況では崩れやすく、微妙な品質差や安全性の優先順位をうまく表現しきれない。ここで「好み」を学ぶ段階が効いてくる。

好み学習：正解が一つではない世界で“より良い”を学ぶ

会話の品質には正解が一つではない。丁寧さ、簡潔さ、根拠提示、慎重さなど、複数の基準が絡む。そこで「同じ質問に対する二つの回答を比べて、どちらが良いか」をデータとして集める。この比較データから、良い回答に点数を付ける役割を持つモデルを作り、その点数が高くなるように元のモデルを調整するのがRLHFの代表的な考え方である。

ここで理解しておきたいのは、モデルが直接「正解」を学んでいるのではなく、「評価者が好む方向」へ寄せられている点だ。だからデータ収集や評価基準の設計がそのままモデルの性格になる。迎合しやすくなる、無難になりやすい、といった副作用が出るのもこの構造から説明できる。

RLHF：ご褒美を最大化するように学ぶが、運用は難しい

RLHFの流れは、概念としては「人間が良いと感じる回答に高い報酬を与え、その報酬が増えるようにモデルを更新する」である。これにより、事前学習で得た知識や文法能力を保ちつつ、応答の方針だけを人間の期待に合わせられる。

一方で、学習が不安定になりやすい、調整が難しい、報酬モデルの癖に引っ張られる、といった実務上の課題もある。報酬を最大化しようとして、評価者が喜びそうな言い回しだけが上手くなり、中身の正確さが伴わないこともある。これが迎合やそれっぽい断定の増加につながる場合がある。

DPO：強化学習を使わず「選好」を直接反映する

DPOは、好みデータを使う点では同じだが、強化学習のループを回さずに、より直接的に「好まれる回答を出しやすくする」方向へ学習する発想である。比較データを見て、好まれた回答の確率を上げ、好まれなかった回答の確率を下げる。これにより、実装が単純になり、学習の安定性が上がりやすい。

DPOの良さは、運用上の扱いやすさにある。学習が回しやすく、破綻しにくい。一方で、どの程度ベースモデルから離れるか、好みの押し付けが強すぎないか、といった設計課題は残る。結局は、好みデータの質と、どんな方針を学ばせるかが決定的である。

まとめ：指示追従は「目的関数の再設計」であり、人格はデータで決まる

SFTは良いお手本を真似る段階で、RLHFやDPOは「どちらがより良いか」を学ぶ段階である。次トークン予測だけでは保証されない丁寧さや安全性、役立ち度は、こうした追加学習で目的が作り替えられることで実現される。ただし、何を良いとするかはデータと評価基準に依存し、そこがそのままモデルの性格になる。指示に従えるモデルを作るとは、モデルを賢くするだけでなく、「どんな助手であってほしいか」を明文化し、それを学習として落とし込む作業である。

---

生成は一歩ずつ進む：LLMは毎回「次の1トークン」を選んでいる

LLMの生成は、文を一気に出すのではなく、次のトークンを1つ選び、その結果を文脈に追加し、また次を選ぶ、という手順を繰り返す。だから生成が長くなるほど計算は増える。さらに、各ステップでモデルは語彙表の全候補に対して「どれが来そうか」の分布を出す。ここから実際に出力するトークンをどう選ぶかが、デコーディングである。

最も単純なのは、毎回もっとも確率が高いトークンを選ぶ方法で、安定しているが単調になりやすい。逆に確率分布からランダムに選ぶと多様性は出るが、破綻もしやすい。現実の運用では、その中間を取るためにいくつかの制御を組み合わせる。

代表的なのが温度で、確率分布の尖り具合を調整する。温度を下げると保守的になり、上げると多様になる。また、上位の候補だけを残すtop-kや、確率の合計が一定になるまで候補を残すtop-pもよく使われる。これらは「あり得ない候補を切り捨て、あり得る範囲でランダム性を残す」ための道具である。

さらに、同じフレーズを繰り返す癖を抑えるために、過去に出たトークンにペナルティを与える方法もある。停止条件の設計も重要で、EOS（終了記号）や特定の区切りが出たら止める、といった制御が品質と安全に直結する。

KVキャッシュ：過去の計算を使い回して“毎回やり直し”を避ける

推論が遅い最大の理由は、生成のたびに過去の文脈を参照する必要があるからだ。素朴に実装すると、新しいトークンが増えるたびに、過去全体を含む計算を繰り返してしまう。これを避けるのがKVキャッシュである。

自己注意は、過去のトークンの情報を参照する際に、過去側の内部表現をある形に変換して使う。KVキャッシュは、この「過去側の変換結果」を保存しておき、次のステップでは新しいトークンに関する部分だけ計算し、保存した過去情報と組み合わせて参照を作る。結果として、毎回“全文を再計算する”必要が減り、生成が高速化する。

ただし、キャッシュはメモリを消費する。文脈が長くなるほど、保存する過去情報が増え、GPUメモリを圧迫する。長文対応の実装では、速度だけでなくメモリ管理が主要テーマになる。

バッチング：一人ずつ処理するより、まとめて流す方が速い

推論のコストを下げるには、GPUを遊ばせないことが重要だ。単発のリクエストを一つずつ処理すると、GPUの計算ユニットが十分に埋まらず、効率が落ちる。そこで複数のリクエストをまとめて処理するバッチングが使われる。

実務では、入力の長さや生成の進み具合がユーザごとに異なるため、固定バッチは扱いにくい。そこで「到着したリクエストを短い時間窓でまとめて流す」「生成ステップが近いものをまとめて処理する」といった動的バッチングが行われる。さらに、入力を一気に読み込む段階と、生成を刻む段階では計算の性質が違うため、それぞれで最適なスケジューリングが必要になる。

量子化：軽くするほど速くなるが、壊れ方にも癖がある

量子化は、モデルの重みや計算を低いビット幅で表現し、メモリと計算コストを下げる手法である。たとえば8ビット、4ビットの表現を使うと、メモリ帯域が節約され、推論が速くなることがある。特に大きいモデルほど効果が出やすい。

ただし量子化は、精度劣化と引き換えである。劣化は一様ではなく、数字の計算、長い文脈での一貫性、微妙な言い回し、専門領域の正確性などで目立つことがある。また、すべてを同じ精度で落とすのではなく、「特定の層は高精度のまま残す」「重みは低精度だが一部の計算は高精度で行う」といった折衷が取られることが多い。量子化の設計は、速度と品質のバランス設計である。

まとめ：推論は“確率の選び方”と“計算の回し方”の両輪で最適化される

LLMの生成は、次トークンを選ぶ手順の繰り返しであり、デコーディングの設計が出力の性格を決める。KVキャッシュは過去の計算を使い回して速度を上げるが、メモリを消費する。バッチングはGPU効率を高め、スループットを上げるが、遅延とのトレードオフがある。量子化は軽量化と高速化に効くが、壊れ方を理解した上で使う必要がある。推論最適化は、モデルそのものではなく、生成戦略とシステム設計を含む“運用の科学”である。