📋 要約（TL;DR）#
- 🔑 「コンテキストロット」問題: LLMは入力が長くなると性能が劣化する、これが最大の敵だった
- 🔑 再帰的言語モデル（RLM）: LLM自体を再帰的に呼び出し、巨大な入力を分割処理する新アプローチ
- 🔑 コンテキストウィンドウの100倍を処理: なんと2桁分もコンテキストを拡張できた！
- 💡 読みどころ: 推論時スケーリングの次のフロンティア、RLMが開く新しい可能性
🎯 みんな、長いプロンプトで困ってない？#
こんにちは！Emmaです 🍫
最近、Claude Codeで大規模なコードベースを分析したり、RAGで大量のドキュメントを検索したり…みんなも「もっと長いコンテキストが欲しい！」って思ったことない？
でね、Google Geminiが100万トークン、Llama-4 Scoutに至っては1000万トークンのコンテキストウィンドウを発表して、「問題解決！」って雰囲気なんだけど…
実は、大きなコンテキストウィンドウ ≠ 高性能な推論なんだよね 😅
これ、**「コンテキストロット」**って呼ばれる問題で、Chromaの研究者たちが指摘した現象なんだけど、「LLMの性能は入力が長くなると信頼性が低下する」んだって。
でね、MITの研究者たちがこの問題に革新的なアプローチで挑んだ論文が出たの！
タイトルは「Recursive Language Models」。2025年12月にarXivに投稿されて、2026年1月に改訂された最新の論文だよ 📄
なんと、コンテキストウィンドウの100倍の入力を処理できる手法を提案してるの！
一緒に見ていこう！🤔
🔬 この論文、何が新しいの？#
問題：コンテキストロット#
まず、なぜ「大きなコンテキストウィンドウ」だけじゃダメなのか理解しておこう 🔍
LLMのアテンション機構は、2次の計算複雑性を持ってる。つまり：
- 入力が n → 2n になると、計算量は 4倍 に
- 入力が n → 10n になると、計算量は 100倍 に！
これ、推理モデル（o1とかR1とか）では特に問題になるんだ。なぜなら、モデルが「考える」過程で自分自身に出力を食わせ続けるから、コンテキストがどんどん膨らんでいくの。
さらに、「Needle in a Haystack（干し草の中の針）」テストで分かったことがある：
GPT-4の検索精度は、コンテキストが長くなると、文書の中央部分（10%-50%）にある情報の検索で特に劣化する
つまり、「コンテキストウィンドウに入る」ことと「正しく処理できる」ことは別なんだ 🎯
解決策：再帰的言語モデル（RLM）#
MITチームのアイデアはシンプルだけど強力：
「巨大なプロンプトを一度にLLMに食わせるんじゃなくて、LLMに自分で分割させて、再帰的に処理させよう」
これが**再帰的言語モデル（RLM）**の核心だ！
🧠 RLMはどう動くの？#
Read-Eval-Print-Loop（REPL）環境#
RLMの心臓部は、PythonのREPL環境なんだ 🐍
イメージしてみて：
- 巨大なテキスト（例：100万トークン）がある
- このテキスト全体をLLMに食わせるんじゃなくて、REPL変数に保存する
- LLMにはクエリだけを渡す
- LLMは必要なときにREPLから部分的にデータを取り出す
- 取り出した断片を**別のLLM呼び出し（サブLLM）**で処理
- 結果を統合して最終回答を出す
これ、LLMが自分で「何を読むべきか」を決めるってこと！賢いでしょ？😊
システムプロンプトの例#
論文で使われてるシステムプロンプトには、こんな指示が含まれてる：
「まずコンテキストを見てチャンキング戦略を決め、コンテキストをスマートなチャンクに分割し、各チャンクにLLMをクエリして回答をバッファに保存し、全てのバッファをクエリして最終回答を生成する」
つまり、LLM自体に**「どうやって問題を分解するか」を考えさせる**の！
具体例：マジックナンバーを探す#
論文のデモ問題：
- ランダムな巨大テキストの中に、どこかに7桁の数字が隠されている
- クエリ：「マジックナンバーを探して。何？」
通常のLLMなら、巨大なテキストを一度に処理しなきゃいけなくて、精度がガタ落ちする。
でもRLMなら：
- まずコンテキストのサイズを確認
- チャンキング戦略を決める（例：1万字ずつ分割）
- 各チャンクをサブLLMに送って「数字ある？」と質問
- 数字が見つかったチャンクを特定
- 最終回答を返す
これで2桁分（100倍）コンテキストを拡張できたんだ！🎯
📊 結果はどれくらいすごいの？#
4つの長文脈タスクで検証#
MITチームは4つのタスクでRLMを評価した：
- Needle in a Haystack（NIAH） - 巨大なテキストから特定情報を検索
- マルチニードル - 複数の情報を統合
- 長文要約 - 巨大な文書の要約
- 質問応答 - 長文脈ベースのQA
結果サマリー#
- ✅ コンテキストウィンドウの100倍まで入力拡張可能
- ✅ 短いプロンプトでも、通常のLLMより大幅に精度向上
- ✅ コストは通常のLLMと同等
- ✅ RLM-Qwen3-8B（微調整版）は、ベースモデルより28.3%向上
- ✅ なんと3つのタスクでGPT-5（バニラ）に迫る性能！
これ、8BモデルがGPT-5に肉薄するってことだよ？すごくない？😲
🔄 なぜRLMはうまくいくの？#
1. 段階的な処理#
人間だって、巨大な本を一度に全部読むなんてできないよね？章ごとに読んで、必要な部分をメモして、最後に統合するはず。
RLMも同じアプローチなんだ。「一気に全部」じゃなくて、「必要な分だけ、必要なときに」📖
2. コンテキストロットの回避#
巨大な入力を一度に食わせないから、アテンション機構が過負荷にならない。
モデルは常に「小さなコンテキスト」で作業できるから、精度が安定するの 🎯
3. 推論時スケーリングの新次元#
2025年は「推論時スケーリング」の年だった。o1やR1が登場して、「考える時間を増やせば性能が上がる」ことが分かった。
RLMは別の次元でスケーリングする：
- 従来の推論時スケーリング: 時間をかけて「深く考える」
- RLMのスケーリング: 再帰呼び出しで「広く処理する」
この2つは組み合わせ可能！2026年は「RLM × 推論モデル」の年になるかも？🚀
🤔 実際どう使えるの？#
ユースケース#
- 大規模コードベース分析 - リポジトリ全体を一度に分析
- 法律文書レビュー - 何百ページもの契約書を要約・検索
- 学術論文調査 - 関連論文を大量に読み込んで統合
- 企業内部文書検索 - ナレッジベース全体からのRAG
使い始めるには#
なんと、コードがGitHubで公開されてる！
👉 https://github.com/alexzhang13/rlm
好きなLLMにRLMのスキャフォールディングを被せるだけで、すぐに試せるんだ。
💭 Emmaの感想#
これ読んでて思ったんだけど、RLMって人間の読解プロセスに近いんだよね。
みんなも論文読むとき、最初から最後まで一気に読まないでしょ？ 目次を見て、気になる章を拾い読みして、必要なら前後の章も読んで…って感じで。
LLMにも同じことができるようにした、それがRLMなんだと思う。
それに、「コンテキストウィンドウを大きくする」っていうハードウェア頼みのアプローチだけじゃなくて、アルゴリズムで解決しようとしてるところが好きだな〜 🍫
2026年、推論モデルが当たり前になった今、次は**「どうやって巨大な情報を効率的に処理するか」**が勝負になる気がする。
RLMはその答えの一つかもしれないね！
📚 参照#
- Recursive Language Models - arXiv - MIT研究チーム
- Recursive Language Models解説記事 - Where Machines Think
- GitHub: RLM実装 - alexzhang13
- Context Rot - Chroma Blog - Chroma研究チーム
みんなはどう思う？「LLMに自分で分割させよう」ってアプローチ、試してみたい？コメントで教えてね〜 ✨
Emmaでした！次回もお楽しみに〜 🍫