GPT-4: 私が書いたコードを使ってみますか?調査によると、APIの不正使用率は62%を超えている。

言語モデリングの新しい時代が到来し、大規模言語モデル (LLM) は自然言語を理解するだけでなく、ユーザーのニーズに基づいてカスタムコードを生成することもできます。

その結果、API を使用してコードスニペットを生成したり、コード内のバグを検出したりするなど、プログラミングに関する質問に答えるために大規模な言語モデルをクエリすることを選択するソフトウェアエンジニアが増えています。大規模言語モデルを使用すると、Stack Overflow などのオンラインプログラミングフォーラムを検索するよりも、プログラミングに関する質問に対してより適切でカスタマイズされた回答を取得できます。

LLM は速度が速いですが、コード生成における潜在的なリスクも隠蔽されます。ソフトウェアエンジニアリングの観点からは、構文エラーの回避や生成されたコードの意味理解の向上などの側面を含む多くの研究結果があるにもかかわらず、LLM のコード生成機能の堅牢性と信頼性は十分に研究されていません。

オンラインプログラミングフォーラムの場合とは異なり、LLM によって生成されたコードはコミュニティの仲間によってレビューされないため、ファイルの読み取りや変数のインデックス作成における境界チェックの欠落、ファイル I/O のクローズの欠落、トランザクションの完了の失敗など、API の誤用に関する問題が発生する可能性があります。生成されたコードサンプルを実行できたり、機能を正しく実行できたとしても、誤用すると、メモリリーク、プログラムクラッシュ、ガベージコレクションの失敗など、製品に重大な潜在的リスクが生じる可能性があります。

さらに悪いことに、このような質問をするプログラマーは、API に不慣れである可能性が高く、生成されたコードスニペットの潜在的な問題を特定できないため、最も脆弱な立場にあります。

下の図は、ソフトウェアエンジニアが LLM にプログラミングに関する質問をする例を示しています。Llama-2 は構文的に正しく、機能的に正しく、文法的に整列したコードスニペットを生成できることがわかりますが、ファイルがすでに存在する場合やフォルダーが存在しない状況を考慮していないため、十分に堅牢ではありません。

したがって、大規模言語モデルのコード生成機能を評価する際には、コードの信頼性を考慮する必要があります。

大規模言語モデルのコード生成機能を評価するという点では、既存のベンチマークのほとんどは、生成されたコードの実行結果の機能的な正確性に焦点を当てています。つまり、生成されたコードがユーザーの機能要件を満たすことができれば、ユーザーはそれを受け入れることができます。

しかし、ソフトウェア開発の世界では、コードが正しく実行されるだけでは十分ではありません。ソフトウェアエンジニアに必要なのは、長期的には潜在的なリスクなしに、新しい API を正しく確実に使用するコードです。

さらに、現在のプログラミング問題の範囲のほとんどは、ソフトウェアエンジニアリングの範囲から遠く離れています。データソースは主に、Codeforces、Kattis、Leetcode などのオンラインプログラミングチャレンジネットワークです。これは注目すべき成果ですが、現実世界のアプリケーション向けのソフトウェアの開発を支援するには十分ではありません。

この目的のために、カリフォルニア大学サンディエゴ校の Li Zhong 氏と Zilong Wang 氏は、大規模言語モデルによって生成されたコードの信頼性と堅牢性を評価できるフレームワーク RobustAPI を提案しました。これには、プログラミング問題データセットと抽象構文木 (AST) を使用した評価機能が含まれています。

論文アドレス: https://arxiv.org/pdf/2308.10335.pdf

データセットの目的は、実際のソフトウェア開発に近い評価設定を作成することです。この目的のために、研究者は Stack Overflow から Java に関する代表的な質問を収集しました。 Java は最も人気のあるプログラミング言語の 1 つであり、Write Once Run Anywhere (WORA) 機能によりソフトウェア開発で広く使用されています。

それぞれの問題について、研究者は詳細な説明と関連する Java API を提供します。また、大規模な言語モデルを呼び出してコードスニペットと対応する説明を生成するためのテンプレートのセットも設計しました。

研究者らは、生成されたコードスニペットを抽象構文木 (AST) を使用して分析し、予想される API 使用パターンと比較する評価ツールも提供しています。

研究者らはまた、Zhangらの方法（2018）に従って、AIの使用パターンを構造化された呼び出しシーケンスに形式化しました。この構造化された呼び出しシーケンスは、これらの API を正しく使用して潜在的なシステムリスクを排除する方法を示しています。ソフトウェアエンジニアリングの観点からは、この構造化された呼び出しシーケンスに違反すると失敗とみなされます。

研究者らは、24 の代表的な Java API に関する 1,208 件の実際の質問を Stack Overflow から収集しました。研究者らは実験的評価も実施し、クローズドソースの言語モデル（GPT-3.5とGPT-4）だけでなく、オープンソースの言語モデル（Llama-2とVicuna-1.5）もテストした。モデルのハイパーパラメータ設定については、デフォルト設定を使用し、それ以上のハイパーパラメータ調整は実行しませんでした。彼らはまた、ゼロショットとワンショット、つまりプロンプトでそれぞれ 0 個または 1 個のデモンストレーションサンプルを提供する 2 つの実験形式も設計しました。

研究者らは、LLM によって生成されたコードを徹底的に分析し、一般的な API の誤用を調査しました。この研究が、コード生成時に LLM が API を誤用するという重要な問題を理解するのに役立つことを期待しています。同時に、この研究は、一般的に使用される機能の正確性を超えて、LLM の評価に新しい次元を提供することもできます。さらに、データセットと評価ツールはオープンソースになります。

この論文の貢献は次のように要約されます。

LLM コード生成の信頼性と堅牢性を評価するための新しいベンチマーク、RobustAPI が提案されています。
Stack Overflow の質問で構成されるデータセットと AST を使用した API 使用状況チェッカーを含む包括的な評価フレームワークが提供されます。研究者らはこのフレームワークに基づいて、GPT-3.5、GPT-4、Llama-2、Vicuna-1.5 など、一般的に使用されている LLM のパフォーマンスを分析しました。
LLM 生成コードのパフォーマンスが完全に分析されます。各モデルにおける一般的な API の誤用をまとめ、今後の研究と改善の方向性を指摘しています。

方法の概要

RobustAPI は、LLM で生成されたコードの信頼性と堅牢性を総合的に評価するためのフレームワークです。

以下では、データセットを構築する際のデータ収集プロセスとプロンプト生成プロセスについて説明し、次に RobustAPI で評価された API の誤用パターンを示し、誤用の潜在的な結果について説明します。最後に、抽象構文木を方法として、RobustAPI による API の誤用を検出する静的分析を示します。

結果は、新しい方法がキーワードマッチングなどのルールベースの方法と比較して、LLM 生成コードの API 誤用をより高い精度で評価できることを示しています。

データ収集

ソフトウェアエンジニアリングの分野における既存の研究成果を活用するために、RobustAPI 構築の出発点は ExampleCheck (Zhang et al. 2018) のデータセットでした。 ExampleCheck は、オンライン Q&A フォーラムでよくある Java API の誤用を調査するためのフレームワークです。

研究者らは、以下の表 1 に示すように、データセットから 23 個の一般的な Java API を選択しました。これら 23 個の API は、文字列処理、データ構造、モバイル開発、暗号化、データベース操作など 5 つの領域をカバーしています。

プロンプト生成

RobustAPI には、データセットのサンプルを入力できるプロンプトテンプレートも含まれています。その後、研究者らはプロンプトに対する LLM の応答を収集し、API を介してチェッカーを使用してコードの信頼性を評価しました。

このプロンプトでは、まずタスクの説明と必要な応答形式が示されます。次に、実行される実験が少数ショットの実験である場合は、少数ショットのデモンストレーションも行われます。次に例を示します。

デモサンプル

デモサンプルは、LLM が自然言語を理解するのに役立つことが示されています。 LLM のコード生成能力を徹底的に分析するために、研究者は、シングルショットの無関係なデモンストレーションとシングルショットの関連するデモンストレーションという 2 つの少数ショット設定を設計しました。

単一サンプルの無関係なデモンストレーション設定では、LLM に提供されるデモンストレーション例では無関係な API が使用されます。研究者たちは、このようなデモンストレーション例によって、生成されたコードの構文エラーが排除されるだろうと仮説を立てた。 RobustAPI で使用される無関係な例は次のとおりです。

LLM 用に提供されるデモンストレーション例では、1 サンプル相関デモンストレーション設定で指定された問題に使用されるものと同じ API が使用されます。この例には質問と回答のペアが含まれています。このデモ例の質問はテストデータセットに含まれておらず、研究者は API の誤用がないこと、回答が質問のセマンティクスと適切に整合していることを確認するために、回答を手動で修正しました。

Java API の誤用

研究者らは、RobustAPI の 23 個の API について 40 個の API ルールをまとめ、これらの API のドキュメントで検証しました。これらのルールには以下が含まれます。

（１）APIガード条件。APIを呼び出す前にチェックする必要がある。たとえば、File.exists() の結果は File.createNewFile() の前にチェックする必要があります。

（２）必要なAPI呼び出しシーケンス、つまり、APIは特定の順序で呼び出される必要があります。たとえば、close() は File.write() の後に呼び出す必要があります。

（３）API制御構造たとえば、SimpleDateFormat.parse() は try-catch 構造に含まれている必要があります。

次に例を示します。

APIの不正使用の検出

コード内の API 使用の正確性を評価するために、RobustAPI は、図 2 に示すように、コードセグメントから呼び出し結果と制御構造を抽出することにより、API 使用ルールに基づいて API の誤用を検出できます。

コードチェッカーは、まず生成されたコードスニペットをチェックして、それがメソッド内のコードスニペットであるか、クラスのメソッドであるかを確認し、スニペットをカプセル化して抽象構文ツリー (AST) を構築できるようにします。

次に、チェッカーは AST を調べて、すべてのメソッド呼び出しと制御構造を順番に記録し、呼び出しシーケンスを生成します。

次に、チェッカーはこの呼び出しシーケンスを API 使用ルールと比較します。各メソッド呼び出しのインスタンスタイプを推測し、そのタイプとメソッドをキーとして使用して、対応する API 使用ルールを取得します。

最後に、チェッカーはこの呼び出しシーケンスと API 使用ルール間の最長共通シーケンスを計算します。