これから学ぶ人も、資格取得を目指す人も、最適なカリキュラムを選べます。
これから学ぶ人も、資格取得を目指す人も、最適なカリキュラムを選べます。
CTC 教育サービス
[IT研修]注目キーワード Python Power Platform 最新技術動向 生成AI Docker Kubernetes
前回に続いて、2024年に公開された論文「AI-assisted Assessment of Coding Practices in Industrial Code Review」に基づいて、Google社内での大規模言語モデルによるコードレビュー支援の事例を紹介します。今回は、開発者によるテスト利用を開始した後のチューニングとその改善結果を説明します。
前回の記事で説明したように、AutoCommenterの実環境への適用は、次の4つのフェーズに分けて行われました。
開発チーム内のテスト利用を終えて、3,000名程度のボランティアによるテストを開始すると、数日の間に多数の問題点が報告されましたが、その大部分が特定のベストプラクティスに関するものでした。2022年にPythonのバージョンが3.9に上がって、モジュールのインポート処理に関するベストプラクティスが変更されました。しかしながら、AutoCommenterの学習データには2022年以前のデータが含まれており、古いベストプラクティスの適用を勧めるコメントが数多く生成されていたのです。
この問題を根本的に解決するには、適用対象外になったベストプラクティスを除外した学習データを用意して、モデルを再学習する必要があります。しかしながら、モデルの再学習には時間とコストがかかるため、ベストプラクティスに変更が発生するごとにモデルを再学習するのは現実的ではありません。そこで、AutoCommenterの開発チームでは、適用対象外のベストプラクティスのリストを作成しておき、モデルの予測結果からフィルタリングで除外することにしました。この方法であれば、頻繁に変更が発生しても即座に対応できます。
その後、さらに数ヶ月のテスト利用を続けた所、ポジティブなフィードバックの割合が54%程度から上昇しない状況が継続しました。そこで、さらなる改善のために、AutoCommenterが生成したコメントの内容を具体的に分析することにしました。具体的には、開発者からフィードバックがあったコメントの中から370件のコメントをサンプリングで抽出した上で、15人の評価者に依頼して、オリジナルのフィードバックは伏せた状態で、再度、評価を行いました。その結果、ポジティブな評価は60%で、オリジナルフィードバックとほぼ同じ値になりました。また、ネガティブな評価が付いたコメントを分析した所、次のようないくつかのパターンの分類できることが分かりました。
(1) 複数のトピックや複雑すぎるトピック
AutoCommenterは、改善が必要なコードと適用するべきベストプラクティスのドキュメントへのリンクを出力しますが、実際に該当のドキュメントを開いてみると、複数のトピックが説明されていたり、説明内容が複雑なため、具体的にどのように改善すればよいかが分からないことがありました。
(2) サマリーの品質に関する問題
AutoCommenterが示したドキュメントのサマリーがコメント内に表示されますが、生成されたサマリーの品質が悪いために、サマリーの内容がよく理解できないことがありました。
(3) 一概に良し悪しが判断できないトピック
例えば、ライブラリー内での機能フラグの使用は、一般的には避けるべきと考えられますが、標準的に機能フラグが使用されているライブラリーもあります。このようなライブラリーに追加するコードでは、ライブラリーとしての標準に合わせて機能フラグを使用することがありますが、これに対しても改善を要求するコメントが生成されることがありました。
(4) 系統的に生成される誤ったコメント
例えば、C++のstd::vectorに要素を追加する際に、push_backメソッドとemplace_backメソッドの両方が利用できる場合は、push_backメソッドの利用が推奨されるというベストプラクティスがあります。AutoCommenterのモデルは、emplace_backメソッドを使用しているコードに対して、実際にはpush_backメソッドが使用できない場合でも、push_backメソッドの利用を推奨するコメントを生成するケースがありました。
(5) 有用性の低いコメント
コメントの末尾にはピリオド「.」を付けるべきというベストプラクティスがあります。しかしながら、末尾のピリオドの有無はそれほど大きな違いをもたらす訳ではなく、このようなコメントは多くの場合、有用ではないというフィードバックが与えられます。
AutoCommenterの開発チームは、これらの分析の過程で発見された有用性が低い17個のベストプラクティスを前述のフィルタリングの仕組みで除外しました。また、頻繁に参照されるドキュメントについては、生成されたサマリーを手動で書き直すことで、サマリーの品質を向上しました。これらの改善の結果、ポジティブなフィードバックの割合は80%まで向上しました。この後、すべての開発者の半数にAutoCommenterを適用する形でA/Bテストを実施して、コードレビューにかかる時間やコメントのやり取りの回数の変化を確認した所、統計的に有意な差は認められませんでした。これは、少なくともAutoCommenterの適用による悪影響はないことを示すものと考えて、すべての開発者に対するAutoCommenterの適用を開始したということです。
前述の改善活動により、ポジティブなフィードバックの割合が80%に達したことを説明しましたが、これはあくまで、フィードバック全体の80%という意味です。開発者がフィードバックを返すことはそれほど多くないため、AutoCommenterが生成したコメント全体の何%がポジティブに受け取られているかは、この数字だけでは判断できません。そこで、AutoCommenterの開発チームは、生成したコメントの何%が実際のコードに適用されているかを調査することにしました。
まず、AutoCommenterがコメントを付けたコードが、その後、リポジトリにコミットされたコードにそのままの形で残っているかを機械的にチェックした所、約50%はコミット時のコードからは無くなっていました。これは、開発者がコメントの指示に従って修正したか、もしくは、別の理由で該当のコードが削除されたことを意味します。そこで、40個のコメントをサンプリングで抽出して、実際の修正内容を確認した所、約80%はコメントの指示に従った修正が行われていました。この結果を単純に当てはめると、全体の50%の中の80%、すなわち、AutoCommenterが生成したコメント全体の40%は、コメントの指示にしたがった修正が行われていることになります。
今回は、2024年に公開された論文「AI-assisted Assessment of Coding Practices in Industrial Code Review」に基づいて、Google社内での大規模言語モデルによるコードレビュー支援の事例について、開発者によるテスト利用を開始した後のチューニングとその改善結果を説明しました。開発者からのフィードバックだけではなく、さまざまな評価手法を組み合わせることで、改善するべきポイントを的確に発見していることがわかります。
次回は、Googleのデータセンターネットワークに関する話題をお届けします。
Disclaimer：この記事は個人的なものです｡ここで述べられていることは私の個人的な意見に基づくものであり、私の雇用者には関係はありません｡
[IT研修]注目キーワード Python Power Platform 最新技術動向 生成AI Docker Kubernetes
