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 使用ルール間の最長共通シーケンスを計算します。

この呼び出しシーケンスが予想される API 使用ルールと一致しない場合、チェッカーは API の誤用が発生したと報告します。

 実験結果

研究者らは、GPT-3.5、GPT-4、Llama-2、Vicuna-1.5 の 4 つの LLM で RobustAPI を評価しました。

実験で使用される評価指標には、API 不正使用率、実行可能サンプルの割合、全体的な API 不正使用率が含まれます。

この実験の目的は、以下の質問に答えることです。

• 質問 1: 実際のプログラミング問題を解決するときに、これらの LLM の API 誤用率はどれくらいですか?
• 質問 2: 無関係なデモ サンプルは結果にどのような影響を与えますか?
• 質問 3: 正しい API 使用例によって API の誤用率を減らすことができますか?
• 質問 4: LLM によって生成されたコードが API 使用チェックに失敗するのはなぜですか?

具体的な実験プロセスについては原著論文を参照してください。研究者らが得た 5 つの発見は次のとおりです。

発見 1: 現実世界のプログラミング問題に対する最先端の大規模言語モデルの答えは、多くの場合、API の誤用によって影響を受けます。

発見 2: 実行可能コードを含むすべての LLM 回答のうち、コード セグメントの 57 ～ 70% に API の誤用の問題があり、運用時に深刻な結果を招く可能性があります。

発見 3: 無関係なサンプル例は API の誤用率を減らすのには役立ちませんが、より効果的な回答を誘発し、モデルのパフォーマンスをベンチマークするために効果的に使用できます。

発見 4: 一部の LLM は正しい使用例を学習できるため、API の誤用率を削減できます。

発見 5: GPT-4 には実行可能コードを含む回答の数が最も多くあります。ベンチマーク API の場合、異なる LLM の誤用率の傾向も異なります。

さらに、研究者らは論文の中で、GPT-3.5に基づく典型的なケースも実証しました。つまり、モデルは異なる実験設定下で異なる反応を示すということです。

このタスクでは、PrintWriter.write API を使用して文字列をファイルに書き込むモデルが必要です。

ゼロショットとワンショットの無関係なデモンストレーション設定では、答えは若干異なりますが、どちらも API の誤用の問題を示しており、例外は考慮されていません。モデルに API の正しい使用例を提供すると、モデルは API の使用方法を学習し、信頼性の高いコードを生成しました。

詳細については原文論文を参照してください。