探索による自己改善 — コード生成とディープリサーチエージェント

7.1サーチによる自己改善という枠組み

本章では、モデルの出力を大量に生成し、その中から正しい解を選び出す「サーチ」によってタスク解決能力を引き上げる二つのアプローチを扱う。一つはコード生成モデルにおける大規模サンプリングと選抜であり、AlphaCodeとAlphaCode 2を通じて詳しく見ていく。もう一つはディープリサーチエージェントにおけるエージェント的な探索であり、SearchO1を中心に扱う。前者は宿題2（HumanEvalを題材にした反復サンプリング）の延長線上にあるより複雑な問題であり、後者は宿題3で実際に使うことになるパターンである。

講義全体を貫く前提は次の一文に集約される。モデルが出力しうる解の探索空間の中には、すでに正解が存在している。問題は、その探索空間から答えをどうキュレーションするかである。単純なコード補完（1行を書き足すオートコンプリート）では高い成功率が得られる一方、問題文を理解し、解法を設計し、最初から最後まで解き切るという「エンドツーエンド」の問題になると、格段に難しくなる。この難易度のギャップこそが、本章で扱う探索技術が必要とされる理由である。

7.2AlphaCode — 競技プログラミング問題を解くパイプライン

AlphaCodeが取り組んだのは、単純な関数補完ではなく競技プログラミングの問題である。問題文は長く、入出力例という「契約」だけが与えられ、モデルは問題文を理解した上でどのようなアルゴリズムで解くべきかを自ら判断しなければならない。これはHumanEvalのような「関数のdocstringを見て実装を完成させる」問題よりもはるかに難しい。当時（本講義のおよそ4年前）、AlphaCodeは10のコンテストで参加者中平均54.3パーセンタイルにランクインし、AIが狭いタスクを超えて問題をエンドツーエンドに解けることを示した最初の例として位置づけられている。

AlphaCodeのパイプラインは、大規模言語モデルが普及する以前の設計であり、独自にモデルを事前学習するところから始まる。GitHubのコード約700GBを用いて次トークン予測でエンコーダ・デコーダモデルを事前学習し（マスク言語モデル損失を使用）、その後CodeContestsデータセット（競技プログラミングの問題と解答の大規模コーパス）でfine-tuningを行う。fine-tuning時にはGOLDと呼ばれる正則化テクニックが使われ、トークンの尤度に応じて重み付けを行うことで、より意味のあるパターンに高い確率を割り当て、精度を改善する。これに加えて value conditioning and prediction という手法も併用された。

7.3大規模サンプリングとフィルタリング・クラスタリングによる選抜

事前学習・fine-tuning済みのモデルから、AlphaCodeは1問あたり100万個という桁違いの数の解を生成する（Pythonが半分、C++が半分）。プロンプト中の問題タグや難易度評価をランダム化し、サンプリング温度を高く設定することで解の多様性を確保する。しかし100万個の解をそのまま競技プラットフォーム（CodeForces）に提出することはできない。そこで二段階の選抜を行う。第一に、問題文中に与えられた例題の入出力に対してテストを実行し、通過しない解を除外する（フィルタリング）。第二に、構文的には異なるが意味的には等価な解をまとめるクラスタリングを行う。このクラスタリングには、問題文から追加のテスト入力を予測するよう別途訓練した「テスト入力生成モデル」が使われ、未知の問題に対しても新たなテストケースを作り出すことで意味的等価性を判定する。

この選抜を経て、実際にCodeForcesの10コンテスト（各5,000人規模）に提出した結果、AlphaCodeは平均54.3パーセンタイルにランクし、過去半年の参加者の28%と互角の成績を残した。ここで重要な指標の区別がある。pass@kはk個のサンプルを無制限に評価できると仮定した場合のカバレッジ（少なくとも1つが正解する確率）を測るのに対し、n@k（この講義では10@k）はk個生成したサンプルのうち実際に提出できるn個だけを評価する、より現実的な指標である。10@kはpass@kより必ず低くなり、10個しか提出できない設定では40%台に達するpass@kに対し実際の10@kは30%程度にとどまる。この差が、選抜（フィルタリング・クラスタリング）段階のボトルネックの大きさを示している。

モデルサイズと解率の関係についても明確な傾向がある。9B、41B、41B+クラスタリングという3つの設定を比較すると、モデルサイズが大きいほど、また同じモデルでもサンプリング予算を1kから1Mまで増やすほど、一貫して解率が向上する（対数線形の関係）。さらに41B+クラスタリングは同じ41Bの素のモデルより一貫して良い成績を残しており、クラスタリングによる多様性の確保がそれ自体で性能改善に寄与することが分かる。

7.4ばらつきの要因と AlphaCode の限界

コンテストごとの成績にはかなりのばらつきがあり、あるコンテストIDでは好成績、別のコンテストIDでは大きく崩れるという現象が観察された。この点は講義中の質疑でも取り上げられている。

AlphaCodeの全体的な学びとしては、大規模サンプリング＋フィルタリング＋クラスタリングによって高いカバレッジを実現できること、そして生成されたコードが訓練データの単純なコピーではなく、実際に新規性のある（分布外の）解法に到達していたことが確認された点が挙げられる。一方で明確な限界もある。第一に、訓練時に最適化していた損失（loss）は解決率（solve rate）の貧弱な代理指標に過ぎない。ある問題を解ける解法は複数存在しうるため、損失を下げることと実際に解けることは必ずしも一致しない。第二に、動的計画法や構成的アルゴリズムを要する問題では性能が振るわなかった。第三に、100万サンプルという規模のサンプリングを要する時点で、時間制約のある実運用には適さない。時間効率を重視するなら、生成されたそばから採用可能な解をランク付けする仕組みが必要になる。そして、難しい問題ほど一発（one-shot）の生成では太刀打ちできず、複数ステップに分けて解く方式のほうが有効であることも示唆された。

7.5AlphaCode 2 — 独自事前学習から既存LLMの活用へ

AlphaCode 2（Google）は、AlphaCodeとは異なる出発点に立つ。独自にモデルを事前学習する代わりに、既存の大規模言語モデルであるGemini Proをfine-tuningして使うという仮説から始まった。変更点は大きく三つある。第一に、事前学習ではなくfine-tuningのみで問題特化の性能を引き出す。第二に、多様性を確保するために単一モデルではなく、異なるハイパーパラメータ（難易度・タグの扱いなど）でfine-tuningした複数のAlphaCode 2モデル（モデルファミリー）を用意し、大規模サンプリングをそのファミリー全体に分散させる。第三に、候補の選抜を、意味的等価性によるヒューリスティックなクラスタリングだけに頼るのではなく、コードサンプルの正しさを0〜1のスコアで推定する学習済みのスコアリングモデル（一種の報酬モデル）に委ねる。

データセット面でも刷新があり、CodeContestsのv2版（オープンソース化されたもの）を用いて複数モデルをfine-tuningし、さらに人手で精査・スコア付けした高品質データセットでスコアリングモデルを訓練する。サンプリング段階では、Pythonを廃してC++のみに絞り、温度とメタデータをランダム化して多様な出力を得る。生成されたサンプルのうち、コンパイルに失敗したりテストに通らないものが実に95%除去され、約5万件が残る。そこから上位10クラスタに集約し、スコアリングモデルで再ランキングして各クラスタから最良の候補を1つずつ選び、提出する。

結果は劇的である。AlphaCodeが100万サンプルを要して達成した解率に、AlphaCode 2はわずか100サンプルで到達する。さらにサンプリング予算を100万まで増やせば、解率はAlphaCodeの25%に対しAlphaCode 2は43%と、ほぼ2倍に達する。人間の競技者との比較では、AlphaCodeが46パーセンタイル（参加者の46%を上回る）であったのに対し、AlphaCode 2は全体で85パーセンタイル、上位2つの提出まで許すなら参加者の99.5%を上回る成績を残した。この改善は、より良い基盤モデル、多様な解の生成、そして学習されたスコアリングによる選抜という三つの改善が組み合わさった結果であり、サンプル数を増やさずとも性能を大きく引き上げられることを示している。

7.6難易度への適応と推論の内在化（クラス討議）

AlphaCode系のアプローチにはなお大きなコストがかかり、しかもコード生成という領域に強く特化している。生成されたサンプルの大半（AlphaCode 2でも95%）はコンパイルにすら通らず、無駄になる計算量も大きい。この課題を受けて、講義では二つの問いが学生に投げかけられた。「タスクの難易度に応じてこれらの手法をどう変えるべきか」、そして「推論そのものをモデルに内在化させるにはどうすればよいか」である。

推論の内在化については、学生から「訓練データのどの部分がどのアルゴリズムに対応するかのヒントを与える」というアイデアが出された。講師はこれをより一般化し、プログラマが答えを書く前に頭の中で考えているプロセスそのものを訓練データに取り込む発想だと位置づけた。具体的には、chain of thoughtを訓練データに含める方法や、STaRのアプローチ（モデルに解答をヒントとして与え、そこに至る理由付けを生成させて訓練データ化する）が挙げられた。さらに、複雑な問題では一気に解くのではなく部分問題に分解し、各部分にヒントを与えるという方向性も議論された。ただし、ある学生が指摘したように、最初のステップは合っていても後続のステップが誤っている場合にどう扱うかという問題は残る。講師の回答は、多くの問題には共通する抽象化されたパターンがあるため分解がうまく機能するが、分布外のパターンに出会った場合は人間参加型のループが必要になるというものであり、これは前回講義で扱われた「AI Scientist」的な研究とも接続する。より根本的には、木探索のように途中まで生成してからバックトラックできる仕組みが本来望ましい方向であるが、これはまだ初期段階の研究領域であると位置づけられた。

7.7ディープリサーチエージェントへの転換 — SearchO1 の設計

後半では、コードから離れ、ディープリサーチエージェントの構築へと話題が移る。SearchO1は大規模推論モデル（LRM）を土台に、クエリに応じて情報を取得しながら推論する仕組みである。LRMは推論能力自体は高いが、知識のカットオフ日付を持つため最新の情報を持たない。さらに、知識にギャップがある箇所では、GPQAデータセットでの観察によれば「perhaps」「alternatively」「wait」といった不確実性を示す語が推論チェーンに頻出する。この不確実性は放置すると推論チェーン全体に伝播してしまう。

最も単純な対処は素朴なRAG（Retrieval-Augmented Generation）である。クエリを1回生成して関連文書を取得し、プロンプトに挿入してから最終的な推論を行う。しかしこれでは不十分である。理由は、検索が最初の1回きりで、その後の調整ができない点にある。単純な質問（例えば天気を尋ねるだけの質問）であれば1回の検索で足りるが、複数の部分から成る複雑な問題では、推論がある程度進んだ時点で新たに別の情報が必要になることが多い。実際、単純なRAGは単発の質問に対する直接推論よりは改善を示すものの、多段階推論では性能が頭打ちになる傾向がある。

SearchO1が提案する解決策は二段構えである。第一に、推論の途中で知識ギャップを検知するたびに検索クエリをその場で生成し、1回の推論セッション内で複数回にわたって文書を取得する。これは特殊トークンによって検索をトリガーする「agentic RAG」の考え方であり、生成された出力トークンの不確実性を手がかりに、推論チェーンの中に検索クエリを挿入し、取得結果を再びチェーンに差し込む。第二に、取得した文書をそのままプロンプトに追加するのではなく、Reason-in-Documentsと呼ばれるモジュールで文書を分析し、現在のクエリと直前までの推論を踏まえて関連するチャンクだけを抽出する。これにより、複数の文書（10件・20件）をそのまま詰め込んだ場合に起きがちな「情報過多でモデルが処理しきれない」問題を回避し、推論チェーンに滑らかに統合できる情報だけを与えることができる。

7.8SearchO1 の実例と評価結果

講義では、複数の化学反応の結果生じる「生成物3」の炭素原子数を問う化学の問題を例に、3つのアプローチを比較している。

この違いは定量的な評価でも裏付けられている。物理・化学・生物の各領域でpass@1を縦軸に、取得文書数を横軸にとると、直接推論や素のRAGでは文書数を増やしても精度は向上しない。一方SearchO1では文書数を増やすほど精度が向上する。これは単にコンテキストを長くしているのではなく、各文書から関連情報だけを抽出して要約しているためであり、反復的な精緻化（iterative refinement）とは異なる「並列的な精緻化」という軸を提供していると説明された。

GPQAデータセット（大学院レベルの物理・化学・生物の難問）で人間の専門家と比較すると、SearchO1は物理と生物では専門家に匹敵する、あるいはそれを上回ることさえある成績を示した。ただし比較は同一領域の専門家同士（物理学者が物理の問題を解いた場合の成績）で見る必要がある点に注意が必要で、化学領域では専門家に対する優位性はまだ小さい。この理由として、化学は構造のわずかな変更が全体の性質を大きく変えてしまう領域であり最適化が難しいのではないかという学生の仮説が提示されたが、講師はこれを検証可能な仮説として保留した。さらに、HotpotQA、2WikiMultihopQA、MuSiQue、Bamboogleといった複数文書にまたがるマルチホップ質問応答のベンチマークでは、標準的なRAGはもちろんagentic RAGでも性能が頭打ちになる傾向が見られるのに対し、SearchO1は多くのケースで最高性能を達成している。全体として、知識ギャップを検知して都度検索しながら情報を精緻化する能力が、複雑な多段階の推論において特に大きな価値を持つことが示された。

なお、SearchO1と対になる研究としてSearchR1が言及されている。SearchO1がプロンプトベースで検索のタイミングと内容を制御するのに対し、SearchR1は強化学習によって「いつ・何を検索すべきか」をモデル自身に学習させるアプローチであり、本講義では詳細な解説はされなかったが、宿題3に関連する発展的な読み物として紹介された。

7.9モデルの自信過剰とキャリブレーションの課題

講義の締めくくりは、モデルの確信度と正答率の関係についての質疑である。ある学生は、1000回生成した出力それぞれに対応するトークンの確率（あるいはその集約値）が、実際の正答率と相関しているのかを尋ねた。講師の回答は、多くの研究で共通して観察されている傾向として、出力トークンの対数確率を適切に集約（単純な合計ではなく平均や幾何平均などの方法で）すると、モデルは自らの正しさについて過信する傾向があるというものだった。

もしその出力が実際には50%しか正しくないとしても、モデルはそれでも過信気味に、80%程度の確信度でそれが正しいと主張してしまう。

この過信は、モデルの出力を後から訂正しようとした際にも表れる。モデルが自分の答えに固執し、なかなか意見を変えないという現象は、まさにこのキャリブレーション不良の表れである。どのラボのどのモデルがどう振る舞うかは公開されていないため一般化はできないが、観察されるパターンとしては、答えが正しい場合はモデルも相応に確信を持っている一方、答えが誤っている場合でもモデルは過信したままであることが多いという非対称性がある。この確信度を訓練時のフィードバック（2回目のパスで確信度を推定させる、あるいはRLやRLHFで確信度自体を較正するなど）によって改善しようとする研究の方向性も存在するが、モデルが「自分が何を知らないか」を認識する能力（ハルシネーションの根本原因の一つ）は、依然として活発な研究領域であり続けている。

講義の言葉

用語集

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