この論文は 自動プログラム修復 の分野に位置づけられる。論文によれば、現在の最先端は、1 回限りの対話で LLM を用いる手法か、ハードコードされたフィードバックループで反復的に用いる手法が占めている。後者に対する論文の批判は、固定されたループではモデルがプロンプトで与えられたコードコンテキストしか得られず、バグについての情報を集めることも、修正の材料となりうるコードを探すこともできない、というものである。これは、バグの理解、役立つコードの探索、修正候補の試行を行き来する人間の開発者とは異なる。RepairAgent はそうではなく、LLM をツールの呼び出しによって行動を計画・実行する自律的なエージェントとして扱う。著者らは、知る限りこれがプログラム修復のための初の自律的な LLM ベースのエージェントであると述べている。
このアプローチは 3 つの構成要素からなる。LLM エージェント（評価では GPT-3.5）は、サイクルごとに 1 回、動的なプロンプトで問い合わせを受ける。このプロンプトの静的なセクションは役割、目標、ガイドライン（繰り返し現れる修正パターンの一覧を含む）を示し、動的なセクションは現在の状態、利用可能なツール、それまでに集めた情報、直前のコマンドの結果を保持する。14 個のツールは、コードの読み取りと抽出、コードベースの検索と別の LLM 呼び出しによるメソッド本体の生成、テストの実行と障害箇所の特定（fault localization）、修正の書き込み、そして仮説の表明や破棄を行う制御コマンドをカバーする。ミドルウェアは LLM の出力を解析してヒューリスティックに補正し、以前のコマンドとまったく同じ繰り返しを拒否し、ツールを隔離された環境で実行し、プロンプトを更新する。3 つの状態 ── バグを理解する、修正のための情報を集める、修正を試みる ── を持つ有限状態機械は、厳密な順序を強制することなく、ある時点で利用できるツールを制限する。
要点
- Defects4J の全 835 件のバグに適用したところ、RepairAgent は 186 件でもっともらしい修正を、164 件（v1.2 で 74 件、v2.0 で 90 件）で正しい修正を生成した。正しい修正のうち 116 件は開発者による修正と完全に一致し、48 件は意味的に一致していた。
- Defects4J では以前に ChatRepair が 162 件のバグを修正していた。RepairAgent は 3 つのベースライン（ChatRepair、ITER、SelfAPR）のいずれも修正できなかった 39 件のバグを修正しており、特に Defects4J v2（ChatRepair の 48 件に対して 90 件）と、1 行を超える修正を要するバグ（複数行で 46 件、複数ファイルで 3 件の正しい修正）で良好な結果を示した。
- 単純な変更で済むところに複雑な修正を提案することがあり、そのため ChatRepair が修正できる 1 行のバグの一部を取りこぼしている。複数行や複数ファイルのバグでは、必要な箇所の一部しか編集しないことが多い。
- バグ 1 件あたりのコストの中央値は約 27 万トークンで、GPT-3.5 の価格で約 14 米セントであった。所要時間の中央値は 920 秒で、その 99% はツールの実行（主にテスト）に費やされていた。修正できたバグが消費したトークン（2 万 1,000）は、修正できなかったバグ（31 万 5,000）よりはるかに少なかった。
- 100 件のバグを対象としたアブレーションでは、検索ツールを取り除くと正しい修正が半減し（21 件に対して 11 件）、コストはおよそ 2 倍になった。状態機械を取り除くと、エージェントは情報を集めずに修正を提案することが多くなり、集めた情報を 1 サイクルしか保持しないとコマンドを繰り返すようになった。完全な障害箇所の特定の代わりに GZoltar に基づく現実的な障害箇所の特定を用いた場合は、16 件のバグを修正した。
- モデルの訓練データのカットオフ後である 2023 年に修正されたバグから GitBug-Java でサンプリングした 100 件では、13 件を正しく修正した。内訳は、1 行のバグ 19 件のうち 9 件だが、複数行または複数ファイルのバグ 81 件のうちでは 4 件にとどまった。著者らは、RepairAgent は汎化しており、データリークの影響を強くは受けていないと結論づけ、複数行での結果が弱いのは GitBug-Java のバグがより複雑であるためだとしている。
補足
エージェントはバグ 1 件あたり平均 35 回ツールを呼び出す。最も頻繁なのは write_fix で、これは提案されたパッチの変種を最大 30 個サンプリングし、テストが失敗した場合は変更を元に戻す。著者らは妥当性への脅威として、GPT-3.5 の訓練データからのデータリークの可能性、Defects4J ではバグごとに少なくとも 1 つの失敗するテストケースが保証されていること、障害箇所の特定の精度、LLM の非決定性を挙げ、今後の課題として部分的な修正をヒューマン・イン・ザ・ループで活用することを提案している。実装は AutoGPT フレームワーク上に構築されている。著者らは、論文の初期版が公開された後に、ソフトウェアエンジニアリングのタスクを対象とする他の LLM ベースのエージェントが提案されたことにも触れている。