💻 computer science

BLAgent: Agentic RAG for File-Level Bug Localization

BLAgent は、コード構造を考慮したエンコーディング、二重の視点からのクエリ変換、および二段階のエージェント型再ランク付けを通じてファイルレベルのバグ局在化を強化する新規のエージェント型検索拡張生成フレームワークであり、SWE-bench Lite において最先端の精度を達成するとともに、コストを大幅に削減し、下流の自動プログラム修正の成功率を向上させる。

原著者： Md Afif Al Mamun, Gias Uddin

公開日 2026-05-19

📖 1 分で読めます☕ さくっと読める

CC BY 4.0

原著者： Md Afif Al Mamun, Gias Uddin

原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 ✨ これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。免責事項の全文を読む

ここでは、BLAgent論文の説明を、比喩を用いたシンプルで日常的な言葉で翻訳します。

大きな問題：干し草の山から針を見つけること

あなたが自動車整備士（ソフトウェア開発者）で、壊れた車を修理しようとしている場面を想像してください。お客様から「左に曲がると奇妙な音がする」という苦情が持ち込まれます。

ソフトウェアの世界では、この苦情はバグレポートです。車は数百万行ものコードを含む巨大なコードリポジトリ（干し草）であり、そのノイズの原因となっている特定のコード行が針です。

長らく、これらのバグを修正しようとする AI ツールは、まず針を見つけられないために苦労してきました。AI がエンジンの間違った部分（間違ったファイル）を推測すれば、間違ったものを修理しようとしてしまい、車は相変わらず壊れたままです。これをバグ局所化と呼びます。

解決策：BLAgent（スーパー探偵）

著者たちはBLAgentと呼ばれる新しいシステムを開発しました。これは単に推測するだけでなく、修理を試みる前に修正が必要な正確なファイルを見つけるために、賢明で段階的な調査プロセスを用いるスーパー探偵のようなものです。

BLAgent はAgentic RAG（検索拡張生成）と呼ばれる技術を使用します。平易な英語で言えば、AI が単に「幻覚」のように答えを捏造するのではなく、図書館（コードリポジトリ）に行き、正しい本（コードファイル）を見つけ、それを読み、その上で答えについて考えることを意味します。

BLAgent の仕組みを、3 つの簡単なステップに分解して説明します。

1. 図書館の整理（スマートなチャンキング）

図書館がぐちゃぐちゃになっていると想像してください。本は半分に破られ、ページはランダムに貼り付けられています。「エンジン」についての本を司書に頼んでも、「エンジン」と書かれたページが、実は料理本から取られたものかもしれません。

従来の方法： 従来の AI は、本のページを破るように、コードをランダムなテキストの断片に分割します。
BLAgent の方法： BLAgent は構造的なマップ（AST と呼ばれる）を使用します。「関数」や「クラス」が完全な章のようなものであると理解し、コードをこれらの章の終わりのみで切断します。
秘密の武器： また、すべてのページにファイルパス（本の住所）をスタンプします。バグレポートに特定のフォルダ名が言及されている場合、BLAgent はその住所を瞬時に正しい本と一致させることができます。

2. より良い質問をする（双方向のクエリ）

司書に助けを求めていると想像してください。

悪い質問： 「私の車が壊れています。」（曖昧すぎる）
BLAgent の戦略： 最良の結果を得るために、2 つの異なる質問を投げかけます。
1. 構造的な質問： 「turn_signal 関数を含むファイルはどれですか？」（特定の名称やコード構造を探す）
2. 行動的な質問： 「車が曲がるときにノイズを出す状況を処理しているファイルはどれですか？」（症状や行動を探す）

両方を質問することで、BLAgent は網を広げ、バグレポートの言葉とコードの言葉が異なるだけで正しいファイルを見逃さないようにします。

3. 探偵の調査（エージェントによる再ランク付け）

ここが最も重要な部分です。図書館は BLAgent に、最も可能性の高い本（ファイル）トップ 15 のリストを提供します。しかし、どれが実際に犯人なのでしょうか？

従来の AI： リストの最初の本を選び、それを修理しようとします。
BLAgent（エージェント）： 探偵のように振る舞います。表紙を見るだけでなく、本を開いて、上位候補の骨格（目次と章の見出し）を確認します。
- 自分に問いかけます：「このファイルの構造は事件と一致していますか？」
- 各ファイルにスコア（0 から 10）を割り当てます。
- その後、上位の容疑者については、最終的な証拠に基づく決定を下すために、関連セクションの実際のテキストを読み込みます。

この「限定された推論」は、探偵が図書館全体を検索するのではなく、最も可能性の高い容疑者のみを調査することを意味し、時間とコストを節約します。

なぜこれが重要なのか：修理工場

この論文は、BLAgent をSWE-bench（現実世界のソフトウェアバグのコレクション）という有名なベンチマークでテストしました。

結果： BLAgent は、使用された AI モデルに応じて、**78% から 86%**の確率で修正すべき正しいファイルを見つけました。
比較： 従来の手法は、正しいファイルを見つける頻度が低かったです。
コスト： BLAgent は、従来の最高水準の手法よりも18 倍安価です。従来の手法は図書館を検索するために 100 人のチームを雇うようなものでしたが、BLAgent は地図を持った非常に賢い探偵 1 人を雇うようなものです。

バグ修正への影響：
BLAgent を自動修復システムに接続したところ、そのシステムは以前よりも20% 多くのバグを正常に修正しました。

比喩： 整備士に間違ったエンジン部品を与えれば、車は修理できません。しかし、正しい部品（正確な局所化）を与えれば、修理できます。BLAgent は、整備士が正しい部品を受け取れることを保証します。

論文が言及していないこと

すべてのバグを修正できるとは主張していません。約 14% の場合、正しいファイルが隠れすぎていたり、バグレポートが曖昧すぎたりして、BLAgent でもトップリストから見つけることができませんでした。
すべてのソフトウェアに対する魔法の杖であると主張していません。これはテストされたもののような Python プロジェクトで最もよく機能し、バグレポートの品質に依存します。
ファイルを見つけることが唯一のステップだとは述べていません。ファイルが見つかった後、AI は実際にコードの修正を書かなければならず、それは失敗する可能性があります。しかし、ファイルを見つけることが最大の障壁です。

まとめ

BLAgentは、AI が壊れたコードを見つけるためのより賢い方法です。ランダムに推測するのではなく、コード図書館をより良く整理し、より賢い質問をし、行動を起こす前に証拠を検証する「探偵」のステップを使用します。これにより、ソフトウェアバグの根本原因を見つけることが、はるかに速く、安価で、正確になります。

技術概要：BLAgent ファイルレベルのバグ局所化のためのエージェント型 RAG

問題定義

バグ局所化は、根本原因分析、トリアージ、自動プログラム修復（APR）などのダウンストリームタスクにおいて、ソフトウェア保守における重要なボトルネックのままです。大規模言語モデル（LLM）ベースの修復システムは進展を遂げていますが、その有効性は本質的にファイルレベルの局所化の質によって制約されています。階層的なパイプラインにおいて、不正確なファイル選択は、後の段階（例えば、文レベルの局所化やパッチ生成）に誤りを伝播させ、修復の失敗を引き起こすことがよくあります。

既存のコード向け検索拡張生成（RAG）アプローチは、静的な検索と単純なテキストベースのチャンキングに依存することが多く、コードの構造的な複雑さや正確な故障ファイルの特定に必要な推論を捉えきれていません。さらに、純粋な埋め込みベースの手法は機能的関連性を評価する推論能力に欠け、既存のエージェント型アプローチはしばしば無制限のグラフベースの探索を採用し、許容しがたい計算コストを招いています。

手法：BLAgent フレームワーク

著者らは、ファイルレベルのバグ局所化のために設計された新しいエージェント型 RAG フレームワークであるBLAgentを提案します。このシステムは、精度とコストのバランスを取るために 3 つの中核コンポーネントを統合しています。

1. 経路拡張 AST ベースのチャンキングによるリポジトリ符号化

単純なテキスト分割の代わりに、BLAgent は抽象構文木（AST）の境界（関数、クラス、論理ブロックなど）に基づいてソースファイルを分割するCodeSplitterを採用します。これにより、コード構造の断片化を防ぐ意味的保存が保証されます。

経路拡張: 各コードチャンクには、相対ファイルパス（例：src/utils/math.py）が先頭に付加されます。これにより、バグレポート内のパスのようなシグナル（トレースバック、モジュール参照など）とコードチャンクの間に直接の整合性チャネルが作成され、自然言語記述とコード識別子間の語彙ミスマッチが解決されます。

2. 二重視点クエリ変換

バグレポートとコードの間の意味的ギャップを埋めるために、BLAgent は LLM を用いて各バグレポートを 2 つの補完的なクエリに分解します。

構造的変換（ $T_0$ ）: 静的・構文的側面に焦点を当て、識別子、モジュール、関数名、トレースバックの文脈を抽出します。
振る舞的変換（ $T_1$ ）: 実行時の振る舞いに焦点を当て、観測された症状、期待出力と実際の出力、およびトリガー条件を捉えます。
両方のクエリは、ベクトルデータベースから候補ファイルを検索するために独立して使用されます。得られた候補セットは、重複を除去して統合され、エージェントのために 15 ファイルに制限されたコンパクトなプールを形成します。

3. 2 フェーズ型エージェント再ランク付け

BLAgent は、2 フェーズのプロセスを通じて検索された候補セットに対して有界推論を実行します。

フェーズ 1: スケルトンベースのエージェントスコアリング（SAS）: ReAct ベースのエージェントが、候補ファイルの構造的スケルトン（クラス、関数シグネチャ、ドキュメント文字列）を反復的に検査します。どのファイルの修正が必要かという仮説に基づき、関連性スコア（0〜10）を割り当てます。このフェーズは、完全なソースコード処理を回避することで、コンテキスト制限内で効率的に動作します。
フェーズ 2: 証拠に基づく再ランク付け（EAR）: 同点の解消と実装レベルの関連性の検証を行うため、フェーズ 1 から上位 $M$ （5 に設定）のファイルがワンショット推論を受けます。文脈は、ファイルのグローバル構造と検索器によって強調されたメソッドの完全な実装のみを含むように剪定されます。LLM は、この根拠ある証拠に基づいて最終的なランキングを行います。

主要な貢献

局所化のためのエージェント型 RAG: BLAgent は、検索を反復的かつツール拡張型推論と統合する有界推論フレームワークを導入し、無制限のグラフ探索の高コストを回避します。
AST 認識型・経路拡張チャンキング: 構文境界を保存し、チャンクにファイルパスを付加することが、標準的なテキストベースまたはコード認識型チャンキングと比較して検索の再現率を大幅に向上させることを論文は示しています。
二重視点クエリ: バグレポートを構造的および振る舞的クエリに分解することが、補完的な検索シグナルを提供し、初期候補プールの再現率を向上させることをフレームワークは示しています。
コスト効率の高い設計: 推論をコンパクトで検索でフィルタリングされた候補セットに制限し、コードスケルトンを使用することで、BLAgent はグラフベースのエージェント型ベースラインと比較して、はるかに低いトークン消費量と API コストで高い精度を達成します。

実験結果

このフレームワークは、SWE-bench-Liteデータセット（300 の実世界の Python バグ）で評価されました。

局所化精度:
- オープンソースモデル（GPT-OSS-120B）を使用した場合、BLAgent はTop-1 精度 78.6%、MRR 0.851を達成しました。
- クローズドソースモデル（Claude-4.6-Sonnet）を使用した場合、Top-1 精度 86.7%、MRR 0.900を達成しました。
- これらの結果は、LocAgent（グラフベースのエージェント型アプローチ）やAgentless（局所化機能を備えた APR フレームワーク）を含む最先端のベースラインを、しばしば大幅な差で上回っています。
コスト効率: BLAgent は、同じクローズドソースモデルを使用する場合、最強のベースライン（LocAgent）よりも18 倍以上安価です。300 インスタンスすべてを完了する総コストは約 27 ドルですが、LocAgent は 182 インスタンスのみで 300 ドルの予算を使い果たしました。
自動プログラム修復（APR）への影響: Agentless APR フレームワークに統合された場合、BLAgent はエンドツーエンドの課題解決率を20% 以上（多数決投票により 27.6% から 34.0%）向上させました。
汎用性: このアーキテクチャは、単一のプロンプト変更で関数レベルの局所化に成功裏に拡張され、パイプラインの構造的変更なしに最先端の結果を達成しました。

意義と主張

この論文は、BLAgentが検索とエージェント型推論を効果的に組み合わせることで、ファイルレベルのバグ局所化において新しい最先端を確立したと主張しています。その主な意義は、以下の点を示すことにあります。

局所化が決定的要因である: 正確なファイルレベルの局所化は、エンドツーエンドの自動修復成功において測定可能な向上に直接つながります。
有界推論は無制限探索に優れている: 高品質で検索によりフィルタリングされた候補セットに制約されたエージェント型推論は、精度とコストの両面で複雑なグラフベースのアプローチを上回ります。
検索の質が性能を規定する: エージェント型パイプラインの有効性は、本質的に初期の密検索器の再現率によって制限されるため、チャンキングとクエリ変換の改善が不可欠です。
コスト効果の高いスケーラビリティ: 高性能な局所化は、オープンソースモデルと効率的なコンテキスト管理（スケルトン）を使用して達成可能であり、プロプライエタリモデルやグラフ探索の許容しがたいコストなしに高度なバグ局所化をアクセス可能にします。

著者らは、正確な局所化は必要ですが、完全な修復には十分ではないと結論付けています。なぜなら、ダウンストリームでの失敗（関数/行レベルの局所化とパッチ生成）が依然として重大なボトルネックだからです。しかし、BLAgent は、LLM ベースのソフトウェア保守における上流の局所化課題に対処するための、堅牢でコスト効率の高い基盤を提供します。