Alibaba LingmaAgent：包括的なリポジトリ探索による自動イシュー解決の改善

この論文は、実際のコードリポジトリにおけるイシューを解決するための自動ソフトウェアエンジニアリング手法 LingmaAgent を提示している。LingmaAgent は、Alibaba Cloud が開発した IDE ベースのコーディングアシスタント TONGYI Lingma に導入されている。Alibaba Group の Tongyi Lab に所属する著者らは、それまでの LLM ベースの エージェントは局所的なコード情報に焦点を当てていたため、グローバルなコンテキストや関数・クラス間の相互 依存関係を把握できていなかったと論じる。彼らの立場は、リポジトリ全体を包括的に理解することこそが自動 ソフトウェアエンジニアリングへの最も重要な道筋だというものである。ここで扱うバージョン（v2、2025 年 3 月 26 日付）は FSE ‘25 の併設プロシーディングスに掲載されている。

手法は 3 つの段階で動作する。まず、リポジトリのナレッジグラフをトップダウンで構築する。各ファイルを 抽象構文木で解析してファイル・クラス・関数の階層的な木にし、そこに関数呼び出し関係を表す有向エッジを 加える。エッジは意図的に関数に限定されており、著者らは関数をプログラム実行の基本単位と呼んでいる。次に、 そのグラフをモンテカルロ木探索で探索する。イシューとの BM25 による関連度で展開を誘導し、文脈内の例と chain-of-thought を与えたプロンプトで LLM に到達した各ノードの関連度を採点させ、高得点のノードから呼び出し 関係に沿って展開する。最後に、要約エージェントが見つかった内容をリポジトリレベルの「経験」と計画へと凝縮 し、エージェントは AutoCodeRover から採用した検索 API を通じてさらにコードを取得した うえで、障害箇所を特定してパッチを生成する。

主なポイント

• SWE-Bench の Lite サブセット（300 インスタンス）において、GPT-4 Turbo を用いた LingmaAgent は イシューの 21.33% を解決した。論文の比較条件では SWE-Agent が 18.00%、 AutoCodeRover が 16.11% であり、著者らはこれを SWE-agent に対する 18.5% の相対的な改善と報告している。
• LingmaAgent が解決したケースは SWE-agent のものと部分的にしか重ならない。SWE-agent 流の実行フィード バック（再現、修正、再実行）を LingmaAgent に加えると、GPT-4 での解決率は 27.7% に上がり、著者らはこれを 2 つのアプローチが相補的であることの表れと解釈している。
• 同じパイプラインに Claude 3.5 Sonnet（v1022）と実行フィードバックを組み合わせると、SWE-bench Lite の 38.33% を解決した。これは論文で試したモデルの中で最も高い。
• アブレーションはいずれも解決率を下げた。呼び出しグラフを除くと 19.67%、要約エージェントを除くと 17.67%、木探索と要約の両方を除くと 16.00% になった。
• レビューに通らなかったパッチを再生成させる LLM ベースの静的レビューエージェントを加えることも、解決率を 18.33% へと下げた。著者らは、静的レビューが表層的な文法情報に頼っており、論理的な誤りを見逃すため ではないかと推測している。
• 障害箇所の特定は、関数レベル（49.3%）とファイルレベル（67.7%）の両方で、どちらのエージェントの ベースラインよりも正確だった。
• 木探索の反復回数を増やすと解決率は上がったが、その効果は逓減し、200〜600 回の間ではパッチの適用率が 低下した。
• Java、JavaScript、TypeScript のリポジトリにまたがる 194 件のイシューからなる Alibaba Cloud の社内データ セットでは、LingmaAgent は完全自動で 16.9% を解決した。エンジニアが計画、検索呼び出し、障害箇所の特定を 調整できる（介入は 5 回未満）ランダムな 30 件のサブセットでは、解決率が 16.7% から 43.3% に上がった ── ただし 30 件での結果である。
• Python のプロトタイプが RepoUnderstander としてオープンソース化された。

補足

著者らは 2 つの限界を挙げている。1 つは木探索がリソースを消費することである（彼らは 600 回の反復と 300 秒の制限を設定したが、彼らのテストでは 50 回の反復でもすでに他のエージェントを上回っていた）。もう 1 つは、評価が主に SWE-bench Lite に依拠しており、ヒューマン・イン・ザ・ループの評価は範囲が限られ、 使用したモデルが学習時にテスト対象リポジトリの一部を見ていた可能性があることである。今後の課題として、 動的で継続的に更新される SWE-bench を提案している。

この論文は ソフトウェアイシュー解決 の領域に位置づけられる。ナレッジグラフの構築は リポジトリの前処理の一形態であり、木探索は障害箇所特定の戦略である。また、自らが依拠する SWE-agent と AutoCodeRover のエージェントと直接比較している。