オフライン評価では、テストデータ上でどのAI設定がより良く見えるかが分かります。A/Bテストでは、実際のユーザーと実際の入力を使って、本番環境でどちらがより良いパフォーマンスを発揮するかが分かります。JieGouのbakeoffシステムは両方をサポートしており、このガイドではライブA/Bテストの側面をカバーします。
A/Bテストを行うタイミング（オフライン評価との比較）
オフラインbakeoff（固定された入力セットで出力を比較する方法）は以下に適しています：
- ローンチ前の初期モデル選定
- 開発中のプロンプト反復
- 根本的に異なるアプローチの比較
ライブA/Bテストは以下の場合に適しています：
- 2つの有力な候補にすでに絞り込んでいる場合
- 本番入力がテストセットと重要な点で異なる場合
- 長期間にわたる実際のパフォーマンスを測定したい場合
- ステークホルダーの承認にテスト結果ではなく本番データが必要な場合
A/Bテストのセットアップ
JieGouでのステップバイステップのプロセスは以下の通りです：
ステップ1：A/Bルーティングでbakeoffを作成する
bakeoffセクションに移動し、モードとして「A/B Test Routing」を選択します。比較したい2つのバリアントを選びます——2つのrecipe、2つのモデル設定、または2つのworkflowです。
ステップ2：トラフィック分割を設定する
デフォルトでは、トラフィックはバリアント間で50/50に分割されます。保守的にしたい場合は調整できます——例えば、データ収集をしながら実験的バリアントへの露出を制限するために90/10にすることも可能です。
ステップ3：自動停止条件を設定する
JieGouはカイ二乗統計検定を使用して、一方のバリアントが他方よりも統計的に有意に優れているかを判定します。以下を設定できます：
- 最小サンプルサイズ — 各バリアントで少なくともN回の実行が完了するまで勝者を宣言しない
- 有意水準の閾値 — 勝者を宣言するためのp値の閾値（デフォルト：0.05）
自動停止条件が満たされると、JieGouは自動的にトラフィックの100%を勝利バリアントにルーティングし、通知します。
ステップ4：結果をモニタリングする
テスト実行中、bakeoffダッシュボードには以下が表示されます：
- バリアントごとの実行回数
- 経時的なLLMジャッジスコア
- 現在の統計的有意性
- 現在のトラフィックに基づく有意性到達の推定時間
ステップ5：レビューと確定
テストが終了したら（自動停止または手動判断のいずれか）、完全な結果をレビューします：スコア分布、信頼区間、コスト比較、実行時間の差異。その後、勝利バリアントをデフォルトに昇格させます。
一貫性の保証
A/Bルーティングの決定はRedisにキャッシュされます。特定の実行コンテキストがバリアントに割り当てられると、テスト期間中はそのバリアントに固定されます。これにより、同じrecipeが連続実行で異なる結果を生成するような混乱する動作を防ぎます。
測定すべき指標
LLMジャッジスコアが主要なメトリクスですが、以下の追加シグナルも考慮してください：
- 実行コスト — 品質がわずかに低くてもコストが60%削減されるバリアントが、本番環境ではより良い選択かもしれません
- 実行時間 — 品質が同等でも、より高速なレスポンスはユーザーエクスペリエンスを向上させます
- エラー率 — 成功時のスコアが高くても、5%の確率で失敗するバリアントは、失敗しないバリアントより劣ります
実践的なヒント
- 少なくとも48時間テストを実行して、時間帯や曜日による入力パターンの変動を捕捉してください
- 一度に多くのことをA/Bテストしない — モデルとプロンプトを同時に変更すると、差異の帰属が不可能になります
- テスト開始前に仮説を文書化する — 「Claudeバリアントはニュアンスで高スコアになるが、コストは2倍になると予想する」のような記述は、結果が実用的かどうかの評価に役立ちます
- まずオフラインbakeoffを使用して候補を絞り込み、その後トップ2の候補を本番でA/Bテストしてください
提供状況
A/Bテストルーティングはenterpriseプランでご利用いただけます。オフラインbakeoff（recipe対recipe、モデル対モデル）はProプランでご利用いただけます。すべてのbakeoffモードについて詳しく見る。