推論モデルは「プロンプト」ではなく「訓練」で生まれる

去年のチームランチで下手な説明をしてしまったのですが、その後ますます確信を深めた意見があります。推論モデルを「段階的に考えるよう指示された普通のLLM」と捉えているなら、推論モデルをまだ理解できていません。そしてその誤解は、本番環境でコストと精度を静かに損なっています。推論モデルはプロンプトの技法ではありません。訓練の産物です。数学やコードが得意になるchain-of-thought的な振る舞いは、システムプロンプトに書いたものからではなく、検証可能な報酬による強化学習から生まれます。Sebastian Raschkaが新しい11時間のコース「推論モデルを作る」で扱っている内容をたどる中で、ようやくこれを本当に腹落ちさせられました。小さなQwen3のベースモデルを読み込み、検証器を作り、GRPOを回すと、推論トレースが長くなり、精度が上がっていくのを目にできます。自分の訓練ループでそれが起きるのを一度見ると、もう見なかったことにはできません。

主張をきちんと説明したうえで、行き過ぎた部分は修正します。プロンプトが本当に重要な箇所が一つあるからです。それを無視するのは、別の種類の誇張になってしまいますから。

「とりあえずプロンプトで」モデルが破綻する理由

よく語られる話はこうです。2022年、研究者が「ステップごとに考えてみよう」を付け加えると算術の精度が劇的に上がることを発見し、chain-of-thoughtプロンプティングが生まれた。それ自体は間違っていません。しかし、その後に何が起きたかを話が省いています。各ラボはその振る舞いを取り出し、強化学習で重みに焼き付けたのです。現代の推論モデルは、あなたの「ステップバイステップ」の呪文を必要としません。正解にたどり着く推論トレースを生成したことに報酬を与えられた結果、訓練されたことで、デフォルトで長い推論トレースを生成するのです。

これは数時間の実験で自分で確かめられます。ベースモデル、たとえばQwen3 0.6Bは一般的なコンシューマー向けGPU一枚で動きますが、これを使ってchain-of-thoughtプロンプトありとなしでMATH-500を評価します。すると、わずかな向上が見られます。次に、同じモデルファミリーのRLVRで訓練された版を使います。二つの条件の差はもはや「わずかな向上」ではなく、「崖」です。どんなシステムプロンプトを書いても、この差は埋まりません。これが私の主張の実証的な核心です。能力は重みに宿っており、その重みは訓練によってそうなったのであって、推論時の巧妙なトークンの並べ方によってではありません。

混乱が続くのは、外から見ると両者がよく似ているからです。どちらも回答の前に長い中間推論を出力します。しかし表面の類似は、因果関係の違いを隠しています。ベースモデルに段階的に考えさせるのは、暗算をしながら思考過程を実況するようなものです。実況は能力の後に続いてくるのです。一方RL訓練は能力そのものを変えます。モデルは最終的な正解率に向けてエンドツーエンドで最適化され、難しい問題で正解を出すための道具として、長い推論が偶然にも有効な戦略になるからです。

検証器こそが肝

私がMLエンジニアだった頃、RLHFで少し厄介に感じていたのは報酬モデルでした。人間の好みを模倣する別のニューラルネットワークを訓練し、そのモデルに対してポリシーを最適化し、そして残りのプロジェクト期間は報酬ハッキングとの戦いに費やします。ポリシーは、報酬モデルの点数は高いけれど実際の人間にはまったく役に立たない、退化した出力を見つけ出すのです。それはアーキテクチャに組み込まれた敵対的な関係です。

検証可能な報酬による強化学習（RLVR）はこれを完全に回避します。そして検証器をゼロから作ってみると、その手の打ち方がいかにエレガントかが分かります。数学の場合、検証器は退屈で決定的なプログラムです。モデル出力から最終的な答えを抽出し、正規化し（分数、小数、1/2と0.5のような等価な表記を扱う）、数学的な等価性を確認します。正解なら報酬1、不正解なら0。ハックできる学習済みの報酬モデルは存在しません。報酬信号はグラウンドトゥルースそのものです。

これが、推論モデルがまず数学とコードで得意になった理由です。どちらの領域にも、安価で信頼性の高い検証器があります。数学では記号的な等価性チェッカー、コードではユニットテストです。出力をランク付けする人間のアノテーターは不要で、必要なのはブール値を返すPython関数だけです。特定ドメインの推論を作ろうとする人にとっての実際的な帰結は厳しいものです。ドメインの検証器を書けるなら、おそらくそのドメインの推論器を訓練できます。書けないなら、つまりそのドメインでの正しさが、マーケティングコピーのように好みの問題であるなら、RLHFと報酬ハッキングの頭痛に付き合うしかありません。

新しいドメインで推論を成立させるボトルネックは、計算資源やデータではありません。「正しい」が何を意味するかをプログラムとして書けるかどうかです。

訓練の前にまず検証器を作ることの好きなところの一つは、二役をこなすことです。MATH-500で評価のためにベースモデルを採点するのと同じグレーダーが、RL中には報酬関数になります。自分で実装してみると、その中にどれほど細かな作業が含まれているかに気づきます。答えの抽出は本当に面倒です。モデルは数十通りの形式で最終解答を書くため、脆い抽出器は報酬信号を静かに壊します。「したがってx = 7」と書いたモデルは、正規表現がボックス付きの答えしか探さなければ不正解と判定されるかもしれません。雑な検証器は雑なポリシーを教えます。これは論文を読むだけでは決して学べない類の教訓です。

GRPOが重みに実際にすること

簡略化したゼロからの形での訓練ループ自体は、驚くほどコンパクトです。DeepSeekが広めたGroup Relative Policy Optimizationは、PPOをメモリ食いにしていた批評家ネットワークを取り除きます。価値関数を学習する代わりに、同じプロンプトに対するグループの応答を生成し、検証器で全部を採点し、各応答のアドバンテージをグループ平均との相対で計算します。グループ平均より良い応答のトークン確率は押し上げられ、悪い応答は押し下げられます。

def grpo_advantages(rewards: torch.Tensor) -> torch.Tensor:
# rewards: [group_size], one per sampled response to the same prompt
mean = rewards.mean()
std = rewards.std().clamp_min(1e-4)
return (rewards - mean) / std  # relative advantage per response
# Training step: maximize advantage-weighted log-probability
def grpo_loss(logprobs: torch.Tensor, advantages: torch.Tensor) -> torch.Tensor:
# logprobs: summed sequence log-prob under the current policy
return -(advantages.detach() * logprobs).mean()

実際の実装では、ポリシーが参照モデルから離れすぎないようKLペナルティを加え、PPOから借りたクリッピングも加えますが、上の骨格が本質的なアイデアであることは間違いありません。そしてこれを観察すると魔法のように感じるのは、推論スタイルについてモデルに何も伝えていないことです。報酬を与えるのは正しい最終解答だけです。それでも訓練が進むにつれて、応答の長さは伸びていきます。モデルは途中で「待って、確かめよう」といった自己修正を始めます。検証的な振る舞いを含むトレースの方が正解に至りやすく、報酬を得られるのは正解だけだからです。chain-of-thoughtのスタイルは、誰かが設計した振る舞いではなく、最適化問題に対する創発的な解です。だから私は「プロンプトではなく訓練されたもの」と言うのです。プロンプト時代のこの振る舞いは、人間がRLが後に独自に発見したものを真似していたにすぎないのです。

ハイプ・サイクルが飛ばしている実務上のエンジニアリングの注意点がここにあります。適度なGPUを備えた0.6Bモデルで、この動きを実際に観察するには十分です。数ドル/時間で借りられるハードウェアで、GRPOによるMATH-500の計測可能な改善が得られます。フロンティアモデルは得られません。それで構いません。それはこの演習の目的ではないのです。

推論時スケーリング：計算資源が訓練の一部を置き換えるところ

RLが始まる前にも、重みを固定したまま回答を改善する技術群があります。temperatureとtop-pで複数の候補をサンプリングし、それらを組み合わせるのです。Self-consistencyが主力です。k個の答えを生成し、最終解答の多数決を取ります。驚くほどよく効きますし、ベースモデルでも効きます。これは冒頭の主張に対して私が認めるべき最初のひびです。推論時の計算は、本物で直交した改善の軸なのです。

ただし、これらの技術が実際に何を要求しているかを見てください。多数決が効くのは、モデルがすでに正解を出す確率が無視できないほどあるときだけです。多数決は既に存在する信号を増幅するのであって、無から信号を生み出すわけではありません。系列の対数確率で候補をランク付けする採点ベースの選択も、同じ性質を持ちます。そして、モデルが自分の回答を批評して修正する自己改善ループは、ベースモデルでは残念なほど弱いことが分かっています。正直な自己批評そのものが、RLによって植え付けられる能力だからです。どの推論時の工夫も訓練と組み合わさるものであり、訓練の代わりにはなりません。フロンティアシステムがRLで訓練されたモデルと推論時スケーリングを組み合わせるのは、両者が足し算ではなく掛け算になるからです。

コストの側面は実務家にとって重要です。k=16のself-consistencyは推論コストが16倍になります。それが良いトレードかどうかは、精度対コストの曲線次第です。それに正直に答える唯一の方法は、MATH-500の精度を候補数に対してプロットすることです。似た計算資源の配置の問題を、フラッシュ級モデルと推論効率についての記事でも扱いました。繰り返し出てくるテーマは、「より多くの計算を使う」には少なくとも三つの異なる意味があり、それらは互換ではないということです。

蒸留と、プロンプトがまだ生き残る唯一の場所

ゼロからのパイプラインの最終段階は蒸留です。強力な（通常は大型の）推論器の長い推論トレースを取り、普通の教師あり学習で小さなモデルを直接ファインチューニングします。RLも検証器もループに入りません。実際にデプロイする安価で小さな推論モデルの多くは、こうして作られています。そしてこれは、私の主張を崩すどころか補強します。推論の振る舞いは依然として、RLで訓練されたモデルが生成した訓練データから来ており、報酬ではなく勾配降下法を通じて移されているだけです。能力がプロンプト時に注入されることは決してなく、常に最適化によって焼き込まれます。

では、私の逆張りの主張はどこで崩れるのでしょうか。正直に言えば、ここです。プロンプトは周縁部でまだ重要で、その周縁部はゼロではありません。推論の努力量の制御、つまり現行世代のモデルが公開している低・中・高の思考予算設定は、精度とレイテンシ・コストを有意にトレードオフできる推論時のレバーです。構造化出力の制約、検証器をループに入れたパイプライン、制約付きデコーディングは、いずれもプロンプトやハーネスのレベルの技術で、実際の価値があります。制約付きデコーディングについての記事でも論じたとおりです。そして、ベースモデルしか使えず何も訓練できないなら、chain-of-thoughtプロンプトは評価でまだ確かな点数を稼ぎます。「プロンプトではなく訓練されたもの」は、能力がどこから生まれるかについての主張であって、推論時の選択が重要ではないという主張ではないのです。

読むより作る方が勝る理由

当然ながら、よくある反論があります。自作の推論モデルのチュートリアルは、「自分でCPUを作るガイド」のようなもので、魅力的だけれど役には立たないのではないか。本物の訓練にはクラスタと独自データが必要だから、と。しかし私は、これは演習の目的を見誤っていると思います。古典的な「シェルをゼロから作る」チュートリアルについても同じことを言えます。これについてはWhat Building a Shell Teaches You About Unixで、まさにこの理由から評価しました。bashを置き換えるためにシェルを書く人はいません。fork、exec、パイプ、シグナル処理が、暗記した抽象概念ではなく、手に持っている機構になるから書くのです。

推論モデルについても同じです。私の仕事の進め方を永続的に変えたのは、論文ではなく実装の細部でした。

• 検証器を書いて分かったのは、報酬の品質はソフトウェアエンジニアリングの問題だということです。正規化のエッジケースが訓練を静かに歪めます。「報酬はグラウンドトゥルースだ」という言葉も、答え抽出器が正しい限りでしか真になりません。
• 系列の対数確率によるスコアリングを実装すると（そこに伴う数値安定性の工夫も含めて）、ポストトレーニングの文献にある損失関数の半分が解けました。どれも、異なるポリシーの下で応答がどれだけ尤もらしいかを比較することに帰着します。
• GRPOの最中に、誰にも促されずに応答長が伸びていくのを見て、推論スタイルは表面的な振る舞いにすぎないという私に残っていた最後の思い込みが消えました。正しさだけが目的関数のとき、最適化が見つけ出すものなのです。
• Self-consistencyで候補数に対する精度をプロットしたことで、精度と単位コストのトレードオフについて、どのベンチマーク表も与えてくれなかった実感が得られました。

学習目的であれば、計算資源の不安もそれほど大げさではありません。初期の部分、つまりベースモデルの読み込み、KVキャッシュを使ったストリーミング生成、検証器の構築、MATH-500の実行は、CPUとノートPCの範囲か、それに近いものです。GRPOの訓練にはGPUが要りますが、必要なのは一枚だけで、時間単位で借りれば多くの教科書よりも安く済みます。家では再現できないのは規模であり、規模は本当に別の分野です。これは私たちが検証したDeepSeekの推論エンジンにまつわる神話の一つにも通じます。フロンティアラボの配信スタックは、チュートリアル規模には存在しない問題を解決しますし、その逆もまた然りです。

実践的な結論

一つだけ持ち帰るなら、検証器中心の世界観を持ってください。現代の推論スタックは、ベースモデル、「正しい」が何を意味するかを決めるプログラム、それに対して最適化するRLアルゴリズム、そして結果を掛け算にする推論時の技術、という構成です。プロンプトはその系の端に位置し、訓練が生み出した能力を操縦するだけです。これを理解しているチームは、効果が積み上がる場所に労力を注ぎます。より良い検証器、より良い報酬設計、そして実務を捉えきれていないAIベンチマークの多くに欠けていると私たちが論じてきたような、より良い評価ループです。そうでないチームは、システムプロンプトを調整し続けて、なぜ精度が頭打ちになるのか首をかしげることになります。

ランチテーブルでの私の主張は、一つのただし書き付きで生き残ります。推論モデルはプロンプトで作られるのではなく訓練されるものです。ただし、その周りに組むハーネス（プロンプトを含む）が、訓練で得られた能力のうちどれだけを実際に引き出せるかを決めます。一度、小さい版を自分で作ってみてください。11時間のコーディングは、この件で二度と混乱しないための安い代償です。