知財求人 - 知財ポータルサイト「IP Force」
▶ セールスフォース ドット コム インコーポレイティッドの特許一覧
特表2025-521113自動プログラム修復のための検索拡張パッチ生成のためのシステム及び方法
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2025-07-08
(54)【発明の名称】自動プログラム修復のための検索拡張パッチ生成のためのシステム及び方法
(51)【国際特許分類】
G06F 8/35 20180101AFI20250701BHJP
G06F 8/30 20180101ALI20250701BHJP
G06F 8/65 20180101ALI20250701BHJP
【ＦＩ】
G06F8/35
G06F8/30
G06F8/65
【審査請求】有
【予備審査請求】未請求
(21)【出願番号】P 2024568263
(86)(22)【出願日】2023-05-05
(85)【翻訳文提出日】2024-11-15
(86)【国際出願番号】 US2023021133
(87)【国際公開番号】W WO2023224819
(87)【国際公開日】2023-11-23
(31)【優先権主張番号】63/343,264
(32)【優先日】2022-05-18
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】17/896,873
(32)【優先日】2022-08-26
(33)【優先権主張国・地域又は機関】US
(81)【指定国・地域】
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＰＹＴＨＯＮ
(71)【出願人】
【識別番号】506332063
【氏名又は名称】セールスフォース インコーポレイテッド
(74)【代理人】
【識別番号】110004381
【氏名又は名称】弁理士法人ＩＴＯＨ
(72)【発明者】
【氏名】ワン，ユエ
(72)【発明者】
【氏名】ワン，ウェイシ
(72)【発明者】
【氏名】ジョティ，シャフィク レイハン
(72)【発明者】
【氏名】ホイ，チュ ホォン
【テーマコード（参考）】
5B376
【Ｆターム（参考）】
5B376BC31
5B376CA02
(57)【要約】
ニューラルネットワークモデルを使用した自動プログラム修復のためのシステム及び方法について説明する。第１のバグ含有コードパッチが受信された後、パッチリトリーバのリトリーバエンコーダを使用して、第１のバグ含有コードパッチの第１の表現が生成される。パッチリトリーバは、第１の表現に基づいて、第１の複数のバグ修正コードペアから第１のバグ修正コードペアを検索する。第１の拡張バグ含有コードパッチは、第１のバグ含有コードパッチ及び第１のバグ修正コードペアに基づいて生成される。パッチジェネレータは、第１の拡張バグ含有コードパッチに基づいて、修正されたコードパッチを生成する。
【特許請求の範囲】
【請求項1】
自動プログラム修復のための方法であって、第１のバグ含有コードパッチを受信するステップと、
パッチリトリーバのリトリーバエンコーダを使用して、前記第１のバグ含有コードパッチの第１の表現を生成するステップと、
前記パッチリトリーバを使用して、前記第１の表現に基づいて、第１の複数のバグ修正コードペアから第１のバグ修正コードペアを検索するステップと、
前記第１のバグ含有コードパッチ及び前記第１のバグ修正コードペアに基づいて第１の拡張バグ含有コードパッチを生成するステップと、
パッチジェネレータを介して、前記第１の拡張バグ含有コードパッチに基づいて、修正されたコードパッチを生成するステップと
を含む方法。
【請求項2】
前記パッチリトリーバは、前記第１のバグ含有コードパッチとの語彙的類似性及び意味的類似性のうちの少なくとも１つに基づいて検索を実行するように構成される、請求項１に記載の方法。
【請求項3】
前記パッチリトリーバは、前記第１のバグ含有コードパッチとの語彙的類似性及び意味的類似性の組合せに基づいて検索を実行するように構成される、請求項２に記載の方法。
【請求項4】
前記パッチジェネレータは、シーケンス生成のためのTransformerベースのニューラルネットワークモデルを含む、請求項１に記載の方法。
【請求項5】
前記第１の拡張バグ含有の前記第１のバグ修正ペアは、前記パッチジェネレータのためのガイド修正パターンとして使用される、請求項１に記載の方法。
【請求項6】
前記第１のバグ含有コードパッチを受信する前に、２段階トレーニングプロセスを実行するステップであって、第１のトレーニングセットを使用して第１段階で前記パッチリトリーバをトレーニングすること、及び
前記トレーニングされたパッチリトリーバ及び第２のトレーニングセットを使用して、第２段階で前記パッチジェネレータをトレーニングすること
を含むステップ
をさらに含む、請求項１に記載の方法。
【請求項7】
前記第１のトレーニングセットは、バグ含有パッチ及び対応する修正されたパッチを含む、請求項６に記載の方法。
【請求項8】
複数の機械可読命令を含む非一時的機械可読媒体であって、前記複数の機械可読命令は、１つ又は複数のプロセッサによって実行されると、前記１つ又は複数のプロセッサに、第１のバグ含有コードパッチを受信するステップと、
パッチリトリーバのリトリーバエンコーダを使用して、前記第１のバグ含有コードパッチの第１の表現を生成するステップと、
前記パッチリトリーバを使用して、前記第１の表現に基づいて、第１の複数のバグ修正コードペアから第１のバグ修正コードペアを検索するステップと、
前記第１のバグ含有コードパッチ及び前記第１のバグ修正コードペアに基づいて第１の拡張バグ含有コードパッチを生成するステップと、
パッチジェネレータを介して、前記第１の拡張バグ含有コードパッチに基づいて、修正されたコードパッチを生成するステップと
を含む方法を実行させるように適合される、非一時的機械可読媒体。
【請求項9】
前記パッチリトリーバは、前記第１のバグ含有コードパッチとの語彙的類似性及び意味的類似性のうちの１つ又は複数に基づいて検索を実行するように構成される、請求項８に記載の非一時的機械可読媒体。
【請求項10】
システムであって、非一時的メモリと、
前記非一時的メモリに結合され、前記非一時的メモリから命令を読み出して前記システムに方法を実行させるように構成された１つ又は複数のハードウェアプロセッサと
を備え、前記方法は、
第１のバグ含有コードパッチを受信するステップと、
パッチリトリーバのリトリーバエンコーダを使用して、前記第１のバグ含有コードパッチの第１の表現を生成するステップと、
前記パッチリトリーバを使用して、前記第１の表現に基づいて、第１の複数のバグ修正コードペアから第１のバグ修正コードペアを検索するステップと、
前記第１のバグ含有コードパッチ及び前記第１のバグ修正コードペアに基づいて第１の拡張バグ含有コードパッチを生成するステップと、
パッチジェネレータを介して、前記第１の拡張バグ含有コードパッチに基づいて、修正されたコードパッチを生成するステップと
を含む、システム。
【請求項11】
前記パッチリトリーバは、前記第１のバグ含有コードパッチとの語彙的類似性及び意味的類似性のうちの少なくとも１つに基づいて検索を実行するように構成される、請求項１０に記載のシステム。
【請求項12】
前記パッチリトリーバは、前記第１のバグ含有コードパッチとの前記語彙的類似性及び前記意味的類似性の組合せに基づいて検索を実行するように構成される、請求項１１に記載のシステム。
【請求項13】
前記パッチジェネレータは、シーケンス生成のためのTransformerベースのニューラルネットワークモデルを含む、請求項１０に記載のシステム。
【請求項14】
前記第１の拡張バグ含有の前記第１のバグ修正ペアは、前記パッチジェネレータのためのガイド修正パターンとして使用される、請求項１０に記載のシステム。
【請求項15】
前記方法は、前記第１のバグ含有コードパッチを受信する前に、２段階トレーニングプロセスを実行するステップであって、
第１のトレーニングセットを使用して第１段階で前記パッチリトリーバをトレーニングすること、及び
前記トレーニングされたパッチリトリーバ及び第２のトレーニングセットを使用して、第２段階で前記パッチジェネレータをトレーニングすること
を含むステップ
をさらに含む、請求項１０に記載のシステム。
【発明の詳細な説明】
【技術分野】
【0001】
［相互参照］
本開示は、２０２２年８月２６日に出願された米国非仮特許出願第１７／８９６，８７３号の優先権を主張するものであり、この米国非仮特許出願は、米国特許法第１１９条の下で、２０２２年５月１８日に出願された米国仮特許出願第６３／３４３，２６４号の優先権を主張するものであり、これらは、その全体が参照により本明細書に組み込まれる。
本開示は、２０２２年８月２６日に出願された米国非仮特許出願第１７／８９６，８７３号の優先権を主張するものであり、この米国非仮特許出願は、米国特許法第１１９条の下で、２０２２年５月１８日に出願された米国仮特許出願第６３／３４３，２６４号の優先権を主張するものであり、これらは、その全体が参照により本明細書に組み込まれる。
【0002】
［技術分野］
実施形態は、一般に、機械学習及び自動コード生成に関し、より具体的には、検索拡張パッチ生成（ＲＡＰ－Ｇｅｎ）を使用した自動プログラム修復（ＡＰＲ）のためのシステム及び方法に関する。
実施形態は、一般に、機械学習及び自動コード生成に関し、より具体的には、検索拡張パッチ生成（ＲＡＰ－Ｇｅｎ）を使用した自動プログラム修復（ＡＰＲ）のためのシステム及び方法に関する。
【背景技術】
【0003】
ソフトウェア開発者は、多くの場合、ソースコードをデバッグ及び修復するために多大な時間及びエネルギーを費やしており、ソフトウェア開発が高価で時間のかかるものになっている。既存の自動プログラム修復ツールの中には、開発時、構築時、又は実行時におけるパッチの探索を含むユースケースで、プログラム修復の難易度及びコストを軽減するものもある。例えば、いくつかの探索ベースの（generate-and-validateとも呼ばれる）アプローチでは、手動のヒューリスティックルール又は冗長性ベースの技法を介してマイニングされた修正パターンに基づいて修復を探索し得る。冗長性ベースの技法は、一般に、多くの場合、修正されたパッチがコードベース内の他の場所（ドナーコードスニペット）から見つかる（又は再構成される）ことができるという冗長性仮定を行う。従って、これらの従来の探索ベースの技法は、プログラムを修復する際の精度及び効率が限られている。
【0004】
従って、自動プログラム修復のためのより効率的な方法が必要である。
【図面の簡単な説明】
【0005】
【図3】本明細書で説明されるいくつかの実施形態による、検索拡張パッチ生成を使用した自動プログラム修復フレームワークのための例示的なアーキテクチャを示す例示的なブロック図である。
【図4B】本明細書で説明されるいくつかの実施形態による、トレーニングされた検索拡張パッチ生成フレームワークを使用した推論プロセスの方法を示す例示的な論理フロー図である。
【図5】本明細書で説明されるいくつかの実施形態による、図１～図４Ｂに関連して説明される検索拡張パッチ生成を使用した自動プログラム修復フレームワークの例示的なデータ性能を示す例示的なデータテーブルを提供する。
【図6】本明細書で説明されるいくつかの実施形態による、図１～図４Ｂに関連して説明される検索拡張パッチ生成を使用した自動プログラム修復フレームワークの例示的なデータ性能を示す例示的なデータテーブルを提供する。
【図7】本明細書で説明されるいくつかの実施形態による、図１～図４Ｂに関連して説明される検索拡張パッチ生成を使用した自動プログラム修復フレームワークの例示的なデータ性能を示す例示的なデータテーブルを提供する。
【図8】本明細書で説明されるいくつかの実施形態による、図１～図４Ｂに関連して説明される検索拡張パッチ生成を使用した自動プログラム修復フレームワークの例示的なデータ性能を示す例示的なデータテーブルを提供する。
【図9】本明細書で説明されるいくつかの実施形態による、図１～図４Ｂに関連して説明される検索拡張パッチ生成を使用した自動プログラム修復フレームワークの例示的なデータ性能を示す例示的なデータテーブルを提供する。
【図10】本明細書で説明されるいくつかの実施形態による、図１～図４Ｂに関連して説明される検索拡張パッチ生成を使用した自動プログラム修復フレームワークの例示的なデータ性能を示す例示的なデータテーブルを提供する。
【図11】本明細書で説明されるいくつかの実施形態による、図１～図４Ｂに関連して説明される検索拡張パッチ生成を使用した自動プログラム修復フレームワークの例示的なデータ性能を示す例示的なデータテーブルを提供する。
【図12】本明細書で説明されるいくつかの実施形態による、図１～図４Ｂに関連して説明される検索拡張パッチ生成を使用した自動プログラム修復フレームワークの例示的なデータ性能を示す例示的なデータテーブルを提供する。
【図13】本明細書で説明されるいくつかの実施形態による、図１～図４Ｂに関連して説明される検索拡張パッチ生成を使用した自動プログラム修復フレームワークの例示的なデータ性能を示す例示的なデータテーブルを提供する。
【0006】
これらの図では、同じ符号を有する要素は、同じ又は同様の機能を有する。
【発明を実施するための形態】
【0007】
本明細書で使用される場合、「ネットワーク」という用語は、任意の人工知能ネットワーク若しくはシステム、ニューラルネットワーク若しくはシステム、及び／又はその上に若しくはそれと共に実装される任意のトレーニング若しくは学習モデルを含む、任意のハードウェア又はソフトウェアベースのフレームワークを備え得る。
【0008】
本明細書で使用される場合、「モジュール」という用語は、１つ又は複数の機能を実行するハードウェア又はソフトウェアベースのフレームワークを含み得る。いくつかの実施形態では、モジュールは、１つ又は複数のニューラルネットワーク上に実装され得る。
【0009】
既存の自動プログラム修復システムは、手動デバッギング作業を低減し、ソフトウェア信頼性を向上させ得る。従来の探索ベースの技法は、典型的には、修正パターンをマイニングするためにヒューリスティックルール又は冗長性仮定に依拠する。深層学習ベースのアプローチの中には、コード修復パッチを生成するように学習モデルをトレーニングすることによって、プログラム修復プロセスを自動化し得るものもある。しかしながら、このような学習モデルの性能は、プログラム修復の非常に複雑な探索空間をモデル化するための固定パラメータセットによって制限されることが多い。
【0010】
効率的且つ正確なコード修復システムの必要性に鑑み、本明細書で説明される実施形態は、関連する修正パターンに基づいてパッチリトリーバを使用してコードパッチを検索するための検索拡張パッチ生成フレームワークを提供する。具体的には、生のソースコードに基づく疎な検索及び密な検索を通じて、語彙的マッチング及び意味的マッチングの両方を考慮する修正パターンマイニング用にハイブリッドパッチリトリーバが構成され得る。また、このリトリーバは、抽象構文木などの言語固有の特徴を必要としないので、言語に依存しないリトリーバである。以前の修正パターンマイニングモデルからの１つの改善点は、リトリーバが、様々な修正テンプレートをクラスタ化する代わりに、各バグ含有パッチ（buggy patch：バグのあるパッチ）のためのガイド修正パターンとして、上位１つの関連するバグ修正ペア（bug-fix pair）を利用することである。この戦略は、関連するバグ修正例を探索してバグ修正のためのいくつかの修復手がかりを抽出することが多い人間の開発者のデバッグ挙動と一致する。
【0011】
一実施形態では、事前トレーニングされたTransformerベースのエンコーダ－デコーダモデル（例えば、ＣｏｄｅＴ５モデル）が、基盤パッチジェネレータとして採用され得る。ＣｏｄｅＴ５は、コード認識言語モデリング目標を使用して大規模ソースコードコーパスで事前トレーニングされたジェネリックプログラミング言語モデルである。事前トレーニングされたエンコーダ－デコーダモデルをトレーニングして、パッチリトリーバとＣｏｄｅＴ５パッチジェネレータとを接続するために、２段階トレーニング戦略が使用され得る。パッチリトリーバは、まず、関連するバグ修正パターンを探索し、次いで、ソースバグ含有コード（buggy code：バグのあるコード）及び外部（検索された）バグ修正知識の両方に基づいて、修正されたパッチを合成するために、それらをパッチジェネレータに渡す。次いで、検索された修正パターンは、ソースバグ含有パッチに直接追加され得る。このようにして、リトリーバは、プログラム修復のための修正パターンマイニングにおける検索のために、任意のシーケンスツーシーケンス学習ベースのモデルと統合され得る。
【0012】
図１は、いくつかの実施形態による、図３に示される自動プログラム修復フレームワークを実装するためのコンピューティングデバイス１００の簡略図である。図１に示すように、コンピューティングデバイス１００は、メモリ１２０に結合されたプロセッサ１１０を含む。コンピューティングデバイス１００の動作は、プロセッサ１１０によって制御される。また、コンピューティングデバイス１００は、１つのプロセッサ１１０のみと共に示されているが、プロセッサ１１０は、コンピューティングデバイス１００内の１つ又は複数の中央処理装置、マルチコアプロセッサ、マイクロプロセッサ、マイクロコントローラ、デジタルシグナルプロセッサ、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、特定用途向け集積回路（ＡＳＩＣ）、グラフィックス処理ユニット（ＧＰＵ）などを表し得ることが理解される。コンピューティングデバイス１００は、スタンドアロンサブシステムとして、コンピューティングデバイスに追加されたボードとして、及び／又は仮想マシンとして実装され得る。
【0013】
メモリ１２０は、コンピューティングデバイス１００によって実行されるソフトウェア及び／又はコンピューティングデバイス１００の動作中に使用される１つ又は複数のデータ構造を記憶するために使用され得る。メモリ１２０は、１つ又は複数のタイプの機械可読媒体を含み得る。機械可読媒体のいくつかの一般的な形態には、フロッピー（登録商標）ディスク、フレキシブルディスク、ハードディスク、磁気テープ、任意の他の磁気媒体、ＣＤ－ＲＯＭ、任意の他の光学媒体、パンチカード、紙テープ、穴のパターンを有する任意の他の物理媒体、ＲＡＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＦＬＡＳＨ－ＥＰＲＯＭ、任意の他のメモリチップ若しくはカートリッジ、及び／又はプロセッサ若しくはコンピュータが読み取るように適合された任意の他の媒体が含まれ得る。
【0014】
プロセッサ１１０及び／又はメモリ１２０は、任意の適切な物理的配置で配置され得る。いくつかの実施形態では、プロセッサ１１０及び／又はメモリ１２０は、同じボード上、同じパッケージ（例えば、システムインパッケージ）内、同じチップ（例えば、システムオンチップ）上などにおいて実装され得る。いくつかの実施形態では、プロセッサ１１０及び／又はメモリ１２０は、分散、仮想化、及び／又はコンテナ化されたコンピューティングリソースを含み得る。そのような実施形態と一致して、プロセッサ１１０及び／又はメモリ１２０は、１つ又は複数のデータセンタ及び／又はクラウドコンピューティング施設に位置し得る。
【0015】
いくつかの例では、メモリ１２０は、１つ又は複数のプロセッサ（例えば、プロセッサ１１０）によって実行されたとき、本明細書でさらに詳細に説明する方法を１つ又は複数のプロセッサに実行させ得る実行可能コードを含む非一時的有形機械可読媒体を含み得る。例えば、図示のように、メモリ１２０は、システム及びモデルを実装及び／若しくはエミュレートするために、並びに／又は本明細書でさらに説明される方法のいずれかを実装するために使用され得る自動プログラム修復モジュール１３０のための命令を含む。自動プログラム修復モジュール１３０は、データインターフェース１１５を介して、プログラムバグなどの入力を含む入力１４０を受信し得る。自動プログラム修復モジュール１３０は、コードパッチなどの出力１５０を生成し得る。
【0016】
いくつかの実施形態では、自動プログラム修復モジュール１３０は、リトリーバエンコーダサブモジュール１３１と、パッチリトリーバサブモジュール１３２と、パッチジェネレータサブモジュール１３３とを含む。一実施形態では、自動プログラム修復モジュール１３０及びそのサブモジュール１３１～１３３は、ハードウェア、ソフトウェア、及び／又はそれらの組合せによって実装され得る。
【0017】
コンピューティングデバイス２００などのコンピューティングデバイスのいくつかの例には、１つ又は複数のプロセッサ（例えば、プロセッサ１１０）によって実行されると、１つ又は複数のプロセッサに、方法のプロセスを実行させ得る実行可能コードを含む非一時的な有形の機械可読媒体が含まれ得る。方法のプロセスを含み得る機械可読媒体のいくつかの一般的な形態としては、例えば、フロッピー（登録商標）ディスク、フレキシブルディスク、ハードディスク、磁気テープ、任意の他の磁気媒体、ＣＤ－ＲＯＭ、任意の他の光学媒体、パンチカード、紙テープ、穴のパターンを有する任意の他の物理媒体、ＲＡＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＦＬＡＳＨ－ＥＰＲＯＭ、任意の他のメモリチップ若しくはカートリッジ、及び／又はプロセッサ若しくはコンピュータが読み取るように適合された任意の他の媒体が挙げられる。
【0018】
図２は、図３に記載の自動プログラム修復フレームワーク及び本明細書で説明される他の実施形態を実装するのに適したネットワーク化されたシステムの簡略ブロック図である。一実施形態では、ブロック図２００は、ユーザ２４０によって動作され得るユーザデバイス２１０と、データベンダサーバ２４５、２７０、及び２８０と、サーバ２３０と、説明される実施形態に従って、様々な方法論を実行するように動作する他の形態のデバイス、サーバ、及び／又はソフトウェア構成要素とを含むシステムを示す。例示的なデバイス及びサーバには、ＭＩＣＲＯＳＯＦＴ（登録商標）ＯＳ、ＵＮＩＸ（登録商標）ＯＳ、ＬＩＮＵＸ（登録商標）ＯＳ、又は他の適切なデバイス及び／若しくはサーバベースのＯＳなどのＯＳを動作させる、図１に記載されたコンピューティングデバイス１００と同様であり得るデバイス、スタンドアロン、及びエンタープライズクラスのサーバが含まれ得る。図２に示されるデバイス及び／又はサーバは、他の方法で展開されてもよく、実行される動作、及び／又はそのようなデバイス及び／又はサーバによって提供されるサービスは、所与の実施形態のために組み合わせられるか、又は分離されてもよく、より多数又はより少数のデバイス及び／又はサーバによって実行されてもよいことを理解することができる。１つ又は複数のデバイス及び／又はサーバは、同じ又は異なるエンティティによって動作及び／又は維持され得る。
【0019】
ユーザデバイス２１０、データベンダサーバ２４５、２７０及び２８０、並びにサーバ２３０は、ネットワーク２６０を介して互いに通信し得る。ユーザデバイス２１０は、出力データ異常レポートを受信するためにサーバ２３０に関連付けられたプロセス及び／又はアプリケーションを含み得る、ユーザデバイス２１０に利用可能な様々な機能にアクセスするために、ユーザ２４０（例えば、ドライバ、システム管理者など）によって利用され得る。
【0020】
ユーザデバイス２１０、データベンダサーバ２４５、及びサーバ２３０は各々、本明細書で説明される様々なアプリケーション、データ、及びステップを実装するために、１つ又は複数のコンピュータ可読媒体上に記憶されたプログラムコード及び／又はデータなどの命令を実行するための１つ又は複数のプロセッサ、メモリ、及び他の適切な構成要素を含み得る。例えば、そのような命令は、システム２００の様々な構成要素の内部及び／若しくは外部の、並びに／又はネットワーク２６０を介してアクセス可能なメモリ又はデータ記憶デバイスなどの１つ又は複数のコンピュータ可読媒体に記憶され得る。
【0021】
ユーザデバイス２１０は、データベンダサーバ２４５及び／又はサーバ２３０とのワイヤード及び／又はワイヤレス通信のために構成された適切なハードウェア及びソフトウェアを利用し得る通信デバイスとして実装され得る。例えば、一実施形態では、ユーザデバイス２１０は、自律運転車両、パーソナルコンピュータ（ＰＣ）、スマートフォン、ラップトップ／タブレットコンピュータ、適切なコンピュータハードウェアリソースを有する腕時計、適切なコンピュータハードウェアを有する眼鏡（例えば、ＧＯＯＧＬＥ ＧＬＡＳＳ（登録商標））、他のタイプのウェアラブルコンピューティングデバイス、埋め込み型通信デバイス、及び／又はＡＰＰＬＥ（登録商標）のＩＰＡＤ（登録商標）などのデータを送信及び／又は受信することができる他のタイプのコンピューティングデバイスとして実装され得る。１つの通信デバイスのみが示されているが、複数の通信デバイスが同様に機能してもよい。
【0022】
図２のユーザデバイス２１０は、ユーザインターフェース（ＵＩ）アプリケーション２１２、及び／又は他のアプリケーション２１６を含み、これらは、実行可能なプロセス、プロシージャ、及び／又は関連するハードウェアを有するアプリケーションに対応し得る。例えば、ユーザデバイス２１０は、サーバ２３０からバグ含有コード及び／又は修正されたコードを示すメッセージを受信し、ＵＩアプリケーション２１２を介してメッセージを表示し得る。他の実施形態では、ユーザデバイス２１０は、必要に応じて、専用ハードウェア及び／又はソフトウェアを有する追加の又は異なるモジュールを含んでもよい。
【0023】
様々な実施形態では、ユーザデバイス２１０は、ユーザデバイス２１０に機能を提供するために特定の実施形態において所望され得る他のアプリケーション２１６を含む。例えば、他のアプリケーション２１６には、クライアント側セキュリティ機能を実装するためのセキュリティアプリケーション、ネットワーク２６０を介して適切なアプリケーションプログラミングインターフェース（ＡＰＩ）とインターフェースをとるためのプログラムクライアントアプリケーション、又は他のタイプのアプリケーションが含まれ得る。他のアプリケーション２１６にはまた、ユーザが、ネットワーク２６０を介して、電子メール、通話、テキスト、及び他の通知を送受信することを可能にする、電子メール、テキスティング、音声、ソーシャルネットワーキング、及びＩＭアプリケーションなどの通信アプリケーションが含まれ得る。例えば、他のアプリケーション２１６は、サーバ２３０から予測結果メッセージを受信する電子メール又はインスタントメッセージングアプリケーションであり得る。他のアプリケーション２１６は、入力及び／又は出力情報を受信し得るデバイスインターフェース及び他のディスプレイモジュールを含み得る。例えば、他のアプリケーション２１６は、バグ含有コード及び／又は修正されたコードを閲覧するためのインターフェースをユーザ２４０に提供するように構成されたグラフィカルユーザインターフェース（ＧＵＩ）を含む、プロセッサによって実行可能な資産管理のためのソフトウェアプログラムを含み得る。
【0024】
ユーザデバイス２１０は、様々なアプリケーション及びデータを記憶し、ユーザデバイス２１０の様々なモジュールの実行中に利用され得る、ユーザデバイス２１０の一時的及び／又は非一時的メモリに記憶されたデータベース２１８をさらに含み得る。データベース２１８は、ユーザ２４０に関するユーザプロファイル、ユーザ２４０によって以前に閲覧又は保存された予測、サーバ２３０から受信された履歴データなどを記憶し得る。いくつかの実施形態では、データベース２１８は、ユーザデバイス２１０に対してローカルであり得る。しかしながら、他の実施形態では、データベース２１８は、ユーザデバイス２１０の外部にあり、ネットワーク２６０を介してアクセス可能なクラウドストレージシステム及び／又はデータベースを含むユーザデバイス２１０によってアクセス可能であり得る。
【0025】
ユーザデバイス２１０は、データベンダサーバ２４５及び／又はサーバ２３０と通信するように適合された少なくとも１つのネットワークインターフェース構成要素２１９を含む。様々な実施形態では、ネットワークインターフェース構成要素２１９には、ＤＳＬ（例えば、Digital Subscriber Line）モデム、ＰＳＴＮ（Public Switched Telephone Network）モデム、イーサネット（登録商標）デバイス、ブロードバンドデバイス、衛星デバイス、並びに／又はマイクロ波、無線周波数、赤外線、Bluetooth（登録商標）、及び近距離通信デバイスを含む様々な他のタイプのワイヤード及び／若しくはワイヤレスネットワーク通信デバイスが含まれ得る。
【0026】
データベンダサーバ２４５は、バグ含有コード及び修正されたコードのペアを含むトレーニングデータセットをサーバ２３０に提供するために、データベース２０３ａ～ｎ（又は集合的に２０３と呼ばれる）のうちの１つ又は複数をホストするサーバに対応し得る。データベース２０３は、１つ又は複数のリレーショナルデータベース、分散データベース、クラウドデータベースなどによって実装され得る。
【0027】
データベンダサーバ２４５は、ユーザデバイス２１０及び／又はサーバ２３０と通信するように適合された少なくとも１つのネットワークインターフェース構成要素２２６を含む。様々な実施形態では、ネットワークインターフェース構成要素２２６には、ＤＳＬ（例えば、Digital Subscriber Line）モデム、ＰＳＴＮ（Public Switched Telephone Network）モデム、イーサネット（登録商標）デバイス、ブロードバンドデバイス、衛星デバイス、並びに／又はマイクロ波、無線周波数、赤外線、Bluetooth（登録商標）、及び近距離通信デバイスを含む様々な他のタイプのワイヤード及び／若しくはワイヤレスネットワーク通信デバイスが含まれ得る。例えば、一実装形態では、データベンダサーバ２４５は、ネットワークインターフェース２２６を介してデータベース２０３からサーバ２３０に資産情報を送信し得る。
【0028】
サーバ２３０は、図１に記載された自動プログラム修復モジュール１３０及びそのサブモジュールと共に収容され得る。いくつかの実装形態では、モジュール１３０は、コードの修正されたパッチを生成するために、ネットワーク２６０を介してデータベンダサーバ２４５においてデータベース２１９からデータを受信し得る。生成されたコードの修正されたパッチは、ネットワーク２６０を介してユーザ２４０によるレビューのためにユーザデバイス２１０に送信され得る。
【0029】
データベース２３２は、サーバ２３０の一時的及び／又は非一時的メモリに記憶され得る。一実装形態では、データベース２３２は、データベンダサーバ２４５から取得されたデータを記憶し得る。一実装形態では、データベース２３２は、自動プログラム修復モジュール１３０のパラメータを記憶し得る。一実装形態では、データベース２３２は、以前に生成されたコードの修正されたパッチ及び対応する入力特徴ベクトルを記憶し得る。
【0030】
いくつかの実施形態では、データベース２３２は、サーバ２３０に対してローカルであり得る。しかしながら、他の実施形態では、データベース２３２は、サーバ２３０の外部にあり、ネットワーク２６０を介してアクセス可能なクラウドストレージシステム及び／又はデータベースを含むサーバ２３０によってアクセス可能であり得る。
【0031】
サーバ２３０は、ネットワーク２６０を介してユーザデバイス２１０及び／又はデータベンダサーバ２４５、２７０若しくは２８０と通信するように適合された少なくとも１つのネットワークインターフェース構成要素２３３を含む。様々な実施形態では、ネットワークインターフェース構成要素２３３には、ＤＳＬ（例えば、Digital Subscriber Line）モデム、ＰＳＴＮ（Public Switched Telephone Network）モデム、イーサネット（登録商標）デバイス、ブロードバンドデバイス、衛星デバイス、並びに／又はマイクロ波、無線周波数（ＲＦ）、及び赤外線（ＩＲ）通信デバイスを含む様々な他のタイプのワイヤード及び／若しくはワイヤレスネットワーク通信デバイスが含まれ得る。
【0032】
ネットワーク２６０は、単一のネットワーク又は複数のネットワークの組合せとして実装され得る。例えば、様々な実施形態では、ネットワーク２６０は、インターネット又は１つ又は複数のイントラネット、地上通信線ネットワーク、ワイヤレスネットワーク、及び／又は他の適切なタイプのネットワークを含み得る。従って、ネットワーク２６０は、システム２００の様々な構成要素によってアクセス可能な、プライベート若しくはローカルエリアネットワークなどの小規模通信ネットワーク、又はワイドエリアネットワーク若しくはインターネットなどの大規模ネットワークに対応し得る。
【0033】
図３は、本明細書で説明される実施形態による、ＲＡＰ－Ｇｅｎフレームワーク３００とも呼ばれる、検索拡張パッチ生成（ＲＡＰ－Ｇｅｎ）を使用した自動プログラム修復フレームワーク３００の例示的なアーキテクチャを示す例示的なブロック図である。ＲＡＰ－Ｇｅｎフレームワーク３００は、検索を介して関連するバグ修正パターンと共に、入力されたバグ含有パッチに基づいてターゲットプログラムパッチを生成することを目的とする。
【0034】
自動プログラム修復のための検索拡張パッチ生成のタスク定式化は、以下のように説明される。
を、|Ｄ|個のバグ修正ペア（ＸｉＹｉ）から構成されるプログラム修復データセットとし、ここで、Ｘｉ及びＹｉは、それぞれ、ｉ番目のバグ含有プログラムパッチ及び修正されたプログラムパッチである。コードベースＣ（例えば、コードベース３０２）は、以前のバグ修正ペアの大きな集合
を含み、ここで、（Ｂｊ，Ｆｊ）は、ｊ番目のバグ修正ペアを示す。Ｄ内のバグ含有プログラムパッチＸｉ３０８が与えられると、パッチリトリーバ３０４は、φによってパラメータ化された関連性スコアリング関数ｆφ（Ｘｉ，Ｂｊ）に基づいて、コードベースＣ内の１つ又は複数の最も関連性のあるバグ修正ペア（複数可）（Ｂｊ、Ｆｊ）を検索する。
【数1】
【数2】
【0035】
いくつかの実施形態では、元の入力シーケンスＸｉ３０８を、検索されたバグ修正ペアで拡張して、新しい入力シーケンス３１２を形成し、例えば、
次いで、パッチジェネレータ３０６（例えば、シーケンスツーシーケンス（ｓｅｑ２ｓｅｑ）ジェネレータを使用するものであり、シーケンスジェネレータ３０６とも呼ばれる）が、自己回帰的に
からＹｉ３１６を生成し得る。フレームワーク３００は、θによってパラメータ化されたパッチジェネレータ３０６を用いて確率
を学習し得、ここで、Ｙｉ，１：Ｙｉ，ｋ－１は、ｋ番目のトークンの前の前のシーケンスであり、ｎは、ターゲットシーケンスＹｉ内のトークンの数を示す。いくつかの実施形態では、外部コードベースＣ３０２は、ノンパラメトリックメモリとみなされ得、検索されたバグ修正ペア３１０は、パッチ生成モデル３０６のためのガイド修正パターンとみなされ得る。確率的には、検索Ｚｊ（Ｂｊ，Ｆｊ）は、潜在変数として定式化され得、これは、場合によってはｔｏｐ－１で近似され得る。形式的には、
であり、ここで、
は、リトリーバＰφ（ＺｊＸｉ）からのｔｏｐ－１の検索された出力である。ｋ＞１にわたるマージナライゼーションはトレーニング及び推論を複雑且つ非効率的にするので、効率向上のためにｔｏｐ－１近似が採用され得る。いくつかの実施形態では、フレシェ開始距離（ＦｉＤ）法を用いたｔｏｐ－ｋ（例えば、ｋ＝２，３，５）が使用され得る。
【数3】
【数4】
【数5】
【数6】
【数7】
【0036】
図３の例に示すように、ＲＡＰ－Ｇｅｎフレームワーク３００は、パッチリトリーバ３０４と、コード認識事前トレーニング済みパッチジェネレータ３０６とを含む。パッチリトリーバ３０４は、自動プログラム修復に役立つ関連する修正パターンを検索するように構成される。これは、関連性スコアリング関数ｆφ（Ｘｉ、Ｂｊ）を基に、（クエリ）バグ含有パッチＸｉ３０８とコードベースＣ３０２内の前の（キー）バグ含有パッチＢｊとの間の関連性を計算し得る。様々な実施形態では、パッチリトリーバ３０４は、語彙ベースのリトリーバ（lexical-based retriever）（例えば、ＢＭ２５）及び／又は意味ベースのリトリーバ（semantic-based retriever）（例えば、Dense Passage Retrieval（ＤＰＲ））を含み得る。図３の例では、パッチリトリーバ３０４は、ニューラルネットワークモデル（例えば、リトリーバエンコーダ３１８）を含み、ハイブリッドアプローチを使用して、語彙ベースのリトリーバ（例えば、ＢＭ２５）と意味ベースのリトリーバ（例えば、ＤＰＲ）とを組み合わせて、語彙情報と意味情報の両方を考慮に入れる。
【0037】
語彙ベースのリトリーバ（Lexical-based Retriever）。いくつかの実施形態では、語彙ベースのリトリーバ（例えば、ＢＭ２５）は、用語ベースのリトリーバを使用して実装され得、語彙的マッチングのために疎ベクトル表現を使用し得る。語彙ベースのリトリーバは、各コードパッチをbag-of-words表現として変換し、クエリパッチＸｉと候補パッチＢｊとの間の語彙的類似性（lexical similarity）を計算し得る。計算された類似性スコアは、ｆφ（Ｘｉ，Ｂｊ）＝ＢＭ２５（Ｘｉ，Ｂｊ）と表される。一例では、疎な用語ベースのリトリーバは、コードのセマンティクスに影響を与えないソースコード内の識別子命名（identifier naming）の選択に敏感であり得る。
【0038】
意味ベースのリトリーバ（Semantic-based Retriever）。いくつかの実施形態では、意味ベースのリトリーバは、Dense Passage Retriever（ＤＰＲ）を使用して実装され得、それらの意味的類似性（semantic similarity）を測定することを介して、関連するパッチを検索し得る。いくつかの実施形態では、コードパッチを符号化するために、エンコーダ（例えば、Transformerベースのエンコーダ）を使用して、各パッチを固定サイズの密ベクトルにマッピングし得る。ＤＰＲは、事前トレーニングされたTransformerベースのニューラルネットワークモデル（例えば、Code Bidirectional Encoder Representations from Transformers（ＣｏｄｅＢＥＲＴ）など）のエンコーダから初期化され得る。エンコーダは、１つ又は複数のプログラミング言語の大規模なコードリポジトリ（例えば、６つのプログラミング言語のＧｉｔＨｕｂコードリポジトリ）を使用して事前トレーニングされ得る。一例では、エンコーダからの［ＣＬＳ］トークンの最終層の隠れ状態がパッチ表現として使用される。いくつかの実施形態では、共有ＤＰＲを使用して、クエリパッチＸｉ３０８及びＣ内の候補パッチＢｊを、それぞれ、
として別々に符号化し得る。次いで、以下のように、これらの２つのパッチ表現間の内積によって類似性が計算される：
【数8】
【数9】
【0039】
いくつかの実施形態では、共有ＤＰＲを使用して、クエリパッチＸｉ３０８及びＣ内の候補パッチＦｊを、それぞれ、
として別々に符号化し得る。次いで、以下のように、これらの２つのパッチ表現間の内積によって類似性が計算される：
【数10】
【数11】
【0040】
本明細書の説明は、一般に、検索のためにＸｉとＢｊとの間の類似性（例えば、ｆφ（Ｘｉ，Ｂｊ）を使用）を使用するが、検索に使用される類似性は、ＸｉとＢｊとの間の類似性（例えば、ｆφ（Ｘｉ，Ｂｊ）を使用）、ＸｉとＦｊとの間の類似性（例えば、ｆφ（Ｘｉ，Ｆｊ）を使用）、及び／又はそれらの組合せを含み得ることに留意されたい。
【0041】
いくつかの実施形態では、意味ベースのリトリーバ（例えば、ＤＰＲ）は、バグ含有パッチと修正されたパッチとのペアを含むトレーニングデータセットを使用してさらにトレーニングされる。一例では、バグ含有コードＢｊをクエリとみなし、対応する修正されたコードＦｊをキーとみなすことによって、バグ修正ペアを含むコードベース３０２が使用され得る。これは、バグ含有パッチ及びその修正されたパッチが多くの場合同様のセマンティクス（例えば、識別子、データフロー、及びコード構造）を共有するという仮定に基づいて実行され得る。この技法は、バグツーバグ探索データセットをキュレーションするために必要とされる膨大な手作業による注釈付け作業を回避するために使用され得る。
【0042】
バグ修正ペアがクエリ及び対応するキーとして使用される例では、意味ベースのリトリーバをトレーニングするために、バッチ内ネガティブを用いた対照学習法３１４が使用され、バッチ内ネガティブは、以下のように、対照損失（例えば、ＩｎｆｏＮＣＥ対照損失）を最適化するために使用される：
ここで、Ｍは現在のミニバッチであり、Ｎはミニバッチ内の正のトレーニング例の数を示す。この目的は、負例間の類似性を最小にしながら、正例間の類似性を最大にすることを目的とする。それぞれの正例は、|Ｍ|－１個の負のサンプルを有し得る。様々な対照学習技法、例えば、バッチ内ネガティブ戦略、ハードネガティブマイニング戦略などが使用され得るが、いくつかの実施形態では、上記で説明したバッチ内ネガティブを用いた対照学習は、ノイズの多いトレーニングデータに対してハードネガティブマイニング戦略よりも良好な性能を提供することに留意されたい。
【数12】
【0043】
いくつかの実施形態では、推論段階において、クエリバグ含有パッチＸｉ３０８が与えられると、意味ベースのリトリーバ（例えば、ＤＰＲ）は、Ｘｉ（クエリ）とＢｊ（キー）との間の類似性を計算することによって、関連するバグ修正ペア（Ｂｊ，Ｆｊ）を検索する。いくつかの実施形態では、意味ベースのリトリーバは、ＸｉとＦｊとの間の類似性、及び／又はＸｉ（クエリ）とＢｊ（キー）との間の類似性との組合せに基づいて、関連するバグ修正ペアを検索し得る。
【0044】
ハイブリッドリトリーバ（Hybrid Retriever）。図３の例に示すように、いくつかの実施形態では、語彙情報と意味情報の両方を考慮に入れるために、語彙リトリーバ（例えば、ＢＭ２５）と意味リトリーバ（例えば、ＤＰＲ）を組み合わせるハイブリッドアプローチが利用される。例えば、類似性スコアは、
として計算され得、ここで、
は、２つのリトリーバのバランスをとるための重みであり、経験的に１に設定され得る。ハイブリッドリトリーバは、語彙情報又は意味情報のいずれかのみに依拠するリトリーバと比較して、よりロバストである。
【数13】
【数14】
【0045】
図３の例では、ＲＡＰ－Ｇｅｎフレームワーク３００は、修正されたコードパッチを生成するためのパッチジェネレータ３０６を含む。いくつかの実施形態では、コード認識事前トレーニングパッチジェネレータ３０６によって、ソースバグ含有パッチ３０８又はクエリバグ含有パッチ３０８とも呼ばれる入力バグ含有パッチ３０８（Ｘｉと示される）、及び検索されたバグ修正パターン３１０（Ｂｊ、Ｆｊと示される）を使用して、例えば、以下のような連結を使用して、拡張バグ含有コードパッチ３１２が生成される：
パッチジェネレータ３０６は、（例えば、ｓｅｑ２ｓｅｑモデルを用いて）修正されたコードパッチＹｉ３１６を生成するために構築される。ＲＡＰ－Ｇｅｎフレームワーク３００内のパッチジェネレータ３０６は、シーケンス生成のための任意の適切なニューラルネットワークモデル（シーケンス生成モデル又はシーケンスジェネレータとも呼ばれる）を含み得る。いくつかの実施形態では、パッチジェネレータ３０６は、自然言語実装上で最適化されたシーケンスジェネレータを含む。
【数15】
【0046】
いくつかの実施形態では、パッチジェネレータ３０６は、大規模ソースコードコーパスで事前トレーニングされたコード認識プログラミング言語モデルを含む。一例では、シーケンスジェネレータは、欠陥検出及びコードリファインメント（code refinement）など、複数のコードインテリジェンスタスクにおいて最先端の（ＳｏＴＡ）結果を達成する、統合された事前トレーニングされたTransformerベースのエンコーダデコーダモデルであるＣｏｄｅＴ５を使用する。これは、ＧｉｔＨｕｂから収集された８つの異なるプログラミング言語（ＪａｖａＳｃｒｉｐｔ（登録商標）及びＪａｖａ（登録商標）を含む）における８３０万個の関数で事前トレーニングされ得る。ＣｏｄｅＴ５は、識別子認識事前トレーニング目的を採用して、コード固有の知識を言語モデルに組み込み得る。これは、コードに対して最適化されたコード固有のバイトペア符号化（ＢＰＥ）トークナイザを提供し得、Out-of-Vocabulary（ＯｏＶ）問題を回避することが可能であり得る。ＣｏｄｅＴ５は、強力なコード理解能力を提供し得るパッチジェネレータ３０６において使用され得る。
【0047】
図３の例に示すように、パッチジェネレータ３０６（例えば、ＣｏｄｅＴ５）への検索拡張入力３１２は、
として準備され得、ここで、［ＢＵＧ］及び［ＦＩＸ］は、検索されたバグ修正ペアをソースバグ含有パッチ３０８と分離するための特別なトークンである。パッチジェネレータ３０６（例えば、ＣｏｄｅＴ５）は、
を入力としてとるためのエンコーダ３１８と、修正されたパッチＹｉ３１６を合成及び生成するためのデコーダ３２０とを含み得る。いくつかの実施形態では、パッチジェネレータ３０６のトレーニング中、教師強制アルゴリズムを使用して、言語モデリング損失を最小限に抑え得る。いくつかの実施形態では、トレーニングされたパッチジェネレータを使用した推論中、ビーム探索（例えば、サイズ５）を使用して、候補修正されたパッチのランキングリストを生成する。
【数16】
【数17】
【0048】
様々な実施形態では、ＲＡＰ－Ｇｅｎフレームワーク３００は、（例えば、ＣｏｄｅＴ５を使用して）大規模コードコーパスに対する事前トレーニングを介して符号化された一般的なコード理解知識を活用する。例えば、ソース入力シーケンス３１２は、元のバグ含有コードパッチ３０８と、パッチリトリーバ３０４からの上位にランク付けされたバグ修正ペア３１０とを連結することによって生成され得る。いくつかの実施形態では、拡張されたソース入力バグ含有パッチ３１２は、ｔｏｐ－ｋ（例えば、ｋ＝２，３，５）の検索されたバグ修正ペアを入力バグ含有パッチ３０８に連結することによって生成され得る。
【0049】
図４Ａは、本明細書で説明されるいくつかの実施形態による、図３に示されるような自動プログラム修復のための検索拡張パッチ生成フレームワークをトレーニングする方法を示す例示的な論理フロー図である。方法４００のプロセスのうちの１つ又は複数は、少なくとも部分的に、１つ又は複数のプロセッサによって実行されると、１つ又は複数のプロセッサに、プロセスのうちの１つ又は複数を実行させ得る、非一時的有形機械可読媒体上に記憶された実行可能コードの形態で実装され得る。いくつかの実施形態では、方法４００は、検索拡張パッチ生成を使用して自動プログラム修復を実行するための自動プログラム修復モジュール１３０（例えば、図１）の動作に対応する。
【0050】
ステップ４０２において、リトリーバエンコーダを含むパッチリトリーバが提供される。図３の例では、検索拡張パッチ生成フレームワーク３００において、リトリーバエンコーダ３１８を含むパッチリトリーバ３０４が提供される。いくつかの実施形態では、ステップ４０４に示されるように、リトリーバエンコーダ３１８は、例えば、大規模プログラミング言語コーパス（例えば、１つ又は複数のプログラミング言語におけるＧｉｔＨｕｂコードリポジトリ又は他の適したコードリポジトリ）を含む第１のトレーニングデータセットを使用して、事前トレーニングされる。
【0051】
ステップ４０６において、シーケンスジェネレータニューラルネットワークモデルを含むパッチジェネレータが提供される。図３の例では、検索拡張パッチ生成フレームワーク３００において、パッチジェネレータ３０６は、シーケンスジェネレータニューラルネットワークモデル、具体的には、ジェネレータエンコーダ３１８及びジェネレータデコーダ３２０を含むTransformerベースのエンコーダデコーダモデルを含む。いくつかの実施形態では、ステップ４０４に示されるように、パッチジェネレータ３０６は、例えば、大規模プログラミング言語コーパス（例えば、１つ又は複数のプログラミング言語におけるＧｉｔＨｕｂコードリポジトリ又は他の適したコードリポジトリ）を含む第２のトレーニングデータセットを使用して、事前トレーニングされる。
【0052】
ステップ４１０において、パッチリトリーバ及びパッチジェネレータを含むＲＡＰ－Ｇｅｎフレームワーク（例えば、図３のＲＡＰ－Ｇｅｎフレームワーク）が、例えば、２段階トレーニングプロセスを使用してトレーニングされ得る。２段階トレーニングプロセスは、第３のトレーニングデータセットを使用してパッチリトリーバをトレーニングすることによって第１段階トレーニングが実行されるステップ４１２を含む。いくつかの実施形態では、第３のトレーニングデータセットは、コードベース３０２内のバグ修正ペアを使用し得る。例えば、パッチリトリーバ３０４の意味リトリーバをトレーニングするために第３のトレーニングデータセットを使用する場合、コードベース内のバグ修正ペアのバグ含有コードＢｊがクエリとみなされ得、対応する修正されたコードＦｊがキーとみなされ得る。別の例では、コードベース内のバグ修正ペアの修正されたコードＦｊがクエリとみなされ得、対応するバグ含有コードＢｊがキーとみなされ得る。これは、バグ含有パッチ及びその修正されたパッチが多くの場合同様のセマンティクス（例えば、識別子、データフロー、及びコード構造）を共有するという仮定に基づく。第３のトレーニングデータセットのためにコードベース３０２内のバグ修正ペアを使用することによって、第３のトレーニングデータセットとしてバグツーバグ探索データセットをキュレーションするために必要とされる膨大な手作業による注釈付け作業が回避され得る。一例では、第１段階のトレーニングは、対照損失を最適化することによって、対照学習アルゴリズムを使用し得る。
【0053】
２段階トレーニングプロセスは、第１段階トレーニングによってトレーニングされたパッチリトリーバを使用して、第４のトレーニングデータセットを使用してパッチジェネレータをトレーニングすることによって第２段階トレーニングが実行されるステップ４１４を含む。一例では、パッチジェネレータへの入力が、元の入力バグ含有コードパッチと、トレーニングされたパッチリトリーバからの上位にランク付けされたバグ修正ペアとを使用して生成される場合、教師強制アルゴリズムを使用して、言語モデリング損失を最小限に抑える。
【0054】
第２段階トレーニング中、第４のトレーニングセットがバグ修正ペアコードベースから生成される例では、パッチリトリーバ（第１段階トレーニングを使用して既にトレーニング済み）は、グラウンドトゥルースのバグ修正ペアにアクセスすることを許可されない。そうでなければ、パッチジェネレータが検索された修正をターゲット出力として直接コピーし得るので、トレーニング損失は容易にゼロ近くまで低下する。その例では、第４のトレーニングセットの各サンプルは、コードベースからの対応するバグ修正ペア（グラウンドトゥルースバグ修正ペアとも呼ばれる）のバグ含有パッチであり、対応するグラウンドトゥルースは、対応するバグ修正ペアの修正されたパッチである。各サンプルバグ含有パッチ入力について、別のバグ修正ペア（グラウンドトゥルースのものではない）が、パッチリトリーバによってコードベースから検索される。検索されたバグ修正ペアは、バグ含有パッチ入力に付加されて、パッチジェネレータのための拡張シーケンス入力を生成する。グラウンドトゥルースのバグ修正ペアへのアクセスがないという要件は、コードベースが第４のトレーニングセットを提供するために使用されるときのトレーニングの第２段階にのみ適用され、コードベースが第３のトレーニングセットを提供するために使用されるときのパッチリトリーバをトレーニングする第１段階には適用されないことに留意されたい。
【0055】
第３及び第４のデータセットがどのように生成されるか？ダウンストリームデータセットごとにバグ修正ペアがあり、これはまさに第３のトレーニングセットであることを想起されたい。
【0056】
図４Ｂを参照すると、本明細書で説明されるいくつかの実施形態による、トレーニングされた検索拡張パッチ生成フレームワークを使用する推論プロセスの方法４５０を示す例示的な論理フロー図が示されている。方法４５０のプロセスのうちの１つ又は複数は、少なくとも部分的に、１つ又は複数のプロセッサによって実行されると、１つ又は複数のプロセッサに、プロセスのうちの１つ又は複数を実行させ得る、非一時的有形機械可読媒体上に記憶された実行可能コードの形態で実装され得る。いくつかの実施形態では、方法４５０は、検索拡張パッチ生成を使用して自動プログラム修復を実行するための自動プログラム修復モジュール１３０（例えば、図１）の動作に対応する。
【0057】
ステップ４５２において、トレーニングされた検索拡張パッチ生成フレームワークによって第１のバグ含有パッチが受信される。図３の例では、トレーニングされた検索拡張パッチ生成フレームワーク３００は、第１のバグ含有パッチ３０８を受信し、それをそのトレーニングされたパッチリトリーバ３０４の入力に提供する。
【0058】
ステップ４５４において、第１のバグ含有パッチに基づいて１つ又は複数のバグ修正ペアが提供される。図３の例では、トレーニングされたパッチリトリーバ３０４は、第１のバグ含有パッチ３０８を受信し、例えば、第１のバグ含有パッチ３０８とバグ修正ペアとの間の類似性に基づいて、コードベース３０２から１つ又は複数のバグ修正ペアを検索する。様々な実施形態では、類似性は、第１のバグ含有パッチ３０８とバグ修正ペアのバグ含有パッチとの間の類似性、第１のバグ含有パッチ３０８とバグ修正ペアの修正されたパッチとの間の類似性、又はそれらの組合せに基づいて決定される。類似性は、語彙的類似性、意味的類似性、又はそれらの組合せを含み得る。
【0059】
ステップ４５６において、第１のバグ含有パッチ及び検索された１つ又は複数のバグ修正ペアに基づいて、第１の拡張バグ含有パッチが生成される。図３の例では、第１のバグ含有パッチ３０８と、パッチリトリーバ３０４によって提供された１つ又は複数のバグ修正ペア３１０とを使用して第１の拡張バグ含有パッチ３１２が生成される。第１の拡張バグ含有パッチ３１２は、パッチジェネレータ３０６に提供される。
【0060】
ステップ４５８において、第１の拡張バグ含有パッチを使用して、第１のバグ含有パッチのための第１の修正されたパッチが生成される。図３の例では、パッチジェネレータ３０６は、第１の拡張バグ含有パッチ３１２を受信し、第１の拡張バグ含有パッチ３１２に基づいて第１の修正されたパッチ３１６を生成する。
例示的なデータ実験及び性能
例示的なデータ実験及び性能
【0061】
図５を参照すると、いくつかの実験では、ＲＡＰ－Ｇｅｎフレームワークは、２つの一般的なＡＰＲデータセット、すなわち、ＪａｖａＳｃｒｉｐｔにおけるＴＦｉｘ（Berkay Berabi, Jingxuan He, Veselin Raychev, and Martin T. Vechev, TFix: Learning to Fix Coding Errors with a Text-to-Text Transformer, Proceedings of Machine Learning Research (PMLR), Vol. 139, 780-791）及びＪａｖａにおけるCode Refinement（Michele Tufano, Cody Watson, Gabriele Bavota, Massimiliano Di Penta, Martin White, and Denys Poshyvanyk, An Empirical Study on Learning Bug-Fixing Patches in the Wild via Neural Machine Translation, ACM Trans. Softw. Eng. Methodol. 28, 4 (2019), 19:1-19:29）で評価されている。両方のデータセットは、元々ＧｉｔＨｕｂコミットから収集されるが、ＴＦｉｘ内のバグ修正ペアが静的アナライザによって検証され得る一方で、Code Refinement内のペアは、コミットメッセージが「fix bug」のようなキーワードを含むかどうかをチェックすることにより検証されるという大きな違いがある。ＴＦｉｘ及びCode Refinementベンチマークのデータ統計を図５の表１に示す。
【0062】
ＴＦｉｘ。具体的には、ＴＦｉｘは、５５０万個のＧｉｔＨｕｂコミットからキュレーションされたＪａｖａＳｃｒｉｐｔコードパッチペアを含む大規模プログラム修復データセットである。これは、静的アナライザＥＳＬｉｎｔによって検出される５２個の一意のエラータイプ（error type）を包括的にカバーする。エラータイプに加えて、エラーメッセージ及び局所化されたエラー行などの豊富なエラー注釈を提供するので、従来の作業のような欠陥局所化（fault localization）の必要がない。ＴＦｉｘでは、Ｔ５－ｌａｒｇｅを用いたテキストツーテキスト生成問題としてＡＰＲタスクに取り組む。ソース入力シーケンスにおいて、それらは、全てのエラー情報をバグ含有コードパッチと共に組み合わせて単一のテキストにする：
fix {error type} {error message} {error context}
ここで、エラーコンテキストは、所与の局所化されたエラー行からなり、その２つの隣接するコード行は、バグ含有コードパッチを形成するために使用される。目標シーケンスは、エラーコンテキストにおいてエラー行を修正された行で置き換えることである。同じデータフォーマットが実験において採用され、データ例は、図６のソース入力において見出され得る（ＲＡＰ－Ｇｅｎフレームワークがバグを正しく修正する、ＴＦｉｘテストセットでの１つのバグ修正例を示す）。
fix {error type} {error message} {error context}
ここで、エラーコンテキストは、所与の局所化されたエラー行からなり、その２つの隣接するコード行は、バグ含有コードパッチを形成するために使用される。目標シーケンスは、エラーコンテキストにおいてエラー行を修正された行で置き換えることである。同じデータフォーマットが実験において採用され、データ例は、図６のソース入力において見出され得る（ＲＡＰ－Ｇｅｎフレームワークがバグを正しく修正する、ＴＦｉｘテストセットでの１つのバグ修正例を示す）。
【0063】
データ処理中、データ分割（data split）内及びデータ分割間の重複問題が観察される。具体的には、トレーニング、検証、及びテスト用の分割において、それぞれ１１４個、２個、及び４個の複製がある。分割間の重複については、トレーニング用とテスト用、トレーニング用とテスト用、及び検証用とテスト用の分割間に、それぞれ２８個、３４個、及び４個の重複がある。これらの重複（２４３）をフィルタリングし、重複排除されたバージョンＴＦｉｘ（Dedup）を図５の表１に示す。
【0064】
コードリファインメント（Code Refinement）。Tufanoらは、２０１１年３月から２０１７年１０月の間に公開されたGitHub Archive（https://www.gharchive.org/）から収集された、関数レベルでバグ修正ペアを含む２つのコードリファインメントデータセットをリリースした。収集されたバグ修正関数のペアのクオリティを確保するために、Google BigQuery APIを使用して、（「fix」又は「solve」）及び（「bug」又は「issue」又は「problem」又は「error」）のパターンを含むメッセージを有する全てのＪａｖａコミットを識別する。ＴＹＰＥ１、ＶＡＲ１、ＭＥＴＨＯＤ１などのインデックス付きトークンを用いて識別子を難読化することで関数を正規化した。１つのデータ例は図７に見られ得る（Refinement Smallテストセットにおける１つのバグ修正例を示しており、ここでは、ＲＡＰ－Ｇｅｎフレームワークが正しい予測を行っている）。２つのデータサブセットは、トークンの数によって決定され、すなわち、smallセットについては、コードトークンの数≦５０であり、mediumセットについては、５０＜コードトークンの数≦１００である。
【0065】
いくつかの実施形態では、ＲＡＰ－Ｇｅｎフレームワーク３００は、例えば、AdamWオプティマイザ（Ilya Loshchilov and Frank Hutter DecoupledWeight Decay Regularization, ICLR, 2019）を使用して、ベンチマークごとにシーケンスツーシーケンス生成損失を用いて（例えば、３０エポックで）微調整され得る。様々なバッチサイズ（例えば、１６、３２、６４）及び学習率（例えば、１ｅ－４、５ｅ－５、２ｅ－５）を用いて、ハイパーパラメータ調整のためにグリッド探索が行われ得る。例えば、学習率１ｅ－４とバッチサイズ６４がＴＦｉｘに使用され、学習率５ｅ－５とバッチサイズ３２がCode Refinementに使用され得る。一例では、１つのＡ１００ ＧＰＵを用いた各ベンチマークにおけるＲＡＰ－Ｇｅｎ－ｂａｓｅのトレーニング時間は２日以内である。推論中、合成された修正されたパッチのランク付けされたリストを生成するために、５のビームサイズでビーム探索が採用され得る。
【0066】
いくつかの実施形態では、トレーニングセット内のバグ修正ペアは、パッチリトリーバ３０４を構築するための探索コードベースとして採用される。語彙ベースのリトリーバの場合、例示的なオープンソースのＰｙｔｈｏｎライブラリ（例えば、ＢＭ２５のhttps://pypi.org/project/rank-bm25）が使用され得る。疎な用語ベースのリトリーバとして、トークナイザの選択は、検索性能に大きく影響する。実験では、コードトークン化のために最適化されたコード固有のＢＰＥトークナイザであるＣｏｄｅＴ５トークナイザが採用される。ベンチマークＴＦｉｘ及びCode RefinementのＢＭ２５サーチエンジンは、６００Ｇメモリを持つ９５ＣＰＵのマシン上で適用される。各実験は、多重処理で１時間以内に終了する。
【0067】
実験では、意味ベースのリトリーバについて、ＤＰＲで初期化されたＣｏｄｅＢＥＲＴを使用して、意味的マッチングのために各パッチを密ベクトルに符号化する。また、ＩｎｆｏＮＣＥ対照損失を使用して、５０エポックで各ベンチマークに対してＤＰＲモデルを微調整する。バッチサイズ６４と学習率２ｅ－５とが、４０Ｇメモリを持つ１つのＡ１００ ＧＰＵ上で微調整するために使用される。ＴＦｉｘ及びCode Refinementのためのトレーニング時間は、それぞれ約９及び５ＧＰＵ時間である。
【0068】
ハイブリッドリトリーバの場合、ＢＭ２５及びＤＰＲのランキングスコアが計算され、これらの正規化されたスコアを等しい重みで線形結合して、ハイブリッドリトリーバ、すなわち「Hybrid」を構築する。全てのリトリーバについて、ＣｏｄｅＴ５トークナイザを使用して、２５６の最大シーケンス長を有するパッチを符号化する。
【0069】
評価メトリック（Evaluation Metrics）。評価メトリックについては、平滑化されたＢＬＥＵ－４（Chin-Yew Lin and Franz Josef Och, ORANGE: a Method for Evaluating Automatic Evaluation Metrics for Machine Translation, COLING, 2004）スコア及び完全一致（ＥＭ）精度を使用して、プログラム修復性能を評価する（例えば、Yue Wang, Weishi Wang, Shafiq R. Joty, and Steven C. H. Hoi, CodeT5:Identifier-aware Unified Pre-trained Encoder-Decoder Models for Code Understanding and Generation, EMNLP, Association for Computational Linguistics, 8696-8708に従う）。ＢＬＥＵ－４は、サブワードのオーバーラップの程度を評価するためのより緩いメトリックであり、ＥＭは、予測が実際のコミットにおけるグラウンドトゥルースパッチと同一であることを必要とするより厳しいメトリックである。バグ含有プログラムは、異なる修復方法を有し得るので、Error Removalメトリック（例えば、ＴＦｉｘで使用されるような）を使用して、様々な形態の修正を考慮する。既存のエラーが除去され、修正後に新しいエラーが導入されない場合、Error Removalに対して予測は正しいものとしてカウントされる。全てのメトリックについて、結果は０～１００（％）のスケールで提示され、スコアが高いほど性能が良好であることを表す。
【0070】
ベースラインモデル（Baseline Models）。ＲＡＰ－Ｇｅｎフレームワークは、２つのプログラム修復ベンチマークにおいて学習ベースのモデルと比較される。ＣｏＣｏＮｕＴは、畳み込みエンコーダ－デコーダモデルに基づくコンテキスト認識ニューラル機械翻訳フレームワークである。ＳｅｑｕｅｎｃｅＲは、コピー機構を有するＬＳＴＭベースのシーケンスツーシーケンス生成モデルである。加えて、ＲＡＰ－Ｇｅｎフレームワークは、Transformerアーキテクチャに基づいて事前トレーニングされたプログラミング言語モデルと比較される。これらのモデルの１つのグループは、ＲｏＢＥＲＴａ（コード）、ＣｏｄｅＢＥＲＴ、及びＧｒａｐｈＣｏｄｅＢＥＲＴなどのエンコーダのみのモデルである。これらのエンコーダのみのモデルは、プログラム修復タスクのためにランダムに初期化されたデコーダを必要とする。
【0071】
さらに、ＲＡＰ－Ｇｅｎフレームワークは、エンコーダ－デコーダTransformerモデルと比較される。ＰＬＢＡＲＴは、トークンマスキング、トークン削除、及びトークンインフィリングを含むノイズ除去目的を有する統合された事前トレーニングされたモデルである。ＴＦｉｘは、Ｔ５－ｌａｒｇｅチェックポイントで初期化され、ＴＦｉｘデータセットに対する微調整を継続する。ＣｏＴｅｘＴは、テキストとコードの両方で事前トレーニングされた別のＴ５ベースのモデルである。ＮＳＥｄｉｔは、エンコーダ及びデコーダがそれぞれＣｏｄｅＢＥＲＴ及びＣｏｄｅＧＰＴから初期化された言語モデルである。これは、ニューラル記号編集シーケンスを介して修正を生成するように微調整され、Code Refinementベンチマーク上の現在のＳｏＴＡモデルとしてランク付けする。全てのベースラインモデルからの結果は、それらの原論文から得たものである。
【0072】
実験では、検索拡張パッチ生成がプログラム修復のための効果的なアプローチであることを検証する。ＲＡＰ－Ｇｅｎを２つのベンチマークで従来の学習ベースの方法と比較するために、包括的な実験を行った。まず、ＣｏｄｅＴ５モデルがＴＦｉｘに対して評価され、その評価は、データセットの重複排除されたバージョン及びより合理的なメトリックを提供することによって、並びに完全一致と一致するＢＬＥＵ－４スコアのより緩いメトリックを追加的に導入することによって改善される。その結果、ＣｏｄｅＴ５－ｂａｓｅが、このタスクで新しいＳｏＴＡ性能を確立し、ＥＭにおいてＴ５－ｌａｒｇｅの４９．７０を５３．５７に、ＢＬＥＵ－４において７６．９８を７８．８５に改善した。さらに、ＲＡＰ－Ｇｅｎモデルは、ＴＦｉｘ及びCode Refinementの両方のデータセットの両方を使用して評価される。語彙及び意味ベースのリトリーバを用いたＲＡＰ－Ｇｅｎが性能を大幅に向上させることが観察される。具体的には、「Hybrid」を用いたＲＡＰ－Ｇｅｎ－ｂａｓｅは、ＴＦｉｘにおけて最良の性能のベースラインを超えて完全一致を改善し（４９．７０→５４．１５）、「Hybrid」を用いたＲＡＰ－Ｇｅｎ－ｂａｓｅは、Code Refinementベンチマークのsmallセットにおける完全一致（２４．０４→２４．８０）を向上させるとともに、mediumセットにおける完全一致（１４．１８→１５．８４）を向上させた。全てのこれらの結果は、検索拡張パッチ生成（ＲＡＰ－Ｇｅｎ）がＡＰＲのための効果的なアプローチであることを検証する。
【0073】
この実験は、ＣｏｄｅＴ５を用いた検索拡張パッチ生成が、プログラム修復のための効果的なアプローチであることを示している。まず、ＣｏｄｅＴ５がＴＦｉｘベンチマークで従来のＡＰＲ技法と比較され、データの重複排除されたバージョン及びより適切な評価メトリックを用いて改善される。次いで、２つのサイズのＣｏｄｅＴ５と統合されたＲＡＰ－Ｇｅｎフレームワークが、ＴＦｉｘ及びCode Refinementベンチマークで評価される。さらに、この実験は、パッチリトリーバが語彙的類似性及び意味的類似性に関して関連するパッチを見つけることを示している。加えて、検索されたバグ修正パターンがプログラム修復にどのように役立つかを示すためにケーススタディが提供される。加えて、実験が示すように、ＲＡＰ－Ｇｅｎフレームワークは、様々なエラータイプ及び修正パターンに対して改善された性能を提供する。５２個のエラータイプに対する詳細な性能の内訳がリストされ、ＲＡＰ－Ｇｅｎにおける検索拡張の恩恵を受けないエラーのタイプが検査される。さらに、バグ含有コードからエラー行を単に除去する、些細だが支配的なエラー行除去の修正パターンを用いてモデルがどのように機能するかが研究される。
【0074】
この実験は、ＣｏｄｅＴ５を用いた検索拡張パッチ生成がプログラム修復のための効果的なアプローチであることを示している。まず、ＴＦｉｘ評価が改善する。元のＴＦｉｘベンチマークは、主な評価メトリックとして、５２個のエラータイプにわたる完全一致（ＥＭ）精度の直接平均を使用する。しかしながら、図１４の表７に示すように、これらのエラータイプは、分布がかなり不均衡であり、例えば、主要エラータイプ「no-invalid-this」のインスタンスが１６，２１７個である一方で、最小エラータイプ「no-new-symbol」のインスタンスはわずか１０個である。そのため、いくつかの実施形態では、エラータイプ分布を考慮に入れるために加重平均が採用される。さらに、ＴＦｉｘが完全一致をどのように計算するかについてのリリースされたコードを検査したところ、予測された修正がグラウンドトゥルース修正よりもスペース又は新しい行などの空白を１つでも多く含む場合、誤った完全一致とみなされるという別の制限があった。しかしながら、ＪａｖａＳｃｒｉｐｔ言語では、余分な空白はプログラムの正しさに影響を与えない。従って、複数の空白における不一致の影響を排除するためにＥＭを計算する前に空白を正規化する、EM w/o spacesの加重平均のより良好なメトリックが提案される。ＴＦｉｘデータセットには重複問題があるので、その重複排除されたバージョンに関する結果も含まれる。完全一致精度とは別に、ＢＬＥＵ－４スコアのより緩いメトリックを使用して、予測された修正とそのグラウンドトゥルース修正との間の部分的なオーバーラップ（subsequence overlap）を測定する。ＢＬＥＵ－４スコアもまた、空白正規化の後に計算されることに留意されたい。
【0075】
図９の表２に示すように、ＣｏｄｅＴ５モデルは、ＴＦｉｘで他の学習ベースのベースラインと比較される。１つの主な観察点は、元の平均EM w/ spacesメトリックの場合、ＣｏｄｅＴ５－ｂａｓｅ（５０．８８）は、Ｔ５－ｌａｒｇｅのモデルサイズがはるかに大きい（ＣｏｄｅＴ５－ｂａｓｅの約３．５倍）にもかかわらず、Ｔ５－ｌａｒｇｅ（４９．３３）よりも良好な精度をもたらすことである。さらに、妥当な直接平均EM w/o spacesに注目すると、ＣｏｄｅＴ５－ｂａｓｅは、Ｔ５－ｌａｒｇｅに対して絶対精度を約５だけ改善し（４９．３５→５４．３０）、性能を大幅に向上させる。加重平均EM w/o spacesに基づいて、ＣｏｄｅＴ５－ｓｍａｌｌ（５０．３１）及びＣｏｄｅＴ５－ｂａｓｅ（５３．５７）はいずれも、Ｔ５－ｌａｒｇｅ（４９．７０）を含む全てのベースラインよりも性能が優れている。これは、大規模コードコーパスに対するコード認識事前トレーニングを有するＣｏｄｅＴ５モデルが、プログラムをより理解していることを示す。ＴＦｉｘ評価については、ＥＭは、指定されない限り、加重平均EM w/o spacesを示すために使用される。ＢＬＥＵ－４メトリックについては、完全一致メトリックとの整合性が良好であり、ＣｏｄｅＴ５－ｂａｓｅはまた、元のＴＦｉｘに対して７８．８５の最先端（ＳｏＴＡ）性能を発揮する。
【0076】
次に、アブレーション研究観察について説明する。重複排除されたＴＦｉｘデータセットでは、様々なメトリックにわたる性能は一貫してわずかに低下する。これは、元のデータにおけるトレーニング用とテスト用の分割間の重複（３４個のインスタンス）がデータ漏洩問題につながり、性能を不適切に増加させることになるので、予想される現象である。エラータイプ及びエラーメッセージを含むエラー情報が除去された場合、ＣｏｄｅＴ５－ｓｍａｌｌモデルとＣｏｄｅＴ５－ｂａｓｅモデルの両方で、一貫した性能低下が見られ、プログラム修復モデルのためにどのタイプのエラーを修正する必要があるかを通知することが有用であることが明らかになった。
【0077】
図１０の表３を参照して、ＴＦｉｘに対するＲＡＰ－Ｇｅｎ評価について説明する。表３は、ＴＦｉｘベンチマークの重複排除されたバージョンに対するＲＡＰ－Ｇｅｎフレームワークの結果を示す。まず、コードベースからバグ修正ペアをランダムに検索することによって、Ｒａｎｄｏｍベースラインが確立される。ランダム検索によるＲＡＰ－Ｇｅｎ－ｓｍａｌｌとＲＡＰ－Ｇｅｎ－ｂａｓｅの両方の性能低下は、ランダムに検索された修正パターンがプログラム修復のための有用な案内シグナルを提供することができないことを意味している。次いで、語彙ベースのリトリーバＢＭ２５、密ベクトルマッチングに基づく意味ベースのリトリーバＤＰＲ、及びそれらを組み合わせる２つのアンサンブル方法を使用することを含む、異なるリトリーバと統合されたＲＡＰ－Ｇｅｎが比較される。その結果、全ての検索拡張アプローチが、ｓｍａｌｌモデル及びｂａｓｅモデルの両方について、完全一致及びＢＬＥＵ－４の両方に対する性能を有意に改善した。これは、検索拡張生成がＡＰＲのための実行可能且つ効果的なアプローチであり、意味情報及び語彙情報の両方が関連する修正パターンを検索するために重要であることを示す。アンサンブル方法の場合、「Hybrid」を用いたＲＡＰ－Ｇｅｎ－ｂａｓｅは、Ｔ５－ｌａｒｇｅを超えて最良の改善をもたらす（４９．５８→５４．１５ ＥＭ）。これは、語彙情報と意味情報の両方を考慮するアンサンブルアプローチが、２つの世界の最良のものを組み合わせ得ることを検証する。別の観察点は、検索拡張を用いた性能利得が、ＲＡＰ－Ｇｅｎ－ｂａｓｅよりもＲＡＰ－Ｇｅｎ－ｓｍａｌｌで大きいことであり、これは、改善が、モデルサイズの増加と共に飽和点に達する傾向があることを意味している。ＲＡＰ－Ｇｅｎ－ｓｍａｌｌ及びＲＡＰ－Ｇｅｎ－ｂａｓｅは両方とも、異なるパッチジェネレータバックボーンを有するＲＡＰ－Ｇｅｎフレームワーク、具体的には、それぞれ異なるモデルサイズを有するＣｏｄｅＴ５－ｂａｓｅ及びＣｏｄｅＴ５－ｓｍａｌｌを使用する。
【0078】
いくつかの実施形態では、バグを修正する複数の方法が存在し得る。そのため、１つのグラウンドトゥルースパッチとの完全一致は、他の形態の正しい修正を考慮するには厳密すぎるメトリックである。これに対処するために、ＴＦｉｘに従ったエラー除去メトリックを用いたより緩い評価が使用される。このメトリックの下で、修正されたパッチは、それがソースバグ含有パッチ内のエラーを解決し、新しいエラー（静的アナライザＥＳＬｉｎｔによって検出される）をもたらさない限り、正しいとみなされる。１０，４６５個のテストインスタンスに対してこのメトリックを再現しようとすると、２つの困難がある：（１）ＥＳＬｉｎｔを適用するには、各コードパッチに対して完全なファイルコンテキストが必要であるが、９５個のコードファイルは検索することができなくなっていることが分かった。（２）いくつかのデータサンプルでは、リリースされた構成（https://github.com/eth-sri/TFix）でＥＳＬｉｎｔを適用すると、パーサエラーが発生する。その結果、それらの利用不可能なコードファイル及びパーサエラーを有するサンプルを除外することによって、６，７９３個のインスタンスのフィルタリングされたサブセットがキュレーションされ、ここで、ＴＦｉｘから生成された修正がより多くのパーサエラーを有する傾向があることも判明した。図１１の表４を参照すると、エラー除去比較が示されている。ＲＡＰ－Ｇｅｎ－ｓｍａｌｌモデルは、エラー除去においてＴ５－ｌａｒｇｅモデルよりも大幅に性能が優れていることが観察され、これは、ＲＡＰ－Ｇｅｎモデルが、良好な修正の異なる形態を合成することがより可能であることを意味している。さらに、ＲＡＰ－Ｇｅｎ－ｓｍａｌｌでは、完全一致は低いがエラー除去精度は高いという、エラー除去メトリックと完全一致メトリックとの間にずれ（misalignment）があることが観察される。このようなずれは、ＴＦｉｘにおいても観察される。
【0079】
図１２の表５を参照すると、Code Refinement結果及び前述した方法との比較が示されている。全てのベースライン結果（ＣｏｄｅＴ５モデルを含む）は、それらの原論文から直接得られる。「Naive Copy」では、ＢＬＥＵ－４スコアはかなり高いが、完全一致（ＥＭ）はゼロであり、これは、バグ含有コード及びその修正のオーバーラップが大きく、完全一致が一次評価メトリックとして採用されるべきであることを示すことが観察される。ベースラインの中で、ＮＳＥｄｉｔは、smallサブセットで最良の結果（２４．０４ ＥＭ）を出す非常に競合力のあるものであり、マルチタスクトレーニングを伴うＣｏｄｅＴ５－ｂａｓｅは、mediumセットで最良の結果（１４．１８ ＥＭ）を出している。
【0080】
ＲＡＰ－Ｇｅｎモデル比較から、様々なリトリーバを用いたＲＡＰ－Ｇｅｎは、それらのＣｏｄｅＴ５対応物よりも性能を一貫して向上させることが観察される。最良のモデルは、２つのサブセットで新しいＳｏＴＡ結果を確立し（smallの場合は２４．８０ ＥＭ、mediumの場合は１５．８４ ＥＭ）、特に、より困難なmediumセットではＮＳＥｄｉｔを約２絶対ポイント上回る。これは、検索された修正パターンがプログラム修復を案内するための有用なシグナルを提供することを再び確認する。様々なリトリーバの中で、ＤＰＲは、ＲＡＰ－Ｇｅｎ－ｓｍａｌｌ及びＲＡＰ－Ｇｅｎ－ｂａｓｅの両方について、ＢＭ２５よりも良好な結果を出しており、意味情報が、このベンチマークについての意味情報よりも重要な役割を果たし得ることを明らかにする。さらに、「Hybrid」は、ＢＭ２５及びＤＰＲよりも性能が優れており、これは、ハイブリッドアンサンブル方法が、このベンチマークについて意味情報と意味情報の両方のバランスをとるためのよりロバストなリトリーバであることを意味している。
【0081】
要約すると、２つのベンチマークでＲＡＰ－Ｇｅｎを従来の学習ベースの方法と比較するために、包括的な実験を実施する。まず、ＴＦｉｘに対してＣｏｄｅＴ５モデルを評価し、データセットの重複排除されたバージョン及びより合理的なメトリックを提供し、さらに、完全一致と一致するＢＬＥＵ－４スコアのより緩いメトリックを導入することによって、その評価を改善する。その結果、ＣｏｄｅＴ５－ｂａｓｅが、このタスクで新しいＳｏＴＡ性能を確立し、ＥＭにおいてＴ５－ｌａｒｇｅの４９．７０を５３．５７に、ＢＬＥＵ－４において７６．９８を７８．８５に改善した。次に、ＴＦｉｘデータセットとコードリファインメントデータセットの両方でＲＡＰ－Ｇｅｎモデルを評価し、語彙及び意味ベースのリトリーバを用いたＲＡＰ－Ｇｅｎが性能を大幅に向上させることを観察する。具体的には、「Hybrid」を用いたＲＡＰ－Ｇｅｎ－ｂａｓｅは、ＴＦｉｘにおけて最良の性能のベースラインを超えて完全一致を改善し（４９．７０→５４．１５）、「Hybrid」を用いたＲＡＰ－Ｇｅｎ－ｂａｓｅは、Code Refinementベンチマークのsmallセットにおける完全一致（２４．０４→２４．８０）を向上させるとともに、mediumセットにおける完全一致（１４．１８→１５．８４）を向上させた。全てのこれらの結果は、ＣｏｄｅＴ５を用いた検索拡張パッチ生成（ＲＡＰ－Ｇｅｎ）がＡＰＲのための効果的なアプローチであることを検証する。
【0082】
次に、パッチリトリーバが、プログラム修復に役立つ関連する修正パターンを見つけることができるかどうかを評価するために、実験を実施する。まず、クエリと検索されたパッチとの間の語彙的及び意味的類似性に関する関連性を測定するための自動評価が提供される。さらに、検索された修正パターンがより良いＡＰＲにどのように寄与するかを理解するために、特定のケースが提供される。
【0083】
図１３の表６を参照すると、リトリーバの評価が示されている。リトリーバは、クエリと上位の検索されたパッチとの間の語彙的マッチング及び意味的マッチングに関して分析される。語彙的マッチングの場合、それらのサブトークンオーバーラップを測定するためにＢＬＥＵ－４スコアが使用され、意味的マッチングの場合、微調整されたＤＰＲリトリーバによって符号化されたそれらの密ベクトル間のコサイン類似度（CosSim）が使用される。図１３の表６は、ＴＦｉｘ及びCode Refinementの両方のベンチマークでのパッチリトリーバの性能を示す。最初の行は、コードベースからバグ修正ペアをランダムに検索することによる下界性能を示し、このRandomベースラインは、語彙マッチングと意味マッチングの両方においてはるかに低いスコアを達成することが観察される。語彙マッチングの場合、ＢＭ２５は、ＴＦｉｘでＤＰＲより性能が優れているが、２つのCode Refinementサブセットでは性能が劣っており、これは、ＴＦｉｘとCode Refinementとの間のデータ差が原因であり得、後者は、語彙ベースのＢＭ２５リトリーバの性能を妨げる難読化された識別子（例えば、ＶＡＲ１、ＶＡＲ２、…）を採用する。ハイブリッドリトリーバは、全てのデータセットにおいて最良の語彙的マッチングを達成し、意味情報が語彙的マッチングを補完することができることを明らかにする。
【0084】
意味的マッチングの場合、ＤＰＲは、全てのデータセットに対して最良の結果を達成しているが、これは、同一の目的に向けて最適化されることから、驚くべきことではない。特に、ハイブリッドリトリーバは、ＤＰＲよりもわずかに低い結果を達成するが、ＢＭ２５よりははるかに良好な結果を達成し、これは、ハイブリッドリトリーバが、語彙情報と意味情報の両方のバランスをとり、識別子命名の選択に敏感である語彙ベースのリトリーバよりもロバストであり得ることを意味している。
【0085】
再び図６及び図７を参照すると、ＴＦｉｘ（図６）及びCode Refinement（図７）に関するケーススタディなど、プログラム修復において検索された修正パターンがどのように役立つかを示すためにケーススタディが使用され、ここでは、検索拡張ありのＲＡＰ－Ｇｅｎモデルは正しい修正を予測するが、検索拡張なしのＣｏｄｅＴ５はそうすることができない。図６に示すように、検索されたバグ修正パターンは、正確には、ソースバグ含有コードを修復するために必要とされるものである。検索拡張なしでは、ＣｏｄｅＴ５は、恐らく、前の隣接する行からの学習を介して、バグのある行から「.classify()」を誤って除去する。図７のCode Refinementの場合、検索されたバグ修正ペアは、ソースバグ含有コードを修正するようにＲＡＰ－Ｇｅｎモデルを案内するのに十分な情報を提供する。検索拡張なしでは、ＣｏｄｅＴ５は、単にコードの最後の行を除去することによって、誤った修復を実行する。
【0086】
そのため、パッチリトリーバ及び対応する自動プログラム修復システムの性能を評価するために、定量的（図１３の表６）及び定性的（図６及び図７）の両方の結果が得られる。その結果、ハイブリッドパッチリトリーバは、よりロバストであり、プログラム修復システムを支援するために、語彙的及び意味的に関連するパッチを見つけることができることが示された。
【0087】
図８及び図１５の表７を参照して、様々なエラータイプ及び修正パターンについてのＲＡＰ－Ｇｅｎの性能について説明する。まず、異なるエラータイプに対するその性能の内訳に関して、重複排除されたＴＦｉｘデータセットに対する詳細なプログラム修復性能内訳が、図１５の表７にリストされている。ＣｏｄｅＴ５－ｂａｓｅは、４４／５２のエラータイプにおいて以前のＳｏＴＡ Ｔ５－ｌａｒｇｅよりも性能が優れている。特に、主要なエラータイプ「no-invalid-this」の場合、ＣｏｄｅＴ５－ｂａｓｅは、その完全一致をＴ５－ｌａｒｇｅの３７．４８から４３．５７に改善し、これは、より多くの９８個のインスタンスを修復することに相当する。Ｔ５－ｌａｒｇｅは、５２個のエラータイプのうちの４４％について少なくとも５０％のバグを修復することができるが、ＣｏｄｅＴ５－ｂａｓｅは、このパーセンテージを６０％に大幅に増加させ、ＲＡＰ－Ｇｅｎ－ｓｍａｌｌは、６３％にさらに向上させる。全体で、ＲＡＰ－Ｇｅｎ－ｂａｓｅは、はるかに小さいモデルサイズでＴ５－ｌａｒｇｅよりも多くの４７８個のバグ含有プログラムを正しく修復する。
【0088】
さらに、様々なエラータイプについて、ＣｏｄｅＴ５モデルと比較したＲＡＰ－Ｇｅｎにおける検索拡張の効果を分析する。図１４の表７に示すように、検索拡張技法は、様々なエラータイプに対して異なる効果を有し、特定のエラータイプサブセットに対してはプログラム修復性能を損なうことさえあることが観察される。具体的には、実験において、それは、ＣｏｄｅＴ５－ｓｍａｌｌの１０個のエラータイプ及びＣｏｄｅＴ５－ｂａｓｅの１８個のエラータイプについてＡＰＲ性能をダウングレードする。完全一致修正の数に基づいて、ＲＡＰ－Ｇｅｎ－ｓｍａｌｌの最大の性能ダウングレードは、エラータイプ「no-extra-semi」であり（４９７→４９０）、ＲＡＰ－Ｇｅｎ－ｂａｓｅの最大の性能ダウングレードは、エラータイプ「no-console」である（２２８→２２０）ことが観察される。
【0089】
検索拡張がＲＡＰ－Ｇｅｎモデルにおける完全一致性能を妨げることがある理由を調査するために、「no-console」エラータイプのケーススタディを図８に提供する。この場合、グラウンドトゥルース修正は、バグ含有パッチ内のエラー行を直接除去することであり、ＲＡＰ－Ｇｅｎモデルは、完全一致に関して誤った予測としてカウントされる検索された修正パターンに基づいて、それを異なる形式に修復する。これは、プログラム修復システムを評価するための完全一致メトリックの制限を再び確認するものである。
【0090】
次に、ＴＦｉｘベンチマークを使用して、どの修正パターンがモデルによって実行されるかが分析される。バグ修正ペアを手動で検査した後、修正の大部分は、コード挿入及び置換操作と比較して削除操作から構成されることが観察される。バグ修正動作は、コード挿入（１２．５％）、置換（８．１％）、削除（４７．９％）、挿入と置換（６．９％）、挿入と削除（８．２％）、置換と削除（７．２％）、及び３つ全ての方法（９．２％）から構成される。以前の研究もまた、削除操作が最も一般的な修正パターンの１つであることを反映している。削除動作の中で、１つの支配的なバグ修正パターンは、エラー行除去であり、これは、（図８に示す例のように）バグ含有コードからエラー行を単に除去することである。この自明な修正パターンは、重複排除されたＴＦｉｘテストセットにおいて約２３％を占める。このパターンをさらに分析するために、エラー行除去パターンを使用して異なるモデルがどのように機能するかを比較し、その結果を表８に示す。検索拡張を用いて、ＲＡＰ－Ｇｅｎ－ｂａｓｅが、ＣｏｄｅＴ５－ｂａｓｅの６７及びＴ５－ｌａｒｇｅの７１と比較して、最も低い誤検出数５６（９７．０９という最も高い精度に相当）を達成することを観察する。これは、ＲＡＰ－Ｇｅｎが、自明なエラー行除去パターンに過度に依存するのではなく、より多様なバグ修正パターンを学習することができることを示す。さらに、ＲＡＰ－Ｇｅｎ－ｓｍａｌｌは、最良の再現率及びＦ１スコアを達成するが、その代償として、より多くの誤検出の予測を生じる。
【0091】
要約すると、プログラム修復の難易度は、エラータイプごとに異なる。実験における最良のＲＡＰ－Ｇｅｎ－ｂａｓｅは、最良の性能を発揮するベースラインＴ５－ｌａｒｇｅよりも多くの４５６個のバグ含有プログラムを修復し得る。検索拡張が性能をダウングレードさせることがある理由を分析するためにエラー分析が行われ、それが完全一致メトリックの制限によるものであり得ることを示すためにケーススタディが提供される。さらに、エラー行除去の１つの高頻度修正パターンを調査して、このパターンを扱う際に、ＲＡＰ－Ｇｅｎ－ｂａｓｅが最良の精度スコアを与え、ＲＡＰ－Ｇｅｎ－ｓｍａｌｌが最良の再現及びＦ１スコアを達成することを示す。
【0092】
本発明の態様、実施形態、実装形態、又は適用例を示すこの説明及び添付の図面は、限定するものと解釈されるべきではない。本明細書及び特許請求の範囲の趣旨及び範囲から逸脱することなく、様々な機械的、組成的、構造的、電気的、及び動作的な変更を行うことができる。いくつかの事例では、周知の回路、構造、又は技法は、本開示の実施形態を不明瞭にしないために、詳細に図示又は説明されていない。２つ以上の図における同様の番号は、同じ又は同様の要素を表す。
【0093】
この説明では、本開示と一致するいくつかの実施形態を説明する具体的な詳細が記載される。実施形態の完全な理解を提供するために、多数の具体的な詳細が記載される。しかしながら、いくつかの実施形態は、これらの具体的な詳細の一部又は全部がなくても実施され得ることが当業者には明らかであろう。本明細書に開示される特定の実施形態は、例示的なものであり、限定するものではない。当業者は、本明細書では具体的に説明されていないが、本開示の範囲及び趣旨内にある他の要素を実現し得る。加えて、不必要な反復を回避するために、一実施形態に関連して図示及び説明される１つ又は複数の特徴は、具体的に別様に説明されない限り、又は１つ又は複数の特徴が実施形態を非機能的にするであろう場合、他の実施形態に組み込まれてもよい。
【0094】
例示的な実施形態が示され、説明されてきたが、広範囲の修正、変更、及び置換が前述の開示において企図され、いくつかの事例では、実施形態のいくつかの特徴は、他の特徴の対応する使用なしに採用され得る。当業者であれば、多くの変形、代替、及び修正を認識するであろう。従って、本発明の範囲は、以下の特許請求の範囲によってのみ限定されるべきであり、特許請求の範囲は、広く、本明細書に開示された実施形態の範囲と一致するように解釈されることが適切である。
【図1】
【図2】
【図3】
【図4A】
【図4B】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図14-1】
【図15】
【国際調査報告】