機械学習を使ったコード補完で開発者の生産性はどのくらい向上するのか？(1/2)

１．機械学習を使ったコード補完で開発者の生産性はどのくらい向上するのか？(1/2)まとめ

・プログラミングコードは年々複雑化しておりコード補完は不可欠なツールとなっている
・従来のコード補完提案はルールベースのセマンティックエンジンで実装されていた
・最近の研究では大規模な言語モデルを使ったコード提案が実証されておりその効果を調査

２．機械学習によるコード補完を定性的に評価する

以下、ai.googleblog.comより「ML-Enhanced Code Completion Improves Developer Productivity」の意訳です。元記事は2022年7月26日、Maxim TabachnykさんとStoyan Nikolovさんによる投稿です。

人工知能が自然言語の穴埋め問題や次に来る単語を予測する事が出来るのならば、プログラミング言語でも同様に次に使う構文や関数を予測して、開発者に提案する事が出来るのではないだろうか？という発想からスタートした人工知能によるコード補完ですが、一番有名なのはOpenAI Codex、及びその製品化であるGitHub Copilotでしょうか。

コード補完はGitHub Copilotのレビューで指摘があったように学習データとしたコードの品質が低ければ、提案されるコードの品質も低くなることが予想されますが、本実験ではGoogle社内のレポジトリを学習データに使ったとの事で、Google基準のレビューと品質ガイドラインが保たれているでしょうから、隙がなさそうですね。大規模な会社なら微調整をして社内コーディング規則に沿った提案をするモデルも出来そうですね。

アイキャッチ画像のクレジットはPhoto by Jefferson Santos on Unsplash

プログラミングコードの複雑化は、ソフトウェアエンジニアリングの生産性に対する重要な課題となっています。コード補完は、統合開発環境(IDE:Integrated Development Environments)で開発する際に、この複雑さを緩和するために不可欠なツールとなっています。

従来、コード補完候補はルールベースのセマンティックエンジン(SE:Semantic Engines)で実装されており、SEは通常、リポジトリ全体にアクセスできるので、その意味構造を理解することができます。

最近の研究では、大規模な言語モデル(CodexやPaLMなど)により、より長く、より複雑なコード提案が可能になることが実証されており、その結果、有用な製品(Copilotなど)が登場しています。

しかし、機械学習(ML:Machine Learning)によるコード補完が、認識される生産性や受け入れられた提案コード以上に、開発者の生産性にどのような影響を与えるかという問題は、まだ未解決のままです。

本日、私達はどのようにMLとSEを組み合わせて、新しいTransformerベースのハイブリッドセマンティックMLコード補完を開発し、現在Google内部の開発者が利用できるようにしたかを説明します。

(1)SEのシングルトークンサジェストをMLで再ランキングする
(2)シングルまたはマルチライン補完をMLで適用してSEで正しさをチェックする
あるいは
(3) シングルトークンセマンティックサジェストのMLによるシングル・マルチラインコンティニュエーション

これらを利用することによって MLとSEを結合する方法を議論します。

1万以上のGoogle社員のハイブリッドセマンティックMLによるコード補完(8つのプログラミング言語で3ヶ月以上)を対照群と比較したところ、単一行ML補完に触れた場合、コーディング反復時間(ビルドとテストの間の時間)が6%、コンテキストスイッチ(IDEから離れること)が7%減少したことが確認されました。

これらの結果は、MLとSEの組み合わせにより、開発者の生産性を向上させることができることを示しています。現在、3%の新しいコード(文字数で測定)がML補完候補を受け入れることから生成されています。

補完のためのTransformers

コード補完の一般的なアプローチは、コード理解と補完予測を可能にするために、言語理解のための自己Attention機構を利用したtransformerモデルを学習させることです。私たちはコードを言語と同様に扱い、サブワードトークンとSentencePieceの語彙で表現し、TPU上で動作するエンコーダ・デコーダの変換モデルを用いて補完予測を行います。入力はカーソルの周囲にあるコード(1000～2000トークン)で、出力は現在または複数の行を補完するための提案のセットです。シーケンスはデコーダのビーム探索(または木探索)で生成されます。

Google社内の統合レポジトリを使った学習では、行の残りとそれに続くいくつかの行をマスクして、活発に開発されているコードを模倣しています。8つの言語(C++, Java, Python, Go, Typescript, Proto, Kotlin, Dart)で1つのモデルを学習させたところ、全ての言語において性能が向上、もしくは同等になり、専用のモデルの必要性が無くなりました。

さらに、モデルサイズを～5億パラメータとすることで、高い予測精度と低遅延、低リソースコストのトレードオフが可能であることがわかりました。このモデルは、ガイドラインとレビューが強制される統合レポジトリの品質から強く恩恵を受けています。複数行のサジェストに対しては、次の行の完了予測を開始するかどうかを決定するための閾値を学習した単一行モデルを反復して適用します。

エンコーダ・デコーダtransformer モデルを用いて、コードの残り部分(1行または複数行)を予測します。

シングルトークンによるサジェストの再ランク付けをMLで行う

ユーザがIDEで入力している間、コード補完機能は背後でMLモデルとSEに同時にコード補完を対話的に要求します。

SEは通常1つのトークンを予測するだけです。私たちが使うMLモデルは行末まで複数のトークンを予測しますが、最初のトークンがSEからの予測にマッチする予測のみを考慮します。

SEの候補にも含まれるML候補のうち、上位3つを特定し、その順位を上位に押し上げます。そして、再ランクされた結果がIDEでユーザへの提案として表示されます。

実務的には、SEはクラウド上で動作し、開発者が慣れ親しんでいる言語サービス(意味補完、診断など)を提供しているため、ML推論を行うTPUと同じ場所でSEが動作するように配置しました。

SEは、コンパイラのような機能を低遅延で提供する内部ライブラリをベースにしています。リクエストは並列で行われ、MLは一般的に高速に処理されるという設計設定のため(中央値で約40ms)、完了までの待ち時間は増えません。実際の使用では、大幅な品質向上が確認されました。28%の受理された補完提案がブーストによりランクアップし、0.4%がランクダウンしています。さらに、ユーザーが補完候補を受け入れる前に入力する文字数が10%以上減少していることがわかります。