大規模言語モデルを使用した遺伝子改良突然変異の強化

コンテンツの概要

• 抽象的な
• 導入
• 実験のセットアップ
• 結果
• 結論と今後の課題
• 参考文献

抽象的な

大規模言語モデル (LLM) は、プログラム修復などのソフトウェア エンジニアリング タスクにうまく適用されています。ただし、遺伝子改良 (GI) などの検索ベースの技術への応用は、まだほとんど解明されていません。この論文では、検索プロセスを改善するために、GI の突然変異演算子として LLM の使用を評価します。 Gin Java GI ツールキットを拡張して、OpenAI の API を呼び出して JCodec ツールの編集を生成します。 5 つの異なる編集タイプを使用して、編集スペースをランダムにサンプリングします。 LLM ベースの編集では、単体テストに合格するパッチの数が、標準の挿入編集よりも最大 75% 高いことがわかりました。さらに、LLM で見つかったパッチは、一般に標準的な編集に比べて多様性が低いことがわかります。ランタイムの改善点を見つけるために、ローカル検索を使用して GI を実行しました。多くの改善パッチは LLM 拡張 GI によって検出されますが、最良の改善パッチは標準 GI によって検出されました。

導入

ソフトウェア システムが大規模かつ複雑になるにつれて、システムを保守するには多大な手作業が必要になります [2]。ソフトウェアのメンテナンスと最適化タスクにおける開発者の労力を軽減するには、自動化されたパラダイムが不可欠です。 Genetic Improvement (GI) [15] は、検索ベースの技術を適用して、実行時間などの既存のソフトウェアの非機能的特性や、バグの修復などの機能的特性を改善します。 GI は業界で成功を収めています [12,13] が、検索で使用する一連の突然変異演算子によって制限されたままです [14]。

大規模言語モデル (LLM) は、当面の特定のタスクについて追加のトレーニングを行わなくてもテキスト クエリを処理できるため、幅広い用途があります。 LLM は、さまざまなプログラミング言語にわたる何百万ものコード リポジトリで事前トレーニングされています [5]。ソフトウェアエンジニアリングタスクへのそれらの使用は大きな成功を収めており[9,6]、プログラム修復にも有望であることが示されています[17,19]。

Kang と Yoo [10] は、GI を強化するために LLM を使用することには未開発の可能性があることを示唆しています。 GI は、さまざまな最適化タスクに同じ突然変異演算子を使用します。これらの演算子は検索を開始する前に手動で作成されるため、検索スペースが制限されます。私たちは、追加の突然変異オペレーターとして LLM パッチの提案を強化すると、検索空間が豊かになり、より成功するバリアントが得られるという仮説を立てています。

この論文では、GI の突然変異オペレーターとして LLM を使用することで検索の効率と有効性が向上するかどうかを調べるためにいくつかの実験を行います。結果は、LLM で生成されたパッチのコンパイル率が、ランダム検索とローカル検索でそれぞれ 51.32% と 53.54% であることを示しています (中プロンプト カテゴリの場合)。以前の LLM (LLM モデルをそのまま使用) は、約 40% の時間でコンパイルされるコードを生成することが示されていました [16,18]。ランダムにサンプリングされた LLM ベースの編集は、標準の GI 編集と比較して、より頻繁にコンパイルされ、単体テストに合格することがわかりました。単体テストに合格したパッチの数は、GI 挿入編集よりも LLM ベースの編集の方が最大 75% 高いことがわかります。ただし、LLM で見つかったパッチは多様性が低いことが観察されています。ローカル検索の場合、標準の GI ステートメント編集を使用して、次に LLM ベースの編集を使用すると、最良の改善が達成されます。これらの発見は、突然変異オペレーターとしての LLM の可能性を実証し、この分野におけるさらなる研究の必要性を強調しています。

実験のセットアップ

GI における突然変異オペレーターとしての LLM の使用を分析するために、OpenAI による GPT 3.5 Turbo モデルと GI ツールボックス Gin [3] を使用しました。私たちは、Gin 内に実装された 2 種類の検索 (ランダム検索とローカル検索) を実験しました。 OpenAI API を使用した LLM へのリクエストは、Langchain4J ライブラリ経由であり、温度は 0.7 でした。私たちの実験における改善の対象プロジェクトは、Java で書かれた人気のある JCodec [7] プロジェクトでした。編集の対象となる「ホット」メソッドは、Gin のプロファイラー ツールを使用してプロファイリングを 20 回繰り返し、結果のセットの和集合を取得することで特定されました。

ランダム サンプリング実験では、ステートメント レベルの編集 ([14] からコピー/削除/置換/交換、[4] からブレーク/続行/リターンを挿入) と LLM 編集を使用して実行を設定し、各タイプをランダムに 1000 個生成しました。 。編集によって導入された無限ループを捕捉するために、各単体テストで 10000 ミリ秒のタイムアウトが使用されました。タイムアウトを超えるとテスト失敗としてカウントされます。ローカル検索の場合も同様に実験が設定されました。 10 回の反復実行 (上位 10 のホットなメソッドごとに 1 回) がありましたが、実行は 100 回の評価に制限されており、結果として合計 1000 回の評価となり、ランダム検索と一致しました。最初の編集はパッチが適用されていない元のコードの時間を測定するために使用されたため、実際には、実行ごとに 99 回の編集が行われました。

両方のタイプの検索について、LLM にリクエストを送信するための 3 つの異なるプロンプト (単純なプロンプト、中程度のプロンプト、および詳細なプロンプト) を試しました。 3 つのプロンプトすべてで、実装ではコードの 5 つの異なるバリエーションが要求されます。単純なプロンプトでは、追加情報なしでコードのみが要求されます。図 1 に示すように、中程度のプロンプトでは、提供されたコードと要件に関する詳細情報が表示されます。具体的には、使用するプログラミング言語、コードが属するプロジェクト、およびフォーマット指示が LLM に提供されます。詳細プロンプトは、有用な変更の例を示して中プロンプトを拡張します。この例は、Brownlee らによって得られた結果から取られました。 [4]。このパッチは、jCodec プロジェクトに適用された挿入編集の成功例です (つまり、コンパイルされ、単体テストに合格し、元のコードよりも高速化された編集)。実験で使用したすべての詳細なプロンプト リクエストに同じ例を使用します。これは、LLM はユーザーが特定の情報を提示する帰納的推論が可能であり、LLM はその入力を使用してより一般的なステートメントを生成できるためであり、GPT-4 [8] でさらに改良されました。

LLM 編集は、ターゲットの「ホット」メソッドでブロック ステートメントをランダムに選択することによって適用されます。このブロックの内容はin the prompt. The first code block in the LLM response is identified. Gin uses JavaParser (https://javaparser.org) internally to represent target source files, so we attempt to parse the LLM suggestion with JavaParser, and replace the original block with the LLM suggestion.

結果

最初の実験では、標準的な GI 変異、つまり挿入編集とステートメント編集を、ランダム サンプリングを使用した異なる詳細なプロンプト (単純、中、詳細) を使用した LLM 編集と比較します。表 1 は、すべてのパッチと固有のパッチのみの結果を示しています。 JavaParser によって正常に解析されたパッチの数 (Valid という名前)、コンパイルされたパッチの数、およびすべての単体テストに合格したパッチの数 (Passed という名前) が報告されます。元のソフトウェアと構文的に同等のパッチは除外しました。最良の結果は太字で示されています。

標準の挿入およびステートメント編集では実質的により多くの有効なパッチが見つかったが、LLM で生成された編集を使用するとより多くの合格パッチが見つかることがわかります。特に、中プロンプトと詳細プロンプトでは、それぞれ 292 個のパッチと 230 個のパッチが単体テストに合格しました。挿入編集とステートメント編集では、それぞれ 166 と 91 のみが単体テストに合格しました。逸話ですが、パッチ合格率が最も低い/最も高いホットメソッドはオペレータごとに異なります。この変動を理解することは、将来の調査にとって興味深いでしょう。

LLM パッチの多様性が低いことも注目に値します。標準の突然変異オペレーターによって、Medium を使用した LLM よりも 50% 以上多くの固有のパッチが見つかりました。

詳細なプロンプト。ただし、Simple プロンプトでは、提案された編集内容が解析できないことが多いため、単体テストに合格したパッチは 1 つもありませんでした。したがって、LLM に使用可能な出力を生成させるには、詳細なプロンプトが必要です。

私たちは、Medium と Detailed プロンプトの違いをさらに調査し、Medium の方がコンパイルされて渡されたパッチの数が多かったため、Detailed (固有のパッチ セット内) でのパフォーマンスの低下を理解しました。どちらのプロンプト レベルでも、生成された応答は 42 のケース (一意の有効なケースの合計のうち) で同じでした。ただし、Detailed では平均 363 文字の長い応答が生成される傾向にありましたが、Medium では平均 304 文字でした。私たちはいくつかの詳細なプロンプト応答を手動で検査し、その中で他のファイルからの変数を含むいくつかの変数を特定しました。これにより、GI が探索できるコード バリアントのセットが大幅に拡張される可能性があります。

2 番目の実験では分析を拡張し、ローカル検索を使用した標準編集と LLM 編集のパフォーマンスを比較します。表 2 は、ローカル検索実験の結果を示しています。コンパイルおよび通過したパッチの数と、実行時の改善が見つかったパッチの数を報告します。さらに、改善の中央値と最良の値をミリ秒 (ms) 単位で報告します。表では、空のパッチをすべて除外しました。前と同様、最良の結果は太字で表示されます。

繰り返しますが、LLM で [中] および [詳細] プロンプトを使用すると、単体テストに合格したより多くのパッチを見つけることができることがわかります。さらに、これらのプロンプトで LLM を使用すると、さらに改善が見られる可能性があります。具体的には、「中」と「詳細」では、それぞれ 164 件と 196 件の改善が見つかりましたが、挿入では 136 件、ステートメントでは 71 件のみが見つかりました。ステートメント編集では 508 ミリ秒で最高の改善が見られました。 LLM を使用した場合 (中プロンプトを使用) に最も優れた改善が見られましたが、実行時間は 395 ミリ秒しか改善できませんでした。また、詳細プロンプトの応答のコンパイル率が低いため、中プロンプトと詳細プロンプトの違いについて洞察を得るために、ローカル検索結果の一連の編集を調査しました。この例では、一連の編集は関数クリップへの呼び出しをインライン化することを目的としています。詳細プロンプトは、数回の編集でほぼ即座に呼び出しを組み込もうとしたため、無効なコードが発生した可能性があります。一方、Medium プロンプトではそれほど根本的な変更は加えられず、徐々にコードが改良されました。まず、三項演算子式を if-then-else ステートメントとシステム関数呼び出しに置き換えてから、最終的にクリップ関数呼び出しをインライン化しようとしました。

結論と今後の課題

ソフトウェアの遺伝的改良は、検索プロセスで利用する突然変異オペレーターに大きく依存します。演算子を多様化し、検索空間をさらに充実させるために、演算子として大規模言語モデル (LLM) を組み込みました。

制限事項。一般的に言えば、今後の作業では、ターゲットである jCodec 以外のプロジェクトも考慮する必要があります。私たちの実験では API を使用しており、LLM によって生成された応答を制御したり、応答を変更したり最適化したりすることはできませんでした。実験中に動作の変化は観察されませんでしたが、OpenAI はいつでもモデルを変更する可能性があるため、今後の作業ではローカル モデルを考慮する必要があります。 LLM リクエストに対して 3 つのプロンプト タイプのみを使用して実験したところ、この限られた数のプロンプト内で結果にばらつきがあることがわかりました。最後に、LLM からの応答を解析するための実装は比較的単純でした。ただし、これは、報告された結果が悲観的であることを意味するだけであり、LLM ベースのオペレーターによってさらに大きな改善が達成される可能性があります。

まとめ。ランダム サンプリングを使用した標準編集ではより有効で多様なパッチが見つかったが、LLM ベースの編集では単体テストに合格したより多くのパッチが見つかったことがわかりました。たとえば、中プロンプトを使用した LLM 編集では、従来の挿入編集よりも 75% 以上多くのパッチが単体テストに合格することがわかりました。ローカル検索の実験では、ステートメント編集 (508 ミリ秒) で最も優れた改善が見られました。 LLM ベースの改善が最も優れていたのは、中プロンプト (395 ミリ秒) でした。したがって、LLM と「クラシック」GI 編集の両方を組み合わせたアプローチを検討する可能性があります。

私たちの実験により、LLM リクエストに使用されるプロンプトが結果に大きく影響することが明らかになりました。したがって、今後の作業では、迅速なエンジニアリングをさらに実験していきたいと考えています。プロンプトを混合することも役立つ場合があります。たとえば、中程度から始めて詳細に切り替えて、極小値を超える大規模な編集を行います。さらに、LLM 編集を標準のコピー/削除/置換/交換や PAR テンプレート [11] などの他の編集と組み合わせる可能性も興味深いかもしれません。最後に、追加のテスト プログラムでさらに広範な実験を実施したいと考えています。

データの可用性。コード、LLM プロンプトおよび実験インフラストラクチャ、評価からのデータ、および結果は、オープンソースとして [1] から入手できます。このコードは、github.com/gintool/gin の「llm」ブランチにもあります (コミット 9fe9bdf; マスター コミット 2359f57 からブランチされ、Gin との完全な統合が保留されています)。

謝辞UKRI EPSRC EP/P023991/1 および ERC 741278。

参考文献

1. 大規模な言語モデルを使用して遺伝子改良突然変異を強化するアーティファクト。ゼノド (2023 年 9 月)。 https://doi.org/10.5281/zenodo.8304433

   
   

2. B¨ohme, M.、Soremekun, EO、Chattopadhyay, S.、Ugherughe, E.、Zeller, A.: バグはどこにあり、どのように修正されていますか?実践者による実験です。で:Proc.ソフトウェアエンジニアリングの基礎に関する ACM シンポジウム。 pp.117–128 (2017)

   
   

3. Brownlee, AE、Petke, J.、Alexander, B.、Barr, ET、Wagner, M.、White, DR: ジン: 遺伝子改良研究が容易になりました。で：GECCO。 pp. 985–993 (2019)

   
   

4. Brownlee, AE、Petke, J.、Rasburn, AF: Java コードをより高速に実行するためのショートカットを挿入します。で: IEEE CEC 2020。p. 1～8

   
   

5. Chen, M.、Tworek, J.、Jun, H.、Yuan, Q.、Pinto, HPdO、Kaplan, J.、Edwards, H.、Burda, Y.、Joseph, N.、Brockman, G. 他al.: コードでトレーニングされた大規模な言語モデルの評価。 arXiv プレプリント arXiv:2107.03374 (2021)

   
   

6. Fan, A.、Gokkaya, B.、Harman, M.、Lyubarskiy, M.、Sengupta, S.、Yoo, S.、Zhang, JM: ソフトウェア エンジニアリングのための大規模言語モデル: 調査と未解決の問題 (2023)

7. Github - jcodec/jcodec: Jcodec メイン リポジトリ、 https://github.com/jcodec/jcodec

   
   

8. Han、SJ、Ransom、KJ、Perfors、A.、Kemp、C.: 人間と大規模な言語モデルにおける帰納推論。認知システム研究 p. 101155 (2023)

   
   

9. Hou, X.、Liu, Y.、Yang, Z.、Grundy, J.、Zhao, Y.、Li, L.、Wang, K.、Luo, X.、Lo, D.、Wang, H.:ソフトウェアエンジニアリングのための大規模言語モデル: 体系的な文献レビュー。 arXiv:2308.10620 (2023)

   
   

10. Kang, S.、Yoo, S.: 大規模な言語モデルを通じた、目的に合わせた遺伝的改善に向けて。 arXiv:2304.09386 (2023)

    
    

11. Kim, D.、Nam, J.、Song, J.、Kim, S.: 人間が書いたパッチから学んだ自動パッチ生成 (2013)、 http://logging.apache.org/log4j/

    
    

12. キルバス、S.、ウィンデルス、E.、マクベロ、O.、ケルズ、K.、パガーノ、M.、シャランスキー、R.、ノワック、V.、ウィンター、E.、カウンセル、S.、ボウズ、D.、 Hall, T.、Haraldsson, S.、Woodward, J.: ブルームバーグにおける自動プログラム修復の導入について。 IEEE ソフトウェア 38(4)、43–51 (2021)

    
    

13. Marginean, A.、Bader, J.、Chandra, S.、Harman, M.、Jia, Y.、Mao, K.、Mols, A.、Scott, A.: Sapfix: 自動エンドツーエンド修復規模。 ICSE-SEIP で。 pp.269–278 (2019)

    
    

14. Petke, J.、Alexander, B.、Barr, ET、Brownlee, AE、Wagner, M.、White, DR：Gin を使用した自動プログラム変更のためのプログラム変換ランドスケープ。経験的ソフトウェア工学 28(4)、1–41 (2023)

    
    

15. Petke, J.、Haraldsson, SO、Harman, M.、Langdon, WB、White, DR、Woodward, JR: ソフトウェアの遺伝的改良: 包括的な調査。進化的計算に関する IEEE トランザクション 22、415–432 (2018)

    
    

16. Siddiq, ML、Santos, J.、Tanvir, RH、Ulfat, N.、Rifat, FA、Lopes, VC: 単体テストの生成における大規模な言語モデルの有効性を調査します。 arXiv プレプリント arXiv:2305.00418 (2023)

    
    

17. Sobania, D.、Briesch, M.、Hanna, C.、Petke, J.: chatgpt の自動バグ修正パフォーマンスの分析。開催日: 2023 年の自動プログラム修復 (APR) に関する IEEE/ACM 国際ワークショップ。 23～30ページ。 IEEE コンピュータ協会 (2023)

    
    

18. Xia、CS、Paltenghi、M.、Tian、JL、Pradel、M.、Zhang、L.: 大規模な言語モデルによるユニバーサル ファジング。 arXiv プレプリント arXiv:2308.04748 (2023)

    
    

19. Xia、CS、Zhang、L.: 会話を続けましょう: chatgpt を使用して 337 件のバグのうち 162 件を 1 件あたり 0.42 ドルで修正します。 arXiv プレプリント arXiv:2304.00385 (2023)