ソフトウェアコード検証におけるLLMの評価

大規模言語モデル（LLM）は、ソフトウェアの作り方を変えちゃったよね。コードを書いたり、バグを直したり、ソフトウェアをテストしたり、ドキュメントを作ったり、プログラミング言語の翻訳もできるんだ。こういう能力があるから、LLMはソフトウェア開発にめっちゃ便利なんだ。ただ、LLMを使うことには心配ごともある。バイアスのあるデータから学んじゃうリスクがあって、それがエラーや危険な出力につながることもあるし、プライベートな情報を知らずに共有しちゃうかもしれないんだ。それに、LLMはよく「ブラックボックス」みたいになっちゃって、どうやって結論に至ったのかが見えにくいんだよね。これが、どれだけ信用できるのかって疑問を生むわけさ。

この記事では、LLMが生成したコードを評価する方法について見ていくよ。目標は、彼らが作ったコードの妥当性を判断する能力を評価することなんだ。特に、「DeepSeek」のdeepseek-coder-33B-instructっていう特定の大規模言語モデルに焦点を当てて、過去に特定のプログラミングモデルのコード生成で良い結果を出したことがあるからね。

#LLMの役割

LLMは、受け取った入力に基づいて次の単語やフレーズを予測することで動くんだ。彼らはインターネットからのたくさんのテキストを使って訓練されてるから、従来のソフトウェアよりも人間の言葉を理解して処理するのが得意なんだ。LLMが通常使うモデルは「トランスフォーマー」として知られていて、いくつかの技術を使って入力データを処理し、適切なテキストを生成するんだ。

LLMは、コーディングのいろんなタスクで考慮されてるんだ、例えば：

• コード生成：入力に基づいて新しいコードを作る。
• 要約：長いコードやドキュメントを短い要約にする。
• リファクタリング：機能を変えずに既存のコードの構造や可読性を改善する。

LLMが進化し続ける中で、コンパイラテストのコードを検証するために特に使いたいっていう関心が高まってる。検証は、プログラムが正しく動作して、正確な結果を出すかを保証するのに重要なんだ。

#LLMをジャッジとして使う（LLMJ）

この記事では、LLMをジャッジ（LLMJ）として使って、LLMが生成したコードの信頼性をどうやって判断するかについての話をするよ。私たちはテストのためにdeepseek-coder-33B-instructモデルを使ったんだ。このモデルは、以前の研究で特定の並列プログラミングモデル（OpenACCとOpenMP）のコード生成において良いパフォーマンスを見せたんだ。

LLMをジャッジとして使うことは、特定のメトリクスに基づいてコードを評価するようにモデルを訓練することを含む。これによって、LLMがコードのエラーを分析したり、構文が正しいかをチェックしたり、必要な仕様に従っているかを確認できるようになるんだ。このプロセスは、検証プロセスで人間の介入を最小限に抑えるのに重要で、時間と労力を節約できるんだ。

#方法論

#テストスイートの作成

deepseek-coder-33B-instructを評価するために、手動で書かれたコンパイラテストを2つのグループに分けてテストスイートを作成したよ。一方のグループにはいくつかの意図的なエラーがあるコードを入れ、もう一方は変更なしのコードにした。この戦略で、LLMが無効なコードをどれくらい正確に特定できるかを見れるんだ。

評価基準は以下のように構成したよ：

• 構文：コードが文法的に正しいかをチェックする。
• 指示の適切性：正しい操作指示が使われているかを確認する。
• 条項の正確性：仕様に基づいて条項が正しく使われているかをverifyする。
• メモリ管理：CPUとGPU間のデータ転送をどれだけ上手く管理できるかを評価する。
• 準拠性：コードが最新のOpenACCの仕様やベストプラクティスに従っているかを確認する。
• 論理：テスト内の論理が健全かを確認する。

LLMが両方のコードセットにどう反応するかを比較することで、成功するところや苦労するところを評価できるんだ。

#ネガティブプロービング

ネガティブプロービングは、意図的に変更されたコードをLLMがどう評価するかを分析することを含む。つまり、本来有効なコードにエラーを加えて、LLMがどれだけ効果的に判断できるかを見るんだ。

テストを2つのグループに分けたよ：

1. 修正されたコード（エラーあり）

   • 必要なメモリ割り当てを削除。
   • 宣言されていない変数を追加。
   • 不正確な指示にスワップ。
   • 必要な括弧を削除。
   • 有効なコードをランダムなコードに置き換え。

2. 有効なコード（変更なし）

   • 変更されていないコード。

これらのグループを評価するようにLLMに促すことで、設定した基準に基づいて有効なコードと無効なコードを識別する能力に関するデータを集められるんだ。

#エージェントベースアプローチ

エージェントベースアプローチは、LLMを独立した評価者として捉え、出力を向上させるためにさまざまなツールを使うんだ。私たちの場合、コードごとのコンパイルエラーや実行エラーなどの追加情報をLLMに提供したよ。このデータをプロンプトに統合することで、LLMの評価プロセスを改善することを目指したんだ。

#検証パイプライン

検証パイプラインを作成することで、コンパイルされたコードを効率的に評価するための構造化された方法ができるよ。パイプラインは以下のいくつかの段階から構成されてる：

1. コンパイル：構文エラーをチェックするためにコードをコンパイル。
2. 実行：コンパイルが成功した場合、コードを実行。
3. 評価：LLMを使ってコードの妥当性を判断。

各段階を通過したファイルだけが次のステージに進むから、時間とリソースを節約できるんだ。

#実験設定

高性能コンピューティングクラスターを使ってテストを行ったよ。これによって、たくさんのファイルを素早く処理できたんだ。テストには、既存の検証および確認スイートからのC、C++、Fortranのファイルを利用したよ。

#メトリクスの定義

LLMのパフォーマンスを測るために、3つのメトリクスを設定したよ：

• 問題別評価精度：LLMがファイル内の特定の問題をどれだけ正確に特定できたかを測る。
• 全体評価精度：特定の問題に関わらず、LLMの評価の全体的な正確さを考慮する。
• バイアス：LLMが無効なファイルを間違って通過させたり、有効なファイルを誤って失敗させたりしてないかをチェックする。

これらのメトリクスで、LLMのパフォーマンスをはっきりと評価できるんだ。

#結果の分析

#パート1：ネガティブプロービングを使ったLLMJの評価

テストを実行した後、deepseek-coder-33B-instructが私たちの提供した直接的な分析プロンプトに基づいてファイルをどれだけうまく判断できたかを分析したよ。

OpenACCとOpenMPの評価では、次のことがわかった：

• LLMはOpenACCファイルのいくつかの構文エラーやテストロジックエラーに苦労した。
• OpenMPファイルに関しては、LLMは構文エラーをよりよく認識できたが、いくつかの論理エラーを特定するのはまだ苦手だった。

全体的に、有効なコードと無効なコードの認識には混合結果を観察したよ。

#パート2：エージェントベースアプローチと検証パイプラインを使ったLLMJの評価

LLMのパフォーマンスを改善するために、エージェントベースアプローチを作ったんだ。このアプローチでは、評価プロセスを向上させるために直接的なプロンプトと間接的なプロンプトの両方を使用したよ。

1. 直接分析プロンプト：LLMに基準に対してコードを直接評価するように求めた。
2. 間接分析プロンプト：LLMにコードがどう動くかをステップバイステップで説明するように求め、その後で妥当性を判断させた。

比較分析では、両方のプロンプトタイプが異なるレベルの成功を示した。全体的に、間接的なプロンプト技術は、コードの適切な使用や論理を認識する上でより良い結果をもたらしたんだ。

#結論と今後の研究

この探索は、エージェントベースアプローチと構造化された検証パイプラインを合わせることで、LLMが生成したテストの評価が大きく改善されたことを示しているよ。私たちの発見は、これらの戦略を実行することで、deepseek-coder-33B-instructモデルの全体的な精度が向上したことを示しているんだ。

今後は、Fortranコードをテストに組み込むことで研究を拡大するつもりだ。さらに、この研究から得た知見に基づいて、コンパイラテストの生成の自動化を進めることも目指してる。

この作業を続けることで、ソフトウェアの検証や確認におけるLLMの使用をより効果的で信頼できるものにしていきたいと思ってるんだ。