【ソフトウェア開発に革命をもたらすLLM】新たな評価ハーネスを用いた、統合開発環境（IDE）における大規模言語モデルの有効性検証
3つの要点
✔️ 統合開発環境（IDE）における大規模言語モデルの有用性検証：統合開発環境（IDE）でのOpenAIのGPT-3.5、GPT-4、Code Llamaなどの大規模言語モデルの利用可能性とそのプログラミングアシスタントとしての性能を検証。
✔️ 多様な評価シナリオ：ドキュメント生成、バグ修正、コード生成、テストケース生成、ワークスペース理解など、5つの開発シナリオを通じて大規模言語モデルのソフトウェア開発への貢献度を評価。
✔️ 評価ハーネスの提案：新しい評価基準とコパイロット評価ハーネスの導入により、大規模言語モデルの性能をより正確に測定し、開発プロセスのコスト最適化へ貢献を可能に。
Copilot Evaluation Harness: Evaluating LLM-Guided Software Programming
written by Anisha Agarwal, Aaron Chan, Shubham Chandel, Jinu Jang, Shaun Miller, Roshanak Zilouchian Moghaddam, Yevhen Mohylevskyy, Neel Sundaresan, Michele Tufano
(Submitted on 22 Feb 2024)
Subjects: Software Engineering (cs.SE); Artificial Intelligence (cs.AI)
code：
本記事で使用している画像は論文中のもの、紹介スライドのもの、またはそれを参考に作成したものを使用しております。
概要
ソフトウェア開発は絶えず進化しており、開発者の生産性向上に向けた最先端技術の導入に関心が高まっています。中でも、統合開発環境（IDE）での大規模言語モデルの活用が注目されており、OpenAIのGPT-3.5やGPT-4、オープンソースのCode Llamaなどが、高性能なプログラミングアシスタントとしてのポテンシャルを秘めています。この論文では、統合開発環境における大規模言語モデルを活用したプログラミングアシスタントとしての有用性を評価ハーネスを紹介し、多様なプログラミングシナリオと言語における適応性を検証しています。
この検証では、ドキュメント生成（doc）、バグ修正（fix）、自然言語からのコード生成（generate）、コードのテストケース生成（test）、ワークスペース理解とクエリ解決（workspace）の5つの主要な開発シナリオを評価しています。評価ハーネスの指標は、これらの相互作用、正確さ、効率を評価するために、実用を考慮して設計されています。モデルが実世界のコードで関数を生成するための複雑さを適切に評価することを目指しています。
また、大規模言語モデル自体による出力の確率性や論理のギャップを考慮し、新しい評価基準も提案しています。これにより、プロンプトやパラメータの変更が実際のコードに及ぼす影響を自動的に理解し、より正確なパフォーマンス評価を可能にしています。
最終的に、この論文で提案している評価フレームワークは、GPT-3.5やGPT-4、Code Llamaなど、多様なLLMモデルを使用してVisual Studio Codeなどの統合開発環境での有効性を評価しています。開発者の広範なニーズと好みに応えるために、大規模言語モデルによるプログラミングの能力と限界についての包括的な視点を提供しています。
大規模言語モデルによるソフトウェアプログラミングの評価
最新の大規模言語モデルが、ソフトウェアエンジニアリングの分野でどの程度有用であるかを明らかにするため、様々な指標を用いてパフォーマンスを測定しています。従来のHumanEvalに加え、BLEUやCode-BLEUといったマッチベースの指標が一般的に用いられています。これらの指標は、コード生成やコード翻訳といったタスクにおいて、大規模言語モデルの出力の品質を評価する基準となっています。さらに、大規模言語モデル自体を用いた出力評価も行われていますが、機能的な正確性を重視した新たな評価基準の提案もあります。
ドキュメント生成：ここではドキュメントの自動生成に大規模言語モデルがどの程度有効かを検証しています。例えば、VS Code IDEでは、開発者がフィボナッチ関数のドキュメントを大規模言語モデルに生成させるよう依頼する場面があります。評価では、生成されたドキュメントの位置、形式、カバレッジの正確さが重視しています。これには、ドキュメントがコードの構文を崩さずに適切に挿入されているか、関数の説明が適切に記述されているかなども考慮されています。
バグ修正：大規模言語モデルを使用して静的解析ツールによって特定されたバグを修正するタスクも検証しています。目標は、修正後のコードが元のコードよりも全体的にエラーが少ない状態になることです。このプロセスでは、様々な言語に対応する静的解析器が用いられ、修正が成功したかどうかは、修正後のコードが構文的に正しく、静的解析の警告やエラーが解消されているかによって評価されています。VS Code IDEでの「yield」の綴り間違いを修正する例などが挙げられます。
これらのタスクを通じて、大規模言語モデルがソフトウェア開発プロセスにおいてどのように貢献できるか、その潜在的な価値と限界を検証しています。特に、静的解析ツールによって見つかったバグに対する修正提案では、新たなエラーの導入を避けつつ、元の問題を効果的に解決することが重要です。
自然言語からのコード生成（generate）：自然言語の指示から正確なコードスニペットを生成する能力は、大規模言語モデルの革新的な進歩を示す重要なタスクです。VS Code IDEでのフィボナッチ数列を生成する関数の例は、この技術が実際にどのように機能するかを視覚的に示しています。開発者は大規模言語モデルにタスクを説明し、結果として得られたコードはエディターに差分ビューで表示されます。
生成されたコードが成功したと見なされるためには、2つの主要な基準を満たす必要があります。1つは構文的に正確であること、もう1つは関連するテストケースをすべてクリアすること。構文の正確さは、言語固有のパーサーを用いて確認され、テスト通過率はプロジェクトのテストスイートを実行することで検証します。これにより、大規模言語モデルが生成したコードの実用性と信頼性が評価されます。評価手順は、テストケースを含むリポジトリのセットから始め、特定の条件を満たすメソッドを選択します。選ばれたメソッドに対して、大規模言語モデルにそのボディを生成させ、"Your Code Here"というコメントと置き換えて提供します。生成されたメソッドボディは元の位置に戻され、変更後のコードはテストスイートで評価されます。
このプロセスを通じて、大規模言語モデルが自然言語の指示に基づいてどの程度効率的かつ正確にコードを生成できるかを深く理解することができます。
コードのテストケース生成（test）：大規模言語モデルの進化により、コードのテストケースを自動生成することが可能になりました。開発者がユニットテストを作成するプロセスを効率化し、品質保証のプラクティスに新たな動機付けを提供します。VS Code IDEでフィボナッチ関数のテストケースを要求する開発者の例は、この技術がどのように実際の開発環境に適用されるかを示しています。
生成されたテストケースが成功するための基準は2つです。1つは構文的に正確であること、もう1つは実行時に合格することです。この評価では、テスト対象のコードが正しいという前提のもとに行います。生成されたテストの構文正確さと合格率は、言語固有のパーサーを用いてチェックされます。
評価手順では、まずメソッドのセットからスタートし、大規模言語モデルにそれぞれのメソッドに対するテストを生成させます。これには、メソッドのシグネチャ、ドックストリング、ボディを大規模言語モデルに提供し、"Your Code Here"というプレースホルダーを使って元のメソッドボディを置き換えます。
テストが生成された後、それをメソッドが存在するリポジトリに追加し、テストの実行を試みます。JavaScriptとTypeScriptでは、JestやMochaライブラリを使用してテストを生成し、リポジトリの既存テストスイートとは独立しています。生成されたテストの評価では、インポートエラーを避けるために、テストを一時的にメソッドのファイルに追加し、全体を実行します。自明なテストケース（例えば、常にtrueであるべきテスト）の実行結果がfalseまたはエラーを返した場合、生成されたテストの結果は信頼できないと判断されます。
このプロセスを通じて、大規模言語モデルが生成したテストケースが、ソフトウェア開発のテストフェーズにおける効率性と正確性をどのように向上させるかを検証しています。
ワークスペースの理解とクエリ解決（workspace）：ユーザーの質問に答えるために関連するコードスニペットを特定する能力は、大規模言語モデルの理解力を試す重要なタスクです。このプロセスでは、大規模言語モデルがユーザーの自然言語クエリと膨大なコード量の両方をどの程度理解できるかが試されます。具体的には、VS Code IDEでのフィボナッチ関数に関するテスト要求の例を通じて、この技術の実用性が示されています。
大規模言語モデルによって取得されたスニペットの品質は、平均逆順位（MRR）とエンドツーエンドのキーワード検出の2つの方法で評価されます。平均逆順位は、モデルが提供するスニペットリスト内で正しいスニペットがどの位置にあるかに基づいて計算され、テストケースごとのモデルのスコアの平均値を表します。一方、エンドツーエンドのキーワード検出は、クエリに対する正しい回答に関連するキーワードがモデルの応答に含まれているかをチェックすることで、取得されたスニペットの関連性を評価します。
評価は、モデルにユーザークエリとそれに関連するコードベースの全文脈を提供し、関連するコードスニペットのリストを取得させることから始まります。平均逆順位を用いて、モデルが取得したスニペットの品質を直接評価し、モデルがどれだけ関連性の高いコードスニペットを見つけ出せるかを測定します。さらに、クエリと取得したスニペットをコンテキストとしてモデルに提供し、元のユーザークエリに対する回答を求めることで、全ての取得されたスニペットの品質を評価します。モデルの最終的な応答から、質問に完全に答えるために必要な情報が見つかったかどうかを判断します。
このアプローチにより、モデルが実際に手元の質問に答えるのに役立つコードスニペットをどれだけ効果的に見つけ出せるか、その取得能力をエンドツーエンドで評価することができます。
評価ハーネスのデータ収集
この論文では、プログラミングの世界でより良い評価指標を提供するため、コパイロット評価ハーネスを開発しています。このハーネスは、開発者が作成したコードを様々な角度から評価し、その品質を向上させるためのものです。ここでは、この評価システムを構築する際の重要な一歩である「データ収集」について説明しています。
データ収集の過程では、JavaScript、Typescript、Python、Java、C/C++、C#の6つの主要なプログラミング言語をカバーする、数百の公開GitHubリポジトリから情報を収集しています。これらのリポジトリからは、特定の基準を満たすコードのメソッドを抽出し、それらを評価の基礎として使用します。特に、ビルドやテストの実行が可能なリポジトリのみを対象にしており、そのためには多様なビルドおよびテスト戦略を試みる特別なビルドエージェントを開発しています。このエージェントはまた、静的解析ツールを用いた評価も可能にします。
GitHubリポジトリからの選定基準は厳格で、特に言語ごとに異なる要件があります。たとえば、JavaScriptとTypescriptのリポジトリは、`package.json`ファイルがルートディレクトリに存在し、npmを使用して管理されているものを対象とします。Javaでは、Mavenを使用し、JDK 1.8でビルド可能なプロジェクトを選んでいます。Pythonでは、すべての依存関係が仮想環境内で正常にインストールできるリポジトリのみが選ばれ、C/C++では、手動で選定したリポジトリセットから、Dockerイメージ内でビルドおよびテストが可能なものを利用しています。
リポジトリの選定にあたっては、サイズが1MB未満または100MBを超えるもの、10分以上ビルドやテストの実行に時間がかかるもの、そしてメソッドを含まないものは除外しています。これにより、高品質なデータセットの構築を目指しています。
このデータ収集プロセスを通じて、多様なプログラミング言語とプロジェクトに対する評価ツールの構築を目指しています。これにより、ソフトウェア開発の品質向上に貢献し、開発者がより効率的かつ効果的にコードを書く手助けをすることを目標としています。
評価ハーネスのテストケース収集
この論文では、プログラミング言語ごとに適切なリポジトリを厳選し、それらの中から効果的なテストケースを生成するための手法を開発しています。このプロセスは、コードの品質を測定し、改善するための重要なステップです。ここでは、この論文で採用している主なアプローチを紹介しています。
ドキュメンテーションの自動生成：縮小化や難読化を受けていない、3行以上のメソッドを持つリポジトリを対象にテストケースを作成しています。評価対象のコーディングアシスタントには、これらのメソッドに対する適切なドキュメント文字列を生成する課題が与えられます。生成されたドキュメントが適切な位置にあり、形式が正しく、内容が充実している場合、成功とみなします。
バグ修正：静的解析ツールが指摘する警告やエラーを基にテストケースを生成しますが、インポートや設定に関連する警告は除外しています。生成された修正案が文法的に正しく、静的解析の警告数を減少させる場合、これを成功と評価されます。ただし、元の問題を修正する過程で新たな問題を生じさせないことが重要です。
自然言語からのコード生成：既存のテストでカバーされているメソッドに焦点を当て、コーディングアシスタントに対して、指定されたメソッドシグネチャに合致するメソッド本体の生成を依頼します。生成されたコードが文法的に正しく、すべての関連テストをパスする場合、成功とみなしています。
コードからのテスト生成：リポジトリ内で特定されたメソッドに対して、動作するテストの提供をコーディングアシスタントに求めます。提供されたテストが対象メソッドを呼び出し、適切に実行される場合、これを成功と評価しています。
ワークスペース理解とクエリ解決：開発者が提出したプロジェクトのワークスペースに関する質問を収集し、関連するコードスニペットを提供することで解決を図ります。提供されたスニペットの品質は、平均逆順位（MRR）を用いて評価されています。
実験
先ほどのト評価ハーネスの指標とテストケースを使用して、OpenAIのモデルであるGPT-3.5とGPT-4、およびCodeLlamaの性能をドキュメント生成とバグ修正のシナリオにおいて評価しています。これは、70万人以上のアクティブユーザーを持つVSCode IDEの大規模言語モデルパワードチャット拡張機能をコードアシスタントとして使用しています。
この実験は、以下の3つの質問に答えることを目的としています。
- RQ1. モデル比較：コーディングアシスタントと統合された際、異なる大規模言語モデルは互いにどのように比較されるか？
- RQ2. 統合の改善：評価ハーネスは、コーディングアシスタントでの大規模言語モデルの統合を改善するために、エンジニアにどのような洞察を提供できるか？
- RQ3. データの妥当性：評価テストケースは、IDEを介したユーザーと大規模言語モデルの対話が現実世界の使用パターンをどの程度反映しているか？
まずは、「RQ1. モデル比較：コーディングアシスタントと統合された際、異なる大規模言語モデルは互いにどのように比較されるか？」です。ここでは、GPT-3.5、GPT-4、そしてCode Llamaの3つのモデルを比較しています。
ドキュメンテーション生成のでは、下表のように、ドキュメンテーション生成では、GPT-4が他の2つのモデルを上回るパフォーマンスを示しています。特にPythonではCode LlamaがGPT-4に匹敵する結果を出しましたが、C/C++ではCode Llamaのパフォーマンスが大きく低下しています。これは、GPT-3.5とGPT-4がインターネット上の広範なオープンソースコードから学習しているため、多様なコードパターンを認識しやすいことが要因と考えられます。対照的に、より小規模なCode Llamaは、特定のコードスニペットに対する経験が限られているため、一部のシナリオで劣る結果となっています。
バグ修正のテストでは、GPT-4が僅かにGPT-3.5を上回り、Code Llamaがそれに続いています。しかし、C#のバグ修正では、3つのモデルすべてが苦戦し、GPT-3.5が他の2つのモデルをわずかに上回る結果となっています。GPT-4が提案した修正が間違った場所に適用されるケースも観察され、潜在的な解決策にもかかわらず、バグを修正できない場合がありました。
GPT-3.5は、GPT-4がより高度で複雑な修正を試みる一方で、より基本的で効果的ではない解決策を選択することが多いことがわかりました。このような差異は、特に型指定に関するエラーの解決時に顕著で、GPT-4はより適切な型を推測しようとしますが、それがコードのコンテキストに合致しない場合があります。一方で、GPT-3.5はより単純なアプローチを採用することで、問題を回避しますが、これは必ずしも最良の実践とは言えません。
この比較から、GPT-4が全体的に優れたパフォーマンスを発揮する一方で、特定のシナリオではCode LlamaやGPT-3.5が有効な解決策を提供する可能性があることが明らかになりました。各モデルの強みと弱みを理解することで、コーディングアシスタントの統合と利用をさらに最適化することが可能と考えられます。
次に「RQ2. 統合の改善：コパイロット評価ハーネスは、コーディングアシスタントでの大規模言語モデルの統合を改善するために、エンジニアにどのような洞察を提供できるか？」です。ここでもドキュメント生成とバグ修正のプロセスに焦点を当て、これらの課題を解決するための改善策を検証しています。
ドキュメント生成における課題と解決策：ドキュメント生成の評価からは、4つの主なエラータイプが特定されています。コードロジックの変更、構文の変更、不完全なドキュメント文字列、関係のないドキュメント文字列です。特に、GPT-4は指示に従う能力が高く、よりクリーンなコード変更を提案する傾向がありますが、これがドキュメント生成タスクの失敗に繋がることもあります。
これに対処するため、コーディングアシスタントのプロンプトに、焦点のコードを変更しないよう具体的に指示することで、全言語にわたり評価結果が顕著に改善されました。この変更は、C++で5％からJavaで11％までのパフォーマンス向上に繋がりました。また、GPT-4が特定の指示にどのように敏感に反応するかを示す事例も見られます。
バグ修正の評価では、静的解析器が検出するエラータイプを慎重に分析しています。両モデルはオブジェクトの名前空間を見つけ出し、型の問題を修正する能力がありますが、"has an 'any' type"エラーの正確な解決には至っていません。
この問題を解決するためには、大規模言語モデルパワードチャット拡張機能でモデルにターゲット変数の型や名前空間などの追加コンテキストを提供する必要があります。これにより、モデルが問題を正しく修正できるようになり、誤った型の使用や新しい型の幻覚を避けることができます。
この実験を通じて、大規模言語モデルを統合開発環境に統合する際の課題を明らかにし、それらの課題を解決するための具体的な改善策を提案しています。堅牢で包括的な評価システムを用いることで、これらの発見と改善は可能となり、開発プロセスの質の向上に貢献することが期待されます。
最後は、「RQ3. データの妥当性：評価テストケースは、大IDEを介したユーザーと大規模言語モデルの対話が現実世界の使用パターンをどの程度反映しているか？」です。
この論文では、実際のgitリポジトリから収集したデータセットを用いて、IDEを介したユーザーと大規模言語モデルの対話が現実世界の使用パターンをどの程度反映しているかを検証しています。特に、VS Codeで利用可能な大規模言語モデルパワードチャット拡張機能のドキュメント生成とバグ修正機能の使用方法に焦点を当て、数百人のMicrosoft開発者の使用データを収集し、これをこの論文で提案するテストケースと比較することでデータセットの妥当性を確認しています。
ドキュメント生成に関しては、文書化されたコードスニペットをOpenAIのada埋め込みモデルを使用して埋め込み、これをMicrosoft開発者の使用データと比較しました。この比較により、ドキュメント生成機能に関して、この論文で提案するデータセットが、実際の開発者の使用パターンと類似していることが示されました。
バグ修正においても、バグを含むコードスニペットを埋め込み、PCA次元削減を利用して2次元でプロットしました。この分析から、バグ修正機能に関して、この論文が提案するテストケースが、実際の使用状況と同様の空間内に存在することが確認されました。
この論文の目標は、テストケースを実際の使用例と完全に一致させることではなく、テストケースが実用的な使用状況の範囲内にあるかどうかを検証することでした。この分析結果は、ドキュメント生成とバグ修正の両機能に関して、この論文で提案するデータセットが、現実の使用状況と一致していることを示唆しています。これにより、大規模言語モデルを用いた開発支援ツールの実用性に関する重要な洞察が得られ、開発プロセスの質の向上に寄与することが期待されます。
まとめ
大規模言語モデルを開発者が複雑なエンジニアリングタスクに活用する頻度が高まる中、大規模言語モデルによって生成されたコードの堅牢な評価の必要性が増しています。多くの企業や製品がワークフローへの大規模言語モデルの統合を目指す現状では、既存の評価メトリクスだけでは、自動生成されたコードの品質と正確性を十分に保証することができません。この問題への対策として、本論文ではCopilot評価ハーネスを提案し、メソッド生成、テスト生成、ドックストリング生成、バグ修正、ワークスペース理解という5つの主要な評価メトリクスを導入しました。これらのメトリクスに基づくテストケースと評価結果の収集方法について詳しく説明し、複数のプログラミング言語にわたる予備的な結果も共有しています。
評価ハーネスの開発目的は、大規模言語モデルが生成したコードの品質を検証することにあります。コード生成に関する機械学習技術が大きく進歩する一方で、大規模言語モデルをコードワークフローに確実かつ効果的に組み込むためには、慎重な監督と工学的な努力が求められます。開発者が大規模言語モデルを自身のコーディングプロセスに適切に統合できるよう、包括的な評価スイートを提供することが目標です。コパイロット評価ハーネスを使用することで、プログラマはプロンプトの表現や情報提供の順序、モデルへのコンテキスト提供の変更など、様々なパラメータの影響をより体系的に評価できるようになります。
さらに、コパイロット評価ハーネスは、コスト最適化にも貢献します。例えば、予算に配慮した大規模言語モデルがドキュメント作成などのタスクで満足できるパフォーマンスを提供する可能性を示すことができます。この洞察により、開発者はリソースを賢く配分し、コスト効果の高い大規模言語モデルを適切に活用しつつ、より複雑なタスクには高性能な大規模言語モデルを使用して最良の成果を目指すことができます。
この記事に関するカテゴリー
