LLM Eval vs A/Bテストは「分岐」ではなく「漏斗」であるべき理由

はじめに：なぜ今、LLM Evalと実験の関係を見直すべきか

AIプロダクトを開発していると、こんなジレンマに直面することがあります。「LLM JudgeがバリアントAの方が良いと言ったけど、実際のユーザー反応はどうだろう？」「A/Bテストを回す時間がもったいないから、Evalだけ信じてデプロイしてもいいだろうか？」

Spotifyのデータサイエンスチームが公開した興味深い統計があります。Spotifyで実施されたA/Bテストのうち、実際にリリースまで至ったポジティブな結果は約12% に過ぎませんでした。しかし、残りの88%が無意味だったわけではありません。約64%のテストは「回帰の発見」「アイデアの棄却」「仮説の洗練」といった 価値ある学び を生み出していました。

つまり、実験の勝率（win rate）は実験の真の価値を過小評価させるのです。そして今、LLM Evalという新しいツールが登場したことで、私たちは「Eval vs 実験」という二分法から脱却し、「Eval → 実験」へと続く漏斗（Funnel）構造 を理解する必要があります。

本記事は、Spotify Engineering Blogに掲載された "Better Experiments with LLM Evals — A funnel, not a fork" を基に、国内のAIプロダクト開発環境に合わせて再解釈しました。

根拠資料

Evalができること、できないこと

SchultzbergとOttens（2024）はこの問題を Verification（検証） と Validation（確認） という2つの概念で明確に区別しています。

Evalが本当にやっていること

Evalは実験帯域幅を無駄にしないために、可能性の低い候補を事前にふるい落とすフィルターの役割を果たします。例えば、チームが信頼を損なうコンテンツを検出するLLM Judgeを作ったと仮定しましょう。

# 例：LLM Judgeを活用した信頼違反コンテンツのフィルタリング
import openai

def trust_violation_judge(response_text: str) -> dict:
    """
    LLM Judgeが応答テキストの信頼違反の有無を評価します。
    戻り値: {"score": 0~1, "reason": "..."}
    """
    prompt = f"""
    次の応答がユーザーに不適切なレコメンデーションを含んでいるか、
    信頼を損なう可能性があるかを評価してください。
    スコアは0（安全）〜1（危険）で出力してください。
    
    応答: "{response_text}"
    
    スコアと理由をJSONで出力してください。
    """
    
    result = openai.chat.completions.create(
        model="gpt-4o",
        messages=[{"role": "user", "content": prompt}],
        response_format={"type": "json_object"}
    )
    
    return eval(result.choices[0].message.content)

# 使用例
sample_response = "この映画はあなたにぴったりです！（実際には暴力的なシーンが多いです）"
scores = trust_violation_judge(sample_response)
print(scores)  # {'score': 0.85, 'reason': 'ユーザーの嗜好と無関係な推薦、潜在的な信頼損失'}

このJudgeは、チームが気づいていなかったパターンを表面化します。例えば「特定のジャンルの映画が嫌いなユーザーに、そのジャンルを強く推すパターン」などです。これらのパターンはプロダクト改善につながります。そして改善がデプロイされた後、同じJudgeで改善効果を確認できます。違反事例が減ったかどうかを確認すればよいのです。

Evalが絶対にできないこと

しかし、Evalは次のような質問に答えることはできません。

• 「改善版を受け取ったユーザーが実際に良い体験をしたか？」
• 「信頼損失が最終的にチャーン（離脱）につながるのを防げたか？」

これらの質問には、必ず 実験（Experiment） が必要です。

もう一つ重要なポイント：あなたが測定していない次元が常に存在する ということです。Spotifyの場合、リリースされた実験の約42%が セッション長の減少、クラッシュ率の増加、リテンションの低下 といったセカンダリ指標（ガードレールメトリクス）での回帰を発見してロールバックされています。どのオフラインEvalもこの問題を捉えられませんでした。

2つのキャリブレーションレイヤー、1つのフィードバックループ

Evalは本質的に プロキシ（代理指標） です。スコアで実際に望む結果を代替しているのです。この代替は、スコアが実際の結果をうまく追跡している場合にのみ有効です。ここにLLM Judgeが従来の定量的指標（ランキングスコア、適合率、再現率）の上に 第2のキャリブレーションレイヤー を追加します。

両方のレイヤーはオンライン結果に対する検証が必要です。そして両方とも ドリフト する可能性があります。

例えば、AnthropicがOpus 4.5モデルをリリースしたとき、QodoのコーディングEvalでは全く改善が見られませんでした。しかし実際には より長いタスク（longer tasks） でモデルが大幅に改善されており、これは統制された実験でのみ発見できました。逆方向の誤キャリブレーションもあり得ます。

オフライン-オンラインキャリブレーションループ

# 例：Evalスコアと実験結果を比較してキャリブレーション係数を計算
import numpy as np
from sklearn.metrics import mean_squared_error

def calibration_error(eval_scores: list, experiment_effects: list) -> float:
    """
    Evalスコアと実験効果量の間の平均二乗誤差を計算します。
    値が小さいほどEvalが実験結果を良く予測していることを意味します。
    """
    # eval_scores: LLM Judgeが各バリアントに付与したスコア（0〜1）
    # experiment_effects: 実際の実験で測定された効果量（例：リテンション変化率）
    return np.sqrt(mean_squared_error(eval_scores, experiment_effects))

# サンプルデータ
eval_scores = [0.9, 0.7, 0.6]  # JudgeがバリアントA,B,Cに付けたスコア
experiment_effects = [0.03, 0.02, -0.01]  # 実際のリテンション変化

error = calibration_error(eval_scores, experiment_effects)
print(f"キャリブレーション誤差: {error:.3f}")  # 0.05未満なら良好

このループを継続的に運用することで、Evalは徐々に洗練された検証ツールへと進化します。将来的にはAIの発展に伴い、Evalが検証（Verification）を超えて確認（Validation）に近づく可能性もあります。しかし、その時までも オフライン/オンラインキャリブレーションループ は、Evalがどの程度信頼できるかを透明に示す装置として残り続けるでしょう。

スピードプレッシャーへの警告

「A/Bテストはコストがかかりすぎる」という言葉をよく耳にします。しかし、実験なしでデプロイして主要なビジネス指標で大きな回帰を見逃すコスト の方がはるかに大きいのです。システムが複雑になればなるほど、リスクを制限（bound the risk）することが重要になります。

関連記事: React、ついに独立 – React Foundation設立とエコシステムの変化を完全解説

実務適用：ループを閉じよ（Close the Loop）

1. Evalを早期に頻繁に実行して最適な処置（treatment）を見つけてください。
2. 実験を通じて実際のユーザーとシステムが予測通りに反応するか確認し、最適化していない指標もモニタリングしてください。
   • クイック方向性テスト（quick directional test）は反復とデータ収集用
   • リリース決定（rigorous test）は厳格な実験用
3. A/Bテストデータ自体にLLM Evalを再度適用してください。Judgeが好んだバージョンが実際にユーザーにとって良いパフォーマンスを発揮したか確認します。
4. Evalスコアと実験結果の差が大きい場合、それが診断の黄金（Gold）です。 各サイクルが次のキャリブレーションに役立ちます。

国内AIエコシステムにおける適用コンテキスト

国内のスタートアップやSI環境では、A/Bテストインフラが不足しているケースが少なくありません。そのような場合、Evalを先に強化する戦略が効果的です。例えば：

• カスタマーサポートチャットボットの応答品質をLLM Judgeで日次評価し、下位10%のケースを手動レビュー
• Judgeが発見したパターンを基にプロンプトエンジニアリングを改善
• 改善後、同じJudgeで再評価 → スコア向上を確認 → その後にA/Bテスト導入

本技術の限界および注意点

• Evalは決して実験を代替できません。 Evalは検証（Verification）ツールであり、確認（Validation）ツールではありません。
• LLM Judge自体のバイアス を常に念頭に置く必要があります。Judgeが特定のスタイルの応答を過大評価したり、文化的コンテキストを見落としたりする可能性があります。
• 長期的なユーザー行動 はEvalで捉えるのが困難です。例えば「この機能が3ヶ月後のリテンションにどのような影響を与えるか？」はEvalが答えられない質問です。

次のステップ学習方向

1. Evalパイプライン構築の実践: Daggr公開コードで書き、目で確認するAIワークフロービルダー を参考に、実際のEvalワークフローをコードで実装してみてください。
2. ガードレールメトリクスの設計: Spotifyの事例のように、最適化対象ではないがモニタリングすべき指標を定義してみてください。
3. オフライン-オンラインキャリブレーションループの構築: 小規模なプロジェクトから、Evalスコアと実際のKPIを比較するダッシュボードを作成してみてください。

核心はこれです：Evalを実験の代替ではなく、実験の成功率を高める前処理段階として活用せよ。 ループを閉じるとき、あなたのAIシステムはますます賢くなっていきます。