MITの研究者が、言語モデルのコンテキストウィンドウの制限を事実上解決する画期的な手法を開発した。従来の言語モデルは、入力できるトークン数に物理的な上限があり、長いプロンプトを処理する際には情報の圧縮や要約が必要となり、品質の劣化が避けられなかった。しかし、この新しい「再帰的言語モデル(RLM)」アプローチでは、巨大なプロンプトをテキストファイルとして外部環境に保存し、モデルにツールを与えてその中を検索させることで、最大1,000万トークン以上の処理を可能にする。この手法は既存のモデルに適用可能で、コストを抑えながら品質を大幅に向上させることができる。モデルの核となる知性はそのままに、周辺のスキャフォールディング(足場構築)によって性能を飛躍的に高めるという、AI開発における新しいパラダイムを示している。
無限のコンテキストウィンドウを実現する革新的アプローチ
MITが基本的に無限のコンテキストウィンドウを解決しました。そして、これはどんなモデルにも適用できるんです。これは再帰的言語モデルと呼ばれていて、モデルの核となる知性の周りにスキャフォールディング、つまりインフラを構築することに、まだまだ成長の余地があることを示す素晴らしい例なんです。この論文について詳しくお話ししますが、本当に信じられないような内容なんですよ。
私たちは、推論時間スケーリングのレンズを通して、大規模言語モデルが任意の長さのプロンプトを処理できるようにすることを研究しています。まず、ハイレベルな結果をお見せしてから、詳細をすべて説明しますね。
こちらに見えているのはGPT-5で、この技術を使っていない状態です。ニードル・イン・ザ・ヘイスタック(干し草の中の針)テストでは非常にうまく機能しています。しかし、ULongやULongペアでは、コンテキスト長が増加するにつれて品質が急速に低下し、基本的に26万2,000トークン付近でゼロになってしまいます。
ところが、私たちの新しい再帰的言語モデル戦略を使うと、品質が時間の経過とともにかなり一貫して保たれ、100万トークンまで達してもそれが維持されるんです。そして、彼らが発見した技術をお伝えすると、それはとても明白で、きっと自分自身に問いかけると思いますよ。どうして今まで思いつかなかったんだろうって。
コンテキストウィンドウの基本概念と課題
では、少し立ち止まって考えてみましょう。現代の言語モデルにはコンテキストウィンドウと呼ばれるものがあります。プロンプトを送信するとき、何でもかんでも入れられるわけではありません。入力サイズには制限があるんです。これがコンテキストウィンドウと呼ばれるものです。
そして通常起こるのは、コンテキストウィンドウにより多くの情報を入れれば入れるほど、モデルがその中で物事を見つけたり、つながりを作ったりするのが難しくなるということです。これはコンテキスト腐敗と呼ばれていて、大きな問題なんです。
先ほどの図に戻ると、基本的にそれが見えているわけです。ニードル・イン・ザ・ヘイスタックが何か、ULongが何かについては説明します。もう少しお付き合いください。
MIT研究者の挑戦
それで、これらのMIT研究者は自分たちに問いかけたんです。コアモデルを実際に変更することなく、コンテキストウィンドウのサイズを劇的に増やすことはできないだろうかと。コンテキストウィンドウを100万トークンにできないだろうか。1,000万トークンはどうだろうかと。
これは長期的なタスク、数百万のドキュメントを検索する場合、巨大なコードベースにとって特に重要になります。大きなコンテキストウィンドウを持つことは信じられないほど重要なんです。
この分野における一般的で、ますます人気が高まっている推論時のアプローチの1つは、コンテキスト凝縮または圧縮です。基本的に、多くのモデルプロバイダーやサービスプロバイダーが行っているのは、コンテキストウィンドウを見て、コンテキストウィンドウの限界に達し始めたら、それを圧縮し始めるということです。
基本的には、LLMを使ってコンテキストウィンドウの中身を要約し、縮小するんですが、これは情報が失われます。毎回それを行うたびに、本質的に情報を圧縮して品質のビットを失っているんです。時にはそれは問題ないこともあります。少しの品質を失うことは全く問題ないこともありますが、多くの場合、それは非常に重要なんです。
したがって、圧縮や凝縮の技術は完璧ではありません。完璧には程遠いですが、それが今日多くの企業が行っていることなんです。
想像してみてください。本当に長い物語があって、それを要約して、その要約を要約して、それを何度も繰り返すんです。最終的には、詳細を失って、もう完全な物語を持っていないことになります。本質的に、それが圧縮で起こることなんです。
革新的な解決策の提案
では、彼らが提案していることをお話ししますが、振り返ってみると本当に明白なんです。効果的に彼らがやっているのは、環境コードを作成し、モデルの物理的なコンテキスト制限で許可されているよりも大きな巨大なプロンプトをテキストファイルのようなファイルに入れて、そのプロンプトを検索するためのツールをモデルに与えることなんです。
もしこれがRAG(検索拡張生成)のように聞こえるなら、ある種そうなんですが、それは環境内で行われています。では、順を追って説明しましょう。
外側に言語モデルがあります。再帰的言語モデルフレームワークがあります。それからPython環境があります。Python環境では、プロンプトを変数として保存します。そして、その巨大なプロンプトを検索するためのツールをモデルに与えるんです。
それがここで見えているものです。パート1、パート2と分割します。異なるクエリを持つことができて、最終的な答えがあります。しかし、ここが本当の魔法が起こる場所なんです。ここが再帰的な部分が起こる場所です。
モデルが関連すると思われるコンテキストの一部を見つけたとき、実際にそれに対して再びクエリを実行し、どんどん深く掘り下げることができるんです。
つまり、例えば1,000万トークンのコンテキスト、1,000万トークンのプロンプトを取って、それを見続け、特定のセクションに深く入り込み、それから戻ってきて、そのセクションで見つけたものを使い、他のセクションで見つけたものと組み合わせることができるんです。したがって、基本的に無限のコンテキストウィンドウを持つことができるわけです。
実践的な動作例
ここには信じられないほど長い物語があって、プロンプトは「あなたは非常に長い本を読んでいます。大災害の前に作られたすべてのアイテムをリストアップできますか?」となっています。それから物語全体がプロンプトに配置され、それに対してクエリを開始します。
そしてここで、再帰的検索に入ると、第1章ですべてのアイテムを見つけます。すべてのアイテムを見つけたら、さらに深く掘り下げます。これらのセクションで、明示的に見つかったと書かれているアイテムを探します、といった具合です。
したがって、すべての詳細を見つけることができ、要約は必要ありません。コンテキストの圧縮も必要ないんです。
重要な洞察は、長いプロンプトはニューラルネットワークに供給すべきではないということです。これは私がますます目にしていることで、ニューラルネットワーク、モデルの実際の重み、モデルの核となる知性がほぼ独立して扱われ、その核となる知性の周りにますます多くのスキャフォールディングが構築されているんです。
それによって、より良いメモリ、より効果的なメモリを持ち、ツールを使えるようになります。これらすべてがモデルの周りに構築されているんです。
AI開発における新しいパラダイム
そして私はしばらく言ってきたんですが、これらのモデルは本当に優秀です。99.9%のユースケースに十分なほど知的なんです。そして開発者として私たちがすべきことは、より多くのツール、より多くのスキャフォールディングを構築し、これらのモデルがすでに持っている知性でより多くのことができるようにすることなんです。
ところで、これらの技術のいくつかを試して、ワークフローの残りを自動化したい場合は、今日のビデオのスポンサーであるZapierで実行できます。Zapierについてお話しできることをとても楽しみにしています。彼らは素晴らしいパートナーです。私は文字通り、このビジネスと以前のビジネスで10年以上Zapierを使ってきました。
今日は、Zapierエージェントについてすべてお話ししましょう。想像できるあらゆるツールに接続されたスーパーパワーを持つエージェントを想像してみてください。Zapierはずっとワークフローの自動化を構築してきました。そして今、彼らは7,000以上のさまざまなツールからなる非常に大きなライブラリを取り、エージェント、特にZapierエージェントがそれらに直接接続できるようにしたんです。
MCPを介したClaudeとの非常に緊密な統合があり、最近ローンチされて以来、さらに良くなっています。正直なところ、私のビジネスの半分は現在Zapier上で動いています。
最も簡単なAIオーケストレーションが必要な場合は、Zapierをチェックして、Zapierエージェントを使ってください。すべてのリンクを下に記載します。彼らは素晴らしいパートナーであり、私は彼らのプラットフォームの大ファンなんです。改めてZapierに感謝します。
具体的なテスト手法とベンチマーク
さて、ビデオに戻りましょう。代わりに、LLMが象徴的に相互作用できる環境の一部として扱われるべきなんです。
では、彼らは実際にどのようにこれをテストしたのでしょうか。ニードル・イン・ザ・ヘイスタックについて話しましたね。これを発明したGreg Cameronに敬意を表しますが、他のテストもあります。ニードル・イン・ザ・ヘイスタックはすべての最新モデルでほぼ解決されています。
ここに戻ってスクロールすると、GPT-5が見えます。これがニードル・イン・ザ・ヘイスタックです。そして品質、パーセンテージが物理的なコンテキストウィンドウの最後まで一貫して維持されているのが分かります。だからニードル・イン・ザ・ヘイスタックは多かれ少なかれ解決されています。
しかし、これらのより難しいテストの一部は解決されていません。彼らは4つの主要なユースケースに対してテストしました。深い研究、情報集約、コードリポジトリの理解、そして合成的なペアワイズ推論タスクです。そして最後のものについては、最先端のモデルでさえそれらのタスクで非常にひどく失敗します。
RLMは1,000万トークン以上のスケールでも非常に強力なパフォーマンスを示し、ほとんどの場合、長いコンテキスト処理において他のすべてのアプローチを二桁のパーセンテージの利益で劇的に上回り、同等またはより低いコストを維持していることが分かりました。
つまり、この巨大なウィンドウを得るだけでなく、信じられないほどの品質を得るだけでなく、実際にはほとんどの場合、より多くのトークンを使用しないため、実際により安価なんです。すぐにそこでの例外をお伝えします。なぜなら、これらすべてがそれで行われているからです。
モデルは、プレーンテキストで保存されているコンテキストウィンドウに入り、それを検索するために少しのコードを書くだけでいいんです。毎回全体のコンテキストを自分自身にロードする必要はないんです。そして通常、そこから費用が発生します。
各種テストの詳細説明
では、実際のテストについてお話ししましょう。ニードル・イン・ザ・ヘイスタックについて何度か話しました。それが何かを説明しますが、まずこれらのテストについて簡単に説明させてください。
LLMの実効的なコンテキストウィンドウは、モデルの物理的な最大トークン数よりもはるかに短いことがよくあります。つまり、このモデルは25万6,000トークンをサポートできると聞いたとき、それは物理的な限界です。
しかし、コンテキスト全体で複雑な推論を行っている場合や、最後のドキュメントを中間の別のドキュメントと比較する必要があるユースケースがある場合、本当に急速に劣化し始めます。
したがって、25万6,000トークンと表示されていても、多くのユースケースでは実際にはそうではないんです。そしてそこがRLMが本当に輝く場所なんです。
では、まず単一のニードル・イン・ザ・ヘイスタックです。基本的に、コンテキストウィンドウを何でも、物語でも、ハリー・ポッターの本でも何でもいいので埋めて、その真ん中にランダムな文字列、何かを置くんです。「password equals 1234」と言います。
それから全体のプロンプトをコンテキストウィンドウに渡して、「ねえ、パスワードは何?」と言います。そしてそれをどこかでそこから見つけなければなりません。モデルは基本的にこれを完璧にマスターしています。これを常に完璧にできない最先端モデルは本当にありません。
しかし、それから私たちはBrowsecomp Plusのようなより難しいものがあり、これは深い研究に非常に似たマルチホップ質問応答ベンチマークです。たくさんのドキュメントをロードして、モデルがコンテキストウィンドウ全体のさまざまなドキュメントを見る必要がある質問に答えなければなりません。
つまり、最初から少し、最後から少し、といった具合です。そしてコンテキストウィンドウのさまざまな部分から詳細の正しい組み合わせを持っている場合にのみ、正しい答えが得られます。
それからULongがあります。ULongは長い推論ベンチマークで、入力のチャンクを意味的に検査して変換し、これらのチャンクを集約して最終的な答えを形成する必要があります。これはBrowsecompのより洗練されたバージョンと考えることができます。
それからULongペアがあり、これはULongの拡張で、特にチャンクのペアを集約して最終的な答えを構築する必要があります。繰り返しますが、ULongのより複雑なバージョンです。
そして最後にLongBench v2があり、これはコードリポジトリの理解のためのものです。巨大なコードベースを入れて、それに対して質問をし、さまざまな関数が何をするかを理解しようとします。それには多くの異なる場所を見る必要があります。
開発者なら、私が何について話しているか分かるでしょう。ある場所でメソッドを見て、それからコードの他の場所で行っている呼び出しをトレースしなければならず、それは非常に難しく、同時にコードベース全体の理解を本当に必要とします。
テスト結果の詳細分析
彼らはこれらすべてを2つの主要なモデルに対してテストしました。中程度の推論を持つGPT-5があり、彼らは480億パラメータのQwen 3 Coder(350億の活性パラメータ)というオープンソースモデルを使用しました。
そして4つの異なるアプローチを使用しました。RippleによるRLMを使用しました。Rippleは私が言及した環境です。サブコールなしのRippleによるRLMがあり、これは1回の呼び出しだけを行い、再帰的に進んで追加情報を見つけようとしなかったことを意味します。
それから要約エージェントがあり、これは伝統的な方法のようなものです。そして最後にCode Actがあり、これはRLMに似ていますが、プロンプトをコンテキストウィンドウの外にオフロードせず、言語モデルに直接提供します。
では、結果について話しましょう。彼らはニードル・イン・ザ・ヘイスタックを除外しました。なぜなら、それは基本的に解決されているからです。本当に良い比較ではありません。
しかし、Code QA、Browsecomp、ULong、ULongペアを見ると、多くの場合、RLM、サブコールなしのRLMでさえ、他の方法よりもはるかに良い結果を出したことが分かります。これはQwen 3 CoderとGPT-5です。
GPT-5上のRLMは全般的にはるかに、はるかに良い結果を出しました。彼らはこれらのテストからいくつかの観察結果を持っています。それらを順に説明しましょう。
観察1:RLMは1,000万トークン以上の領域にスケールでき、長いコンテキストタスクにおいてベース言語モデルや既存のタスク非依存エージェントスキャフォールドを上回ることができます。
しかし、それが最も印象的な部分ではありません。これを見てください。GPT-5 Miniが600万から1,100万の入力トークンを取り込むコストは150ドルから275ドルです。一方、RLM GPT-5の平均コストは99ドルで、要約と検索のベースラインの両方を29%以上上回っています。
より安く、より良い。それが本当に求められることのすべてです。
観察2:Ripple環境は長い入力を処理するために必要であり、RLMの再帰的サブコーリングは情報密度の高い入力に強力な利益を提供します。
つまり、長いプロンプトをコンテキストウィンドウの外にオフロードするだけで良いのです。しかし、本当に複雑または洗練されたプロンプトがあり、その多くの異なる部分に触れる必要がある場合、その再帰的要素を持つことが同じくらい重要なんです。
観察3:言語モデルのパフォーマンスは入力長と問題の複雑さの関数として劣化しますが、RLMのパフォーマンスはより良くスケールします。
これは本当に重要です。コンテキストの長さだけでなく、そのコンテキストで何をしているかということなんです。RLMなしでは、複雑さが増し、コンテキストウィンドウが増加するにつれてモデルは苦労します。しかしRLMを使うと、実際に本当にうまくスケールするんです。
観察4:RLMの推論コストはベースモデル呼び出しに匹敵しますが、軌道の長さの違いによる高い分散があります。
つまり、システムに何でも再帰的に行う能力を与えている場合、それがどこまで深く進むかは分かりません。したがって、本当に深く進むと、より高価になり、コストにこれらのスパイクがあります。
RLMは適切な答えを見つけるまでコンテキストと反復的に相互作用し、タスクの複雑さに応じて反復の長さに大きな違いが生じます。しかし、コンテキスト全体を取り込む要約ベースラインと比較して、RLMはモデルが選択的にコンテキストを表示できるため、すべてのタスクでより強力なパフォーマンスを維持しながら、最大3倍安価です。
観察5:RLMはモデル非依存の推論戦略です。つまり、これを基本的にどのモデルにも接続できるということで、これは素晴らしいことです。しかし、異なるモデルはコンテキスト管理とサブコーリングに関して異なる全体的な決定を示します。
明らかに、すべてのモデルは異なります。異なる個性を持っています。問題への異なるアプローチを持っています。コーディングの得意さに違いがあります。そしてこれらの違いは、このシステムがどのように機能するかに影響します。
特にBrowsecomp Plusでは、GPT-5を使ったRLMはほぼすべてのタスクを解決しますが、Qwen 3 Coderを使ったRLMは半分を解決するのに苦労します。
左のチャートでは、GPT-5が見え、25パーセンタイル、50パーセンタイル、75パーセンタイルで全体的にコストがかなり低いことが分かります。そして突然、95パーセンタイルで要約エージェントとCode Actエージェントにコストのマッシブなスパイクがあり、RLMエージェントにもスパイクがあります。一方、ベースモデルは非常に低いですが、これは単なるコストであることを覚えておいてください。品質は考慮されていません。
ベースモデルは非常に低いままですが、RLMアプローチは、より大きなコンテキストと複雑さで品質を維持しているにもかかわらず、コストで本当にスパイクし始めます。
こちらでは同じことを見ていますが、Qwen 3 Coderを使っています。
実装の詳細とコード例
では、実際にどのように見えるのでしょうか。その大きなプロンプトで情報を見つけようとして、再帰的にそれを見て調べようとしているとき、そのコードのいくつかは実際にどのように見えるのでしょうか。
まあ、こんな感じです。ReActがたくさんあります。誰が思ったでしょうか? 特定のパターンを探しています。それから深く入り込み、あなたが開発キャリアでおそらく使ったことのある標準的なReActのようなものです。
この論文は魅力的だと思いました。私はスキャフォールディングに非常に強気です。モデルの核となる知性の周りで、これらの信じられないほどのアンロックを見つけ続けると本当に思っています。
モデルは並行して良くなっていますが、より多くのツール、より多くのスキャフォールディング、モデルの周りにより多くのハーネスを構築することから、品質改善のためのさらに多くの余地があると思います。
あなたがどう思うか教えてください。このビデオを楽しんでいただけたら、ぜひいいねをして、チャンネル登録を検討してください。
コメント