こんにちは。ZENKIGENデータサイエンスチームの川﨑です。所属チームでXアカウントを運用しており、AIに関する情報を発信していますのでご興味あれば覗いてみてください。
論文は以下になります。
概要
一般的な開発において、バグの再現が重要なことは言うまでもないと思います。そして、再現の実現手段として、バグ再現テスト（Bug Reproduction Test）という手法があります。バグ再現テストとは、バグが存在する場合にテストが失敗し、修正後には成功すること（Fail-to-Pass test）で、バグの発生箇所や挙動を明確化し、修正の効果を検証するための自動テストです。BRTがあることで、バグが修正されたことの確認はもちろん、テストの挙動を確認することでバグの根本原因を把握する上でも有用と考えられます。
一方で、実際の開発現場ではお客様の問い合わせなどでバグが発覚することも多く、バグ報告時にBRTが存在しないことも多いです。そのため、バグの修正時の対応工数がかさむことも多いです。
そこで、本研究では、バグ再現テスト（BRT）の自動生成を行うエージェントを提案し、Google社の実際の産業・コードベースを対象にBRTの自動生成の検証をしています。また、Google社はPasserineという自動プログラム修正システムを構築しています。このPasserineと組み合わせることで、バグの自動修正割合が改善するかも検証しています。[1]
手法
ベンチマーク手法(adaption of RIBRO)
図1. LIBROの手法概要。Agentic Bug Reproduction for Effective Automated Program Repair at Googleより引用。
本研究では、ベンチマーク手法「LIBRO」というBRT生成手法を用いています。LIBROは、＜バグ報告テキスト / BRT＞のペアをfew-shotの枠組みで入力することで、バグ報告のテキストからBRTを生成させる手法です。
今回はRIBROで用いるLLMを、BRT Agentと同様にGoogle社の内部コード等を用いてファインチューニングしたGeminiモデルに置換しています。また、バグファイルのリストを入力として受け取るように修正を加えています。
BRT Agent
図2. BRT Agentの手法概要。Agentic Bug Reproduction for Effective Automated Program Repair at Googleより引用。
BRT Agentは、バグ報告とバグファイルのリストを入力として受け取り、バグ再現テスト（BRT）を生成するエージェントです。BRT Agentは、Reasoning LLMとCode-Editing LLMの2種類のLLMを連携させる仕組みとなっています。Reasoning LLMがバグの内容と現在の状態を理解し、アクションを決める役割を担い、Code-Editing LLMが実際のテストコードの変更を行います。
具体的には、図3からActionを選択し実行、結果を確認し再度Actionを選択するという手順を反復的に行いテストコードを生成します。
図3. BRT Agentが実行するアクションのリスト。Agentic Bug Reproduction for Effective Automated Program Repair at Googleより引用。
実験
データセット
Google社内で、開発者によって報告された80個の本番環境のバグを使用しています。これらのバグは、Java、C++、Pythonなど7つのプログラミング言語で構成されています。
実験方法
LLMの確率的挙動を考慮し、各バグに対して複数回の実験を行っています。LIBROではそれぞれ50回、BRT Agentではそれぞれ20回の実験を行い、その結果を比較しています。
また、BRT Agentの総ステップ数は25回を上限としています。
評価方法
BRT Agentの性能を評価するために、以下の3つの指標を用いて評価を行っています。
- 候補BRT割合（Candidate BRTs）：少なくとも１つ以上テストコードが生成されたバグのうち、バグのあるバージョンのコードで失敗したバグの割合。
- もっともらしいBRT割合（Plausible BRTs）：バグのあるバージョンのコードで失敗し、かつ修正後のコードで成功するテストが生成されたバグの割合。
- 候補BRTがもっともらしいBRTとなった割合：もっともらしいBRT / 候補BRT。BRT生成の精度を示す指標。
さらに、生成できたもっともらしいBRTを先述のPasserineに提供することで、Passerineでの自動修正割合が向上するかどうかも評価しています。
結果・考察
LIBROとBRT Agentの比較
図4. LIBROと、BRT Agentの各種BRT割合を比較した表。及び、プログラミング言語ごとのもっともらしいBRT割合を比較した表。Agentic Bug Reproduction for Effective Automated Program Repair at Googleより引用。
表4より、候補BRTの生成割合・もっともらしいBRTの生成割合ともに、BRT AgentがLIBROを上回っていることがわかります。また、候補BRTがもっともらしいBRTとなった割合も、BRT AgentがLIBROを上回っています。これは、BRT AgentがLIBROよりもより適切なテストコードを生成できていることを示しています。
また、プログラミング言語ごとに見た結果でも、7つ中5つの言語でもっともらしいBRTの生成率が上回っています。
BRTをPasserineに渡した際の自動修正割合
図5. BRT AgentでもっともらしいBRTを生成できたバグを対象として、PasserineにBRTを渡した/渡さなかった場合にプログラムの修正に成功したバグの数をベン図で表現した図。Agentic Bug Reproduction for Effective Automated Program Repair at Googleより引用。
続いて、もっともらしいBRTが生成できたバグを対象に、もっともらしいBRTをPasserineに渡した際の自動修正割合がどう変わるかを見てみます。こちらの表のバグ総数は23となります。表3よりwith BRTの自動修正割合が17 / 23、without BRTの自動修正割合が13 / 23となっており、BRTを提供することで自動修正割合が大幅に向上することが確認されます。
一方で、BRTを入力しない場合のみ修正できたバグも2つあり[2]、一概にBRT提供が万能ではない点も示唆されています。
BRTをPasserineに渡した際のステップ数
図6. PasserineにBRTを渡した/渡さなかった場合のPasserineの実行ステップ数の分布。Agentic Bug Reproduction for Effective Automated Program Repair at Googleより引用。
こちらの表は、with BRTとwithout BRTでPasserineのステップ数の分布を比較した結果です。実行ステップ数が25のものは、プログラムが修正しきれず打ち切りとなった結果も含みます。表より、with BRTの方がステップ数が少なく、より効率的にプログラムを修正できていることがわかります。
まとめ
以上、Google社の実際の産業・コードベースを対象に、バグ再現テスト（BRT）の自動生成エージェント「BRT Agent」を提案した論文でした。Reasoning LLMとCoding LLMを連携させることで、より高精度なBRT生成が実現され、実験では候補BRT生成率・もっともらしいBRT生成率ともに大幅な向上が確認されました。また、生成されたBRTを活用することで、自動プログラム修正システムPasserineの修正成功率や効率も改善されることが示され、産業現場での実用性が期待されます。現時点で実用的なBRT生成率は約28%と課題は残るものの、今後のさらなる改良や大規模データセットでの検証が期待される研究と感じました。
お知らせ
少しでも弊社にご興味を持っていただけた方は、お気軽にご連絡頂けますと幸いです。まずはカジュアルにお話を、という形でも、副業を検討したいという形でも歓迎しています。
Discussion