こんにちは！
今週はDXソリューション事業本部 Devグループ マネージャーの小倉が担当します！
LLMに長文を与えると、精度が低下するケースをよく見かけますよね。 今回は、そうした長文に対しても推論精度を維持しやすい手法である「RLMs（Recursive Language Models）」について紹介します！
対象の論文
- 1. サマリ
- 2. 背景：Context Rot（コンテキスト劣化）とタスク複雑性
- 3. 技術詳解：Recursive Language Models (RLM) の構造
- 4. 実験評価：性能と経済性の検証
- 5. 考察
- 6. 所感
- We’re Hiring!
1. サマリ
- 課題： 既存のTransformerベースのモデルは、コンテキスト長が増大すると精度が急落する「Context Rot（コンテキスト劣化）」や、物理的なウィンドウ上限（本論文中では GPT-5 を約272Kトークンとして扱っています）の制約を克服できていません。
- 手法： 入力プロンプトを直接モデルに入力せず、Python REPL環境の外部変数として隔離します。LLMがプログラムを介して自身を再帰的に呼び出し、情報をシンボリックに処理する新しい推論パラダイム「RLM」を提案しています。
- 結果： 10Mトークン規模の超長文コンテキストにおいても、従来の検索（RAG）やコンテキスト圧縮といった手法を大幅に上回る性能を実証しています。
2. 背景：Context Rot（コンテキスト劣化）とタスク複雑性
LLMの有効なコンテキスト窓は、単なる「長さ」だけではなく、「長さ × タスク構造」の関係によって崩壊することが明らかになっています。本論文では、タスクの難易度を入力長に対する計算量（計算複雑性）として、以下のように定義しています。
定数複雑性 (
): S-NIAH。特定情報の位置が特定できれば解けるため、劣化は緩やかです。
- 内容：長い無関係テキスト（haystack）のどこかに埋めた特定フレーズや数値（needle）を見つけて答えるタスクを50問集めたものです。
- 重要ポイント：入力が長くなっても「探すべき針」は1つなので、理屈の上では処理コストが入力長に対して“ほぼ定数”です（やることは“1個探す”こと）。
Sequential-NIAH: A Needle-In-A-Haystack Benchmark for Extracting Sequential Needles from Long Contexts (Yifei Yu, 2025)
線形複雑性 (
): OOLONG。全行の集計が必要なタスクです。プロンプトが長くなるほど劣化が加速します。
- 内容：入力をチャンク（多数のエントリ）に分け、各チャンクを意味的に検査・変換し、その結果を集約（カウントなど）して最終回答を作ります。
- 評価：RLM論文ではtrec_coarse split（セマンティックラベル付きの質問セット）にフォーカスし、スコアは元論文準拠です（数値は許容、それ以外は完全一致）。
- 重要ポイント：多くのクエリで「ほぼ全エントリを使う」必要があり、入力長が増えるほど処理量も増えるため、線形にスケールします。
Oolong: Evaluating Long Context Reasoning and Aggregation Capabilities (Amanda Bertsch, 2025)
二次複雑性 (
): OOLONG-Pairs。全要素間のペア関係を抽出するタスクです。フロンティアモデルであっても早い段階で性能が大きく低下します。
- 内容：RLMで独自に作成したデータセットです。単体のチャンク集約ではなく、チャンクの“ペア”を集約しないと答えられないクエリを追加したものです。
- 評価：F1スコア。
- 重要ポイント：ほぼ全ペアを見る必要がある設計なので、入力長
に対して二次（
）にスケールする、情報密度が極端に高いタスクです。
論文では、長文処理における3つのタスク（S-NIAH、OOLONG、OOLONG-Pairs）で GPT-5 と RLM を比較しています。 その結果、単純な検索に近い S-NIAH では GPT-5 も高い性能を維持する一方、入力全体の集約が必要な OOLONG や、要素間の関係性まで扱う OOLONG-Pairs では、GPT-5 の性能が入力長の増加に伴って大きく低下することが示されています。 これに対して RLM は、より複雑なタスクでも比較的安定した性能を維持しており、長文かつ高複雑度の問題に対する有効性が示されています。
3. 技術詳解：Recursive Language Models (RLM) の構造
RLMは、LLMを単なる「情報の読取機」としてではなく、外部環境を操作する「プログラミング・エージェント」として機能させます。
3.1 REPL（Read-Eval-Print Loop）環境の役割
REPLとは
プログラムのインタプリタと直接対話する方式です。
Python コマンドを実行したときに起動するインタプリタや、Jupyter などは REPL の一種です。
- コンテキストの外部化: プロンプトはモデルのトークン空間ではなく、REPL環境内の変数（文字列）として保持されます。
- シンボリック操作: モデルは
print(context[:1000])や正規表現を用い、巨大なデータから必要な情報だけを「覗き見（peek）」します。これにより、履歴を圧迫せずに情報をフィルタリングできます。 - プログラムによる再帰: モデルは
llm_query()関数を生成し、動的に切り出した特定のスライスをサブモデルに再帰処理させることが可能です。
3.2 推論ループのアルゴリズム
- 初期化: プロンプトを変数にロードし、メタデータ（文字数など）のみをモデルに提示します。
- 実行: モデルがPythonコードを生成し、REPL上で実行します。
- 継続: 標準出力の要約を履歴に追加し、終了判定が出るまでループを繰り返します。
- 出力:
FINAL_VAR()を経由することで、モデルの最大出力長に縛られない巨大なテキストの構築・出力が可能になります。
4. 実験評価：性能と経済性の検証
4.1 主要ベンチマーク結果
論文では、複雑さの異なる長文ベンチマークに対して、ベースモデル、CodeAct、Summary agent、RLM などの複数手法を横並びで評価しています。 GPT-5 を用いた比較では、RLM がすべての評価タスクで最良のスコアを示しており、特に BrowseComp+ や OOLONG-Pairs のような、長さや推論の複雑さが大きいタスクで差が大きく表れています。 この結果から、RLM は単なる長文対応手法というよりも、複雑な探索や集約を必要とする問題設定で特に効果を発揮することが分かります。
4.2 ファインチューニングの効果
Qwen3-8Bをベースに、上位モデルの実行ログを用いて微調整を行った結果、RLMとしての「戦略（いつ分割し、いつサブモデルを呼ぶか）」を学習させることに成功しました。特筆すべきは、学習時とは無関係なドメインでも性能が向上した点であり、推論の手続き自体が汎用的な能力として定着することを示唆しています。
4.3 コストと実行時間
現状の課題として、処理が逐次的であるため実行時間が長くなる傾向があります。一方で、経済性の面では、コード（正規表現など）を用いて必要な箇所だけをピンポイントで閲覧するため、単純な要約エージェントよりも安価に済むケースも見られます。
5. 考察
5.1 Context Rot（コンテキスト劣化）の克服
ベースモデル（GPT-5）は、たとえプロンプトが物理的なコンテキスト窓の内側に収まっていたとしても、タスクが複雑化するにつれて精度が急落するという課題がありました。これに対しRLMは、入力を外部環境化し、実行コードを通じて「計算を局所化」することで、この劣化を効果的に抑制することに成功しました。
5.2 情報の密度と複雑性への耐性
全データのペアを精査する必要がある「二次複雑性タスク（OOLONG-Pairs）」において、ベースモデルが0.1%と壊滅的な結果に終わる中、RLMは58.0%という高いスコアを達成しました。この差は、複雑な情報の処理において「一度の出力（One-shot）」で解決を図るのではなく、「プログラムによる反復的な検証」プロセスを介することが不可欠であることを示唆しています。
5.3 選択的閲覧によるコスト最適化
RLMが、従来の要約エージェントよりも低コストで動作するケースがある点も注目に値します。これは、モデルがPythonコード（正規表現やスライスなど）を駆使し、膨大なコンテキストの中から「必要な箇所だけをピンポイントで閲覧する（Selectively view context）」能力を持っているためです。無差別な情報の読み込みを避け、探索を最適化した結果といえます。
6. 所感
6.1 エージェントへの活用可能性
ベクトル検索だけでなく、RLMというツールをエージェントに与えることで、探索や回答手法の幅が広がりそうだと感じました。
特に、特定のキーワードがある場所を探すようなケースでは、ベクトル検索を用いたRAGよりも有効な場面があると考えられます。
6.2 セキュリティ上の懸念
AIに書かせたコードをユーザーの確認なく実行するため、セキュリティ面での考慮が必要だと感じました。
特に、公開されているコードにはファイルを open する処理も含まれているため、RLMがさまざまなファイルを読み込んでしまう可能性があります。
RLMにどこまで許可するかを見極めたうえで活用していくことが重要そうです。
We’re Hiring!
燈株式会社（Akari Inc.）では、お客様へのAIソリューション提供だけでなく、社内の開発プロセスでもAI活用を積極的に進めています。 論文を読みながら新しい技術をキャッチアップし、実際の開発につなげていくことに興味のあるAIエンジニアを募集しています！ 興味がある方は、ぜひカジュアル面談でお話しましょう！🔥
