【論文】2023 Large Language Models for Software Engineering: Survey and Open Problems
[2310.03533] Large Language Models for Software Engineering: Survey and Open Problems
要旨
本論文は、ソフトウェアエンジニアリング（SE）分野における大規模言語モデル（LLM）の新たな応用領域に関する調査を提供します。また、ソフトウェアエンジニアが直面する技術的課題にLLMを適用するための今後の研究課題も提示します。LLMの新たに生じた特性は、コーディング、設計、要求仕様、修復、リファクタリング、パフォーマンス改善、ドキュメント作成、および分析など、ソフトウェアエンジニアリング活動全体にわたり、斬新で創造的な応用可能性をもたらします。しかし、これらの特性は同時に大きな技術的課題も伴い、ハルシネーションのような誤った解答を排除するための信頼性ある手法が求められています。我々の調査は、信頼性が高く効率的で効果的なLLMベースのSEシステムを開発・導入する上で、従来のSEとLLMを組み合わせたハイブリッド技術が重要な役割を果たすことを明らかにしています。
Introduction
本論文は、大規模言語モデル（LLM）をソフトウェアエンジニアリング（SE）に応用する分野における最新の進展、技術的な進歩、および実証的な結果を調査したものです。この調査を通じて、急速に発展しているものの、まだ初期段階にあるこの研究分野における空白を浮き彫りにしています。また、文献におけるギャップや技術的な機会に基づき、ソフトウェアエンジニアリング研究コミュニティにとっての未解決の問題や課題も特定しています。
この急速に拡大する分野を網羅することは難しいものの、本調査がSEにおける新たなLLMベースの分野の初期段階の全体像を把握するのに役立つことを期待しています。この分野の科学的・技術的な構造はまだ形成されつつありますが、既に今後の研究の方向性や取り組むべき技術的な課題、また、将来に向けた有望な研究の道筋を確認することが可能です。
特に、ソフトウェアエンジニアリングの既存のトレンドや確立されたアプローチ、サブディシプリン（分野）との関連性や共鳴が見受けられます。また、技術的な課題も多く存在する一方で、この分野の未来には楽観的な要素も少なくありません。多くの研究者が科学的にも、また経験則としても指摘しているように、幻覚（ハルシネーション）問題はLLMの普遍
的な課題であり、特にLLMベースのSEにおいて顕著な問題です。幻覚とは、LLMが架空の出力を生成してしまうことを意味し、SEの文脈では、生成された成果物が誤っているにもかかわらず、正しそうに見えることを指します。このようにして、LLMがバグを導入する可能性があります。
しかし、他のLLM応用分野とは異なり、ソフトウェアエンジニアには自動化可能な真実（すなわちソフトウェアの実行結果）があり、ほとんどのSE成果物を評価する際の基準として使用できます。さらに、SE研究コミュニティは既に、人間が生み出す誤った結果を検証するための自動・半自動の技術開発に多大な努力を払ってきました。これにより、幻覚などの問題に対処するための豊富な経験と専門知識が蓄積されています。
もちろん、既に人間が設計した成果物の正確性を保証するために用いられているように、自動テスト技術も重要な役割を果たすでしょう。しかし、新しい機能やシステムを完全に生成する場合、自動テストデータ生成には「オラクル問題」（ある入力に対する出力が正しいかどうかを判断する自動化技術）が障害となります。LLMがハルシネーションを引き起こしやすいことを考慮すると、オラクル問題は今後さらに重要な課題となり、その解決が一層影響力を持つことになります。
一方で、既存のソフトウェアシステムの適応、改良、および開発を対象とするSE応用の一部には、容易に自動化可能なオラクル、すなわち元のシステムの機能的な動作が利用可能です。
本論文では、このアプローチを「自動回帰オラクル」と呼んでおり、これはすでに遺伝的改良の分野で有効性が証明されています【8】。自動回帰オラクルは、ソフトウェアシステムの既存バージョンを参照として用い、その後の改良や変更の出力を評価します。ただし、システムが「本来あるべき」動作ではなく「現状の」動作のみを基準とするため、機能的な誤りを組み込んでしまうリスクがあります。このため、自動回帰オラクルは機能回帰のテストに限られるため、既存の機能を維持するケース、例えば性能向上や意味を保持するリファクタリングといった非機能的改善に適しています。
LLMへの入力は今後の研究の中心的テーマとなり、プロンプトエンジニアリングおよびプロンプト最適化に関する文献が急速に発展すると予想されます【9】。本調査では、ソフトウェアエンジニアリングにおけるプロンプトエンジニアリングに関連する既存の研究と未解決の課題を強調します。
LLMの出力はコードに限定されず、要求仕様、テストケース、設計図、ドキュメントといった他のソフトウェアエンジニアリング成果物も含めることが可能です。一般に、LLMは言語を基盤とした性質を持つため、言語で定義されるあらゆるソフトウェアエンジニアリング成果物を生成することができます。
通常、LLMの出力としてソフトウェアエンジニアリング成果物が主要な結果と見なされますが、これは唯一の出力ではありません。主要な出力に付随する説明もLLMの重要な出力です。本調査では、プロンプトエンジニアリング（LLMへの入力の最適化）だけでなく、主要な出力に付随する説明の最適化に対するさらなる研究の必要性も指摘しています。
LLMは本質的に非決定的であり、同じプロンプトでも実行するたびに異なる結果を生じます（温度設定がゼロでない限り。温度ゼロは複数回の実行で最適でないとされることが多い）【10】。さらに、温度設定にかかわらず、プロンプトの微妙な変更でも大きく異なる出力をもたらすことがあります【10】。この非決定的な挙動は、プロンプトエンジニアリングや出力処理への動機付けとなると同時に、LLMベースのソフトウェアエンジニアリングの科学的評価においても課題を提起します。
例えば、「プロセスを実行するたびに結果が異なる場合、提案された技術が最先端よりも進展しているかどうかをどのように判断するのか？」という問題です。この問題は、経験的ソフトウェアエンジニアリング【11】や探索ベースのソフトウェアエンジニアリング（SBSE）【12】の文脈で既に詳細に研究されています。特に、SBSEはLLMベースのソフトウェアエンジニアリングと多くの類似点を持ち、雑音の多い、非決定的、かつ不完全な結果においても堅牢な科学的評価を達成する必要があります【13】【14】。したがって、LLMベースの科学的評価に必要な堅牢な科学的評価技術に関する成熟した文献が既に存在します。
例えば、SBSE分野では、パラメトリックおよびノンパラメトリックな推測統計などの研究が進んでおり、非決定的アルゴリズムにおいても堅牢な科学的結論を提供するための手法として一般的に使用されています。
LLMベースのソフトウェアエンジニアリングの成長トレンドを理解するため、arXiv上で特定のトピックに関する論文数のデータを手動で分析しました。表Iには、2023年7月27日にKaggle（https://www.kaggle.com/datasets/Cornell-University/arxiv）で公開されたarXivメタデータダンプから手動で抽出した生データが含まれています。まず、分類コードが「cs」プレフィックス（コンピュータサイエンス）で始まらない論文を除外し、A列のデータを作成しました。
次に、LLMに関連するコンピュータサイエンス論文を特定するため、人工知能（cs.AI）、機械学習（cs.LG）、ニューラル・進化計算（cs.NE）、ソフトウェアエンジニアリング（cs.SE）、およびプログラミング言語（cs.PL）のサブカテゴリに分け、「Large Language Model」、「LLM」、および「GPT」という語句をタイトルまたは要旨に含むものを抽出し、L列のデータを作成しました（「GPT」が一般計画ツール（General Planning Tool）を指すものは手動で除外）。
最後に、同様の語句でソフトウェアエンジニアリング（cs.SE）およびプログラミング言語（cs.PL）におけるLLMベースのソフトウェアエンジニアリング論文を特定しました。これらのクエリは概算的なものなので、得られた数値の詳細ではなく、全体的な傾向に基づいて強い証拠のある結論に限定しています。それでもなお、他の研究者による再現性をサポートするため、観測された生データも報告しています。
図2は、コンピュータサイエンスに関するarXiv掲載論文数（青の|A|）およびLLMに関する論文数（オレンジの|L|）の増加を示しています。特にソフトウェアエンジニアリングとLLMに関する論文は緑（|L ∩ S|）で表されています。全体の出版量が急増しているため、縦軸は対数スケールで示されています。予想通り、コンピュータサイエンス全体の論文数も増加傾向にあります。また、最近のLLMに対する注目の高まりから、LLMに関する論文数が指数的に増加しているのも特段驚くことではありません。
注目すべきは、図中の緑色で示されたように、LLMのソフトウェアエンジニアリングへの応用が急速に進んでいることです。この傾向をさらに詳しく調べるため、図3においては、すべてのコンピュータサイエンス論文に対するLLM論文の割合（青色）と、すべてのLLM論文に対するLLMベースのソフトウェアエンジニアリング論文の割合（オレンジ色）を示しています。ご覧の通り、2019年以降、LLMベースのソフトウェアエンジニアリングに関する論文の割合が急激に増加しており、既にすべてのLLM論文の10%以上がLLMベースのソフトウェアエンジニアリングに関するものとなっています。
この成長を受けて、今後もLLMベースのソフトウェアエンジニアリング（LLM-Based SE）に関する多数の調査が予想されます。文献が急速に拡大しているため、SE全体を網羅する研究を1本の論文に収めることは難しいでしょうが、特定のサブ領域を詳細に扱った包括的な調査や、系統的文献レビュー（SLR）によって、一次文献を系統的に整理し、SE全体に関連する横断的な課題を特定することが期待されます。実際、すでにこのようなSLRも出始めています。例えば、Houら【15】は、2017年から2023年にかけての229本の研究論文を網羅した優れたSLRを提供し、LLMによって取り組まれたSEタスクやデータ収集・前処理手法、プロンプトエンジニアリングなどLLM性能の最適化戦略を報告しています。
本論文の残りの部分は、図1に示されたトップレベルのソフトウェア開発活動および研究領域に従って構成されています。
PRELIMINARIES
LLM
大規模言語モデル（LLM）は、大量のデータで訓練されたAIモデルであり、人間のような文章生成が可能です。論文の独立性を確保するため、LLMの用語集を表IIIに掲載しています。
LLMは通常、トランスフォーマーなどのディープラーニング技術に基づいており、有用な言語出力を生成する能力を持っています。そのため、テキスト生成【16】、質問応答【17】、翻訳【18】、要約【19】、感情分析【20】といった幅広い言語関連のタスクを実行可能です。
Rumelhartら【21】はリカレントニューラルネットワーク（RNN）の概念を提唱し、順序データの処理の可能性を開きました。さらに、HochreiterとSchmidhuber【22】がRNNの拡張として導入したLong Short Term Memory（LSTM）アーキテクチャは、多くの応用で性能を大幅に向上させました。
2017年にVaswaniら【23】が導入したトランスフォーマーアーキテクチャは、自己注意メカニズムにより単語間の関係を捉えることができ、言語モデルに大きな影響を与え、LLMに関する研究が急増するきっかけとなりました。
2018年にOpenAIは生成型事前学習トランスフォーマー（GPT）モデルを発表し、以降GPT-2、GPT-3、GPT-3.5、GPT-4と続きました。特にGPT-3およびGPT-3.5では、生成性能が大きく向上したことから、GPT（およびChatGPT）への関心が高まり、LLM全体への注目も集まりました。
LLMが高い性能を発揮できるのは、大規模なコーパスで訓練されていることに一因があります。例えば、GPT-3は45TBのテキストデータで訓練され、1750億のパラメータを持っています。Meta社は2023年2月にLLaMAをオープンソースで公開しました。このモデルは1.4兆のトークンで訓練され、モデルサイズも70億から650億パラメータにわたります【24】。
Categories of Large Language Models
大規模言語モデル（LLM）は以下の3つのカテゴリに分類されます：
エンコーダのみのモデル：オートエンコーダとも呼ばれ、エンコーダーネットワークで構成されており、デコーダーネットワークはありません。入力シーケンスを受け取り、それを低次元の表現にマッピングします。オートエンコーダの目的は、入力データのエンコードを学習することです。エンコーダのみのLLMの例には、GoogleのBERT、MetaのRoBERTa、MicrosoftのDeBERTaがあります【1】。
エンコーダ・デコーダモデル：エンコーダーネットワークに加え、デコーダーネットワークも備えています。デコーダーはコンテキストベクターと生成済みトークンを基に、トークンまたはシンボルを逐次生成して出力シーケンスを作成します。機械翻訳やテキスト生成などのタスクに適用可能です。エンコーダ・デコーダLLMの例には、GoogleのT5やMetaのBARTがあります【1】。
デコーダのみのモデル：他の2つのLLMタイプとは異なり、デコーダのみのLLMには入力データを処理するエンコーダコンポーネントがなく、デコーダのみで構成されています。デコーダは、与えられたコンテキストまたは入力に基づいて直接出力シーケンスを生成します。通常、オートレグレッシブモデルといったアーキテクチャに基づき、トークンごとに出力を生成します。デコーダが生成する各トークンは、前に生成されたトークンとコンテキストに依存しています。
デコーダのみのモデルの代表例には、OpenAIが開発したGPT（Generative Pre-trained Transformer）シリーズ、MetaのLLaMA、AnthropicのClaude、GoogleのPaLMがあります【1】。
Large Language Models for Software Engineering
LLMは自然言語関連のタスクに広く応用されてきましたが、プログラミング言語を扱うソフトウェア開発タスクへの応用も最近大きな注目を集めています。
2021年にOpenAIはGPT-3を微調整したモデルCodeXを発表し、GitHubのCopilotで使用されています。CopilotはVisual Studio Code、Visual Studio、Neovim、JetBrainsのユーザーに対しコード補完機能を提供します。最新版のCopilot、GitHub Copilot XはGPT-4をベースにしています。2023年2月、GitHubは開発者が記述したコードの平均46%がCopilotによって生成されたと報告しており【25】、Javaに関してはその割合が62%にも上ります。GitHubのCEO、トーマス・ドームケ氏は、2023年6月に「近い将来、Copilotが80%のコードを生成するようになる」と述べました【26】。
2022年にはDeepMindがAlphaCodeを発表しました【27】。AlphaCodeは、GitHub上の公開リポジトリから選定されたデータを用い、400億のパラメータで訓練されており、シミュレーション評価で5,000人以上の参加者がいるコンテストにおいて、平均で上位54%の順位を達成しています。
最新のGPTモデルであるGPT-4もコード生成機能を備えています。GPT-4の技術レポートによれば、OpenAIの164個のプログラミング問題で構成されたオープンソースデータセット「HumanEval」におけるゼロショットのpass@1精度は67%です【28】。また、100のLeetCode問題を使ったベンチマークでは、GPT-4は人間の開発者に匹敵する性能を示しました【29】。
2023年8月24日には、MetaがCode Llamaをオープンソースでリリースしました【30】。Code Llamaは、公開されているLLMの中でもコーディングタスクにおける最先端のモデルとされています。
表IIには、自然言語による指示に基づきコードの生成や補完を行うために設計された代表的なLLMが一覧で示されています。
REQUIREMENTS ENGINEERING AND DESIGN
要求工学（リクワイアメントエンジニアリング）は、ソフトウェアエンジニアリングにおける重要な分野です。この分野は、ソフトウェアエンジニアが構築するシステムの技術的属性と、そのシステムが構築される目的を結びつける根幹を成します。要求工学に関する文献は成熟しており、関連する問題に取り組む大規模な研究コミュニティも存在します【31】。
また、人工知能を用いて要求工学を支援する取り組みも以前から行われており、特に要求工学における計算検索の形での研究が注目されています【32】。しかし、これまでのところ、LLMベースのソフトウェアエンジニアリングに関する新しい文献で要求工学が取り上げられることは少ない状況です。
Zhangら【33】は、ChatGPTのゼロショットによる要求検索性能を4つのデータセットを用いた2つの要求分析タスクで予備的に評価しました。これらの結果はまだ初期段階ですが、LLMが効率的かつ効果的な要求工学を支援する可能性について楽観的な見通しを示しています。Luoら【34】は、BERTを用いて要求の自動分類に対応するプロンプトエンジニアリングを行いました。Luitelら【35】は要求の完全性に注目し、BERTを使用して要求内の空欄を埋める予測を生成しました。
Open Problems in LLMs for Requirement Engineering
他のソフトウェア開発活動と異なり、LLMベースの要求工学や設計に関する研究はあまり見当たりませんでした。実際、高レベルの設計目標に対してLLMに依存することに慎重なエンジニアが多いという証拠もあります【36】。したがって、この未開拓の研究分野をさらに発展させる大きな機会があると考えられます。
現在、LLMの応用は主にコード生成やテスト、修復といったタスクに集中しており、これらのタスクはLLMのコード生成能力による恩恵を受けています。しかし、LLMは自然言語処理能力を備えているため、要求工学活動の支援にも大きな可能性を秘めています。
例えば、トレーサビリティはソフトウェアエンジニアリングにおける長年の横断的な課題です。特に、要求とコードやテストなどの他のエンジニアリング成果物との間のトレーサビリティリンクを特定することは、要求が自然言語で書かれているため非常に難しいのですが、LLMにとっては自然に適した分野と言えます。
CODE GENERATION AND COMPLETION
ソフトウェアエンジニアリングにおけるLLMの応用分野の中で、コード補完はこれまでで最も徹底的に研究されてきた分野です。LLMが登場する以前から、既存のコードリポジトリから学ぶことが、成功したインテリジェントなコード補完の鍵であるとされていました【37】。事前学習済みのLLMは、この初期の期待に応える成果を上げています。LLMの一般的な弱点として幻覚（ハルシネーション）が指摘されていますが、コード補完のタスクでは、開発者に対する推奨システムとして機能するため、幻覚の問題を回避できます。開発者がコードベースに幻覚出力が入り込むのを防ぐ役割を担うのです。
もちろん、幻覚の頻度が高ければコード補完の推奨システムは効果を発揮しないでしょう。しかし、広範な迅速な導入とコード補完に関するすでに報告されている好意的な結果は、その懸念が杞憂であったことを示しています。例えば、Muraliら【38】は、MetaでIncoder LLM【39】を基にしたコード補完ツールCodeComposeの展開経験を報告しており、15日間で450万回のコード補完提案があり、開発者の受け入れ率は22%でした。質的なフィードバックも92%が肯定的でした。同様に、Pengら【40】は、GitHub Copilotを使用した場合、JavaScriptでHTTPサーバを実装するという非自明なタスクを、サポートなしのグループと比べて56%速く完了できたと報告しています。
多くのソフトウェアエンジニアは、LLMの恩恵が人によるフィルタリングの労力を上回るとすでに判断しているようで、積極的な採用率と高い使用意欲が報告されています。LLMベースのコード補完が完全に普及すると、プログラマーはコードを書く時間よりもレビューに費やす時間が増えるだろうと期待されています【41】。
A. Code Generation Models
自動コード生成には長い歴史があり、その起源は自動プログラム合成の初期のビジョンにさかのぼる。この分野は発展を続け、現在では目覚ましい成果を生み出している。
- Program synthesis
- S. Gulwani, O. Polozov, R. Singh et al., 2017
On the Naturalness of Software
- On the naturalness of software
- A. Hindle, E. Barr, Z. Su, P. Devanbu, and M. Gabel, 2012
- ソフトウェアの「自然さ」に関する先駆的な研究
- この研究から、プログラマーが記述するコードやプログラミング言語がコードの記述スタイルを規定することで、コードが非常に予測可能なものになることが明らかになった
The Plastic Surgery Hypothesis
- The plastic surgery hypothesis
- E. T. Barr, Y. Brun, P. Devanbu, M. Harman, and F. Sarro, 2014
- 大規模なJavaプロジェクトのリポジトリにおけるコミットの43%が既存のコードから再構築できることを発見
Automated program repair | Communications of the ACM
- Automated program repair
- C. L. Goues, M. Pradel, and A. Roychoudhury, 2019
- プログラムの自動修復。他の箇所から既存のコードを借用して問題を修正するように進行する。
- A study of the uniqueness of source code
- M. Gabel and Z. Su, 2010
- 新しいコード片を作成するために、プログラマーが6行以上のコードを記述する必要があることを発見
A Transformation System for Developing Recursive Programs
- A transformation system for developing recursive programs
- J. Darlington and R. M. Burstall, 1977
- 伝統的な「構成による正当性保証アプローチ」
Evaluating Large Language Models Trained on Code
- Evaluating Large Language Models Trained on Code
- Mark Chen et al., 2021
- GitHubから公開されているコードでファインチューニングされたGPT言語モデル「CodeX」を発表し、そのPythonコード記述能力を評価
- ドックストリングからプログラムを合成する際の機能的正確性を測るために「HumanEval」という新しい評価セットをリリースし、CodeXがGPT-3やGPT-Jよりもこれらの問題に対して優れた性能を発揮することを確認
- それ以来、LLMベースのコード生成に関する研究が急増し、HumanEvalデータセットは多くの後続の研究で利用されている
- Competition-Level Code Generation with AlphaCode
- Yujia Li et al., 2022
- 競技プログラミングの問題に対して新しい解法を生成するシステム「AlphaCode」を発表
- 信頼性のあるパフォーマンスを達成するために以下の3つの重要な要素が不可欠であることを発見しました：
- 訓練と評価のための広範なプログラミングデータセット。
- 大規模かつ効率的にサンプリング可能なTransformerベースのアーキテクチャ。
- 探索空間を探索するための大規模なモデルサンプリングと、それに続く振る舞いに基づくフィルタリング。
- Codeforcesプラットフォーム上でのプログラミングコンテストのシミュレーション評価において、AlphaCodeは平均で参加者5,000人以上のコンテストで上位54%のランクを達成
- Textbooks Are All You Need
- S. Gunasekar et al., 2023
- 教科書レベルの高品質なコードコーパスのみで訓練することで、少ないパラメータ数のLLMがはるかに大きなモデルに匹敵する性能を発揮できることを報告
- GPT-4モデルを用いて既存のPythonコードコーパスを分類し、プログラミングを学びたい学生にとってそのコードが教育的価値を持つかどうかを判断させた。次に、GPT-3.5を用いてPythonに関する合成教科書を作成した。
- ChatGPT for Programming Numerical Methods
- A. Kashefi and T. Mukerji, 2023
- aaaa
- Towards code generation from bdd test case specifications: A vision,
- L.Chemnitz, D.Reichenbach, H.Aldebes, M.Naveed, K.Narasimhan,and M.Mezini, 2023
- aaaa
B. Prompt Engineering for Improved Code Generation
プロンプトエンジニアリングは、コード生成を改善する方法として広く活用されている。
Towards Enhancing In-Context Learning for Code Generation | Request PDF
- Towards Enhancing In-Context Learning for Code Generation,
- J.Li, Y.Zhao, Y.Li, G.Li, and Z.Jin, 2023
- CodeX、CodeGeeX、CodeGen、およびInCoderにおいて、複数のベンチマーク（Python用のMBPP、Java用のMBJP、JavaScript用のMBJSP）でpass@1が約50%から80%向上したことを報告
- Piloting Copilot and Codex: Hot Temperature, Cold Prompts, or Black Magic?
- J.-B. Doderlein, M. Acher, D. E. Khelladi, and B. Combemale
- HumanEvalおよびLeetCodeでCopilotとCodeXの成功率が約1/4から3/4に改善されたことを報告
(PDF) Controlling Large Language Models to Generate Secure and Vulnerable Code
- Controlling Large Language Models to Generate Secure and Vulnerable Code,
- J. He and M. Vechev, 2023
- プロンプトエンジニアリングを使用してLLM生成コードのセキュリティを向上させ、セキュリティレベルを59%から92%に引き上げたと報告
- ChatGPT Prompt Patterns for Improving Code Quality, Refactoring, Requirements Elicitation, and Software Design,
- J. White, S. Hays, Q. Fu, J. Spencer-Smith, and D. C. Schmidt, 2023
- コード生成を含む様々なソフトウェアエンジニアリングタスク向けにプロンプトエンジニアリングのデザインパターン集を提供
- Conversing with copilot: Exploring prompt engineering for solving cs1 problems using natural language
- P. Denny, V. Kumar, and N. Giacaman, 2023
- プロンプトエンジニアリングがソフトウェアエンジニアリングの学生の計算的思考を育成する有益な学習活動であると主張
他にはプロンプトエンジニアリングを段階的かつ複数フェーズに分解し、LLMとの会話を反復する方法を検討しており、これを「Chain of Thought（思考の連鎖）」推論に近づけている。
- Skcoder: A sketch-based approach for automatic code generation
- J. Li, Y. Li, G. Li, Z. Jin, Y. Hao, and X. Hu, 2023
- 2段階のスケッチベースアプローチ「SkCoder」を使用し、ChatGPTのPass@1が18%向上したことを報告。このアプローチでは、まずLLMがスケッチを作成し、その後でそのスケッチを実装する。
Enabling Programming Thinking in Large Language Models Toward Code Generation | DeepAI
- Enabling programming thinking in large language models toward code generation
- J. Li, G. Li, Y. Li, and Z. Jin, 2023
- Selfevolve: A code evolution framework via large language models
- S. Jiang, Y. Wang, and Y. Wang, 2023
- SELF-EVOLVE と呼ばれる新しい二段階のパイプラインを提案する。SELF-EVOLVEは、LLMを知識の提供者と自己反省型のプログラマーとして活用する点で、従来の検索ベースの手法とは異なる。
- SELF-EVOLVEは、入力プロンプトから知識を獲得し、その知識をもとに中間コードを生成する。その後、SELF-EVOLVEはLLMに専門的なプログラマーとしての役割を担わせ、生成されたコードのデバッグを行わせる。このデバッグは、エラーメッセージをインタープリターから受け取ることで実現され、正しさを検証するための特別なテストケースを必要としない。
- Self-edit: Fault-aware code editor for code generation
- K. Zhang, Z. Li, J. Li, G. Li, and Z. Jin, 2023
- 人間のプログラミングプロセスに着想を得て、Self-Edit と呼ばれる「生成・編集」アプローチを提案。
- Self-Edit は、LLM が生成したコードの実行結果を活用し、競技プログラミングの課題におけるコードの品質を向上させる手法である。
- 具体的には、問題文に記載された例題テストケースで生成コードを実行し、その実行結果を補助コメントとして追加する。このコメントをガイドとして活用し、エラーを認識できるコードエディタを用いて、生成コードの修正を行う。
既存のソフトウェアエンジニアリング解析技術も、ファインチューニングやプロンプトエンジニアリングに追加情報を提供する手段として役立つことがある。
Improving Few-Shot Prompts with Relevant Static Analysis Products | Request PDF
- Improving Few-Shot Prompts with Relevant Static Analysis Products
- T. Ahmed, K. S. Pai, P. Devanbu, and E. T. Barr, 2023
- シンプルな静的解析をプロンプトに組み込むことで、少数ショット学習におけるコード生成の性能を向上させる方法を示した。
- Prompt engineering or fine tuning: An empirical assessment of large language models in automated software engineering tasks
- J. Shin, C. Tang, T. Mohati, M. Nayebi, S. Wang, and H. Hemmati, 2023
- コード生成タスクにおいて、GPT-4のプロンプトエンジニアリングとファインチューニングを比較し、ファインチューニングがプロンプトエンジニアリングよりも効果的であることを示した。
C. Hybrids of LLMs and other Techniques
LLM（大規模言語モデル）と他の既存のソフトウェアエンジニアリング技術を組み合わせる「ハイブリッド化」によって、最も有望な成果が達成できるという強力な証拠も報告されている。
- Planning with large language models for code generation
- S. Zhang, Z. Chen, Y. Shen, M. Ding, J. B. Tenenbaum, and C. Gan, 2023
- ベースラインと比較して約11%から27%の改善を報告
Self-planning Code Generation with Large Language Models
- Self-planning Code Generation with Large Language Model
- X. Jiang, Y. Dong, L. Wang, Q. Shang, and G. Li, 2023
- ベースラインと比較して約11%から27%の改善を報告
- Toolcoder: Teach code generation models to use api search tools
- K. Zhang, G. Li, J. Li, Z. Li, and Z. Jin, 2023
- コード生成とAPI探索技術をハイブリッド化
ハイブリッドアプローチでは、LLMのトップn出力から最適な候補を選択するために、既存のソフトウェアエンジニアリングやAI技術が使用されることもある。
- CODET: Code Generation With Generated Tests
- B. Chen, F. Zhang, A. Nguyen, D. Zan, Z. Lin, J.-G. Lou, and W. Chen, 2023
- テスト生成を使用して候補を選び、5つの事前訓練済みLLMで約20%の改善を報告
- Fault-aware neural code rankers
- J. P. Inala, C. Wang, M. Yang, A. Codas, M. Encarnacion, S. K. Lahiri, M. Musuvathi, and J. Gao, 2022
- ニューラルネットワークベースのランカーを用いてコードの正確性や潜在的な欠陥を予測
Jigsaw: Large Language Models meet Program Synthesis
- Jigsaw: large language models meet program synthesis
- N. Jain, S. Vaidyanath, A. Iyer, N. Natarajan, S. Parthasarathy, S. Rajamani, and R. Sharma, 2022
- プログラムの解析および合成技術に基づいて生成されたコードを後処理する「Jigsaw」を提案
Self-collaboration Code Generation via ChatGPT
- Self-collaboration Code Generation via ChatGPT
- Y. Dong, X. Jiang, Z. Jin, and G. Li, 2023
- LLMをエージェントとして扱い、複数のLLMがコード生成タスクにおいてそれぞれ異なる役割を担い、協力的かつ対話的に問題解決を行う方法を採用。約30%から47%の改善を報告。
D. Scientific Evaluation of LLM-based Code Generation
より徹底した科学的評価の必要性が強く求められています。多くの著者が、LLMが正確で安全かつ信頼性のあるコードを生成できなかった事例を報告しています。Poldrackら[75]も、大規模な人間による検証の重要性を強調しています。本セクションでは、LLMベースのコード生成について、正確性、堅牢性、説明性、決定論、安全性の観点から行われた実証評価に関する文献を紹介します。
正確性評価：
2303.08774- GPT-4 Technical report
- OpenAI, 2023
- GPT-4の技術レポート。GPT-4のHumanEvalデータセットでのコード生成の正確性が評価され、ゼロショットでの正答率は67%と報告された。
- Evaluating the Code Quality of AI-Assisted Code Generation Tools: An Empirical Study on GitHub Copilot, Amazon CodeWhisperer, and ChatGPT
- B. Yetis¸tiren, I. Ozsoy, M. Ayerdem, and E. T ¨ uz¨ un, 2023
- 以前のChatGPTについて報告した結果
- A Categorical Archive of ChatGPT Failures
- A. Borji, 2023
- ChatGPTのコード生成の失敗例を厳密かつ系統的に11種類に分類し、分析を行った。これらの失敗には、推論、事実誤り、数学、コーディング、バイアスなどのカテゴリーが含まれ、それぞれについて論じられている。
- 図4は、AI研究のトレンドとそのメソッドやモデルのコードを紹介するプラットフォーム「Papers With Code」によるHumanEvalデータセットのpass@1（トップ1候補のコードのテスト通過率）で測定されたコード生成の正確性のリーダーボードを示しています。各メソッドの背後にあるLLMモデルもカッコ内に記載されています。
- Reflexion: Language Agents with Verbal Reinforcement Learning
- N. Shinn, F. Cassano, B. Labash, A. Gopinath, K. Narasimhan, and S. Yao, 2023
- 本論文の執筆時点で、最も高性能なコード生成モデル。
- 生成タスクの90%以上で正しいコードを生成できているが、この分野は急速に発展しているため、これらの数値や各モデルの相対的なランキングは変動しやすいものである。たとえば、GPT-4のオリジナルレポートにおけるHumanEvalの正確なコード生成率は67%であったが、執筆時（5か月後）にPapers With Codeから取得した更新データでは80%に達しており、これはその間のGPT-4の進化を反映していると考えられる。
- Large language models of code fail at completing code with potential bugs
- T. Dinh, J. Zhao, S. Tan, R. Negrinho, L. Lausen, S. Zha, and G. Karypis, 2023
- HumanEvalにおいてコンテキストにバグが含まれている場合、コード補完の性能が50%以上低下することを報告
堅牢性評価：
LLMによるコード生成の堅牢性とは、類似したプロンプトに対して意味的および構文的に類似したコード生成が得られる程度を指す。2301.12169
- Navigating Complexity in Software Engineering: A Prototype for Comparing GPT-n Solutions
- C. Treude, 2023
- LLMのコード出力間の類似点と相違点を視覚的に強調表示するためのプロトタイプツール「GPTCOMPARE」を紹介。
- Coco: Testing code generation systems via concretized instructions
- M. Yan, J. Chen, J. M. Zhang, X. Cao, C. Yang, and M. Harman, 2023
- LLMベースのコード生成システムの堅牢性と一貫性をテストするための「COCO」を導入。
説明可能性の評価：
LLMの大きな利点の一つは、従来の機械学習技術と比べて、生成されたコードの成果物に説明が伴う点である。これらの説明は、追加の信頼性を提供し理解を促進することで、LLMの普及を促進する可能性がある。生成されたコードやその他のソフトウェアエンジニアリング成果物に付随する説明の評価と最適化には、さらなる研究が必要である。Experiences from Using Code Explanations Generated by Large Language Models in a Web Software Development E-Book
- Experiences from Using Code Explanations Generated by Large Language Models in a Web Software Development E-Book
- S. MacNeil, A. Tran, A. Hellas, J. Kim, S. Sarsa, P. Denny, S. Bernstein, and J. Leinonen, 2023
- インタラクティブなウェブ開発用電子書籍の初期評価では、大多数の学生がLLMによるコードの説明を役立つと認識していることが示された。
- Chatbots as fluent polyglots: Revisiting breakthrough code snippets
- D. Noever and K. Williams, 2023
- 特にコードが難読化されている場合や十分なドキュメントがない場合に、説明がエンジニアにとって役立つ可能性が示された。このように、LLMが生成したコードを正当化するだけでなく、知見や説明を提供する能力は、教育やドキュメント作成においても貴重な情報源となる可能性がある。
- Investigating Explainability of Generative AI for Code through Scenario-based Design
- J. Sun, Q. V. Liao, M. Muller, M. Agarwal, S. Houde, K. Talamadupula, and J. D. Weisz, 2022
- 生成AIにおけるユーザーの説明可能性に対するニーズを3つのソフトウェアエンジニアリング用途に焦点を当てて調査。：
- 自然言語による記述に基づくコード生成（Copilotを使用）
- 異なるプログラミング言語間の翻訳（Transcoderを使用）
- コードの自動補完（Copilotを使用）
- この調査は、43人のソフトウェアエンジニアを対象に9つのワークショップとして実施され、生成AI（GenAI）を用いたコードに関する11の説明可能性のニーズを特定した。
- また、生成AIに必要な4種類の機能も提案している：
- AIドキュメンテーション
- モデルの不確実性
- 注意の分布
- 社会的透明性（つまり、AIの利用を規定する社会的および組織的な要因を可視化すること）。
- Explainable ai for pre-trained code models: What do they learn? when they do not work?
- A. H. Mohammadkhani, C. Tantithamthavorn, and H. Hemmati, 2022
- アテンションメカニズムを利用して、CodeBERTおよびGraphCodeBERTを用いたコードのドキュメント生成、コードの改良、およびコードの翻訳などのタスクを研究。
決定論的評価：
LLMは非決定的である。
(PDF) LLM is Like a Box of Chocolates: the Non-determinism of ChatGPT in Code Generation
- Llm is like a box of chocolates: the non-determinism of chatgpt in code generation
- S. Ouyang, J. M. Zhang, M. Harman, and M. Wang,
- ChatGPTのコード生成における非決定性を実証的に研究し、タスクの60%以上で異なるリクエスト間でテスト出力が一致しないことを発見した。それにもかかわらず、LLMベースのコード生成に関する論文のうち、非決定性の問題を考慮した実験を行っているのは21.1%に過ぎない。
セキュリティ評価：
- Systematically Finding Security Vulnerabilities in Black-Box Code Generation Models
- H. Hajipour, T. Holz, L. Schonherr, and M. Fritz, 2023
- 数ショットプロンプトを用いた手法でセキュリティ脆弱性を検出するアプローチを提案し、この手法が複数のモデルで数千の脆弱性を自動的に発見することを報告。
- How Secure is Code Generated by ChatGPT?
- R. Khoury, A. R. Avila, J. Brunelle, and B. M. Camara, 2023
- ChatGPTが生成するコードが安全なコーディングの基準を大幅に下回ることを指摘
- Limits of machine learning for automatic vulnerability detection
- N. Risse and M. Bohme, 2023
- モデルが訓練データに含まれる無関係な特徴に過適合するため、脆弱性検出の精度が過大評価される可能性があると報告。
- Evaluating the Code Quality of AI-Assisted Code Generation Tools: An Empirical Study on GitHub Copilot, Amazon CodeWhisperer, and ChatGPT
- B. Yetis¸tiren, I. Ozsoy, M. Ayerdem, and E. T ¨ uz¨ un, 2023
- Copilot、CodeWhisperer、ChatGPTのコードの妥当性、正確性、安全性、信頼性を含む多角的な性能評価を行い、その結果、パフォーマンスに大きなばらつきがあることが示され、さらなる研究の必要性が示唆された。例えば、ChatGPT、Copilot、CodeWhispererが生成したプログラムのうち、それぞれ65%、46%、31%が正しいものであった。
ベンチマーク：
他の科学的評価と同様に、ソフトウェアエンジニアリング評価は公開された代表的なベンチマークスイートに依存している。いくつかのベンチマークが既に登場しており、LLMベースのアプリケーションの評価を支援している。Papers-With-Codeプラットフォームでは、コード生成を評価するための15のベンチマークがまとめられている。評価はしばしばプログラミングコースの小規模な問題[89]、合成された問題セット[90]、LeetCodeのようなオンラインジャッジプラットフォーム[29][65][91]を基に行われています。結果はLLMや訓練データによって異なりますが、これらの評価の総合的な結論として、成功率は20%から80%の範囲内であることが示されています。それにもかかわらず、既存のコード生成ベンチマークはテストスイートに依存してコードの正確性を自動的に判断することが多く、この手法では不十分で誤った判断が生じることもあります[92]。LLMベースのコード生成評価に特化した評価ベンチマークのさらなる研究が必要であることが浮き彫りになっています。
Liuら[93]は、この問題に注目し、既存のテストスイートが多くの偽陽性な結論をもたらすこと（オンラインジャッジプラットフォームでも深刻な問題[92]）を示しました。この問題を軽減するため、LiuらはEvalPlusを提案しました。これは、テスト入力を自動生成し、LLM生成コードの機能的正確性を厳密に評価するコード合成ベンチマークフレームワークです。彼らは14の主要なLLM（GPT-4やChatGPTを含む）を評価し、HumanEvalの新規生成テストでpass@kが平均15%低下することを確認しました。
Jimenezら[94]は、現実的なソフトウェアエンジニアリング環境でLLMのコード生成問題を評価することを目的としてSWE-benchを導入しました。SWE-benchには実際のGitHubの課題から抽出された2,294のソフトウェアエンジニアリング問題が含まれています。結果として、Claude 2とGPT-4はそれぞれ4.8%と1.7%のタスクのみを解決することが示されました。
Open Problems in Code Generation and Completion
生成されたコードの評価は、LLMベースのコード生成と補完における重要な課題であり続けています。既存のソフトウェアテストの知識をこの問題に適用する多くの研究がすでに始まっていますが、自動テスト手法とコード生成・補完手法のより緊密な統合を期待しています。
幸いなことに、自動テストデータ生成に関する多くの既存研究[3]-[5]があり、その多くはLLMによって生成されたエンジニアリング成果物の正確性を保証する上で重要な役割を果たすでしょう。この論文で扱われる課題の共通するテーマは、コードの実行が幻覚的な応答をフィルタリングするために必要な正確な「グランド・トゥルース」を提供することです。また、インタラクティブな推論/アクション（「ReAct」）ダイアログ[95]の一部として、LLMとの間およびLLM内でのガイダンスを提供することもできます。
自動テストデータ生成により、ソフトウェアエンジニアは、このランタイム・グランド・トゥルースの最も関連性の高い領域の探索をターゲットにすることができます。このテストベースのターゲティングは、幻覚による問題を最小限に抑えるために、プロンプトのフィルタリング、微調整、最適化に役立ちます。LLMは、効果的で効率的なソフトウェアテストスイートを構築するプロセスを自動化する大きな可能性も秘めています。
もう一つの重要な問題は、特定のプログラミング言語、コードベース、またはドメインに対してより良いパフォーマンスを発揮するように、事前訓練されたLLMを効率的に微調整する方法です。これは、LLMを最初から訓練するにはかなりの計算資源が必要であるため、特に重要です。
例えば、特定のプログラミング言語のトレーニング例の数が不十分な場合に、コード補完のパフォーマンスを向上させる方法として、転移学習が提案されています[96]。
現在の研究の焦点はLLMによって生成されたコードにありますが、LLMによって生成された説明も少なくとも同等に重要であることが判明するかもしれません。エンジニアが、魅力的な説明が付いた（おそらく）最適ではないソフトウェアエンジニアリング成果物を、魅力的な説明の少ない潜在的により高性能なソリューションよりも好む多くのシナリオを想像することができます。結局のところ、エンジニアは人間が設計したエンジニアリング成果物に対しても同じ判断を定期的に行うので、機械が生成したものに対してはなぜ違うのでしょうか？プロンプトエンジニアリングがLLMへの入力を最適化することに焦点を当てているように、説明エンジニアリングも独自の研究分野になる可能性があります。
SOFTWARE TESTING
A. Generating New Tests Using LLMs
このセクションでは、LLMによるテストデータ生成に関する既存の研究をレビューし、この新興分野の発展における未解決の問題と課題を強調します。生成されたテストは、LLMがコンパイル可能なコードを生成することを保証していないため、実行できない場合があります。Nieらは[99]、TeCoを使用して生成されたテストの29%が実行可能であると報告しています。一方、Yuanらは[100]、ChatGPTによって生成されたテストの約4分の1が実行可能であり、適切なプロンプトエンジニアリングにより3分の1に上昇することを発見しました。
コンパイル可能なテストについては、いくつかの著者らが達成されたコードカバレッジについて報告しています。例えば、Bareißらは[101]、Randoop[102]を使用して達成された10%からCodeXを使用して14%への増加を報告しました。Hashtroudiらは[103]、CodeT5をファインチューニングして生成したテストの行カバレッジが50%増加したと報告しました。Siddiqらは[104]、CodeXを使用してHumanEvalデータセットで80%のカバレッジを報告しましたが、研究されたLLMのいずれもEvoSuite SF110データセットで2%を超えるカバレッジを達成できなかったことも発見しました。
ファズベースのテストやサーチベースのテストなどの既存のテスト生成および評価技術とLLMを組み合わせたハイブリッドアプローチは、すでに有望な結果を示しています。例えば、Lemieuxらは[105]、Search-Based Software Testing (SBST)[5]とCodeXを組み合わせてテスト対象プログラムの高カバレッジテストケースを生成するアルゴリズムであるCODAMOSAを導入しました。SBSTのカバレッジの改善が停滞すると、CODAMOSAはCodeXに、カバレッジが低い関数の例となるテストケースを提供するように要求します。これにより、SBSTは検索空間のより有用な領域に検索を方向付けることができます。486のベンチマークの評価では、CODAMOSAはSBSTとLLMのみのベースラインと比較して、有意に高いカバレッジを達成しました。Huらは[106]、広く研究されているファザであるAFLをChatGPTで拡張して、よりフォーマットに準拠したミュータントを取得するChatFuzzを導入しました。3つのベンチマークから選択された12のターゲットプログラムの評価では、ChatFuzzはAFLよりも13%高い分岐カバレッジを達成しました。Dakhelらは[107]、ミューテーションテストを使用してLLMがテストを生成するのを支援しました。具体的には、彼らはCodexとLlama-2-chatのプロンプトを生存するミュータントで拡張しました。彼らは、彼らのアプローチが28%多くの人間が書いた欠陥を検出すると報告しています。Xiaらは[108]、LLMがC/C++コンパイラ、JDK、SMTソルバー、さらには量子コンピューティングシステムを含むさまざまなアプリケーションドメインとプログラミング言語のシステムのユニバーサルファザとして機能できることを最近実証しました。
Dengらは[109]、DLライブラリをテストするための有効な入力DLプログラムを生成するためにLLM（つまりCodex）を使用するTitanFuzzを提案しました。PyTorchとTensorFlowの結果は、TitanFuzzが最先端のファザよりも30%/51%高いコードカバレッジを達成できることを明らかにしています。その後、彼らはさらにFuzzGPT[110]を導入し、ファジングDLライブラリのための珍しいプログラムを合成します。彼らの結果は、CodeXとCodeGenがファズベースのテスト用に再ターゲットされた場合、PyTorchとTensorFlowでTitanFuzzを凌駕できることを示しました。
Liらは[111]、差分テストとChatGPTのハイブリッドを使用して、バギープログラムの障害誘発テストケースを生成する後者の能力を高めました。彼らは、テストの有効性が29%から78%に改善されたと報告しています。
LLMベースのテスト生成の有望な分野はGUIテストです。なぜなら、GUIを介したアプリケーション状態の操作は、ユーザーインターフェースとアプリケーションドメインの両方の意味的理解を必要とするからです。Sunらは[112]、テキストでユーザーインターフェースを記述し、ChatGPTにテキストに基づいて次に実行したいアクションを尋ね、その回答を実際のGUIインタラクションに変換しました。これにより、最先端技術と比較して32%高いアクティビティカバレッジが実現しました。
古典的な手法にとって特に重要な問題は、ユーザーレポートからテストケースを構築することです。ユーザーレポートは自然言語で書かれています。これは、既存の手法にとってかなりの課題となっていますが、LLMに理想的に適しています。Kangらは[113]、CodeXに基づいて一般的なバグレポートからテストを自動的に生成する、少数のショット学習による障害再現手法であるLibroを導入しました。Libroは約3分の1の障害を再現することに成功しました。
FengとChen[114]は、自然言語で定義された再現手順を含むバグレポートに対して、LLM（ChatGPT）とChain of Thoughtプロンプトエンジニアリングのみを使用して、80%の再現率を実証しました。
いくつかの研究者が、テスト生成の結果を改善するためにプロンプトエンジニアリングを検討しています[115]、[116]。例えば、Schaferらは[116]、失敗したテストと関連するエラーメッセージで再プロンプトし、報告された平均ステートメントカバレッジ68%を達成するTESTPILOTを提案しました。Xieらは[117]、プロジェクトを解析して、焦点となるメソッドとその依存関係を含む適応的な焦点コンテキストを作成することで、テスト生成のプロンプトを作成します。さらに、ルールベースの修復を使用して、テストの構文エラーと単純なコンパイルエラーを修正します。
LLMベースのテストの結果は不確実かもしれませんが、研究者たちは「自己一貫性」[120]の概念に基づいて、クロス参照や多数決[118]、[119]の方法を使用してLLMの信頼性を推定しています。例えば、Kangら[113]が導入したLibroは、CodeXを使用してバグレポートからテストを生成し、障害を再現できます。複数のテストが同様の障害動作を示す場合、LibroはLLMが予測に「自信を持っている」と推定します。さらに、部分的なオラクル情報がある場合、これも信頼性推定の強化に使用できます。このような部分的なオラクル情報は、既存のコードを改善する全体的なプロセスの目標である場合によく利用できます。例えば、既存のテストの効率を向上させる場合、自動化された部分的なオラクル情報は、テストが元のテストと同様に動作するかどうか（同じ状況でパスと失敗）を観察し、実行がより高速であるかどうかを観察することによって収集できます。
B. Test Adequacy Evaluation
テストの有効性は一般的に「十分性基準」[121]、[122]の観点から測定されます。テストはすべての可能性を網羅的に探索することはできないため、十分性基準はテストスイートによって達成される有効性の下限を提供します。
ミューテーションテストは、ソフトウェアテストスイートの十分性を評価するための広く研究されている手法です[123]、[124]。この手法では、合成的な欠陥（「ミュータント」と呼ばれる）が意図的に注入され、テストの十分性が評価されます。ミューテーションテストは、ステートメントカバレッジや分岐カバレッジなどの他の構造カバレッジベースの基準よりも厳格な十分性基準を提供することが示されています[125]。
ミューテーションテストの課題となる未解決問題の1つは、現実世界の重要な欠陥クラスを忠実にモデル化するミュータントを生成することです。Khanfirらは[126]、CodeBertを使用して開発者のようなミュータントを生成し、このアプローチがPiTestよりも優れた欠陥発見能力を持つことを発見しました。Gargらは[127]、CodeBERTを使用して脆弱性を忠実に捉えるミュータントを生成しました。評価の結果、ミュータントの17%は、それぞれの脆弱性の89%が失敗するテストに失敗することがわかりました。Brownlee[128]は、GPT-3.5を使用して遺伝的改善のためのミュータントを生成し、ランダムにサンプリングされたLLMベースの編集が、標準的なGI編集と比較して、より頻繁にコンパイルされ、単体テストに合格することを観察しました。
C. Test Minimisation
テストの最小化は、冗長なテストケースを削除することでソフトウェアテストの効率を向上させます。Panら[129]は、CodeBERT、GraphCodeBERT、および UniXcoder を用いてテストコードの埋め込みを抽出し、テストの最小化を行いました。このアプローチは、0.84 の障害検出率を達成し、平均26.73分と、従来の手法よりもはるかに高速に実行されます。
D. Test Output Prediction
Liuら[130]は、プログラム全体の実行トレースを予測するために、事前学習済みのTransformerモデルであるCodeExecutorを提案しました。このモデルの目的は、実世界の任意のプログラム実行動作を模倣することです。評価では、CodeExecutorをCodeXと比較し、実行トレース予測においてCodeExecutorがCodeXを大幅に上回る性能を示しました（例: Tutorialデータセットでの出力精度は76%対13%）。
E. Test Flakiness
テストが不安定（flaky）であるとは、実行環境に明らかな（テスターが制御可能な）変化がないにもかかわらず、ある時は合格し、別の時は失敗する場合を指します。テストの不安定さは、業界においてテストの効果を妨げる最も重要で影響力のある問題の一つです。大規模言語モデル（LLM）は、不安定さを高い精度で予測するために使用されており、73%のF1スコアや97%の精度が報告されています。
F. Open problems in LLMs for Software Testing
LLM（大規模言語モデル）に基づくソフトウェアテストデータ生成には多くの未解決の問題があり、そのほとんどは既存のソフトウェアテスト技術の範囲内にあります。したがって、今後数年でLLMに基づくソフトウェアテスト生成が大きく発展することが期待されます。このセクションでは、この研究課題のいくつかの方向性を示します。
1) プロンプトエンジニアリング：良いソフトウェアテストの多くの側面は、適切なプロンプトエンジニアリングによって改善される可能性があります。例えば、以下のようなプロンプトを設計する方法を理解する必要があります。
• 生成されたテストの不安定さを予測し、減少させる；
• 過去の故障データを用いたトレーニングなどで、可能性のある故障を明らかにする；
• モックテストと統合テストのバランスを最適化する；
• 現実的なデータビルダー、モックオブジェクト、パラメータ、入力を作成する；
• コーナーケースをカバーするテストを引き出す可能性が最も高いテストを予測する；
• 本番環境で一般的な振る舞いに焦点を当てたテスト生成を調整する。
2) 既存テストの拡張：LLM（大規模言語モデル）に基づくテスト生成に関する研究は、新しいテストスイートの自動生成に焦点を当ててきました。しかし、既存のテスト生成技術の多様性を考慮すると、既存のテストスイートに基づく拡張および再生成という重要な（比較的研究が進んでいない）未解決の問題が残っています。テストの拡張と再生成は、少数ショット学習を活用したり、既存のテストデータと過去の故障を基にファインチューニングすることで、拡張されたテストスイートを生成することが可能です。コーナーケース、過去の故障、およびプログラマーのエラーを捉える追加のテストアサーションを生成するためのLLMに関するさらなる研究が必要です。また、LLMと既存の自動テスト生成技術とのハイブリッド化も生産的なテーマです。
3) テストの正確性：従来のソフトウェアテスト生成はオラクル問題に悩まされてきました。すなわち、テスト結果が正しいかどうかを判断する自動オラクルが欠如しているためです。AI生成のテストに関連する二つのケースがあります。1) 生成されたテストが現在のリリースで合格する場合：機能が正しくテストされていると仮定でき、生成されたテストは回帰テストとして機能し、将来の変更が確認できると考えられます。2) 生成されたテストが現在のリリースで失敗する場合：そのアサーションが間違っているのか、生成されたテストがバグを見つけたのかを知る必要があります。どちらのケースも自己調整がなければ有害な結果をもたらす可能性があります。合格したテストケースは偶然の正確さを反映しているだけかもしれません。さらに悪いことに、実際にコードが間違っている場合があり（そのテストも同様に間違っているが、間違った挙動を捉え、強制してしまう）、そのような場合、テストの生成は将来の修正による不具合の解決を妨げる傾向があります。この問題はLLM生成のテストケースにも影響を与え、特にそのようなテストがオラクル特性を幻覚する場合にはより有害です。生成されたテストにこれらの誤ったオラクルのアサーションが埋め込まれてしまいます。一方で、生成されたテストケースが失敗すると、これはバグを示す可能性があります。このバグの発見はLLMベースのテストにとっての「勝利」となります。しかし、もし偽陽性と真陽性の比率が高い場合、コスト（例えば、人間の評価）により、この技術は実用的ではなくなる可能性があります。たとえ真陽性のバグを明らかにしてもです。生成されたテストの信頼性、正確性、一貫性、堅牢性の自己評価、自己チェックに関するさらなる研究が必要です。LLMベースのテストの実行から得られた生データの自動評価、拡張、フィルタリングの技術を開発し、開発者に「テスト信号」を提示する前に行う必要があります。
LLM（大規模言語モデル）による幻覚とテストの正確性の相互作用は、それ自体が重要なテーマです。LLMに基づくコード生成は、一般的に最も正しいものではなく、最も可能性の高いものによって推進されるため、幻覚は正確性に関する問いに対して脅威をもたらします。興味深いことに、Feldtら[139]は、幻覚がソフトウェアテストに役立つケースを報告しました。なぜなら、それが実際のプログラムの意味論とプログラマーの意味論に対する認識との間の不一致を明らかにする可能性があるからです。彼らは、この能力を活用するために、会話を通じてプログラマーが生成されたテストをフィルタリングする形式の会話型テストエージェントを提案しました。これにより、全体的なテストの正確性に対する脅威を与えることなく、この能力を活用できます。また、LLMに基づくソフトウェアテストの評価の基盤となる科学的基盤についても、さらなる研究が必要です。より多くの注意と配慮が明らかに必要であり、経験的および探索的ソフトウェア工学の基礎に関する以前の研究からの科学的分析と報告に対する『ベストプラクティス』のアドバイスに従う必要があります。
4) ミューテーションテスト：LLM（大規模言語モデル）に基づくテスト生成によって達成可能な妥当性を探るためのさらなる研究が必要です。また、LLMベースの技術を使用してテストの妥当性調査および評価を支援・強化することも求められています。LLMは故障モデルに対してファインチューニングされることで、実際の故障に高度に結びついたミュータントを提案することができ、それによってテストの妥当性を評価することが可能です。
VI. MAINTENANCE, EVOLUTION AND DEPLOYMENT
ソフトウェアの保守と進化は、何十年にもわたって重要な研究テーマとなっています。これらは、理解とビジネスロジックの抽出を求める既存のコードベースに関係しており、再エンジニアリング、改修、リファクタリングを行うことを目指しています。このような保守の問題は、すべて言語が豊富な問題領域に存在します。したがって、この分野でLLM（大規模言語モデル）に基づく技術が多く応用されているのは驚くべきことではありません。このセクションでは、その応用についてレビューします。
コメント
コメントを投稿