少し前、私は検索パイプラインが最も重要な1つのドキュメントを取りこぼす場面を目撃した。40件のドキュメントセットに埋もれた価格メモが、上位50件を返す設定のなか、ひっそりと51位にランクされていた。エージェントは残り49件を要約し、確信を持った数字を顧客に送った。間違った数字だった。解決策はコンテキストウィンドウを大きくすることではなかった。ランカーを修正することだった。
1200万トークンコンテキストLLMに誰かが興奮するたび、私はその話を思い出す。ピッチはいつも同じだ――「すべてをプロンプトに入れれば問題は消える。」消えない。理由を説明しよう。そして実際に何が来るのかも。
まず正直な免責事項。これを書いている時点で、1200万モデルはまだリリースされていない。現在の最前線は100万トークンだ――Claude Opus 4.8 とFable 5はどちらも100万トークンのコンテキストウィンドウで動作し、Geminiの長コンテキスト系列も同程度のレンジにある。以下はすべて分析であり、私が実行したベンチマークではない。基調講演を繰り返すより、物理学の観点から考えることを好む。
1200万トークンコンテキストLLMにサブ二次アテンションが必要な理由
これが壁だ。標準的なアテンションはシーケンス長の二乗でスケールする。入力を12倍にすると、アテンションのコストは12の二乗分――つまりアテンション行列の計算量とメモリが144倍になる。H100を増やしても解決できない。唯一の出口は数学を変えることだ。
それがサブ二次研究の全体像だ。Mambaのような状態空間モデル、線形および疎なアテンションの変形、RWKV型の再帰、そして主に線形なバックボーンに少数の完全アテンション層を組み合わせたハイブリッド設計。Mambaの論文はシーケンス長に対する線形スケーリングと、比較可能なTransformerより約5倍高い推論スループットを報告しており、百万長のシーケンスでも品質が保たれる。
しかし同じ論文はこの問題点について率直だ。著者たちは、これらのアーキテクチャは「言語のような重要なモダリティでアテンションほどのパフォーマンスを発揮できていない」と指摘している。そのギャップがゲームのすべてだ。線形アテンションが安いのは、過去を固定サイズの状態に圧縮するからであり、圧縮とは忘却を意味する。唯一重要な問いは、それがあなたに必要だったものを忘れるかどうかだ。ハイブリッドがここでの賢い賭けだ――精度のためにいくつかの完全アテンション層を残し、残りはボリュームのためにサブ二次で動かす。すべてのトークンが他のすべてのトークンを見るという保証は失われる。1200万トークンでは、そもそもその保証を買う余裕はなかっただろう。
誰もコストを計算しない失敗モード：コンテキスト劣化
私たちはすでに持っている100万ウィンドウさえ十分に活用できていない。それが「コンテキストが増えれば何でも解決する」という枠組みを私が疑う理由だ。
Chromaのコンテキスト劣化に関する研究は幅広いフロンティアモデルをテストし、ウィンドウが満杯に近くない場合でも、入力が増えるにつれて精度が低下することを発見した。トークンを加えると精度を失う。これはアテンション希薄化の問題であり、容量の問題ではない。
典型的な症状は「中央で迷子になる」だ。Liu et al. (2023)は、モデルが長い入力の冒頭と末尾には良く注意するが中央に埋もれた部分には悪く、関連する事実が間違った場所にある場合は精度が急落することを示した。それを1200万トークンで、しかもすでに設計上ロスのあるサブ二次バックボーン上で想像してほしい。位置的希薄化の上にアーキテクチャ的な忘却を積み重ねることになる。
そして検索は推論ではない――これが人々がはまる罠だ。モデルは「干し草の山の中の針」テストに勝てる。1000万トークンの中に植え込まれた1文を見つけられる。しかし同じ干し草の山に散らばった40の事実から結論を合成することには完全に失敗し得る。事実を見つけることはルックアップだ。多くの事実について推論することは別の、より難しいことだ。リテラルなキーワードマッチングを超えたNoLiMaのような難しい長コンテキスト評価は、そのギャップを暴き続けている。1200万の針テスト勝利は、モデルが干し草の山で考えられるかどうかについてほとんど何も教えてくれない。
1200万トークンコンテキストLLMの現実的な時系列
範囲を提示しよう。ただし、過去に時系列の予測を外したことがあることを断っておく。
12から24ヶ月： 研究・デモグレードの1200万コンテキスト、主にハイブリッドアーキテクチャ、アスタリスク付き。強力な針の検索、不安定なクロスドキュメント推論。ベンチマークでは好成績を出すが、エージェントループの中では期待を裏切る種類のもの。
24から48ヶ月： 深さでの推論品質が実務に信頼できるレベルになり、プリフィルのレイテンシが許容範囲内で、価格が理不尽でない本番アクセス。その最後の条件が重みの大半を担っている。
アーキテクチャが機能しても経済性は厳しい。1200万のプリフィルは、モデルが最初の出力トークンを発する前の計算の壁だ。レイテンシは秒から分単位、そしてそれに見合った請求書。今日のOpus 4.8は入力100万トークンあたり5ドルで動く。冷えた1200万プリフィルは1回の入力だけで60ドル、毎回、キャッシュが救ってくれない限り。プロンプトキャッシュはあるといいレベルから荷重支持に変わる。問題はキャッシュがプレフィックスが安定している場合にのみ効果があることで、エージェントループではしばしばそうでない。
エージェントワークフローの準備方法
1200万を待つのではない。それが来るかのように、そしてそれが自分を救わないかのように作る。
コンテキストウィンドウをゴミ引き出しとして扱うのをやめよう。直感はコードベース全体、すべてのドキュメント、完全なチャット履歴を投げ込んでモデルに処理させることだろう。それがコンテキスト劣化を引き起こす方法だ。大きなウィンドウで勝つチームは、小さなウィンドウで規律を身につけたチームだ。
今すぐやる価値がある少しのこと。本当に信頼できる検索を構築し、モデルが間違った1200万ではなく正しい5万トークンを見るようにする――そしてそれは、重要なドキュメントが51位にランクされるケースを捕まえることを意味する。メモリをエージェントが読み書きする明示的なストアとして扱う。ファイルかデータベースか構造化ノート。「会話ログを上にスクロールする」ではなく。古いツール結果を刈り込み、完了したサブタスクを要約してワーキングセットをスリムに保つ。これらのスキルはすべて引き継がれる。ウィンドウが大きくなっても廃れるものは一つもない。
すべてを一つのプロンプトに詰め込めることでしかエージェントが機能しないなら、1200万ウィンドウはあなたの設計を修正しない。より大きなスケールとより高いコストで失敗することを許すだけだ。
コンテキストがボトルネックなのか？
違う。それが私が擁護するポジションだ。
生のコンテキスト長は仕様書の数字だ。マーケティングしやすく、針テストでベンチマークしやすく、進歩と間違えやすい。あなたたちのほとんどが行っているエージェント的な作業の本当のボトルネックは、検索、メモリ、エージェント設計だ。問いは「モデルが1200万トークンを保持できるか」ではなかった。問いは「正しいトークンを見つけ、重みを付け、推論できるか」であり――より大きな干し草の山はそれを厳密により難しくする。
中央で腐る1200万モデルより、外科的な検索を持つ20万モデルの方がいい。週のどの日でも。1200万トークンコンテキストLLMは、リリースされれば、いくつかの本物の問題に対する本物のツールになるだろう。リポジトリ全体の分析、本当に履歴を必要とする長期エージェント。あなたが作るものの大部分にとっては、私のパイプラインが犯したのと同じ過ちをより高い代価で繰り返す方法になるだろう――正しい数字がモデルのアテンションに届かなかったために、確信を持って間違った数字を送ること。
コンテキストは難しい部分ではない。何を入れるかを決めることがすべての仕事だ。