技術要約: SWE-Pruner Pro

問題提起

マルチターン環境で動作するコーディングエージェントは、コードベースとのやり取りの中で、膨大なツール出力（例：cat, grep, ls, python の実行ログ）を蓄積します。これらの出力はしばしば著しい冗長性を伴い、1回のアクション（trajectory）あたりのトークン予算の大部分を消費し、ロングコンテキストによる性能劣化を引き起こします。既存のコンテキスト・プルーニング（文脈削減）ソリューションには、以下の2つのカテゴリがあります：

1. 汎用的な圧縮: LLMLingua2 や Selective Context のような手法は、固定された指標（例：パープレキシティ、構文構造）に基づいてトークンをスコアリングします。これらは、エージェントの進化するタスクへの焦点に適応することができません。
2. タスク特化型のプルーニング: 先行研究である SWE-Pruner は、エージェントの意図（intent）に基づいてプルーニングを条件付けますが、外部のスコアリングモデルと、エージェントが毎ターン生成しなければならない明示的な「ゴールヒント（goal-hint）」クエリを必要とします。これは追加のオーバーヘッドとレイテンシを導入します。

両方のアプローチは、プルーニングの信号を「外部から再構成されるべき量」として扱っていますが、これはエージェントのバックボーンモデルがすでにツールの出力を処理しており、その内部表現の中に、おそらく関連性の情報が既にエンコードされているという事実を無視しています。

手法: SWE-Pruner Pro

SWE-Pruner Proは、外部のスコアリングモデルや明示的な「ゴールヒント」クエリを必要とせず、エージェントのバックボーンの内部隠れ状態から直接プルーニング信号を読み取ることを提案します。この手法は、エージェントの推論ループ内で直接動作します。

コアメカニズム

1. 内部表現の活用: エージェントがツールのレスポンス（$r_t$）を読み取るとき、凍結されたバックボーンは標準的なプリフィル（prefill）を実行し、各トークンに対して最終層の隠れ状態（$h_i$）を生成します。SWE-Pruner Proは、これら既存の状態に軽量なプルーニング・ヘッドを取り付けます。
2. プルーニング・ヘッドのアーキテクチャ:
   • 長さ認識型埋め込み (Length-Aware Embedding): レスポンスの総行数 $N$ に条件付けられた学習済み埋め込み $e(N)$ が、各隠れ状態にブロードキャスト加算されます。これにより、モデルはレスポンスの長さに応じてプルーニング戦略を調整できます（例：すべての行が重要となる短い出力に対しては、より保守的に判断する）。
   • 非線形分類器: 小規模なフィードフォワードネットワーク（LayerNorm + 2つのLinear-GELU-Dropoutブロック）が、拡張された隠れ状態を「保持または削除（keep-or-prune）」のロジットへとマッピングします。この非線形性は、線形プロービング実験で観察された表現空間における重複を解決するために必要です。
   • 決定の集約: 各行内のトークンレベルのロジットは、多数決によって集約され、行全体のバイナリな保持/削除決定を生成します。
3. 学習戦略:
   • データ: ヘッドは、Claude Sonnet 4.6 によって行単位の保持/削除ラベルが付与された22,609件のマルチターン・トラジェトリを用いて学習されます。
   • 損失関数: 著者らは、サンプルごとのバランス調整済みフォーカルロス (per-sample balanced focal loss) を採用しています。グローバルにバランスを取る標準的なフォーカルロスとは異なり、この手法は各サンプル内において「保持（keep）」と「削除（prune）」のトークンに対して個別に損失を計算し、それらを等しい重みで平均化します。これにより、極端な保持率を持つサンプル（例：わずか3%の行のみを保持する場合）が目的関数に等しく寄与することを保証し、モデルが平均的な保持率（約30%）に過学習するのを防ぎます。
4. 推論への統合: このヘッドは、プリフィルフェーズ中に「インサーバー（in-server）」で動作します。これはツールのレスポンスのために生成された隠れ状態を再利用するため、小さなヘッドの単一のフォワードパスを追加するだけで済みます。プルーニングされたレスポンス（$\tilde{r}_t$）は、次のターンのコンテキスト内の生のレスポンスと置き換わりますが、現在のターンの生成自体は依然として生のレスポンス全体に注意（attend）を払います。

主要な貢献

1. 信号の発見: 本論文は、エージェントのバックボーンの内部表現が、ツールの出力に関する行レベルの重要性を既にエンコードしていることを示しています。単純な線形プローブがAUC 0.83を達成したことは、外部からの再構成なしに「保持か削除か」の信号が存在することを証明しています。
2. アーキテクチャ: 長さ認識型埋め込みとサンプルごとのバランス調整済みフォーカルロスを利用して、凍結されたバックボーンから直接精密なプルーニング決定を下す軽量なヘッド、SWE-Pruner Proを導入しました。
3. 効率性: 追加のモデル呼び出しや明示的なゴールヒント・クエリを回避することで、限定的な推論オーバーヘッドで大幅なトークン削減を実現します。

実験結果

本手法は、2つのオープンウェイト・バックボーン（MiMo-V2-Flash および Qwen3-Coder-Next）を用い、4つのマルチターン・ベンチマーク（SWE-Bench Verified, SWE-QA, SWE-QA-Pro, Oolong）で評価されました。

• トークン節約: SWE-Pruner Proは、評価された7つの手法の中で、あらゆる設定においてエンドツーエンドのトークン使用量を削減できた唯一の手法です。
  • SWE-QA-Pro (Qwen3-Coder-Next) において、最大 39% の削減を達成。
  • ロングコンテキストの Oolong ベンチマーク (MiMo-V2-Flash) において、30% の削減を達成。
  • 対照的に、他の手法（例：LLMLingua2）は、ロングコンテキスト・タスクにおいてオーバーヘッドによりトークン使用量が最大190%増加することもありました。
• タスク品質:
  • SWE-QA/Pro: プルーニングなしのベースラインの狭い範囲内にタスク品質を維持しています（例：SWE-QAで+0.02のスコア変化）。
  • Oolong: MiMo-V2-Flashにおいて、精度を +2.2 ポイント向上させました。
  • SWE-Bench Verified: MiMo-V2-Flashでは、未プルーニングのベースラインと比較して、解決率を +3.8% 向上させつつ、入力トークンを7.4%削減しました。Qwen3-Coder-Nextでは、最大の入力トークン削減（-13.5%）を達成しつつ、解決率の低下を最小限（-1.2%）に抑えました。
• レイテンシ: インサーバー・ヘッドは、総生成時間に約 15.0% の累積ウォールタイム（実時間）を加算しますが、このコストは後続のターンにおけるコンテキストサイズの縮小によって相殺されます。

意義と主張

本論文は、コンテキスト・プルーニングに求められる「関連性の判断」は、追加のクエリやモデルを通じて引き出されるべき外部信号ではなく、バックボーンが観測を受動的に読み取っている間に形成される内部表現の中に既に存在しているものであると主張しています。

• パラダイムシフト: エージェントの「周囲」にプルーニングを構築する（外部モデルや明示的なクエリを必要とする）のではなく、SWE-Pruner Proは、エージェントが既に形成している信号を単に「読み取る」のです。
• 実用的影響: このアプローチは、従来の研究で見られた「品質と圧縮のトレードオフ」を解決します。これにより、タスクのパフォーマンスを低下させることなく（場合によっては、ロングコンテキストによる性能劣化を軽減することで、むしろ向上させることで）、積極的なプルーニング（最大39%のトークン節約）を可能にします。
• 汎用性: Python中心のコーディングタスクで評価されていますが、パイプラインは言語に依存せず、自然言語のロングコンテキスト・タスク（Oolong）においてもトークン節約と品質の維持が示されており、このパラダイムがドメインを越えて転移可能であることを示唆しています。

著者らは、コーディングエージェントにとって、最も効率的なコンテキスト管理への道は、バックボーン自身の内部状態を活用することであり、それによって外部のスコアリングメカニズムに伴うレイテンシと複雑さを回避することであると結論付けています。