テスト時計算スケーリング — 繰り返しサンプリングから推論アーキテクチャ探索へ

2.1推論時スケーリングという新しいパラダイム

LLMの開発は伝統的に三段階に分けて語られる。まず事前学習（pre-training）であり、これは数か月単位の時間と大量のGPUを要する最もコスト集約的な段階である。次にファインチューニングがあり、データ量は事前学習に比べて桁違いに少ない。そして最後が推論（inference）であり、従来はユーザーとモデルの一往復のやり取りとして「一度きり」で終わるものだった。本章が扱うのは、この推論の段階でモデルのパラメータを一切変更せずに性能を引き出す手法群、すなわちtest-time computeである。

出発点となるのが「Large Language Monkeys」論文である。前回扱った無限の猿定理を思い出してほしい。ここでのアイデアは単純で、同じ入力問題に対してLLMに一度だけ答えさせるのではなく、10回、100回、1000回と繰り返しサンプリングし、生成された複数の候補から正解を選び出すverifier（検証器）を用意する、というものである。

2.2カバレッジのべき乗則とロングテール問題

この繰り返しサンプリングの効果は、SWE-benchのようなエージェント型ベンチマーク（ソフトウェアエンジニアがコードを編集しパッチを作成する作業を模したもの）でも確認されている。coverage（少なくとも1つのサンプルが正解する問題の割合）をサンプル数1から1000までプロットすると、DeepSeek V3のようなモデルは1000サンプルの時点でClaude 3.5やo1-previewを上回るcoverageに達する。コーディング問題であればユニットテストという明快なverifierが使えるため、これは弱いオープンソースモデルをエンドツーエンドで強いモデルに変換する自動化された方法になる。

前回学んだ事前学習のスケーリング則（データ量・計算量・パラメータ数からテスト損失を予測できるという関係式）に対応する形で、この講義では推論時スケーリング則を導入する。実験的に、coverage C はサンプル数 k に対して、係数 a, b をカーブフィッティングで求める指数的なべき乗則に従うことが分かった。この関係は、Llama-3、Gemma、Pythiaなど70Mから70Bパラメータという幅広いモデルサイズ・アーキテクチャで成立し、非常に小さいモデルでさえこの法則に従う点が興味深い。

なぜべき乗則が現れるのか。個々の問題については、pass@1の正解確率をpとすると、k回サンプリングして少なくとも1回正解する確率（pass@k）は 1 - (1-p)^k という単純な式で書ける。しかし問題集合全体で見るとべき乗則が観測される。数学的な検討の結果、この集合レベルのべき乗則が成立するための必要十分条件は、難問のロングテールが存在することだと分かった。実際にpass@1の分布を見ると、簡単な問題は1回の試行で解けるものが多い一方、複雑な問題になるほどpass@1が下がっていく長い裾（ロングテール）が観測され、この形状こそがべき乗則の背後にある構造である。

2.3検証可能性とGeneration-Verification Gap

繰り返しサンプリングが機能するには自動検証（verification）が不可欠である。答えの候補が大量にあっても、どれが正しいかを判定できなければ意味がない。検証のしやすさはドメインによって大きく異なる。数学の一部の問題では形式的証明（formal proof）ツールを使い、各証明ステップが正しいかを機械的にチェックできる。コーディングではユニットテストが使え、しかも「解を書く」より「テストを書く」方が簡単な場合が多いため、人間がユニットテストを用意してverifierとして使うことができる。

もう一つ興味深い方向性が「AIをコンパイラとして使う」というアプローチであり、講師の研究室で進めている案件でもある。例えばPyTorchのようなソースコードから、CUDAのような低レベルで高度にハードウェア最適化されたコードをLLMに生成させる場合、生成されたCUDAコードとソースのPyTorchコードの出力が任意の入力に対して一致するかを比較するだけで正しさを検証できる。この設定を測るベンチマークがKernelBenchであり、ここでもサンプル数を増やすほどcoverageが向上する同様の傾向が見られ、しかも「完璧な」verifierが標準的に使える点が特徴である。同様に、PythonとC++、あるいはJavaのような言語間の翻訳タスクでも、出力の等価性を比較的容易に測定できる。

一方、明快なverifierが存在しないドメインでは、多数決（majority voting）やモデルベースのランカーといった手法による性能と、真のcoverage（完璧なverifierがあれば得られたはずの性能）の間に大きな乖離が生じる。これをgeneration-verification gapと呼ぶ。多数決は10〜50サンプル程度で頭打ちになるのに対し、完璧なverifierを仮定した場合のcoverageはそれよりずっと高い水準まで伸び続ける。この差は、GSM8Kより難しいMATHデータセットのような、より複雑な問題設定でさらに顕著になる。原因は、最も難しい問題ほど正解が1000〜10000サンプル中でごく数回しか出現しないため、頻度に基づく多数決ではそもそも正解を拾い上げられないという構造にある。

2.4逐次リビジョンとReward Model

並列サンプリング（parallel sampling）は複数の答えを独立に生成する方法だが、テスト時計算をスケールさせるにはもう一つの軸がある。それが逐次リビジョン（sequential revisions）である。モデルに問題への最初のアプローチを出させたのち、それを見直し、改善し、追記させ続け、確信が持てるまで繰り返させてから最終的な答えを出力させる、という方式だ。講義では、この逐次リビジョンはプロンプトによって明示的に指示することを前提としつつ、最近の推論モデルは学習の中でこうした振る舞いを内部的に獲得しており、自らの回答を見直す挙動が自然に現れることにも触れられた。

これに関連して「Scaling LLM Test-Time Compute Optimally Can Be More Effective Than Scaling Model Parameters」という論文が紹介された。ここでは答えの選び方にも複数の方式があるとして、outcome reward model（ORM）とprocess reward model（PRM）が区別される。ORMは最終的な出力全体を見てそれが正しいかどうかのスコアを与えるよう学習された報酬モデルであり、PRMは解答生成過程の各ステップごとにスコアを与えるよう学習された報酬モデルである。例えば数学の問題を5ステップで解く場合、PRMは各ステップの妥当性を採点する。

最もシンプルな組み合わせがbest-of-nであり、n個の並列サンプルを生成し、ORMで最もスコアの高いものを選ぶ。より高度な使い方としてPRM誘導のビームサーチがある。例えば予算4サンプルのステップごとに4つの候補を生成し、PRMスコア上位2つを残して、そこからさらにサンプリングを続ける、という探索である。

2.5難易度依存の最適配分と事前学習との比較

この論文ではMATHデータセット（訓練約12,000問、テスト500問）とPaLMモデルを使い、問題ごとのpass@1性能に基づいて5段階の難易度ビンを定義し、逐次と並列の最適な配分が難易度によってどう変わるかを検証した。結果を見ると、多数決の精度は生成予算の増加とともに頭打ちになり、ORM（紫）、PRM（緑）を使った選択はそれを上回り、逐次リビジョンと並列サンプリングを慎重に組み合わせた設定（青）がさらに良い性能を示す。ただし、逐次と並列をどの比率で混ぜるのが最適かは、依然として未解決の研究課題として位置づけられている。

難易度ビン別に見ると、最も簡単な問題群では逐次トークンの比率が高い設定（濃い紫）が最高精度を達成する一方、難しい問題（バケット4、5）になるほど最適な逐次対並列の比率を言い当てるのが難しくなる。もう一つの重要な観察は、簡単〜中程度の問題では、追加のテスト時計算を投入する方が事前学習をスケールさせるより有利になりうる、という点である。推論トークン数と事前学習トークン数の比を横軸に取ると、簡単・中程度の問題ではこの比が正の方向に効くのに対し、最も難しい問題では、より多くの事前学習を経た大きなモデルの方がトークン効率の観点でなお優れているという結果が示された。

2.6ARCHON — 推論アーキテクチャ探索フレームワーク

逐次と並列の混ぜ方を人手で試行錯誤する代わりに、これを推論アーキテクチャ設計問題として定式化したのが「ARCHON: An Architecture Search Framework for Inference-Time Techniques」である。ARCHONへの入力は、性能を最適化したい対象ベンチマーク群、1問あたりの推論呼び出し予算、利用可能な複数のLLM、そして複数の推論時テクニックである。これらを組み合わせて、与えられた予算の中で品質を最大化するアーキテクチャを見つけ出す最適化器がITAS（Inference-Time Architecture Search）であり、出力は各種モデルとテクニックを組み合わせた具体的なアーキテクチャそのものになる。

いずれの操作も、モデル自体を新たに学習し直すのではなく、プロンプトによる指示だけで実現されている点が特徴である。中でもFusionは意外なほど効果的な手法として紹介された。これは並列に生成した複数のサンプルを1つの最終回答に集約する点で、逐次的な更新の一種にも位置づけられる。

2.7深い推論アーキテクチャの効果とベイズ最適化

Fusionの効果を測るために、ある推論・質問応答系ベンチマークでのwin rateが比較された。ランダムに1つ選ぶ方式（最も弱い）に対し、モデル自身にランキングさせて最上位を選ぶ方式はそれを上回り、さらに正解を教えてくれる仮想的なoracle選択（完璧なverifierを想定）はそれを上回る。ところが、k個の回答をすべてモデルに見せて1つに統合させるFusionは、このoracle選択さえも上回ることが分かった。そして、まず上位k個をランキングで絞り込んでからFusionする方式が最良の結果を示した。この傾向は、1つのモデルだけで生成する場合だけでなく、2個、10個と異なるモデルを混在させてアンサンブルした場合にも同様に確認された。

さらに興味深いのは、これらの操作を何層にも重ねることで精度がさらに向上するという発見である。例えば複数モデルのアンサンブルに加え、Critic-Rankerの層を3段重ね、最後にFuserで統合するというアーキテクチャは、最良の単一モデルを1回だけ使う場合や、最良のモデルを8回使って1層のFusionだけを行う場合よりも、多くのタスクで大幅に高い精度を示した。これは深層学習において層を重ねるほどモデルが賢くなる現象と類比的であり、推論時の層を注意深く重ねることでも同様の効果が得られることを示唆している。

このように操作の組み合わせが膨大になる探索空間を扱うため、ARCHONはベイズ最適化を採用し、探索空間にはいくつかの制約を設けて絞り込んでいる。具体的には、各層で使う推論時テクニックは1種類に限定し、最初の層は必ずGeneratorとし、Criticは必ずRankerやFuserより前に置き、Unit Test生成の後には必ず評価（Evaluation）ステップを続ける、といった制約である。ベイズ最適化は貪欲探索やランダム選択よりも少ない試行回数（Archonが実際に呼び出すモデル構成の数）で優れたアーキテクチャに到達できる、サンプル効率の高い手法として紹介された。

講義の言葉

用語集

言及された研究・システム