ExpeRepairチーム 寄稿
量子位 | 公式アカウント QbitAI
AIが人間のようにバグを修正するようになりました！
「このバグ、先週修正したばかりなのに」「またこのエラーが出た」「新人がまた同じ場所でつまずいている」……
もしあなたがプログラマーなら、このようなイライラする状況によく遭遇しませんか？
既存のAI修復ツールは「金魚」のように7秒の記憶しかなく、問題に遭遇するたびにゼロからやり直します。人間のエンジニア最大の強みは、まさに過去の経験から迅速に解決策を見つけ出す能力です。
そして今、この強みをAIが習得しました：
ExpeRepair——「二重記憶」を持つリポジトリレベルの欠陥修正システムで、人間の認知の2つの記憶モードをシミュレートします。
- エピソード記憶：過去の修正事例を保存します（例：「Sympyプロジェクトのセキュリティ脆弱性を具体的に修正する方法」）
- 意味記憶：高次の修正戦略を精錬します（例：「リソースリークを処理する際には、ファイルとハンドルの両方を同時に閉じる必要がある」）
新しい問題に遭遇すると、ExpeRepairは両方の記憶を同時に呼び起こします：エピソード記憶から類似の事例を参照として取得し、意味記憶から一般的な戦略を抽出して意思決定を導き、オーダーメイドの修正案を動的に生成します。
権威ある評価指標SWE-Bench Liteで、ExpeRepairは60.33%の修正率でトップに立ちました：
この研究は中国科学院ソフトウェア研究所のチームによって提案されました。以下に詳細を説明します。
ExpeRepairの「最強の頭脳」を解明
1. 二重記憶システム：人間のように学習する
ExpeRepairは人間の脳の2つの記憶モードをシミュレートします：
1) エピソード記憶：
具体的な修正事例を記録し、完全な修正軌跡（問題記述、テストスクリプト、修正コード、検証結果）を保存します。成功例と失敗例の両方を含み、正負両面から経験を形成します。
2) 意味記憶：
抽象的な修正戦略を精錬し、LLMを通じて高次の経験を自動的に要約します。例えば、「ファイル操作を処理する際には、権限チェックとリソース解放の両方を同時に考慮する必要がある」などです。
2. 動的知識更新：使えば使うほど賢くなる
記憶システムは継続的に進化します：
1) 追加：新しい問題パターンを発見した際に新たな経験を追加します。
2) 結合：類似する経験の表現を最適化します。
3) 淘汰：古くなった経験や矛盾する経験を削除します。
同時に、記憶ライブラリを洗練された状態に保ちます（15の主要戦略を超えない）。
3. スマート検索：歴史的経験を正確にマッチング
新しい問題に遭遇すると、ベテランエンジニアのように歴史的解決策を「参考に」します：
1) BM25アルゴリズムを通じて類似する歴史的問題を迅速にマッチングします。
2) 最も関連性の高い上位3つの修正事例を抽出します。
3) 抽象的な戦略と組み合わせて動的なヒントを生成します。
ExpeRepair修正プロセスの分解
ExpeRepairは、複雑な自動プログラム修正問題を3つのタスクに分解します：テスト生成、パッチ生成、そしてパッチ検証です。
テストエージェントとパッチエージェントという2つのエージェントを採用し、これらのタスクを協調して処理します。これは、人間の開発者がソフトウェアの問題を分類し解決する方法と似ています。
テスト生成
再現テストは、問題の存在を証明し、候補パッチの正確性を検証するために極めて重要です。
既存の方法は通常、問題記述のみに基づいて再現テストスクリプトを生成しますが、これには2つの主な制約があります：
（1）依存関係、設定、または特定の環境設定の欠落により、実行が頻繁に失敗すること；
（2）問題再現が不十分であること。これは、このようなスクリプトが問題記述内の症状に狭く焦点を当てる傾向があり、より広範な障害の背景を捉えていないためです。
ExpeRepairは、テストエージェントが動的なフィードバックと過去の修正軌跡から蓄積された記憶に基づいて、再現テストを反復的に生成および最適化できるようにすることで、これらの制約を解決します。
具体的には、エージェントはまずエピソード記憶から最も関連性の高いデモンストレーション事例を検索します。これにより、制約（1）が直接解決されます。現在のテスト実行で失敗（例えば、ライブラリの不足や設定エラー）が発生した場合、同じまたは類似の失敗に関連するデモンストレーション事例は、過去にこれらの失敗を成功裏に処理した具体的な例を提供します。次に、エージェントは意味記憶からすべての要約的な自然言語の洞察を抽出します。これらの洞察は、以前の修正から精錬された汎用性の高い高レベル戦略を捉えています。例えば、「セキュリティに敏感な機能をテストする際には、悪意のある入力、エッジケース、潜在的な攻撃ベクトルに対する正しい処理を検証するための包括的なテストケースを実装し、堅牢な検証と適切なエラー応答を確保する」などです。これらの洞察は、エージェントの推論を述べられた症状を単に再現するだけではなく、より広範なものに拡張することで、制約（2）の解決に貢献します。
パッチ生成
問題の再現に成功した後、ExpeRepairはパッチ生成プロセスを開始し、既存の機能を保持しつつ障害を解決できる候補修正案を生成します。
パッチを生成する前に、まず問題が発生した場所を特定することが極めて重要です。本ソリューションは階層的な特定戦略を採用しています。まず問題記述とコードベース構造に基づいて疑わしいファイルを特定し、次に特定されたファイル内で具体的な障害コード行を特定します。
以前の研究が指摘しているように、LLMによって生成されたパッチは不完全な場合が多いです。なぜなら、コードベースレベルの問題を修正するには、通常、コードの複数の部分にわたる変更を調整したり、一連の修正操作を実行したりする必要があるからです。
この問題を解決するため、テスト生成プロセスと同様に、ExpeRepairはエピソード記憶と意味記憶を繰り返し呼び出し、これらの記憶を利用してパッチを生成および最適化します。パッチエージェントはテスト生成段階と同じプロセスに従い、関連するデモンストレーション事例を検索し、反省的な洞察を抽出します。
パッチ検証
候補パッチが再現テストに成功した後でも、それがすぐに最終パッチとして採用されるわけではありません。
これは、チームが実証観察を通じて、再現スクリプトが問題記述内の特定の症状に狭く焦点を当てる傾向があり、誤った判断につながる可能性があることを発見したためです。つまり、パッチが限られたテストには合格しても、より広範なシナリオでは失敗する可能性があります。この問題を軽減するため、ExpeRepairはパッチエージェントに、エッジケース処理、回帰リスク、特定の言語のベストプラクティスへの準拠などの問題を解決するために、パッチの改訂と強化を促します。
次に、チームは追加の検証テストを生成することで、再現テストスイートを拡張します。テストエージェントは、境界条件と極端なケースに対するテストを作成するよう求められます。このプロセスにより、報告された表面的な症状のみを解決し、潜在的な欠陥を包括的に処理しない狭く脆弱な修正案が出現するリスクが低減されます。
最終パッチを選択する際、ExpeRepairはまず、すべての候補パッチを再現テストと検証テストを含む拡張テストスイートで実行します。その後、候補パッチとそれに対応するテスト結果は、専門のレビューエージェントに提出されます。このエージェントは、正確性、ベストプラクティスへの準拠などの基準に基づいて最終パッチを選択します。
実証結果
以下に、一部の実験結果を示します。
SWE-Bench Liteにおいて、ExpeRepairはClaude-3.5 Sonnet + o4-miniを使用することで48.3%の修正通過率を達成し、同種のモデルを使用する他の方法を上回りました。
Claude-4 + o4-miniを使用することで、60.3%の修正通過率を達成し、SWE-Bench Liteのトップに位置しています。
実験はまた、エピソード記憶または意味記憶のいずれかを削除すると、パフォーマンスが著しく低下することを示しました。