DatabricksがDay 1に12,000人の従業員にフロンティアモデルを展開した方法

従業員にフロンティアAI機能へのアクセスを提供することは、Databricksにおける最優先事項です。そのため、新しいモデルが利用可能になったらすぐに従業員がそれらを使用できるようにすることが重要です。同時に、12,000人以上の従業員に新しいモデルへの迅速なアクセスを提供することは、以下の理由から容易ではありません。

1. フロンティアモデルとして売り出されているモデルが、実際にはそうではないことがよくあります。例えば、Opus 5.0はOpus 4.8と比較してコストが高く、社内エンジニアによる定量的および定性的な品質スコアの両方で低い評価となりました。性能が後退したモデルに移行することは、企業を支援するどころか、大きな打撃を与える可能性があります。私たちの経験では、ワークロードを新しいモデルに一斉に移行する前に、モデルの評価を慎重に行う必要があります。
2. 新しいモデルを安易に使用すると、コストが爆発的に増加する可能性があります。コスト削減策を講じることなく、対照群にGPT Astraをリリースしたところ、 開発者1人あたりの平均支出が60%増加しました。1万人以上のユーザーを抱える企業にとって、一晩でコストが60%増加することは、予算計画を立てる上で非常に困難な事態です。Astraが特に優れているタスクをより深く理解した後は、利用方法を誘導することで、全体的なコストを大幅に削減することができました。

本ブログ記事では、Databricksのほとんどの従業員に新しいモデルへの「初日（Day 1）」アクセスを提供しつつ、それらのモデルが長期的に実用可能であるかを評価するために採用した一連の手法について説明します。これらの手法は、新しいモデルを適応的にリリース、評価、および組み込むために、 Unity Gatewayに大きく依存しています。9月21日の週は、Opus 5、GPT-6 Sol、GPT-Lunaが相次いでリリースされ、これらの機能の重要な試金石となりました。その週、Databricksはすべての従業員に初日アクセスを提供し、3日目までに、これらのモデルが効率性のフロンティアにあることを確認するのに十分なデータを収集し、より広範なインフラストラクチャへの組み込みを決定しました。

モデルリリースのライフサイクル

 概略として、Databricksにおける新しいモデルのリリースは、以下のようなパイプラインに沿って行われます。

1. 新しいモデルを「試験的（experimental）」なものとして、すぐにすべての従業員が利用できるようにします。
2. ユーザーごとの予算に基づいて、新しいモデルの使用を制限します。
3. 十分なデータを収集した後、モデルを本番環境に昇格させるか（あるいはデフォルトにするか）を決定します。

ステップ1：新しいモデルをすぐに利用可能にする

クローズドおよびオープンのモデルプロバイダー間でのモデル管理を容易にするため、社内でのすべての利用において自社の Databricks Unity Gatewayを活用しています。これはAIガバナンス、コスト管理、オブザーバビリティの中心的なハブであるため、ここから始めるのは自然なことです。

Gatewayは、すべての従業員が新しくリリースされたモデルにアクセスできるようにする場所です。しかし、サーバー側の設定だけでは不十分です。従業員はノートPCでClaude Code、Codex、および Omnigentメタハーネスを使用しており、新しいモデルの設定を彼らに配布する必要があります。

そこで登場するのが、 Unity Gateway CLI （UG CLI）です。UG CLIは、モバイルデバイス管理を介して展開され、すでに全員のノートPCで動作しています。誰かがClaude Code、Codex、またはOmnigentを起動すると、UG CLIが実行されて新しいモデル、ツール、スキルをチェックし、ローカルハーネスの設定を更新します。UGを使用することで、デフォルトモデルと試験的モデルを中央で指定したり、 スマートルーティング用にモデルを準備したり、各モデルのロールアウトを評価するためのトレースを収集したりできます。

私たちは、Opus 5.5とSol 6の試験的な設定をプッシュするようにUnity Gatewayを設定しました。これらのモデルにはこのタグが表示されるため、従業員はこれを選択できますが、それがクラス最高であるとは限らず、永続的に提供されるわけではない新しいモデルであることを理解できます。

Claude Codeのモデル出力では、Ous 5.5が「Experimental（試験的）」として明確に指定されています

ステップ2：ユーザーごとの予算を使用して使用を制限する

私たちは以前、AI支出に対するユーザーごとの予算設定方法について ブログ記事を執筆しました。それ以来、私たちは総予算アーキテクチャを拡張し、ユーザーごとに定義される4つの主要な予算を含めるようにしました：

1. 月間最大額：各ユーザーには、すべてのモデルにわたる月間の総支出上限が設定されています。
2. 日次暴走制限：すべてのユーザーに日次の最大額が設定されており、セッションの暴走による予期せぬ支出を防ぐために、Slack内で直接上限を引き上げることができます。
3. ［新機能！］クオリティフロンティア予算：月間予算の一定割合を、GPT AstraやClaude Fableなど、品質のフロンティアにある最もプレミアムなモデルに割り当てています。（Fableは現在、Anthropicのデータ保持ポリシーの関係で社内展開されていませんが、新しいポリシーを実装するために緊密に連携しています。）これは、これらのモデルを日常的に使用するのではなく、次の品質層と比較して2〜3倍のコスト増加を正当化できる、独自の適性を持つ専門的なタスクに限定して選択すべきであるという意図を反映しています。
4. ［新機能！］試験的予算：月間予算の別の割合は、テストされていない新しいモデルの使用に割り当てられます。ここでは、導入スピードと、効率性のフロンティアにないモデルを広く公開することによるダウンサイドリスクとのバランスを取ることを目指しています。

モデルリリースの初日に、私たちはUnity Gatewayを介してOpus 5.5とSol 6をすべての従業員に提供し、試験的予算のタグを付けました。その後、数日間かけてデータを収集し、試験的タグを外すか、開発者が目にするモデルカタログから削除するか、次のステップを決定しました。

4つの予算を反映した予算設定の概要

ステップ3：モデルを昇格させるか、除外するか

モデルが効率性のフロンティアにあるかどうかを判断するために、私たちは3つのシグナルを頼りにしています：

1. ベンチマークデータ：私たちは、文書推論、ワークスペース検索、自社製品のGenieなどのオフラインベンチマークや、2つのモデルを並行して実行してプルリクエスト作成の出力を比較するオンラインベンチマークなど、一連のタスクをテストする独自のベンチマークを用意しています。私たちはこれらのベンチマークの拡張と調整を続けています。理想的には、ベンチマークだけで、新しくリリースされたモデルのコストと品質を迅速に判断できるようになることです。
    
2. ユーザーから報告される品質： 試験的なモデルリリースにより、新しいモデルに対する人々の感想に関する豊富な事例データが得られます。パワーユーザーのグループは、新しいモデルを積極的に試して、Slackやアンケートの回答を通じてその体験を比較し合っていることがわかっています。
    
3. OpenTelemetryトレースによるコスト追跡：Unity Gatewayは、すべてのトレースをコスト情報とともに中央の場所に記録します。パイロットユーザーが前世代のモデルと最新のモデルにどのように費用を費やしたかを、セッションごとに比較できます。 これは必ずしも品質を示すものではありませんが、コストを把握するための優れた指標となります。

Opus 5.5とSol 6については、3つの指標すべてが非常に一貫した結果を示しています。

ベンチマーク（当社の OfficeQA Pro V2など）は、Opus 5.5がコストと品質のフロンティアに明確に位置しており、Opus 5から両方の軸で大きく進歩していることを示しています。GPT-6 Solのコストと品質のスコアは、GPT-5.6 SolとGPT-5.6 Terraのほぼ中間に位置しています。

ユーザーレポート では、エンジニアリングやデバッグのタスク（初期導入者の大半はエンジニアです）において、Opus 5.5はOpus 5やOpus 4.8から品質が大幅に向上しており、その記述スタイルが非常に好まれていることで概ね一致しています。一方で、GPT-6 SolはGPT-5.6 Solと比較して、時に品質が低下することがあります。

コスト追跡 により、初期導入者の利用状況を1週間前の同じグループの利用状況と比較することができました。初期導入者は平均的なユーザーよりもAIのパワーユーザーである傾向があるため、同じコホートを維持することが極めて重要であることがわかりました。

新しいモデルを試すユーザーは、実験的にセッション数を増やして利用することがあるため、コストをセッションあたりのドル（$/session）ベースに正規化したいと考えました。しかし、セッションの分布も変化していたため、単純な$/sessionの比較では依然として誤解を招く可能性があることがわかりました。初期導入者は、通常のセッションよりも新しいモデルでより困難な課題に挑戦していたのです。

その結果、セッションがシングルターンかマルチターンか、またファイルの編集を行ったかどうかに基づいてセッションを層別化し、それに応じて分布の重み付けを再調整しました。以下の表は、Opus 5.5対Opus 4.8、およびGPT-6 Sol対GPT-5.6 Solの結果を示しています。

価格が50%引き下げられたことを考えると、GPTの数値はそれほど驚くべきものではありません。しかし、Opus 5でのこれまでの経験を踏まえると、Opus 5.5が実際のワークロードにおいても大幅なコスト削減を実現していることは嬉しい驚きでした。

決定事項

モデルのリリース初日に、従業員にOpus 5、GPT-6 Sol、Lunaへの試験的なアクセスを提供することができました。3日以内に、これらのモデルが効率性のフロンティアに位置していることを確認するのに十分なデータを収集できたため、試験的な予算枠から外し、一般提供モデルとして標準的な利用に移行することを決定しました。

来週にかけて、Opus 5.5についてはさらに一歩進め、前世代よりも高品質かつ低コストであるという明確な位置付けを踏まえ、Claude Codeのデフォルトに設定する予定です。

GPT-6 Solでの経験から、CodexのデフォルトとしてGPT-5.6 Solに取って代わることはないと考えられます。ただし、5.6 Solに対するコスト面での優位性を考慮し、スマートルーターのツールキットにGPT-6 Solを組み込む予定です。

全体として、このプレイブックはモデルの品質とコストを迅速に評価する上で効果的であり、価値が証明された最新モデルを迅速に採用することが可能になりました。新しいモデルがほぼ毎日登場する現在、この柔軟性はかつてないほど重要になっています。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事