この記事は Habr の Yandex 企業ブログで公開されたもので、Yandex Infrastructure の ML ラボの責任者が一人称複数で書いている。著者は同じラボに所属する開発者兼アナリストの同僚を自分と並べて紹介し、チームが Yandex Code Assistant をどのように構築したかを説明している。このアシスタントはその秋、Yandex Cloud プラットフォーム上で無料のテストアクセス付きでローンチされた。著者らは自分たちの目標を、ニューラルネットワークにコードを書くことを教えるだけでなく、開発者がそれに満足するようにすることだと位置づけている。
記事の大部分は測定についてである。チームが頼りにしてきた一連の指標、すなわちビジネス指標としてのリテンション、ユニットテストに基づくオフライン指標、オンラインの受け入れ率を順にたどり、それぞれが単独では不十分だった理由を説明したうえで、チームが開発者の幸福度と呼ぶ複合指標に行き着く（開発者の幸福度指標 を参照）。
要点
- 顧客へのインタビューと自分たち自身の経験を踏まえ、チームはチャットインターフェースではなくインライン提案に注力することを選んだ。開発者が実際に求めていたのはインライン提案のほうだと判断したためである。
- ビジネス指標としては 4 週目以降のリテンションが用いられる。Yandex 社内ではインストールは任意だったため、使い続けていることは、ユーザーが「足で投票している」ことと解釈される。測定に 1 か月かかるため、チームはより速く得られる代理指標を探した。
- 提案はテキストではなくコードとして扱われる。モデルは抽象構文木によって特定される完全な文を予測し、途中で切れた文は悪い提案とみなされ、提案は 500 ミリ秒以内に返さなければならない。
- オフライン評価のために、チームは UnitTest と呼ぶ指標を構築した。ユニットテストでカバーされているコード中の文をマスクし、モデルにそれを予測させ、テストを実行して、合格した割合を数えるものである。著者らは、同じロジックはさまざまな書き方ができるため、この指標は編集距離より優れていると論じている。また、人間の評価者も必要としない。
- チームは独自のモデルを事前学習するのではなく既存のモデルをファインチューニングし、それを自社のリポジトリで行った。学習ターゲットは tree-sitter によって文単位で切り出し、空の文を予測するケースも含めた。記事の言わんとするところは、何も言わないほうがよい場合もあるということである。人はコードを上から下へと書くわけではないため、fill-in-the-middle の能力が重要であることもわかった。
- すべてのビジネスロジックは CPU バックエンドに置かれ、そこで提案をリクエストするかどうかを決め、コンテキストを補強し、結果をランク付けする。LLM の推論は別の GPU バックエンドで行われる。プラグインは薄いプロキシに保たれている。プラグインへの修正がユーザーに届くのははるかに遅いためである。記事は、99 パーセンタイルで 420 ミリ秒以内に収まっていると報告している。
- オンラインの A/B テストでは、ユーザー単位ではなくリクエスト単位でトラフィックを分割した。初期の利用者が少なすぎて、ユーザー単位のサンプルでは有意性に達しなかったためである。
- 受け入れ率が上昇する一方で、利用者は離れ始めた。著者らはこれを、短い提案を数多く表示することで受け入れ率を操作できてしまうことの証拠と捉えている。これが幸福度指標につながり、その導入後、受け入れ率は当初低下したにもかかわらず、リテンションは急上昇した。
- 著者らは、開発者が 1 日に書くコードの 15% がアシスタントを使って書かれており、アシスタントを試した数千人の Yandex の開発者のうち 60% が常用ユーザーになったと報告している。これらはベンダー自身の測定による数値である。
背景
この記事はベンダーによる自社製品の説明であるため、競合するアシスタント（「競合 A」として名前が伏せられたものを含む）との比較として報告されている内容は、Yandex 独自の指標と測定に基づいている。締めくくりの教訓は一般的なものである。プロダクト指標を定義すること、直感的ですばやく計算できるオフライン指標を持っておくこと、最終的なロールアウトの判断にはオンライン指標を優先すること、そして指標を変えることを恐れないことである。プログラマーではない人々を対象とした Yandex の後の製品については、コードを書かない人のためのプログラミング：VibeCraft の仕組み を参照。