SWE-Pruner: Self-Adaptive Context Pruning for Coding Agents

以下は、論文「SWE-Pruner: Self-Adaptive Context Pruning for Coding Agents」の詳細な技術的サマリーです。

1. 問題定義

大規模言語モデル（LLM）エージェントは、コード理解から自律的なパッチ生成まで、ソフトウェアエンジニアリングタスクにおいて顕著な可能性を示しています。しかし、その有効性は「コンテキストの壁」によって深刻に阻害されています。

• トークンの蓄積: 現実世界のソフトウェアリポジトリは膨大です。これらのリポジトリをナビゲートするエージェントは、長い対話履歴や生のファイル内容を蓄積し、長いコンテキストを持つモデルであっても、すぐにコンテキストウィンドウを枯渇させてしまいます。
• コストと遅延: 大量のコードを盲目的に取り込むことは、莫大な API コストと高い推論遅延をもたらします。
• 注意の希薄化: 過剰なコンテキストはノイズを導入し、「注意の希薄化」と幻覚を引き起こし、モデルが重要な実装詳細への焦点を失う原因となります。
• 既存の解決策の限界: 現在のコンテキスト圧縮手法（例：LongLLMLingua、Selective-Context）は、Perplexity（PPL）や自己情報量などの静的な指標に依存しています。これらの手法はタスク非依存であり、しばしばトークンレベルで動作するため、コードの構文論的および論理的構造を破壊し、デバッグやコンパイルに使用できない状態にします。これらは、マルチターンエージェント対話の動的で変化する目標に適応できません。

2. 手法：SWE-Pruner

著者らは、コーディングエージェント向けに特別に設計された自己適応型コンテキスト剪定フレームワークであるSWE-Prunerを提案します。これはエージェントと環境の間にミドルウェアとして機能し、ファイル読み込みコマンド（例：cat、grep）を傍受し、LLM に到達する前に生コンテキストをフィルタリングします。

中核コンポーネント

1. ゴールヒント生成:

   • 静的な圧縮の代わりに、エージェントは現在の情報ニーズの自然言語記述であるゴールヒントを生成するよう指示されます（例：「Auth モジュールのエラー処理ロジックに焦点を当てる」）。
   • このヒントは、剪定システムへのオプションパラメータ（context_focus_question）として渡され、タスク認識型のフィルタリングを可能にします。

2. 軽量ニューラルスキマー:

   • アーキテクチャ: Qwen3-Reranker-0.6B に基づく 0.6B パラメータのモデルです。低遅延と高効率のために設計されています。
   • メカニズム: スキマーは、コンテキスト剪定をリランキング問題として扱います。クエリ（ゴールヒント）とコンテキスト（生のファイル内容）が与えられ、関連性スコアを計算します。
   • 行レベルの粒度: トークンレベルの剪定とは異なり、SWE-Pruner はトークンスコアを行レベルに集約します。これにより、関数定義やクラスブロックなどの構文構造がそのまま保持され、コードの破損が防止されます。
   • トレーニング目的: このモデルは、「保持」と「剪定」の決定間の逐次的依存関係をモデル化するために**条件付きランダム場（CRF）**損失を用いてトレーニングされ、一貫した行レベルの保持を確保します。また、グローバルな関連性を維持するためのドキュメントレベルのリランキングヘッドも含まれています。

3. トレーニングデータ構築:

   • コーディングエージェント向けの行レベル関連性注釈付きデータセットが存在しないため、著者らはティーチャースチューデントパラダイムを用いて61K サンプルのポリグロットコーパスを構築しました。
   • ティーチャ LLM（Qwen3-Coder-30B）は、GitHub リポジトリからタスク指向クエリと行レベルの保持マスクを合成し、9 つの異なるエージェントタスク（デバッグ、リファクタリング、機能追加など）を網羅しました。
   • 「LLM-as-a-Judge」メカニズムにより、高品質な注釈を確保するためにデータをフィルタリングしました。

4. 統合ワークフロー:

   • このフレームワークは、エージェントループ（例：Mini SWE Agent、OpenHands）に統合されます。エージェントがファイルを読み取ると、生出力はゴールヒントと共にスキマーに送信されます。スキマーは関連する行のみを含む剪定済みコンテキストを返し、エージェントがそれを処理します。

3. 主要な貢献

• タスク認識型剪定フレームワーク: エージェントの特定の推論目標に基づいてコンテキスト圧縮を動的に適応させる新たなアプローチを導入し、静的でコンテンツのみの圧縮を超えました。
• 行レベルの構文構造保持: 構文の妥当性と論理的構造を保持する行レベルで動作する軽量ニューラルスキマーを設計しました。これはコードの正確性にとって不可欠です。
• 効率的なアーキテクチャ: 0.6B パラメータのモデルを開発し、大幅なトークン削減を達成しながらも、無視できる遅延（<100ms）しか追加せず、リアルタイムのエージェントワークフローで実用的にしました。
• 合成データパイプライン: コード剪定のための高品質な行レベル教師ありデータを生成するための厳密なパイプラインを作成し、この分野における重要なデータギャップを解消しました。

4. 実験結果

著者らは、SWE-Pruner を 4 つのベンチマークで評価しました。SWE-Bench Verified と SWE-QA（マルチターンエージェントタスク）、および Long Code Completion と Long Code QA（シングルターンタスク）です。

• マルチターンエージェントタスク（SWE-Bench Verified）:

  • トークン削減: 総トークン消費量を23〜38% 削減しました。
  • 成功率: 驚くべきことに、成功率は 1.2〜1.4 ポイント向上しました（例：Claude Sonnet 4.5 では 70.6% から 72.0% に）。
  • 効率性: 対話ラウンドを18〜26% 削減し、集中したコンテキストによりエージェントがより決断的な意思決定を行うことを示しています。
  • コスト: API コストの大幅な削減（最大で約 36% の節約）を実現しました。

• シングルターンタスク（Long Code QA/Completion）:

  • 圧縮率: 厳格な制約下で Long Code QA において最大14.84 倍の圧縮を達成し、LLMLingua2 や RAG などのベースラインを大きく上回りました。
  • 性能: 完全なコンテキストと比較して精度を維持またはわずかに向上させました（例：14.84 倍の圧縮で 58.71% の精度）。一方、トークンレベルのベースラインは高圧縮下で深刻な性能低下を被りました。

• 効率性と遅延:

  • 0.6B スキマーは最小限のオーバーヘッド（最初のトークン遅延 <100ms）を追加するのみで、下流の LLM 復号コストの大幅な削減によって相殺されます。
  • AST 正しさ: SWE-Pruner は87.3% の AST 正しさ（構文的妥当性）を維持し、トークンレベルの手法（0% 近くまたは 13% 未満に低下）を大幅に上回りました。

5. 意義

• コンテキストの壁の解決: SWE-Pruner は、コーディングエージェントのコンテキストウィンドウの制限に対するスケーラブルな解決策を提供し、莫大なコストをかけたり焦点を失ったりすることなく、大規模で複雑なコードベースをナビゲートできるようにします。
• パラダイムシフト: コンテキスト管理を静的な圧縮から動的で目標駆動型の選択へと移行させ、人間の開発者が特定のデバッグや機能の目標に基づいてコードを「スキミング」する方法を模倣します。
• 実用性: このフレームワークは軽量で、モデル非依存（Claude、GLM、Qwen などと動作）であり、ミドルウェアとしてシームレスに統合されるため、既存のエージェントインフラストラクチャに即座に適用可能です。
• 量より質: 結果は、保持されたコンテキストが構造的に完全で、現在のタスクに関連する意味論的である場合、より少ないコンテキストの方がコーディングエージェントにとってしばしば優れていることを示しています。これは、長コンテキスト LLM 研究における支配的な「より多くのコンテキストの方が良い」という仮説に挑戦するものです。