「どちらのプロンプトが良いか？」は単純な質問に聞こえます。実際には、AI出力の評価は応用AIにおいて最も困難な問題の一つです。人間の評価はコストが高く時間がかかります。BLEUやROUGEのような自動メトリクスはニュアンスを見逃します。そして単一ジャッジのLLM評価は、位置、冗長性、ジャッジモデル自体の選好によってバイアスがかかります。
私たちは、マルチジャッジスコアリング、ポジションランダム化、統計的信頼区間でこれらの問題に対処するbakeoffシステムを構築しました。この記事では、アーキテクチャ、統計、そして学んだ教訓をカバーします。
Bakeoffとは
Bakeoffは、同じ入力に対して評価される2つ以上のAI「アーム」——異なるプロンプト、モデル、recipe、またはworkflow——の構造化された比較です。AI出力のA/Bテストと考えてください。ただし、ユーザーのクリック率ではなく自動スコアリングを使用します。
JieGouは6つのbakeoffモードをサポートしています：
- プロンプト vs. プロンプト — 同じrecipe、異なるプロンプトテンプレート
- モデル vs. モデル — 同じrecipe、異なるLLMプロバイダー
- Recipe vs. recipe — 完全に異なるrecipe
- Workflow vs. workflow — 異なるマルチステップworkflow
- Workflowモデル vs. モデル — 同じworkflow、異なるモデル
- A/Bテスト — ユーザーフィードバック付きのライブ本番ルーティング
各bakeoffは最大8アーム、10入力、コストを合理的に保つために合計40セル（アーム×入力）の上限があります。
LLM-as-Judge評価
各セルは、リストワイズ比較アプローチを使用してLLMジャッジによって評価されます。各出力を独立してスコアリングする（相対的なコンテキストが失われる）のではなく、ジャッジはすべてのアームの出力を並べて見て、定義された基準に対してスコアリングします。
評価基準は重み付けされ、0から100でスコアリングされます。デフォルトのプリセットは以下を使用します：
| 基準 | 重み |
|---|---|
| 関連性 | 30% |
| 完全性 | 25% |
| 明確さ | 20% |
| 正確性 | 15% |
| フォーマット | 10% |
ユーザーはこれらの基準をカスタマイズしたり、独自の基準を作成したりできます。重みの合計は100%である必要があります。
ジャッジプロンプトは各アームの出力をランダム化されたラベル（A, B, C…）で提示し、構造化されたスコアを求めます。ジャッジが有効で解析可能なスコアを返すことを保証するために、Zodスキーマ付きのinvokeLLMStructured()を使用しています。
ポジションランダム化
LLM評価における既知のバイアスはポジション選好です——モデルは最初または最後に提示された出力を好む傾向があります。すべての評価呼び出しでアーム対ラベルのマッピングをランダム化します。アーム1は1回の実行では「C」とラベル付けされ、次の実行では「A」になるかもしれません。
これによりポジションバイアスが排除されるわけではありませんが、特定のアームを体系的に有利にするのではなく、ランダムにアーム間に分配されます。複数の入力にわたって、効果は平均化されます。
マルチジャッジコンセンサス
単一ジャッジの評価は本質的にノイズが多いです。異なるモデルは異なる選好を持ち、同じモデルでも同じ入力に対して異なるスコアを与えることがあります。同じ評価に対して2〜3の独立したジャッジを並列に実行し、それらの一致度を測定します。
Kendallのτは一致ペアと不一致ペアを数えることでランク相関を測定します。2人のジャッジが両方ともアームAをアームBより上にランク付けした場合、それは一致ペアです。意見が異なれば、不一致ペアです。係数は-1（完全な不一致）から1（完全な一致）の範囲です。
Spearmanのρは補完的な尺度を提供します：1 - (6 * ランク差の二乗和) / (n * (n^2 - 1))。
一致度は以下のように分類されます：
- 高 — Kendallのτ ≧ 0.7
- 中 — 0.4 ≦ τ < 0.7
- 低 — τ < 0.4
低い一致度はそれ自体が有用なシグナルです。通常、基準があいまいであるか、出力が類似しすぎて差別化できないか、タスクに明確な「より良い」答えがないことを意味します。
コンセンサスランキングはジャッジ間のスコアを平均し、各アームの集計された勝利数で計算されます。
統計的信頼性
各アームについて、平均スコアの周りに95%信頼区間を計算します：mean +/- 1.96 * stdDev / sqrt(n)、ここでnは入力の数です。
2つのアーム間で信頼区間が重なる場合、それをフラグします——差異は統計的に意味がない可能性があります。これにより、チームがノイズに基づいて意思決定することを防ぎます。3入力での2ポイントのスコア差はおそらくランダムです。CIが重ならない10入力での15ポイントの差は、行動する価値があります。
A/Bテスト統合
Bakeoffは「理論的にどちらが良いか」に答えます。A/Bテストは「本番環境でどちらがより良いパフォーマンスを発揮するか」に答えます。
A/Bテストがアクティブな場合、受信したworkflow実行は異なるアームにランダムにルーティングされます（50/50分割）。ユーザーは各出力にスター評価（1〜5）をフィードバックとして提供し、統計的有意性のためにカイ二乗検定を実行します。
テストは2つの条件が満たされたときに自動停止します：p値 < 0.05かつアームごとに少なくとも30のフィードバック応答。これにより、早すぎる結論と不必要に長いテストの両方を防ぎます。
ルーティングの決定は一貫性のために30秒のTTLでRedisにキャッシュされます——同じユーザーがキャッシュウィンドウ内でエンドポイントに繰り返しアクセスすると、同じアームが割り当てられます。
コスト管理
マルチジャッジ評価はジャッジの数（2〜3倍）で実行コストを乗算します。bakeoff開始前に、過去のトークン使用量の中央値をベースラインとして使用し、ジャッジの乗数を考慮した事前コスト見積もりを提供します。
40セルの上限（8アーム×10入力）と10基準の制限により、個々のbakeoffは制限されます。workflowアームについては、各ステップのモデルと期待される入出力サイズを考慮したマルチステップトークンプロジェクションを使用します。
学んだこと
**ポジションランダム化はオプションではなく必須です。**ランダム化なしの初期テストでは、品質に関係なく最初に提示された出力が評価の60〜65%で勝利しました。ランダム化によりこれが48〜52%になり、ノイズの範囲内です。
**2人のジャッジでほとんどの不一致を捕捉できます。**1人から2人のジャッジに増やすと信頼性が劇的に向上しました。2人から3人に増やすとさらに改善しましたが、収穫逓減でした。ほとんどのユースケースでは、Kendallのτレポート付きの2人のジャッジがスイートスポットです。
**信頼区間が行動を変えます。**CIレポートを追加する前は、チームは1〜2ポイントのスコア差のために最適化していました。今では重なる区間を見て、「有意な差はない」と正しく解釈します。これにより、ノイズを追いかけるために費やされるエンジニアリング時間が節約されます。
**構造化出力スキーマが評価を信頼性のあるものにします。**初期バージョンでは自由形式のジャッジレスポンスを使用し、正規表現でスコアを解析していました。これは常に壊れていました——モデルが説明を追加したり、異なる形式を使用したり、基準をスキップしたりしました。Zodバリデーション付きの構造化出力に切り替えることで、解析の失敗を完全に排除しました。