Customizing an LLM for Enterprise Software Engineering
本論文は、大規模な研究において開発者の効率性とコードの品質を大幅に向上させるとともに、企業向けモデルのカスタマイズのための再現可能な青写真を提供する、データ選定とミドトレーニングの包括的なエンドツーエンドのプロセスを通じてグーグルの社内ソフトウェアエンジニアリングエコシステムに適応させた専用大規模言語モデル「Gemini for Google (GfG)」を紹介する。
原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。 免責事項の全文を読む
想像してください。ある世界最高峰の天才シェフ（元の AI モデル）がいるとします。このシェフは、イタリアンパスタ、フランス菓子、あるいは日本の寿司に至るまで、ほぼ何でも調理できます。彼らは公共図書館にあるすべてのレシピ本で訓練されています。
しかし、あなたは巨大でハイテクな企業食堂（Google の社内ソフトウェアエコシステム）で働いています。ここではルールが奇妙です。標準的なオーブンを使うのではなく、独自に構築された専用機械を使用します。食材も独特で、「レシピ」（コード）には、建物外にいる誰も知らない特定の奇妙な名前が付けられています。
もし、その世界最高峰のシェフに食堂の食事を作らせようとすれば、彼は標準的なレシピを使おうとするかもしれません。見た目はどうにか見えるでしょうが、あなたの機械では機能せず、食材を壊してしまう可能性があります。
この論文は、Google がその世界最高峰のシェフを連れて、彼らの特定の食堂に完璧なシェフになるための専門トレーニングキャンプを与えた方法を説明しています。彼らはこの新しいシェフを**「Gemini for Google（GfG）」**と呼んでいます。
彼らがどのように行ったか、簡単なステップに分解して説明します。
1. 「秘密のレシピ本」の収集
単にシェフにさらに多くの公共の料理本を与えるのではなく、チームは社内ドキュメントの膨大な図書館を収集しました。これはコードだけでなく、エンジニアがどのように作業してきたかという全歴史でした。
- 「批評」ログ: 上級エンジニアがコードをレビューし、「これを修正せよ」と言い、ジュニアエンジニアがそれを修正した数千の会話を分析しました。これにより、AI はフィードバックを受け入れて改善する方法を学びました。
- 「バグ修正」ログ: エンジニアが壊れたビルド（ソフトウェアが機能しなくなった状態）をどのように修正したかを観察しました。AI は、「ああ、このエラーが表示された場合、通常はこの特定の行を変更すれば解決する」と学びました。
- 「速度」ログ: エンジニアがプログラムを高速化する方法を研究し、AI に遅い箇所を見つけて修正を提案することを教えました。
- 「チャット」ログ: エンジニアが奇妙な社内ツールについて質問する社内 Q&A セッションを使用し、AI に会社の特定の名称や専門用語を教えました。
2. 「中間トレーニング」手術
通常、モデルはゼロから訓練するか（赤ちゃんの脳から始める）、あるいは最終段階で微調整するだけです。Google はその中間を行いました。
元の AI を、高校を卒業した学生（一般的な事前トレーニング済み）と想像してください。
- 問題: 彼にすぐに高度な企業法を教え始めると、基本的な数学や簡単なエッセイの書き方を忘れてしまう可能性があります。これを「破滅的忘却」と呼びます。
- 解決策: 高校の最終学年から始めるのではなく、学生の3 年生まで遡りました。彼に「秘密のレシピ本」（社内データ）を与え、その時点から教育を継続させました。これにより、学生は一般的な知性を保ちながら、特定の企業ルールを学ぶことができました。
3. 結果：より賢いアシスタント
彼らはこの新しい「Gemini for Google」を、29,000 人のエンジニアを相手に標準バージョンと比較してテストしました。結果は、一般的な GPS と、あなたの特定の街のすべての近道を知っている GPS を比較するようなものでした。
- 往復の減少: エンジニアが助けを求めた際、標準的な AI は正しい結果を得るために約 23% 多くの会話ターンを必要としました。一方、専門特化型の AI は、より頻繁に初回で正解しました。
- コードの生存率向上: 専門特化型の AI が作成したコードは、レビュープロセスを生き残り、最終製品に実際に使用される可能性が17% 高いものでした。却下されたり壊れたりする可能性は低かったです。
- 現実世界での勝利:
- 「タイムトラベル」移行: 彼らは AI を使用して、10 年前のシステムを新しいシステムに更新しました。AI は作業の 80% を自動的に実行し、所要時間を半分に削減しました。
- 「スマートペースト」: エンジニアがあるファイルから別のファイルへコードをコピーすると、AI が自動的にインポートや変数名を修正し、即座に動作するようにしました。これにより、何千回ものキー入力が節約されました。
4. 彼らが学んだこと（教訓）
この論文は、これを行おうとするすべての人にとっての 3 つの大きな教訓を浮き彫りにしています。
- より多くのデータが常に良いとは限らない: AI に何でもかんでも投げつけるだけでは、混乱を招く可能性があります。彼らはデータの適切な組み合わせを慎重に選ぶ必要があり、そうしなければ AI は間違った習慣（例えば、行動するべき時に話しすぎるなど）を学習してしまいます。
- 形式と戦わないこと: 彼らは、AI に新しい奇妙な形式を学習させるのではなく、社内データを AI の元のトレーニングスタイルに見えるように調整する方が容易だと学びました。
- 現実のテストが重要である: 選択式クイズで AI をテストするだけでは不十分です。現実の世界でどのように動作するかを見守る必要があります。エンジニアは実際にそのコードを受け入れましたか？レビューを生き延びましたか？それが真のスコアです。
結論
この論文は、新しい種類の脳を発明することについてではありません。非常に賢く汎用性の高い脳を、特定の企業内での専門的なインターンシップに置くことについてです。企業の歴史、失敗、成功を AI に与えることで、彼らは単に「コードを知っている」だけでなく、彼らのコード、彼らのツール、そして彼らの働き方を知っている AI を作り出しました。
自分の分野の論文に埋もれていませんか？
研究キーワードに一致する最新の論文のダイジェストを毎日受け取りましょう——技術要約付き、あなたの言語で。