モデル評価とA/Bテスト

なぜ科学的なモデル評価が必要か

多くのチームは、モデルをファインチューニングした後、手作業のテスト問題をいくつか解いただけで「効果がかなり良くなった」と感じ、意気揚々と本番環境にデプロイします。しかし、デプロイ後に、特定のシナリオでは改善したものの、他のシナリオでは逆に悪化していることが判明します。ユーザーの全体的な満足度は向上せず、モデルの動作の変化により、一部の既存ユーザーから苦情が寄せられることもあります。これは、科学的な評価システムの欠如による典型的な問題です。

科学的なモデル評価システムには、オフライン評価（デプロイ前に標準化されたテストセットで評価し、「モデルは管理された環境でどのように機能するか」に答える）とオンライン評価（デプロイ後にA/Bテストで実際のユーザーフィードバックを評価し、「モデルは実際のシナリオでどのように機能するか」に答える）の2つのレベルが含まれます。両方のレベルが不可欠です。オフライン評価が良好でもオンラインで良好とは限らず（分布シフトが存在）、オンラインでのパフォーマンスが良好でも、具体的にどこが良いのかがわからなければ継続的な最適化にはつながりません。

オフライン評価指標の設計

オフライン評価の核心は、高品質なテストセットを構築することです。テストセットは、トレーニングセットと完全に独立し（重複があってはならない）、すべての重要なビジネスシナリオをカバーし、各シナリオに十分なサンプル数（少なくとも50〜100件）があり、アノテーションの品質が高い（各データに標準回答または参照基準がある）必要があります。評価指標はタスクタイプに基づいて選択します。分類タスク（意図認識）→ Accuracy、F1、混同行列。生成タスク（対話、文章作成）→ BLEU/ROUGE（参考価値は限定的）→ LLM-as-Judgeスコアリングがより推奨されます。検索タスク→ Recall@k、MRR、NDCG。

import json, random, numpy as np
from scipy import stats
from openai import OpenAI

client = OpenAI(api_key="your-deepseek-api-key", base_url="https://api.deepseek.com")

class ModelEvaluator:
    def __init__(self):
        self.test_set = []
        self.results = {"baseline":[], "candidate":[]}

    def load_test_set(self, path):
        """テストセットを読み込む"""
        with open(path, 'r', encoding='utf-8') as f:
            self.test_set = json.load(f)
        print(f"{len(self.test_set)} 件のテストデータを読み込みました")

    def llm_judge(self, question, answer_a, answer_b, criteria):
        """LLM-as-Judge: DeepSeekに2つの回答の良し悪しを判定させる"""
        prompt = f"""あなたは公平な審査員です。以下の2つの回答を比較してください。

質問：{question}

回答A：{answer_a}

回答B：{answer_b}

評価基準：{criteria}

JSON形式で出力してください：
{{
  "winner": "A" | "B" | "tie",
  "score_a": 1-10,
  "score_b": 1-10,
  "reasoning": "簡単な説明"
}}"""
        response = client.chat.completions.create(
            model="deepseek-chat",
            messages=[{"role":"user","content":prompt}],
            temperature=0.1
        )
        return json.loads(response.choices[0].message.content)

    def evaluate_pairwise(self, baseline_model, candidate_model, num_samples=100):
        """ペアワイズ評価：ベースライン vs ファインチューニング"""
        samples = random.sample(self.test_set, min(num_samples, len(self.test_set)))
        wins_a = wins_b = ties = 0
        for i, item in enumerate(samples):
            answer_a = baseline_model(item["instruction"], item.get("input",""))
            answer_b = candidate_model(item["instruction"], item.get("input",""))
            judgment = self.llm_judge(
                item["instruction"], answer_a, answer_b,
                item.get("criteria", "正確性、完全性、流暢性")
            )
            if judgment["winner"] == "A": wins_a += 1
            elif judgment["winner"] == "B": wins_b += 1
            else: ties += 1
            if (i+1) % 20 == 0:
                print(f"進捗: {i+1}/{len(samples)}, A勝ち:{wins_a} B勝ち:{wins_b} 引き分け:{ties}")
        return {"A_wins":wins_a, "B_wins":wins_b, "ties":ties, "win_rate_B":wins_b/(wins_a+wins_b+ties)}

class ABTestDesigner:
    def __init__(self):
        self.control_group = []
        self.treatment_group = []

    def calculate_sample_size(self, baseline_rate, expected_lift, alpha=0.05, power=0.8):
        """必要なサンプルサイズを計算"""
        from scipy.stats import norm
        z_alpha = norm.ppf(1 - alpha/2)
        z_beta = norm.ppf(power)
        p1 = baseline_rate
        p2 = baseline_rate * (1 + expected_lift)
        p_pooled = (p1 + p2) / 2
        n = (z_alpha * np.sqrt(2*p_pooled*(1-p_pooled)) + z_beta * np.sqrt(p1*(1-p1)+p2*(1-p2)))**2 / (p2-p1)**2
        return int(np.ceil(n))

    def check_significance(self, control_data, treatment_data, metric_name="satisfaction"):
        """統計的有意性をチェック"""
        control = np.array(control_data)
        treatment = np.array(treatment_data)
        t_stat, p_value = stats.ttest_ind(treatment, control)
        effect = (treatment.mean() - control.mean()) / control.mean()
        ci = stats.t.interval(0.95, len(treatment)-1, loc=treatment.mean(), scale=stats.sem(treatment))
        return {
            "metric": metric_name,
            "control_mean": control.mean(),
            "treatment_mean": treatment.mean(),
            "relative_lift": f"{effect:.2%}",
            "p_value": p_value,
            "significant": p_value < 0.05,
            "ci_95": (ci[0], ci[1])
        }

    def run_ab_test(self, model_a, model_b, traffic_split=0.5, duration_days=7):
        """A/Bテストを実行"""
        print(f"A/Bテスト設計：")
        print(f"  対照群（A）：{model_a}")
        print(f"  実験群（B）：{model_b}")
        print(f"  トラフィック配分：{traffic_split*100:.0f}%/{100-traffic_split*100:.0f}%")
        print(f"  推奨実行期間：{duration_days} 日")
        n = self.calculate_sample_size(0.7, 0.05)
        print(f"  各グループの最小サンプル数：{n}")
        return {"status":"running", "expected_completion":f"{duration_days}日後"}

evaluator = ModelEvaluator()
evaluator.load_test_set("test_set.json")
# result = evaluator.evaluate_pairwise(baseline, finetuned, num_samples=100)

ab = ABTestDesigner()
n = ab.calculate_sample_size(baseline_rate=0.72, expected_lift=0.05)
print(f"5%の改善を検出するには各グループ {n} サンプルが必要です")
# significance = ab.check_significance(control_scores, treatment_scores)

A/Bテストのベストプラクティス

ランダムな振り分け：ユーザーIDのハッシュ値を使用してトラフィックを割り当てます（例：hash(user_id) % 100 < 50 → Aグループ）。これにより、2つのグループのユーザー特性の分布が一致することを保証します。サンプルサイズの計算：実験を開始する前に必要なサンプルサイズを計算します。期待される改善が3%〜5%の場合、統計的に有意な結論を得るには通常、各グループ5000〜10000サンプルが必要です。サンプルサイズが不十分なまま結論を出すことは、A/Bテストで最も一般的な間違いです。実験期間：少なくとも1つの完全なビジネスサイクル（通常1〜2週間）実行し、平日と週末の両方をカバーします。短すぎる実験は、「新奇効果」（ユーザーが新しいモデルに好奇心を持つ）や「曜日効果」（週末のユーザー行動が平日と異なる）の影響を受ける可能性があります。覗き見を避ける：実験の途中で頻繁に結果を確認し、早期に終了しないでください。これにより「覗き見バイアス」が発生し、偽陽性率が5%から20%以上に跳ね上がる可能性があります。実験期間を設定したら、期間終了後に結果を確認します。複数指標の総合判断：1つの指標だけを見ないでください。ファインチューニングしたモデルが満足度を3%向上させたが、レイテンシが50%増加した場合、このトレードオフを考慮する必要があります。「ガードレール指標」を設定することをお勧めします。コアビジネス指標（例：コンバージョン率、リテンション率）が大幅に低下した場合、満足度に関係なく実験を一時停止します。

評価から反復へ

評価の最終目的はモデルにスコアを付けることではなく、次の最適化の方向性を見つけることです。評価結果を分析することで、どのシナリオで顕著に改善したか（強化を継続）、どのシナリオで逆に悪化したか（トレーニングデータや戦略の調整が必要）、どのシナリオで変化がなかったか（データが不十分または方法が間違っている可能性）を特定します。評価の洞察を具体的な最適化タスクに変換し、「ファインチューニング→評価→分析→再ファインチューニング」の継続的改善ループを形成します。

A/Bテストのよくある落とし穴

A/Bテストは一見簡単そうに見えますが、実は落とし穴だらけです。前述の覗き見バイアスや新奇効果に加えて、サンプル汚染の問題があります。実験期間中に同じユーザーがAグループとBグループの両方に接触する可能性がある場合（例えば、異なるデバイスで）、実験結果は汚染されます。解決策は、安定したユーザー識別子（デバイスIDではなくアカウントIDなど）を使用して振り分けることです。時間効果の干渉：A/Bテスト中に外部イベント（競合他社の新製品リリース、業界のポリシー変更など）が発生した場合、実験グループと対照グループは同様に影響を受ける可能性がありますが、実験指標から除外することは困難です。解決策は、A/Aテストを対照グループとして使用することです。多重比較問題：10の指標を同時に観察する場合、実際の効果がなくても、1つの指標が「偶然」統計的に有意に達する可能性があります。解決策は、p値にBonferroni補正を適用するか、関心のある主要指標を事前登録することです。長期的な効果評価：ほとんどのA/Bテストは1〜2週間しか続かず、短期的な効果しか観察できません。しかし、多くのAI改善の効果はより長い時間をかけて現れます。例えば、パーソナライゼーション能力の向上は、モデルとユーザーの複数回のインタラクションを必要とします。重要なモデル変更には「ホールドアウトグループ」を設定することをお勧めします。これは、少数のユーザーが長期間にわたって旧バージョンのモデルを使用し続け、長期的な効果を評価するためのものです。同時に、「逆指標」のモニタリングを確立します。ファインチューニングしたモデルは短期的に特定の指標を改善するかもしれませんが、長期的にはユーザーの疲労や利用頻度の低下を引き起こす可能性があります。AI製品の成功は最終的にユーザーのリテンションと長期的な価値にかかっており、短期的な指標の最適化ではありません。

実験文化と管理

健全な実験文化を構築することは、実験技術を習得することよりも重要です。基本原則：実験の結論は意見ではなくデータによって駆動される（「このモデルの方が良いと思う」よりも「データは満足度が3.2%向上し、p=0.02であることを示している」の方が説得力があります）。失敗した実験も成功です（何が機能しないかを知ることは、何が機能するかを知ることと同じくらい価値があります）。大胆な仮説を奨励し、厳密な実験で検証します。実験ナレッジベースを構築し、各実験の仮説、設計、結果、教訓を記録して、同じ過ちを繰り返さないようにします。毎月実験レビューを実施し、先月の実験結果と教訓を共有し、チームの実験的知恵を徐々に蓄積します。