コラム

CTC教育サービス・ホーム　＞　コラム　＞　グーグルのクラウドを支えるテクノロジー　＞　第171回　大規模言語モデルによるコードレビュー支援の適用事例（パート2）

グーグルのクラウドを支えるテクノロジー

CTC 教育サービス

[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes

第171回　大規模言語モデルによるコードレビュー支援の適用事例（パート2） (中井悦司) 2024年4月

はじめに

　前回に続いて、2024年に公開された論文「Resolving Code Review Comments with Machine Learning」に基づいて、大規模言語モデルをコードレビュー支援に適用したGoogle社内の事例を紹介します。この論文では、Google社内では、コードレビューのプロセスに大規模言語モデルによる支援を組み込んでいることが報告されています。今回は、モデルの精度向上に向けたチューニングについて解説します。

レビュープロセスへの適用の流れ

　前回の記事で説明したように、コードレビュー支援に使用する大規模言語モデルは、レビューコメントから対応するコードの修正案を予測します。このモデルは、予測結果とあわせて結果に対する信頼度を出力するようになっており、信頼度が事前に決めたしきい値以上のものだけを使用します。これを現実のレビュープロセスに適用する場合、次のような処理をレビューツールに組み込みます（図1）。

fig01

図1 レビューツール上での処理の流れ（論文より抜粋）

　図1に並んだ箱を上から順に説明すると次のようになります。

(1) レビュアーが入力したコメントを受け取る。
(2) レビュアー以外のツールが自動挿入したコメントやすでに解決済みのコメントを除外する。
(3) モデルの予測に対する信頼度がしきい値以下のものを除外する。
(4) その他の除外ルールを適用して、最終的に残ったものをツールの画面上に表示する。
(5) 開発者が修正案の存在に気づいて内容を確認する。
(6) 開発者が修正案を採用する。

　入力されたすべてのレビューコメントの中で、(6)のステップまでたどり着いたものの割合がこの支援システムの有用度の最終的な評価指標になります。詳しくは次回に説明しますが、レビューツールへの組み込みは段階的に行われており、最初はごく少数のベータユーザーのみに提供されました。その後、モデルのチューニングを実施した最初の正式バージョン（V1）が50%のユーザーに提供されて、ツールの有効性を確認するA/Bテスト（ツールを提供するユーザーと提供しないユーザーの比較テスト）が行われました。その後、さらにチューニングを行った次期バージョン（V2）がすべてのユーザーに提供されました。

モデルのチューニング

　実環境での結果を用いたA/Bテストとは別に、テスト用のデータセットを用いたモデルの評価（オフラインテスト）も実施しており、チューニングによるモデルの性能向上は、主にオフラインテストで評価されました。論文では、チューニングによる性能向上を示すデータとして、図2のグラフが紹介されています。

fig02

図2 チューニングによるモデルの性能向上（論文より抜粋）

　縦軸は、テストデータ全体に対して、正しい予測（期待通りの修正案）が出力されたもののを割合（Recall）を示します。グラフ内に記載された「Recall@70」などの値は、予測案を採用する信頼度のしきい値を表します。「Recall@70」の場合、信頼度が70%未満の予測結果は無条件に破棄されて、正しい予測に失敗したものと判断されます。この値を小さくすれば、Recallは大きくなりますが、一方で、実際の利用者に対して不適当な予測案を提示する可能性も高くなります。この値は、この後で説明するように、ユーザーのフィードバックを元にして変更していきます。
　グラフに示されたそれぞれのチューニングの内容は、次のようになります。

Fine-tuning：前回の記事で説明したように、このモデルは、DIDACTのフレームワークを用いて、複数タスクを同時に学習しています。学習後のモデルに対して、さらに、レビューコメントに対する修正案の予測に特化した追加学習を行いました。
Size tuning：モデルのサイズ（モデルに含まれるパラメーター数）に対するハイパーパラメーターチューニングを行いました。
Single comment：学習データの中には、複数のレビューコメントとそれらをまとめて修正する単一のコード修正を含むものがありますが、テストデータの品質を高めるために、テストセットに使用するデータは、単一のレビューコメントのデータのみに制限しました。
Reduce precision：当初に設定した信頼度のしきい値（70%）は大きすぎるというフィードバックに基づいて、しきい値を50%に変更しました。変更に伴って、修正案の採用率が下がったり、Thumbs-up/down の数が変わるなどのネガティブな影響はありませんでした。
Hyperparameters：複数のハイパーパラメーターに対するチューニングを行いました。
Train on "Done"：学習データの品質を高めるために、レビュアーのコメントに対する開発者からの反論やディスカッションが含まれるデータを除外しました。
Symthetic tasks：元々の学習データは、Google社内のソフトウェア開発で蓄積された履歴データを利用したものですが、これに加えて、人工的に作成した学習データを追加しました。コードの一部を削除した上で「この部分のコードを実装すること」というコメントを追加したり、あるいは、過去にコンパイルエラーが発生していたコードに対して「エラーを修正すること」というコメントを追加するなどした学習データになります。
Language tuning：プログラミング言語によって、信頼度のしきい値を異なる値に設定しました。
Reviewer preview：レビュアー自身が自分のコメントに対する修正案を事前確認して、不適切な修正案を事前に除外できるようにしました。これにより、（開発者に対するネガティブな影響を与えずに）信頼度のしきい値を40%に下げることができました。

　これらのチューニングを実施した結果、最終的には、80.3%のリコールを達成していますが、これはあくまでもテストデータに対する結果です。これらのモデルを適用した実環境での評価は次回に改めて紹介します。

次回予告

　今回は、2024年に公開された論文「Resolving Code Review Comments with Machine Learning」に基づいて、大規模言語モデルをコードレビュー支援に適用したGoogle社内の事例について、モデルの精度向上にむけたチューニングの内容を紹介しました。次回は、これらのモデルをレビューツールに組み込んで実環境で利用する際の工夫と、実環境での評価結果を紹介します。

Disclaimer：この記事は個人的なものです｡ここで述べられていることは私の個人的な意見に基づくものであり、私の雇用者には関係はありません｡