- 本番エンドポイントのトラフィックを制御群と最大20の変量群に分割可能
- 割合は固定で、レプリカ数に依存しないため測定中の偏りを防ぐ
- 実験の終了も削除のみで、クライアント側の変更は不要
何が発表されたか
Together AIは、本番エンドポイントでLLMのA/Bテストを実行できる機能を発表しました。エンドポイントのライブトラフィックを、1つの制御群と最大20の変量群に分割し、それぞれに任意の割合を設定できます。
これにより、候補モデルを実際のユーザーに対して低い割合、例えば5%から段階的に露出して品質を測定できます。シャドウトラフィックでは得られない「ユーザーが実際に反応した結果」を評価するのが目的です。
実験の作成はCLIで1回の呼び出しで行えます。クライアント側のエンドポイント名やAPIキーは変わらないため、ユーザーへの影響はありません。
自作アプローチとの違い
従来、この種の実験はアプリケーション層で行うのが一般的でした。フィーチャーフラグやユーザーIDのハッシュによる振り分け、2つのエンドポイントの切り替え、設定を管理するスプレッドシートなどが使われます。
ただし、この方法はルーティングロジックがアプリケーションに同梱されるため、後々の保守が難しくなります。コホートの分割がクライアントのキャッシュでずれることもあり、実験終了後も分岐コードが残り続ける問題があります。
Together AIの方式では、実験ロジックがエンドポイント層に付属し、クライアント側の変更を必要としません。削除すればトラフィックは100%制御群に戻るため、後始末も簡単です。
動作の仕組みと注意点
実験は、エンドポイントに接続し、制御群は1つ、変量群は1つ以上で構成されます。各群のパーセントは合計100になるように設定します。ルーティングは基本のトラフィック分割を解決した後、制御群に割り当てられたリクエストを実験のメンバー間で再サンプリングします。
重要なのは、変量群のデプロイメントはエンドポイントの基本トラフィック分割で重みゼロにしなければならないことです。実験がそのトラフィックを独占的に受け取ることで、測定値が静かに歪むのを防ぎます。さらに、A/Bテストの割合はレプリカ数と独立した固定値であり、オートスケールによって変動しない設計です。
更新はetagで保護されており、同時に誰かが変更を行った場合、自分の更新は拒否されます。伝播は30〜60秒程度で完了します。
ライフサイクル実験の実際
同社はライブエンドポイントで、95/5で作成し、80/20、50/50にランプし、最後に削除するまでの一連の実験を実施しました。3 RPSのトラフィックを流し、各リクエストをどのデプロイメントが処理したかを記録しています。
各ランプは1回の呼び出しで行われ、etagは1→2→3と進みました。更新後は約75秒待ってから計測しており、削除後は360連続リクエストがすべて制御群に届いたと報告されています。
この結果から、アプリケーション側の変更なしで、実験の作成から削除までを一貫して行えることが分かります。
| 項目 | シャドウトラフィック | 本番A/Bテスト |
|---|---|---|
| 評価できること | 遅延やエラーなどの運用面 | 継続率や評価などユーザーの実際の反応 |
| ユーザーへの影響 | レスポンスは破棄され影響しない | 一部ユーザーは候補モデルに接続 |
| 品質の判断 | できない | 本番データで可能 |
The platform deliberately doesn't guess at your quality metrics; it makes the attribution trivial so your analytics can do the judging.
プラットフォームは品質指標を独自に解釈することはせず、どのデプロイメントが応答したかの記録を簡単にする。そのため、品質の判断は自社の分析に委ねられる。
今後の見通し
今回の機能は、LLMの本番評価をアプリケーション層から分離する試みとして注目されます。今後は、この機能を利用してモデルを本番トラフィックで比較する事例が増えるとみられます。ただし、A/B実験の有効性は、どのような品質指標を設定するかに大きく依存します。また、Together AIプラットフォーム上でしか使えない機能のため、マルチクラウドやオンプレミス環境への適用可否が明らかになれば、選択肢の幅が判断できるようになるでしょう。
日本の開発者・IT企業にとっての意味
日本のIT企業にとって、LLMを組み込んだサービスの品質向上は重要な課題です。本番エンドポイントでのA/Bテスト機能により、自前で振り分けコードや管理ツールを実装する手間を省ける可能性があります。特に、既存のトラフィック分割やロールアウト機能と同じ基盤で実験できるため、運用負荷を抑えながらモデル改善を進められます。ただし、データを外部プラットフォームに送る点や、A/Bテストの設計が自社のサービス特性に合っているかを確認する必要があります。
気になる点
- A/Bテストの結果はどのように計測すればよいですか？
- プラットフォーム側では、遅延、エラー数、スループットなどがデプロイメント単位で取得できます。製品の品質指標（評価、リトライ、タスク完了など）は自社でログを取り、レスポンスメタデータに含まれるデプロイメントIDを結合キーにして分析します。
- 同じユーザーを常に同じテスト群に割り当てられますか？
- リクエストのサンプリングキー（例: prompt_cache_key や user フィールド）を使うと、同じキーのリクエストは同じ群にルーティングされます。キーがない場合、リクエストごとにランダムに割り当てられます。
- 既存のエンドポイントにも導入できますか？
- 制御デプロイメントがトラフィックを処理しているエンドポイントと、準備済みでトラフィック分割に含まれていない候補デプロイメントがあれば利用できます。実験の作成はCLIで可能です。
用語解説
- A/Bテスト
- 2つ以上の群にトラフィックを分け、どちらが良いかを比較する実験手法。
- シャドウトラフィック
- 本番トラフィックのコピーを候補モデルに送り、応答を破棄してテストする方法。
- ブルーグリーンロールアウト
- 2つの環境を切り替えるデプロイ手法で、片方に全トラフィックを移行する。
- etag
- リソースのバージョンを識別する識別子。同時更新を防ぐために使われる。
出典
A/B test models in production
AI導入も顧問も、お任せください
何から手をつけるか、どこまでAIに任せるか。自社の業務に合わせて整理し、導入から運用まで伴走します。相談だけでも構いません。
AI導入について相談する