CodeGrep、リポジトリ検索を14Bの専用エージェントに分離し、修正成功例のtoken使用量を19%削減

コーディングエージェントのコストは、パッチの生成だけでなく、変更すべきファイルの特定からも生じる。新たな研究では、SWE-bench VerifiedにおけるOpenHands 30Bの軌跡を分析した。成功例1件あたり平均23ターン、63万1,000 tokenを消費しており、その多くがgrep、glob、ファイル読み取りの呼び出しに使われていた。そこで研究チームは、探索段階をCodeGrepとして切り出した。CodeGrepは、GRPOでエンドツーエンド学習された14Bの検索エージェントである。複数ターンにわたり検索ツールを並列操作し、最終的に候補ファイルだけを固定された下流のコーディングエージェントへ渡す。

チームは、6万7,000件のオープンソースのエージェント軌跡から教師信号を抽出し、Git worktreeでタスクを分離する強化学習環境を構築した。SWE-bench Verifiedの全500問において、CodeGrepの修正率は27.0%で、独立した検索器を使用しないベースラインは25.8%だった。修正に成功した事例に限ると、対話ターン数は15%、token使用量は19%減少した。ここでより重要な発見は、1.2ポイントの差ではなく、検索精度に効果が現れる閾値が存在する可能性だ。BM25のファイル精度は0.375で、かえって下流エージェントの性能を低下させた。Jinaは0.445でおおむね同等だったが、CodeGrepは0.677に達して初めてrolloutコストを安定して削減した。

これは、coding-agentアーキテクチャに具体的な分割点を示している。汎用モデルが修正のたびにリポジトリの探索方法を学び直す必要はなく、検索戦略を独立して学習・交換できるコンポーネントにできる。ただし、現時点の結果は、著者が設定した単一のOpenHands 30B下流エージェントから得られたものに限られ、コスト統計も成功例を中心としている。論文ではモデル、学習プロセス、評価ツールの公開を約束しているが、発表時点ではまだダウンロードできない。次の焦点は、この精度の閾値を異なるモデル、言語、大規模monorepoでも再現できるか、そして検索器自体の推論コストがtoken削減効果を相殺しないかどうかだ。