論文の概要: The Fact Selection Problem in LLM-Based Program Repair

• arxiv url: http://arxiv.org/abs/2404.05520v3
• Date: Tue, 27 Aug 2024 13:17:20 GMT
• ステータス: 処理完了
• システム内更新日: 2024-08-28 19:29:21.811286
• Title: The Fact Selection Problem in LLM-Based Program Repair
• Title（参考訳）: LLMプログラム修復におけるFact Selection問題
• Authors: Nikhil Parasaram, Huijie Yan, Boyu Yang, Zineb Flahy, Abriele Qudsi, Damian Ziaber, Earl Barr, Sergey Mechtaev,
• Abstract要約: コードコンテキストのような単純な構文的な詳細から、以前はPythonプロジェクトのコンテキストで探索されていなかった意味情報まで、それぞれの事実が有益であることを示す。 重要なことは、プログラム修復プロンプトの有効性は、使用済み事実の数よりも非単調であることが判明した。 我々は、特定のバグに固有の事実を抽出し、プロンプトに含める基本統計モデルManipleを開発した。
• 参考スコア（独自算出の注目度）: 3.7005619077967133
• License: http://creativecommons.org/licenses/by/4.0/
• Abstract: Recent research has shown that incorporating bug-related facts, such as stack traces and GitHub issues, into prompts enhances the bug-fixing capabilities of large language models (LLMs). Considering the ever-increasing context window of these models, a critical question arises: what and how many facts should be included in prompts to maximise the chance of correctly fixing bugs? To answer this question, we conducted a large-scale study, employing over 19K prompts featuring various combinations of seven diverse facts to rectify 314 bugs from open-source Python projects within the BugsInPy benchmark. Our findings revealed that each fact, ranging from simple syntactic details like code context to semantic information previously unexplored in the context of LLMs such as angelic values, is beneficial. Specifically, each fact aids in fixing some bugs that would remain unresolved or only be fixed with a low success rate without it. Importantly, we discovered that the effectiveness of program repair prompts is non-monotonic over the number of used facts; using too many facts leads to subpar outcomes. These insights led us to define the fact selection problem: determining the optimal set of facts for inclusion in a prompt to maximise LLM's performance on a given task instance. We found that there is no one-size-fits-all set of facts for bug repair. Therefore, we developed a basic statistical model, named Maniple, which selects facts specific to a given bug to include in the prompt. This model significantly surpasses the performance of the best generic fact set. To underscore the significance of the fact selection problem, we benchmarked Maniple against the state-of-the-art zero-shot, non-conversational LLM-based bug repair methods. On our testing dataset of 157 bugs, Maniple repairs 88 bugs, 17% above the best configuration.
• Abstract（参考訳）: 最近の研究によると、スタックトレースやGitHubの問題といったバグ関連の事実をインクルードすることで、大規模言語モデル(LLM)のバグ修正機能を強化している。 バグを正しく修正する可能性を最大化するためのプロンプトに、何つの事実を含めるべきなのか? この質問に答えるために、我々は大規模な調査を行い、BugsInPyベンチマーク内のオープンソースのPythonプロジェクトから314のバグを修正するために、7つのさまざまな事実の組み合わせを含む19K以上のプロンプトを使用しました。 以上の結果から,コードコンテキストのような単純な構文情報から,エンジェル値などのLLMの文脈で探索されていない意味情報まで,それぞれの事実が有用であることが判明した。 具体的には、各事実は未解決のまま、あるいは未解決で低い成功率でしか修正されないバグを修正するのに役立ちます。 重要なことに、プログラム修復プロンプトの有効性は、使用済み事実の数よりも非単調であることが判明した。 これらの知見は、与えられたタスクインスタンス上でのLCMのパフォーマンスを最大化するプロンプトに含めるための事象の最適セットを決定するという、事実選択の問題を定義した。 バグ修正には,すべての事実に適合するものが存在しないことが分かりました。 そこで我々は,特定のバグに特異的な事実を抽出し,プロンプトに含める基本統計モデルManipleを開発した。 このモデルは、最も一般的な事実セットのパフォーマンスを大幅に上回る。 事実選択問題の重要性を明らかにするために,我々は,現在最先端のゼロショット,非会話型LPMによるバグ修復手法に対して,Manipleをベンチマークした。 157のバグからなるテストデータセットで、Manipleは88のバグを修復します。

関連論文リスト

• BLAZE: Cross-Language and Cross-Project Bug Localization via Dynamic Chunking and Hard Example Learning [1.9854146581797698]
  BLAZEは動的チャンキングとハードサンプル学習を採用するアプローチである。 プロジェクト横断と言語横断のバグローカライゼーションを強化するために、難しいバグケースを使用してGPTベースのモデルを微調整する。 BLAZEは、トップ1の精度で120%、平均平均精度(MAP)で144%、平均相互ランク(MRR)で100%上昇する。
  論文  参考訳（メタデータ） (2024-07-24T20:44:36Z)
• A Deep Dive into Large Language Models for Automated Bug Localization and Repair [12.756202755547024]
  大規模言語モデル(LLM)は、自動プログラム修復(APR)など、様々なソフトウェアエンジニアリングタスクにおいて顕著な効果を示している。 本研究では,LSMを用いた自動バグ修正について深く検討する。 異なるLLMを用いてバグの局所化と修正を分離することにより、多様なコンテキスト情報の効果的な統合が可能になる。 Toggleは、CodeXGLUEコード改善ベンチマークで、新しい最先端(SOTA)パフォーマンスを実現する。
  論文  参考訳（メタデータ） (2024-04-17T17:48:18Z)
• DebugBench: Evaluating Debugging Capability of Large Language Models [80.73121177868357]
  DebugBench - LLM(Large Language Models)のベンチマーク。 C++、Java、Pythonの4つの主要なバグカテゴリと18のマイナータイプをカバーする。 ゼロショットシナリオで2つの商用および4つのオープンソースモデルを評価する。
  論文  参考訳（メタデータ） (2024-01-09T15:46:38Z)
• The Earth is Flat? Unveiling Factual Errors in Large Language Models [89.94270049334479]
  ChatGPTのような大規模言語モデル(LLM)は、事前学習や微調整の知識が豊富にあるため、様々な応用がある。 それにもかかわらず、医療、ジャーナリズム、教育といった重要な分野に懸念を抱き、事実と常識の誤りを引き起こす傾向にある。 LLMにおける事実不正確な事実を明らかにすることを目的とした,新しい自動テストフレームワークであるFactCheckerを紹介する。
  論文  参考訳（メタデータ） (2024-01-01T14:02:27Z)
• A Critical Review of Large Language Model on Software Engineering: An Example from ChatGPT and Automated Program Repair [19.123640635549524]
  大規模言語モデル(LLM)が注目され、様々なソフトウェアエンジニアリングタスクで有望なパフォーマンスを示した。 本稿では,ChatGPTのバグ修正機能について,研究目的の異なるクリーンAPRベンチマークで概説する。 ChatGPTは、35ラウンド以内の基本的なプロンプトを使用して151のバグギープログラムのうち109を修正でき、最先端のLLM CodeT5とPLBARTを27.5%、予測精度62.4%で上回っている。
  論文  参考訳（メタデータ） (2023-10-13T06:11:47Z)
• Automated Bug Generation in the era of Large Language Models [6.0770779409377775]
  BugFarmは任意のコードを複数の複雑なバグに変換する。 BUGFARMが生成した1.9万以上の変異株から435k以上のバグを総合的に評価する。
  論文  参考訳（メタデータ） (2023-10-03T20:01:51Z)
• Can Large Language Models Infer Causation from Correlation? [104.96351414570239]
  大規模言語モデル(LLM)の純粋因果推論スキルをテストする。 相関文の集合を取り、変数間の因果関係を決定する新しいタスクCorr2Causeを定式化する。 これらのモデルがタスクのランダムな性能にほぼ近い結果が得られることを示す。
  論文  参考訳（メタデータ） (2023-06-09T12:09:15Z)
• How Predictable Are Large Language Model Capabilities? A Case Study on BIG-bench [52.11481619456093]
  実験記録におけるBIGベンチの性能予測問題について検討する。 95%以上のR2$スコアは、実験記録の中に学習可能なパターンが存在することを示している。 BIG-bench Hardのように新しいモデルファミリーを評価できるサブセットが3倍程度小さくなっています。
  論文  参考訳（メタデータ） (2023-05-24T09:35:34Z)
• Using Developer Discussions to Guide Fixing Bugs in Software [51.00904399653609]
  我々は,タスク実行前に利用可能であり,また自然発生しているバグレポートの議論を,開発者による追加情報の必要性を回避して利用することを提案する。 このような議論から派生したさまざまな自然言語コンテキストがバグ修正に役立ち、オラクルのバグ修正コミットに対応するコミットメッセージの使用よりもパフォーマンスの向上につながることを実証する。
  論文  参考訳（メタデータ） (2022-11-11T16:37:33Z)
• TACRED Revisited: A Thorough Evaluation of the TACRED Relation Extraction Task [80.38130122127882]
  TACREDはリレーショナル抽出(RE)において最も大きく、最も広く使われているクラウドソースデータセットの1つである パフォーマンスの天井に到達したのか、改善の余地はあるのか? ラベルエラーは絶対F1テストエラーの8%を占めており、例の50%以上を可逆化する必要がある。
  論文  参考訳（メタデータ） (2020-04-30T15:07:37Z)

関連論文リストは本サイト内にある論文のタイトル・アブストラクトから自動的に作成しています。

指定された論文の情報です。
本サイトの運営者は本サイト（すべての情報・翻訳含む）の品質を保証せず、本サイト（すべての情報・翻訳含む）を使用して発生したあらゆる結果について一切の責任を負いません。