論文の概要: Evaluating Agent-based Program Repair at Google
- arxiv url: http://arxiv.org/abs/2501.07531v1
- Date: Mon, 13 Jan 2025 18:09:25 GMT
- ステータス: 翻訳完了
- システム内更新日: 2025-01-14 14:29:26.089698
- Title: Evaluating Agent-based Program Repair at Google
- Title（参考訳）: Googleにおけるエージェントベースのプログラム修復の評価
- Authors: Pat Rondon, Renyao Wei, José Cambronero, Jürgen Cito, Aaron Sun, Siddhant Sanyam, Michele Tufano, Satish Chandra,
- Abstract要約: エージェントベースのプログラム修復は、複雑なバグをエンドツーエンドで自動的に解決する。
最近の研究は、人気のあるオープンソースSWE-Benchにおけるエージェントベースの修復アプローチの使用について検討している。
本稿では,企業コンテキストにおけるバグに対処するためのエージェント的アプローチの適用可能性について検討する。
- 参考スコア（独自算出の注目度）: 9.62742759337993
- License:
- Abstract: Agent-based program repair offers to automatically resolve complex bugs end-to-end by combining the planning, tool use, and code generation abilities of modern LLMs. Recent work has explored the use of agent-based repair approaches on the popular open-source SWE-Bench, a collection of bugs from highly-rated GitHub Python projects. In addition, various agentic approaches such as SWE-Agent have been proposed to solve bugs in this benchmark. This paper explores the viability of using an agentic approach to address bugs in an enterprise context. To investigate this, we curate an evaluation set of 178 bugs drawn from Google's issue tracking system. This dataset spans both human-reported (78) and machine-reported bugs (100). To establish a repair performance baseline on this benchmark, we implement Passerine, an agent similar in spirit to SWE-Agent that can work within Google's development environment. We show that with 20 trajectory samples and Gemini 1.5 Pro, Passerine can produce a patch that passes bug tests (i.e., plausible) for 73% of machine-reported and 25.6% of human-reported bugs in our evaluation set. After manual examination, we found that 43% of machine-reported bugs and 17.9% of human-reported bugs have at least one patch that is semantically equivalent to the ground-truth patch. These results establish a baseline on an industrially relevant benchmark, which as we show, contains bugs drawn from a different distribution -- in terms of language diversity, size, and spread of changes, etc. -- compared to those in the popular SWE-Bench dataset.
- Abstract（参考訳）: エージェントベースのプログラム修復は、現代のLLMの計画、ツールの使用、コード生成能力を組み合わせることで、複雑なバグをエンドツーエンドで自動的に解決する。
最近の研究は、人気のあるオープンソースのSWE-Benchに対するエージェントベースの修復アプローチの使用について調査している。
さらに、SWE-Agentのような様々なエージェントアプローチが、このベンチマークのバグを解決するために提案されている。
本稿では,企業コンテキストにおけるバグに対処するためのエージェント的アプローチの適用可能性について検討する。
これを調べるため,Googleのイシュートラッキングシステムから引き出された178のバグ評価セットをキュレートした。
このデータセットは、ヒューマンレポート(78)とマシンレポートされたバグ(100)の両方にまたがる。
このベンチマークで修復パフォーマンスのベースラインを確立するために、Googleの開発環境で動作可能なSWE-Agentに似たエージェントであるPasserineを実装した。
20のトラジェクトリサンプルとGemini 1.5 Proで、Passerineは、マシンレポートの73%、人間レポートの25.6%のバグテストに合格するパッチを生成することができる。
手動で調べると、マシンが報告したバグの43%と、人間が報告したバグの17.9%が、少なくとも1つのパッチを持っていることがわかった。
これらの結果は、一般的なSWE-Benchデータセットと比較すると、言語多様性、サイズ、変更の拡散といった点で、異なる分布から引き出されたバグを含む、産業的に関係のあるベンチマークのベースラインを確立します。
関連論文リスト
- Evaluating Software Development Agents: Patch Patterns, Code Quality, and Issue Complexity in Real-World GitHub Scenarios [13.949319911378826]
この調査は、500の現実のGitHubイシューで上位10のエージェントから4,892のパッチを評価した。
一人のエージェントが支配的であり、170の問題が未解決であり、改善の余地があった。
ほとんどのエージェントはコードの信頼性とセキュリティを維持し、新しいバグや脆弱性を避けた。
一部のエージェントはコードの複雑さを増し、多くの重複を減らし、コードの臭いを最小限にした。
論文 参考訳（メタデータ） (2024-10-16T11:33:57Z) - Towards Realistic Evaluation of Commit Message Generation by Matching Online and Offline Settings [77.20838441870151]
オンラインメトリック - VCSに生成されたメッセージをコミットする前にユーザが導入する編集回数 - を使用して、オフライン実験用のメトリクスを選択します。
我々は,GPT-4が生成したコミットメッセージと,人間の専門家が編集したコミットメッセージからなる57対のデータセットを収集した。
以上の結果から,編集距離が最も高い相関性を示すのに対し,BLEUやMETEORなどの類似度は低い相関性を示すことがわかった。
論文 参考訳（メタデータ） (2024-10-15T20:32:07Z) - Leveraging Large Language Models for Efficient Failure Analysis in Game Development [47.618236610219554]
本稿では,テストの失敗の原因となるコードの変更を自動的に識別する手法を提案する。
このメソッドは、LLM(Large Language Models)を利用して、エラーメッセージと対応するコード変更を関連付ける。
当社のアプローチは新たに作成したデータセットで71%の精度に達しています。
論文 参考訳（メタデータ） (2024-06-11T09:21:50Z) - A Novel Approach for Automatic Program Repair using Round-Trip
Translation with Large Language Models [50.86686630756207]
研究によると、ある文の文法的誤りは、それを他の言語に翻訳し、その語を返せば修正できる。
現在の自動プログラム修復(APR)生成モデルは、ソースコードで事前訓練され、修正のために微調整されている。
本稿では,あるプログラミング言語から別のプログラミング言語,あるいは自然言語へのコード変換,そして,その逆といった,微調整ステップをバイパスし,ラウンド・トリップ変換(RTT)を用いる手法を提案する。
論文 参考訳（メタデータ） (2024-01-15T22:36:31Z) - RAP-Gen: Retrieval-Augmented Patch Generation with CodeT5 for Automatic
Program Repair [75.40584530380589]
新たな検索型パッチ生成フレームワーク(RAP-Gen)を提案する。
RAP-Gen 以前のバグ修正ペアのリストから取得した関連する修正パターンを明示的に活用する。
RAP-GenをJavaScriptのTFixベンチマークとJavaのCode RefinementとDefects4Jベンチマークの2つのプログラミング言語で評価する。
論文 参考訳（メタデータ） (2023-09-12T08:52:56Z) - A Comparative Study of Text Embedding Models for Semantic Text
Similarity in Bug Reports [0.0]
既存のデータベースから同様のバグレポートを取得することは、バグを解決するのに必要な時間と労力を削減するのに役立つ。
我々はTF-IDF(Baseline)、FastText、Gensim、BERT、ADAなどの埋め込みモデルについて検討した。
本研究は, 類似のバグレポートを検索するための埋め込み手法の有効性について考察し, 適切なバグレポートを選択することの影響を明らかにする。
論文 参考訳（メタデータ） (2023-08-17T21:36:56Z) - What Happens When We Fuzz? Investigating OSS-Fuzz Bug History [0.9772968596463595]
我々は2022年3月12日までにOSS-Fuzzが公表した44,102件の問題を分析した。
コードを含むバグの発生時期を推定するために,バグ貢献のコミットを特定し,検出から修正までのタイムラインを測定した。
論文 参考訳（メタデータ） (2023-05-19T05:15:36Z) - Auto-labelling of Bug Report using Natural Language Processing [0.0]
ルールとクエリベースのソリューションは、明確なランキングのない、潜在的な類似バグレポートの長いリストを推奨します。
本論文では,NLP手法の組み合わせによる解を提案する。
カスタムデータトランスフォーマー、ディープニューラルネットワーク、および非汎用機械学習メソッドを使用して、既存の同一バグレポートを検索する。
論文 参考訳（メタデータ） (2022-12-13T02:32:42Z) - Using Developer Discussions to Guide Fixing Bugs in Software [51.00904399653609]
我々は,タスク実行前に利用可能であり,また自然発生しているバグレポートの議論を,開発者による追加情報の必要性を回避して利用することを提案する。
このような議論から派生したさまざまな自然言語コンテキストがバグ修正に役立ち、オラクルのバグ修正コミットに対応するコミットメッセージの使用よりもパフォーマンスの向上につながることを実証する。
論文 参考訳（メタデータ） (2022-11-11T16:37:33Z) - S3M: Siamese Stack (Trace) Similarity Measure [55.58269472099399]
本稿では、深層学習に基づくスタックトレースの類似性を計算する最初のアプローチであるS3Mを紹介します。
BiLSTMエンコーダと、類似性を計算するための完全接続型分類器をベースとしている。
私たちの実験は、オープンソースデータとプライベートなJetBrainsデータセットの両方において、最先端のアプローチの優位性を示しています。
論文 参考訳（メタデータ） (2021-03-18T21:10:41Z) - Advaita: Bug Duplicity Detection System [1.9624064951902522]
重複バグ率(重複バグの%)は、製品の成熟度、コードのサイズ、プロジェクトに取り組んでいるエンジニアの数に基づいて、1桁(1～9%)から2桁(40%)の範囲にある。
重複の検出は、2つのバグが同じ意味を持つかどうかを識別する。
このアプローチでは、基本的なテキスト統計的特徴、意味的特徴、文脈的特徴など、複数の機能セットを考慮に入れている。
論文 参考訳（メタデータ） (2020-01-24T04:48:39Z)
関連論文リストは本サイト内にある論文のタイトル・アブストラクトから自動的に作成しています。
指定された論文の情報です。
本サイトの運営者は本サイト（すべての情報・翻訳含む）の品質を保証せず、本サイト（すべての情報・翻訳含む）を使用して発生したあらゆる結果について一切の責任を負いません。