One Tool Is Enough: Reinforcement Learning for Repository-Level LLM Agents

技術的サマリー：1 つのツールで十分：リポジトリレベルのコードナビゲーションのための LLM エージェントの強化学習

問題定義
大規模なソフトウェアリポジトリ内で修正が必要な特定のファイルや関数を特定することは、コードの膨大な量と構造的な複雑さにより、重大な課題です。既存の大規模言語モデル（LLM）エージェントは、通常これをリポジトリレベルの検索タスクとして扱い、複数の補助ツール（例：SearchClass、SearchMethods、GetImports）に依存しています。著者らは、これらのマルチツールパイプラインが主に 2 つの問題に苦しんでいると主張しています。

1. 実行ロジックとの不一致: クラスや継承といった高レベルの抽象化は、コンパイル後にしばしば消滅しますが、実際のコード実行はシーケンシャルなジャンプとシンボルの解決に依存しています。既存のツールは、この実行フローを反映することに失敗することが多いです。
2. 複雑性と誤差の伝播: 複数のツールの管理はモデルの制御を複雑にします。ツールの定義空間が無制限であるため、事前学習済みモデルは、広範なポストトレーニングなしに多数のツールのセマンティクスを内部化することが難しく、フォーマットエラーやパラメータ解析の失敗を招きます。さらに、Docker ベースのパッチ評価が必要となるため、完全な問題解決のためのエンドツーエンドトレーニングは計算コストが高すぎます。

手法：RepoNavigator
本論文は、これらの課題に minimalist な設計と強化学習（RL）によって対処する、リポジトリレベルの問題特定を目的とした LLM エージェント RepoNavigator を提案します。

• 統合されたツール設計（Jump）: 一連の検索ツールの代わりに、RepoNavigator は構造的に根ざした単一のツール Jump を利用します。このツールは、言語サーバー（Python の場合は Pyright など）を介して実装され、呼び出されたシンボルの正確な定義を解決します。これは、現代の IDE が提供する実行を考慮したナビゲーションを抽象化し、エージェントがシンボルの定義を追跡してコードベースを移動できるようにします（例：関数呼び出しからその定義へ、さらにその依存関係へ）。
• エージェントアーキテクチャ: エージェントは reason → act → observe ループで動作します。各ステップで、ポリシーは自然言語による推論を生成するか、特定のシンボルとファイルパスを指定して Jump ツールを呼び出すかを決定します。ツールは定義コードスニペットを返し、これが次の推論ステップの観測となります。
• 強化学習によるトレーニング: RepoNavigator は、Group Relative Policy Optimization (GRPO) を使用して、ベースの事前学習済みモデルから直接エンドツーエンドでトレーニングされます。
  • 蒸留なし: 閉鎖ソースモデル（Claude や GPT など）からの軌跡を教師あり微調整（SFT）で蒸留する先行研究（RepoSearcher、LocAgent など）とは異なり、この手法は「教師」モデルを必要としません。
  • ハイブリッド報酬関数: 報酬 $R$ は 2 つのコンポーネントを組み合わせます。
    1. 結果報酬: 予測されたコード位置のセットと正解との間の Dice 係数で測定されます。
    2. ツール報酬: ツール呼び出しの成功率（フォーマットの正確性とシンボルの存在）に基づきます。
  • 目的: エージェントは、単一のツールの使用を習得しながら、正しいファイルと関数を特定するための長期的な軌跡を最適化することを学びます。

主な貢献

1. 事前学習モデルから強化学習でトレーニングされた初の特定エージェント: 著者らは、閉鎖ソースモデルからの蒸留への依存を排除し、事前学習されたオープンソースモデルから直接 RL を使用してトレーニングされた、初のリポジトリレベルの特定エージェントを提示します。
2. 実行を考慮した単一ツールパラダイム: この設計は、シンボル解決という実際のコード実行セマンティクスと整合する統合された Jump ツールを導入し、以前のマルチツールエージェントの断片的で高レベルな抽象化と対照をなします。
3. 効率性とスケーラビリティ: 本論文は、複雑なマルチツールパイプラインと比較して、単一の強力なツールが効率性と制御性を大幅に向上させ、計算オーバーヘッドを削減しながら最先端のパフォーマンスを実現することを示しています。

実験結果
実験は、Qwen2.5 モデル（7B、14B、32B）をベースラインとして、SWE-bench Verified および SWE-bench Pro（Python サブセット）で行われました。

• パフォーマンス: RepoNavigator は、関数レベルおよびファイルレベルの両方の特定指標（Sample-F1 および IoU）において、最先端（SOTA）のパフォーマンスを達成します。
  • 7B モデルは、14B ベースラインを上回ります。
  • 14B モデルは、32B の競合他社を上回ります。
  • 32B モデルは、ほとんどの指標において閉鎖ソースモデル（例：GPT-5、Claude 3.7 Sonnet）を上回ります。
• トレーニング効率: RL でトレーニングされたエージェントは、ウォームアップに強力な教師モデルを使用しないにもかかわらず、トレーニングフリーのベースラインや蒸留ベースの手法（RepoSearcher など）よりも優れたパフォーマンスを発揮します。
• ダウンストリームへの影響: Agentless の特定モジュールを置換して、ダウンストリームでのパッチ生成のための問題を特定するために使用された場合、RepoNavigator は最終的な問題解決率を向上させます。
• アブレーション研究:
  • 報酬メカニズム: ハイブリッド報酬（結果＋ツールの成功）は重要です。ツールの成功率を削除するとパフォーマンスが低下します。
  • SFT と RL: 事前学習モデルからの直接 RL トレーニングは、SFT を経てから RL を行うパイプラインよりも良い結果をもたらします。これは、SFT による「コールドスタート」の必要性に疑問を投げかけます。
  • ツールの数: Jump ツールにさらに多くのツール（例：GetClass、GetFunc）を追加すると、実際にはパフォーマンスが低下し、より少ない能力の高いツールの方が望ましいことが確認されました。

意義と主張
本論文は、構造的に根ざした単一のツールを RL トレーニングと統合することが、リポジトリレベルの問題特定に対する効率的でスケーラブルな解決策を提供すると主張しています。コード実行の実際のフローを反映し、ツール操作を簡素化することで、RepoNavigator はツールの連鎖の脆さと行動空間の複雑さを軽減します。その結果は、ソフトウェアエンジニアリングにおける長期的な推論タスクにおいては、ツール多様性の広さよりも、単一の堅牢なツールを通じた実行を考慮した探索の深さの方が重要であることを示唆しています。このアプローチは、蒸留のための閉鎖ソース教師モデルへの依存を排除することで、高性能エージェントへのアクセスを民主化します。