【論文】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
自動コード生成には長い歴史があり、その起源は自動プログラム合成の初期のビジョンにさかのぼります[42]。この分野は発展を続け、現在では目覚ましい成果を生み出しています[43]。
Hindleらによるソフトウェアの「自然さ」に関する先駆的な研究から[44]、プログラマーが記述するコードやプログラミング言語がコードの記述スタイルを規定することで、コードが非常に予測可能なものになることがわかっています。さらに、Barrら[45]は、大規模なJavaプロジェクトのリポジトリにおけるコミットの43%が既存のコードから再構築できることを発見しました。彼らはこの現象を「プラスチックサージェリー仮説」と呼びました。なぜなら、自動修復は他の箇所から既存のコードを借用して問題を修正するように進行するからです[46]。
彼らの実証的な研究は、この再利用手法の有効性を示すだけでなく、ソフトウェアが反復的かつ予測可能であることも強調しました。さらに、大規模なリポジトリ（SourceForge）において、GabelとSu[47]は、新しいコード片を作成するために、プログラマーが6行以上のコードを記述する必要があることを発見しました。
コードの自然さ、再利用性、予測可能性に関するこれらの研究結果から、大規模言語モデル（LLM）が同じ予測可能で再利用可能な特性を利用して、効果的なコード生成の推奨を提供できることは驚くべきことではありません。これらの観察は、修復や遺伝的改善のための生成とテスト（generate-and-test）アプローチの成長を支えてきました[8][46]。生成とテストのアプローチは、より伝統的な「構成による正当性保証アプローチ」と比較して[48]、コード変換の自由度を高めます。これは生成されたコードが必ずしも厳密で数学的に定義された正確性（必ずしも適切で有用とは限らない）を維持しない可能性があるためです。
この「意味的に近い隣接候補」を広く探索する自由により、遺伝的改善は劇的な最適化を見つけることが可能になります（VI-Cセクションを参照）。遺伝的改善のアプローチ、命名法、および評価方法論は、LLMベースのコード生成を理解し評価するための科学的枠組みも提供します。これらの技術は、コード変換とコード生成における生成とテストアプローチを共有しており、そのため遺伝的改善の既存の多くの研究がLLMベースのコード生成に直接適用できる可能性があります。
2021年、Chenら[49]は、GitHubから公開されているコードでファインチューニングされたGPT言語モデル「CodeX」を発表し、そのPythonコード記述能力を評価しました。彼らは、ドックストリングからプログラムを合成する際の機能的正確性を測るために「HumanEval」という新しい評価セットをリリースし、CodeXがGPT-3やGPT-Jよりもこれらの問題に対して優れた性能を発揮することを確認しました。それ以来、LLMベースのコード生成に関する研究が急増し、HumanEvalデータセットは多くの後続の研究で利用されています。
2022年、Liら[27]は、競技プログラミングの問題に対して新しい解法を生成するシステム「AlphaCode」を発表しました。彼らは、信頼性のあるパフォーマンスを達成するために以下の3つの重要な要素が不可欠であることを発見しました：
- 訓練と評価のための広範なプログラミングデータセット。
- 大規模かつ効率的にサンプリング可能なTransformerベースのアーキテクチャ。
- 探索空間を探索するための大規模なモデルサンプリングと、それに続く振る舞いに基づくフィルタリング。
Codeforcesプラットフォーム上でのプログラミングコンテストのシミュレーション評価において、AlphaCodeは平均で参加者5,000人以上のコンテストで上位54%のランクを達成しました。
また、いくつかの論文では、大規模なデータセットを基にしたコード合成用LLMが紹介されましたが[50]–[53]、訓練データの事前フィルタリングがほとんど行われていませんでした。2023年には、Gunasekarら[54]が教科書レベルの高品質なコードコーパスのみで訓練することで、少ないパラメータ数のLLMがはるかに大きなモデルに匹敵する性能を発揮できることを報告しました。
彼らはGPT-4モデルを用いて既存のPythonコードコーパスを分類し、プログラミングを学びたい学生にとってそのコードが教育的価値を持つかどうかを判断させました。次に、GPT-3.5を用いてPythonに関する合成教科書を作成しました。また、特定のコード生成の用途にも取り組んでおり、数値アルゴリズムのコード生成[55]や、行動記述からのコード生成[56]などの例があります。コード生成用の既存のLLMとコード生成リーダーボードの詳細は、表IIおよび図4に示されています。
B. Prompt Engineering for Improved Code Generation
プロンプトエンジニアリングは、コード生成を改善する方法として広く活用されています。例えば、Liら[57]は、CodeX、CodeGeeX、CodeGen、およびInCoderにおいて、複数のベンチマーク（Python用のMBPP、Java用のMBJP、JavaScript用のMBJSP）でpass@1が約50%から80%向上したことを報告しました。Doderleinら[58]は、HumanEvalおよびLeetCodeでCopilotとCodeXの成功率が約1/4から3/4に改善されたことを報告しています。また、HeとVechev[59]は、プロンプトエンジニアリングを使用してLLM生成コードのセキュリティを向上させ、セキュリティレベルを59%から92%に引き上げたと報告しました。Whiteら[60]は、コード生成を含む様々なソフトウェアエンジニアリングタスク向けにプロンプトエンジニアリングのデザインパターン集を提供しました。さらに、Dennyら[61]は、プロンプトエンジニアリングがソフトウェアエンジニアリングの学生の計算的思考を育成する有益な学習活動であると主張しています。
他の研究者は、プロンプトエンジニアリングを段階的かつ複数フェーズに分解し、LLMとの会話を反復する方法を検討しており、これを「Chain of Thought（思考の連鎖）」推論に近づけています。例えば、Liら[62][63]は、2段階のスケッチベースアプローチ「SkCoder」を使用し、ChatGPTのPass@1が18%向上したことを報告しています。このアプローチでは、まずLLMがスケッチを作成し、その後でそのスケッチを実装します。Jiangら[64]やZhangら[65]も、Chain of Thoughtスタイルの推論を利用し、LLMに振り返りや自己編集を促すことで性能を向上させようとしています。
既存のソフトウェアエンジニアリング解析技術も、ファインチューニングやプロンプトエンジニアリングに追加情報を提供する手段として役立つことがあります。例えば、Ahmedら[66]は、シンプルな静的解析をプロンプトに組み込むことで、少数ショット学習におけるコード生成の性能を向上させる方法を示しました。Shinら[67]は、コード生成タスクにおいて、GPT-4のプロンプトエンジニアリングとファインチューニングを比較し、ファインチューニングがプロンプトエンジニアリングよりも効果的であることを示しました。
C. Hybrids of LLMs and other Techniques
文献を調査する中で、LLM（大規模言語モデル）と他の既存のソフトウェアエンジニアリング技術を組み合わせる「ハイブリッド化」によって、最も有望な成果が達成できるという強力な証拠が見つかりました。本セクションでは、コード生成のためのハイブリッドLLMに関する研究を紹介します。
複数の著者が、LLMを計画や探索と組み合わせたハイブリッドモデルを開発しました。例えば、Zhangら[68][69]は、ベースラインと比較して約11%から27%の改善を報告しています。また、Zhangら[70]は、コード生成とAPI探索技術をハイブリッド化しました。
ハイブリッドアプローチでは、LLMのトップn出力から最適な候補を選択するために既存のソフトウェアエンジニアリングやAI技術が使用されることもあります。例えば、Chenら[71]はテスト生成を使用して候補を選び、5つの事前訓練済みLLMで約20%の改善を報告しています。Inalaら[72]は、ニューラルネットワークベースのランカーを用いてコードの正確性や潜在的な欠陥を予測しました。Jainら[73]は、プログラムの解析および合成技術に基づいて生成されたコードを後処理する「Jigsaw」を提案しました。
また、Dongら[74]はLLMをエージェントとして扱い、複数のLLMがコード生成タスクにおいてそれぞれ異なる役割を担い、協力的かつ対話的に問題解決を行う方法を採用しました。彼らは約30%から47%の改善を報告しています。
D. Scientific Evaluation of LLM-based Code Generation
より徹底した科学的評価の必要性が強く求められています。多くの著者が、LLMが正確で安全かつ信頼性のあるコードを生成できなかった事例を報告しています。Poldrackら[75]も、大規模な人間による検証の重要性を強調しています。本セクションでは、LLMベースのコード生成について、正確性、堅牢性、説明性、決定論、安全性の観点から行われた実証評価に関する文献を紹介します。
- 正確性評価：GPT-4の技術レポート[28]では、GPT-4のHumanEvalデータセットでのコード生成の正確性が評価され、ゼロショットでの正答率は67%と報告されました。この結果は、Yetistirenら[76]が以前のChatGPTについて報告した結果をわずかに上回るものでした。
Borji[77]は、ChatGPTのコード生成の失敗例を厳密かつ系統的に11種類に分類し、分析を行いました。これらの失敗には、推論、事実誤り、数学、コーディング、バイアスなどのカテゴリーが含まれ、それぞれについて論じられています。
図4は、AI研究のトレンドとそのメソッドやモデルのコードを紹介するプラットフォーム「Papers With Code」によるHumanEvalデータセットのpass@1（トップ1候補のコードのテスト通過率）で測定されたコード生成の正確性のリーダーボードを示しています。各メソッドの背後にあるLLMモデルもカッコ内に記載されています。本稿執筆時点で、最も高性能なコード生成モデルであるReflexion[78]は、生成タスクの90%以上で正しいコードを生成できています。しかし、この分野は急速に発展しているため、これらの数値や各モデルの相対的なランキングは変動しやすいものです。たとえば、GPT-4のオリジナルレポート[28]におけるHumanEvalの正確なコード生成率は67%でしたが、執筆時（5か月後）にPapers With Codeから取得した更新データでは80%に達しており、これはその間のGPT-4の進化を反映していると考えられます。
コード生成と補完に関する文献の有望な結果にもかかわらず、Dinら[79]は、HumanEvalにおいてコンテキストにバグが含まれている場合、コード補完の性能が50%以上低下することを報告しました。
２．堅牢性評価：LLMによるコード生成の堅牢性とは、類似したプロンプトに対して意味的および構文的に類似したコード生成が得られる程度を指します。Treude[80]は、LLMのコード出力間の類似点と相違点を視覚的に強調表示するためのプロトタイプツール「GPTCOMPARE」を紹介しました。また、Yanら[81]は、LLMベースのコード生成システムの堅牢性と一貫性をテストするための「COCO」を導入しました。
３．説明可能性の評価：LLMの大きな利点の一つは、従来の機械学習技術と比べて、生成されたコードの成果物に説明が伴う点です。これらの説明は、追加の信頼性を提供し理解を促進することで、LLMの普及を促進する可能性があります。生成されたコードやその他のソフトウェアエンジニアリング成果物に付随する説明の評価と最適化には、さらなる研究が必要です。
MacNeilら[82]によるインタラクティブなウェブ開発用電子書籍の初期評価では、大多数の学生がLLMによるコードの説明を役立つと認識していることが示されました。また、NoeverとWilliams[83]は、特にコードが難読化されている場合や十分なドキュメントがない場合に、説明がエンジニアにとって役立つ可能性を示しました。このように、LLMが生成したコードを正当化するだけでなく、知見や説明を提供する能力は、教育やドキュメント作成においても貴重な情報源となる可能性があります（セクションXI参照）。
Sunら[84]は、生成AIにおけるユーザーの説明可能性に対するニーズを3つのソフトウェアエンジニアリング用途に焦点を当てて調査しました：自然言語による記述に基づくコード生成（Copilotを使用）、異なるプログラミング言語間の翻訳（Transcoderを使用）、およびコードの自動補完（Copilotを使用）。この調査は、43人のソフトウェアエンジニアを対象に9つのワークショップとして実施され、生成AI（GenAI）を用いたコードに関する11の説明可能性のニーズを特定しました。また、生成AIに必要な4種類の機能も提案しています：AIドキュメンテーション、モデルの不確実性、注意の分布、そして社会的透明性（つまり、AIの利用を規定する社会的および組織的な要因を可視化すること）。
Mohammadkhaniら[85]は、アテンションメカニズムを利用して、CodeBERTおよびGraphCodeBERTを用いたコードのドキュメント生成、コードの改良、およびコードの翻訳などのタスクを研究しました。
決定論的評価：LLMは非決定的です。Ouyangら[10]は、ChatGPTのコード生成における非決定性を実証的に研究し、タスクの60%以上で異なるリクエスト間でテスト出力が一致しないことを発見しました。それにもかかわらず、LLMベースのコード生成に関する論文のうち、非決定性の問題を考慮した実験を行っているのは21.1%に過ぎません。
セキュリティ評価：Hajipourら[86]は、数ショットプロンプトを用いた手法でセキュリティ脆弱性を検出するアプローチを提案し、この手法が複数のモデルで数千の脆弱性を自動的に発見することを報告しました。Khouryら[87]は、ChatGPTが生成するコードが安全なコーディングの基準を大幅に下回ることを指摘しています。また、RisseとBöme[88]は、モデルが訓練データに含まれる無関係な特徴に過適合するため、脆弱性検出の精度が過大評価される可能性があると報告しました。
さらに、Yetistirenら[76]は、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
D. Test Output Prediction
E. Test Flakiness
コメント
コメントを投稿