再帰言語モデル：AIに自身のコンテキストを管理させる
コンテキストウィンドウは劇的に拡大しました：10万、20万、さらには100万トークン。[^1]しかし、根本的な制限は残っています。線形メモリコスト、極端な長さでの注意力の低下、そして一度消費した情報を再訪問や再編成できないことが、長いコンテキストモデルの達成可能な範囲を制限しています。[^2]再帰言語モデル（RLM）はまったく異なるアプローチを取ります。すべてをコンテキストに詰め込むのではなく、RLMはPythonスクリプトとサブLLM呼び出しを使用してモデルに自身のコンテキストを積極的に管理することを教えます。[^3]
要約
MITのRLM論文は、メイン言語モデルが永続的なPython REPLと生成可能なサブLLMインスタンスに作業を委任するアーキテクチャを紹介しています。[^4]大規模な入力を直接読み込む代わりに、モデルはプログラム的にデータを検査し変換します。[^5]テストでは、RLMがモデルのコンテキストウィンドウを100倍超える入力を処理でき、ベースモデルや一般的な長コンテキストスキャフォールドを大幅に上回ることが示されています。[^6]CodeQAでは、GPT-5のベースライン精度は24%ですが、RLMは62%を達成します。[^7]Prime IntellectはRLMトレーニングインフラを実装し、このアプローチがAIエージェントの次の大きなブレークスルーを定義すると予測しています。[^8]
長コンテキスト問題
Transformerの注意機構はシーケンス長に対して二次的にスケールします。[^9]効率的な注意機構のバリアントがこのコストを削減しますが、根本的な課題は残ります：
コンテキストの劣化
研究では、モデルが技術的にその長さをサポートしている場合でも、コンテキストが増加するとモデルのパフォーマンスが低下することが示されています。[^10]有名な「干し草の山の中の針」テストでは、長いコンテキストの中央にある情報がしばしば無視されたり忘れられたりすることが明らかになっています。[^11]
静的コンテキスト
従来のコンテキストウィンドウは、一度書き込みバッファとして動作します。トークンがコンテキストに入ると、モデルはそれらを再編成、要約、または選択的に取得することができません。[^12]無関係な情報が重要な詳細と共に残ります。
メモリコスト
コンテキスト内の追加トークンごとに、推論中のキーバリューキャッシュに比例したメモリが必要です。[^13]100万トークンのコンテキストは、単一のクエリでさえ相当なGPUメモリを必要とします。
RLMソリューション
RLMは「モデルがコンテキストを受け取る」から「モデルがコンテキストを管理する」へとパラダイムを反転させます。[^14]
コアアーキテクチャ
RLMはメインモデルに3つの主要な機能を提供します：[^15]
| 機能 | 実装 | 目的 |
|---|---|---|
| Python REPL | 永続環境 | データの保存、変換、取得 |
| サブLLM | llm_batch()経由で生成可能なインスタンス |
分析タスクの委任 |
| Answer変数 | answer["content"] + answer["ready"] |
反復的な回答の改善 |
メインモデルは大量の入力を直接処理することはありません。代わりに、情報フローを管理するためのPythonコードを書きます。
コントロールプレーン設計
Python REPLは、Prime Intellectが「長いコンテキストのためのコントロールプレーン」と呼ぶものとして機能します。[^16]環境は以下を提供します：
永続状態：変数はモデルのターン間で生き残り、複雑な多段階ワークフローを可能にします。[^17]
並列処理：llm_batch()関数は複数のサブLLM呼び出しを同時に生成し、並列化可能なタスクを劇的に高速化します。[^18]
ツール分離：サブLLMのみがツールアクセス（ウェブ検索、ファイル読み取りなど）を取得し、メインモデルのコンテキストでのトークンの膨張を防ぎます。[^19]
プリインストールパッケージ：数学集約タスクはnumpy、scipy、sympyが自動的に利用可能になります。[^20]
Answer変数パターン
最終的な回答は単一の生成ではなく、反復的に出現します：[^21]
# モデルがanswer変数に書き込み
answer["content"] = "部分的な解決策..."
answer["ready"] = False # 処理を続行
# 後の反復で改善
answer["content"] = "完全な解決策..."
answer["ready"] = True # 完了を通知
このパターンにより、モデルは複数のREPL対話を通じて回答を修正および改善できます。[^22]
コンテキストフォールディングの仕組み
研究者はRLMのアプローチを要約ではなく「学習されたコンテキストフォールディング」と説明しています：[^23]
要約ではない
従来のアプローチは要約によってコンテキストを圧縮し、必然的に情報を失います。[^24]RLMアプローチは以下によってすべての情報を保持します：
- 生データを保存Python変数に
- 選択的にクエリサブLLM呼び出しを通じて
- 必要に応じてプログラム的に変換
- 元のコンテンツを要約しない
サブLLMへの委任
メインモデルが大きなドキュメントセクションの分析を必要とする場合、そのセクションだけでサブLLMを生成します：[^25]
# メインモデルコード
results = llm_batch([
{"prompt": f"セクション1を分析: {section_1}"},
{"prompt": f"セクション2を分析: {section_2}"},
{"prompt": f"セクション3を分析: {section_3}"}
])
# 完全なドキュメントをロードせずに結果を処理
メインモデルのコンテキストはスリムに保たれ、サブLLMがトークン集約型の操作を処理します。[^26]
ベンチマークパフォーマンス
4つの多様な環境でのテストは重要な機能を明らかにしています：[^27]
DeepDive（ウェブリサーチ）
サブLLMがウェブスクレイピングとコンテンツ抽出を処理します。メインモデルが検索戦略を調整し、発見を統合します。[^28]
| アプローチ | 報酬 |
|---|---|
| 標準LLM | 約45% |
| RLM（ヒントなし） | 約55% |
| RLM（戦略ヒントあり） | 約70% |
Oolong（長コンテキスト集約）
実世界の複雑なドキュメント（D&Dセッションのトランスクリプト）が約150万文字でコンテキスト処理をテストしました：[^29]
| アプローチ | 精度 |
|---|---|
| 標準LLM | 約35% |
| RLM | 約75% |
注目すべきは、RLMは合成データでパフォーマンスが低下したことで、このアプローチは人工的なベンチマークよりも現実的な複雑さで優れていることを示唆しています。
CodeQA（ドキュメントQA）
おそらく最も顕著な結果：[^30]
| モデル | アプローチ | 精度 |
|---|---|---|
| GPT-5 | ベースライン | 24.0% |
| GPT-5 | 要約エージェント | 41.3% |
| GPT-5 | RLM | 62.0% |
RLMはベースラインパフォーマンスを2倍以上にし、要約を大幅に上回りました。
Verbatim-Copy
反復的な改善によるJSON構造の保持：[^31]
| アプローチ | 精度 |
|---|---|
| 標準LLM | 約65% |
| RLM | 約77% |
Math-Python（注意事項）
RLMは現在、数学タスクで15-25%パフォーマンスが低下します：[^32]
| アプローチ | 精度 |
|---|---|
| 標準LLM | 約70% |
| RLM | 約50% |
研究者はこれを、モデルがRLMスキャフォールディングを数学的推論に効果的に使用するようにまだ訓練されていないことに帰しています。
トークン効率
精度を超えて、RLMはトークン効率を劇的に向上させます：[^33]
メインモデルトークン：同等またはより良い結果のために、プライマリモデルが処理するトークンが2-3倍削減。[^34]
総トークン：サブLLM呼び出しにより増加する可能性がありますが、入力サイズに関係なくメインモデルのコンテキストは制限されます。[^35]
レイテンシのトレードオフ：シングルパス推論と比較して、順次REPL操作は40-80%のレイテンシを追加します。[^36]
Prime Intellectの2026年予測
Prime IntellectはRLMトレーニングインフラを構築し、大胆な予測をしています：[^37]
2026年のパラダイム
彼らは3つの前提に基づいてRLMを次の大きなブレークスルーとして位置づけています：[^38]
1. トレーニングの優位性：固定スキャフォールドとは異なり、RLMはコンテキスト管理を改善するために強化学習でエンドツーエンドでトレーニングできます。[^39]
2. 注意機構との補完性：「効率的な注意機構とコンテキストフォールディングの両方が真の長期エージェントに必要です。より良い注意機構はコンテキストの劣化を遅らせます。コンテキストフォールディングはアクティブな管理を可能にします。」[^40]
3. 長期エージェント：RLMは数週間または数ヶ月にわたって動作し、拡張されたタスクタイムライン全体でコンテキストを管理するエージェントを可能にします。[^41]
RLMEnvインフラ
Prime IntellectはRLM互換環境とトレーニングインフラをリリースしました：[^42]
- Environments Hub上の複数の環境
- prime-rlトレーニングフレームワークとの統合
- コミュニティ実験にオープン
未開拓の可能性
現在のモデルは「スキャフォールディングの不適切な使用により、かなりのパフォーマンスが活用されていない」ことを示しています。[^43]RLM専用にトレーニングされていないモデルは、その機能を十分に活用していません。これはRLMネイティブトレーニングからの大きな利益を示唆しています。
オープンソースリリース
MITチームは完全なリソースをリリースしました：[^44]
- 論文：arXiv:2512.24601
- コード：https://github.com/alexzhang13/rlm
- 環境：様々な長コンテキストベンチマーク
AI開発への影響
エージェントアーキテクチャ
RLMは能力のあるエージェントを構築するための新しいパターンを示唆しています：[^45]
- オーケストレーターモデル制限されたコンテキスト付き
- ワーカーサブLLM特定のタスクを処理
- Python環境状態管理用
- 反復的改善シングルショットではなく
トレーニング要件
RLMを完全に活用するには、モデルに以下を含むトレーニングが必要です：[^46]
- REPL対話用のコード生成
- サブLLM委任戦略
- マルチターン回答改善
- 長期報酬シグナル
コスト構造
RLMはコストをコンテキスト長からオーケストレーションの複雑さに移行させます：[^47]
| 次元 | 従来 | RLM |
|---|---|---|
| メインモデルコンテキスト | 入力に比例 | 制限 |
| サブLLM呼び出し | N/A | 複雑さに比例 |
| レイテンシ | シングルパス | マルチターン |
| メモリ | コンテキストに比例 | 制限 |
主要な要点
再帰言語モデルはコンテキスト処理のパラダイムシフトを導入します：
- アクティブなコンテキスト管理：モデルは受動的に受け取るのではなく、自身のコンテキストを制御
- 100倍の拡張：ネイティブコンテキストウィンドウをはるかに超える入力を処理
- 情報の保持：要約ベースの情報損失なし
- トークン効率：メインモデルのトークン消費が2-3倍削減
- トレーニングの可能性：RLMネイティブトレーニングからの大きな利益が期待
- 長期エージェント：拡張されたタスクタイムラインに適したアーキテクチャ
RLMが「2026年のパラダイム」を代表するというPrime Intellectの確信は、コンテキスト管理がコンテキスト長よりも重要である可能性があるという認識の高まりを反映しています。
