- 大規模言語モデル（LLM） が非常に長い入力プロンプトを処理できるようにする 新しい推論戦略 RLM（Recursive Language Model） が提案された
- RLM は長いプロンプトを 外部環境の一部と見なし、モデルがそれを プログラム的に探索・分解・再帰呼び出し できるようにする
- この方式は既存の コンテキストウィンドウの限界を超えて 最大数千万トークン規模の入力を処理し、既存 LLM と比べて品質が大きく向上 する
- 実験の結果、GPT-5 および Qwen3-Coder ベースの RLM は さまざまな長文タスクで二桁の性能向上 を示し、コストは同等かそれ以下だった
- 長い文脈処理の限界を克服し、LLM の推論能力を大幅に拡張できる一般的なアプローチ と評価される
RLM の概要
- Recursive Language Model（RLM） は、LLM が長い入力を直接ニューラルネットワークに入れるのではなく、それを 外部環境の変数として扱って 相互作用するよう設計されている
- 入力プロンプト P を Python の REPL 環境 の変数としてロードし、LLM がコードによってそれを探索・分解・再帰呼び出しするようにする
- LLM は REPL 環境の状態（例: 文字列長）を認識し、コード実行の副作用を観察しながら段階的に問題を解決する
- この構造は、従来の 文脈圧縮（compaction） や 要約ベースのアプローチ が詳細情報を失う問題を解決する
- RLM は 入力長と出力長の両方を拡張 できる一般的な推論パラダイムとして提示されている
既存アプローチの限界
- 従来の LLM は コンテキストウィンドウの限界 により、長い入力で性能が急激に低下する context rot 現象を示す
- 文脈圧縮（compaction）手法は一定の長さを超えると要約を繰り返すが、細かな情報へのアクセスが必要なタスク には不向きである
- RLM はプロンプトを外部オブジェクトとして扱うことで、入力サイズをモデルの限界以上に拡張 できる
実験設定
- 評価モデル: GPT-5（OpenAI, 2025） と Qwen3-Coder-480B-A35B（Team, 2025）
- 比較対象:
- 基本的な LLM の直接呼び出し
- 要約エージェント（Summary agent）
- CodeAct + BM25 検索ベースのエージェント
- RLM（REPL 環境あり） および RLM（REPL、再帰呼び出しなし）
- GPT-5 の実験では、再帰呼び出し用に GPT-5-mini を、ルートモデルとして GPT-5 を使用し、性能とコストのバランスを確保した
評価タスク
- S-NIAH: 単一の「needle-in-a-haystack」問題で、入力長に関係なく処理コストは一定
- BrowseComp-Plus: 複数の文書をまたぐ multi-hop 質問応答 タスクで、1000 個の文書の中に正答を含む
- OOLONG: 入力のほぼすべての項目を意味的に変換・統合する必要がある 長文推論タスク で、処理コストは入力長に線形比例する
- OOLONG-Pairs: OOLONG の派生版で、ペア単位の情報結合 が必要であり、処理コストは 入力長に二乗比例 する
- LongBench-v2 CodeQA: コードリポジトリの理解を要求する 多肢選択タスク で、最新モデルでも難しい問題
主な結果
- RLM は GPT-5 と比べて長い文脈でも性能低下がほとんどない
- GPT-5 は入力長とタスク複雑性の増加に伴って急激に性能が低下した
- RLM は 272K トークンの限界を超える入力（最大 10M+ トークン） も効果的に処理した
- すべての長文タスクで RLM が他の方法と比べて二桁の性能向上 を示した
- コスト効率 も維持され、クエリあたりのコストは既存アプローチと同程度かそれ以下だった
長文タスクの複雑性分析
- LLM の 実質的なコンテキストウィンドウ は物理的な限界よりも タスクの複雑性によってさらに短くなりうる
- 単純な NIAH 問題は 1M+ トークンでも解決可能
- 複雑な OOLONG 系タスクは、はるかに短い長さでも性能低下が発生する
- したがって、タスクの 情報密度と入力長の相関関係 をあわせて考慮する必要がある
結論
- RLM は LLM の推論能力を再帰的に拡張 し、既存モデルでは処理できない 超長文入力 を扱えるようにする
- プロンプトを環境オブジェクトとして扱う設計 が中核的な革新であり、長文処理の構造的限界を解決する
- さまざまなモデルとタスクにおいて、性能・コスト・拡張性のバランスを達成した一般的な推論フレームワーク として提示されている
1件のコメント
Hacker Newsの意見
これは単に subagent の概念のように見える
つまり、別のLLMを呼び出してファイルを読み、必要な情報を抽出させることで、メインのコンテキストを複雑にしないようにするやり方だ
アイデアとしては悪くないが、まったく新しいものではない
現在 Scope プロジェクトで、観測可能な subagent がタスクを再帰的に分解するよう実験している
ただ、この 計画段階の評価 をどう改善すればいいのかわからない
マークダウンファイルにヒューリスティックを記録しているが、構造が緩くて測定が難しい
関連する文献やプロジェクトを知っている人がいたら教えてほしい
RLM はエージェントでも要約でもない
1つのシステム内で複数の LM 呼び出しを使うこと自体は新しい概念ではなく、これは大半の agentic scaffold がやっていることだ
最も近い例として ROMA agent が問題を分解し、複数の sub-agent で解く方式が挙げられる
また、Cursor や Claude Code のようなコードアシスタントも、コンテキストが長くなるほど要約や枝刈りを行う
こうしたアプローチは通常タスク単位で分解するが、RLM は コンテキスト単位の分解 を強調しており、その選択は LM 自身が決めるべきだとしている
核となる洞察は、長いプロンプトをニューラルネットワーク（Transformer）に直接入れるのではなく、LLM が 記号的に相互作用できる環境 の一部として扱うべきだということだ
ただ、これが根本的に RAG とどう違うのか気になる
図4を見ると、違いは人間ではなく LLM が直接 retrieval メカニズムを実装する点のようだ
1️⃣ RAG は workflow に近く、こちらはより agentic だ
2️⃣ 再帰的構造 を持っている
workflow では人間が段階ごとの流れを設計するが、agentic なアプローチではエージェント自身が何を検索し、何回呼び出し、いつ回答するかを決める
たとえば Claude Code や Codex がコードベースを探索しながらファイルを読み、
ripgrepを実行するようなものだこうした再帰的な試みは以前にもあったが（例: babyagi、2023年ごろ）、当時はモデル性能が不十分で、多くの glue code が必要だった
今ではモデルが十分強力になり、こうした構造が実際に機能するようになっている
「T̶u̶r̶t̶l̶e̶s̶ LLMs all the way down」という冗談のように、LLM が際限なく LLM を呼び出す構造を示唆している
もっと読みやすい版の記事がある: alexzhang13 のブログ記事
2026年に期待したいのは、Anthropic や OpenAI が CLI プラグイン開発者向けに「compaction がどう実行されるか」を公開することだ
この技術は Claude Code に組み込まれた機能を置き換えられるかもしれないが、現時点では適切な hook や機能が公開されていない
私は Gemini のソースを見たが、コンテキストウィンドウがいっぱいになると全体を要約するだけの単純なプロンプト構造だった
この論文に似ているように見える: arXiv:2510.14826