カスタム評価パイプライン（カスタムヒョウカパイプライン）

カスタム評価パイプラインとは

カスタム評価パイプラインは、汎用ベンチマーク（MMLU・HumanEval等）では測定できない業務固有のLLM性能を定量評価するために構築する独自の評価システムである。

汎用ベンチマークはモデルの一般的な能力を横断比較するのに有用だが、実際のプロダクション環境では「法律文書から特定条項を正確に抽出できるか」「顧客の問い合わせに適切なトーンで回答できるか」「社内用語を正しく使用できるか」といったドメイン固有の要件が重要になる。カスタム評価パイプラインはこれらの要件を定量化し、モデル選定・ファインチューニング・プロンプトエンジニアリングの効果を客観的に測定する。

パイプライン設計の5ステップ

ステップ1: 評価目的の定義

ステップ2: 評価データセットの構築

高品質な評価データセットの構築は、カスタム評価パイプラインの最も重要かつ工数がかかるステップである。

データ収集方法:

• 本番ログからのサンプリング: 実際のユーザー入力から代表的なケースを抽出
• エッジケース設計: 専門家が意図的に難しいケースを作成（境界値・例外・曖昧な入力）
• 合成データ: LLM で大量のテストケースを生成し、人手でフィルタリング
• A/Bテストデータ: 2つのモデル/プロンプトの出力ペアを収集

データセットサイズの目安:

ステップ3: メトリクス設計

自動メトリクス（コスト低・スケーラブル）:

• Exact Match (EM): 正解と完全一致
• F1 スコア: トークンレベルの精度・再現率の調和平均
• BLEU/ROUGE: 生成テキストと参照テキストの n-gram 重複
• 正規表現マッチ: 出力フォーマットの適合率
• JSON Schema Validation: 構造化出力の妥当性検証

LLM-as-Judge メトリクス（人手の代替・中コスト）:

• ポイントワイズ評価: 1-5段階のスコアリング
• ペアワイズ比較: 2つの出力のどちらが優れているかを判定
• ルーブリック評価: 複数の評価観点に対する個別採点

ステップ4: LLM-as-Judge の構築

LLM-as-Judge は、人間の評価者の代わりに別の LLM が出力品質を採点する手法である。

# LLM-as-Judge の実装例
JUDGE_PROMPT = """以下の回答を1-5の5段階で評価してください。


## 評価基準
- 5: 完璧。正確で包括的、適切なトーン
- 4: 良好。軽微な改善余地あり
- 3: 許容範囲。重要な情報の欠落や不正確さあり
- 2: 不十分。大幅な改善が必要
- 1: 不可。誤情報または有害な内容を含む


## 質問
{question}


## 回答
{answer}


## 参照回答（あれば）
{reference}

JSON形式で出力: {{"score": <1-5>, "reasoning": "<評価理由>"}}"""

LLM-as-Judge の既知のバイアス

ステップ5: パイプラインの自動化

# GitHub Actions でのカスタム評価パイプライン
name: LLM Evaluation Pipeline
on:
  pull_request:
    paths: ['prompts/**', 'config/**']
  schedule:
    - cron: '0 6 * * 1'  # 毎週月曜6時

jobs:
  evaluate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run custom evaluation
        run: |
          python evaluate.py \
            --dataset eval_data/production_sample.jsonl \
            --model gpt-4o \
            --judge-model claude-3-5-sonnet \
            --metrics accuracy,tone,format \
            --output results/
      - name: Check regression
        run: |
          python check_threshold.py \
            --results results/scores.json \
            --min-accuracy 0.92 \
            --min-tone 4.0
      - name: Post results to PR
        if: github.event_name == 'pull_request'
        run: python post_results_to_pr.py

A/Bテストとオンライン評価

オフライン評価 vs オンライン評価

A/Bテストの設計

1. 仮説設定: 「プロンプトV2はV1より顧客満足度が5%向上する」
2. サンプルサイズ決定: 効果量・有意水準・検出力から必要サンプル数を算出
3. トラフィック分割: 通常5-10%のトラフィックを新バージョンに割り当て
4. メトリクス収集: 自動メトリクス + ユーザーフィードバック（thumbs up/down）
5. 統計的判定: p値 < 0.05 かつ実務的に有意な効果量であれば採用

回帰テストとモニタリング

回帰テストの設計原則

• ゴールデンセット: モデル更新時に必ず通過すべき重要ケースのセット（50-100件）
• スナップショットテスト: 期待出力を保存し、大幅な変更を検知（変更率閾値: 10%）
• カナリアテスト: 本番トラフィックの1%で新モデルを実行し、メトリクス劣化を監視

プロダクションモニタリング

# リアルタイム品質モニタリングの指標例
MONITORING_METRICS = {
    "latency_p95": {"threshold": 3000, "unit": "ms"},
    "error_rate": {"threshold": 0.01, "unit": "ratio"},
    "refusal_rate": {"threshold": 0.05, "unit": "ratio"},
    "avg_output_length": {"threshold_range": [100, 2000], "unit": "tokens"},
    "judge_score_rolling_avg": {"threshold": 3.5, "unit": "1-5 scale"},
    "user_thumbs_up_rate": {"threshold": 0.7, "unit": "ratio"},
}

よくある質問（FAQ）

Q1: カスタム評価パイプラインの構築にどの程度の工数がかかるか？

最小構成で1-2週間、本格的なパイプラインで1-2ヶ月が目安である。内訳は、データセット構築（40%）、メトリクス設計・Judge構築（30%）、CI/CD統合・自動化（20%）、ドキュメント化（10%）。最も時間がかかるのはデータセット構築で、特にドメイン専門家によるアノテーションが必要な場合は工数が増大する。まずは50-100件のゴールデンセットで最小構成を立ち上げ、段階的に拡充するアプローチを推奨する。

Q2: LLM-as-Judge の信頼性はどの程度か？

GPT-4o を Judge として使用した場合、人間の評価者間一致率（Inter-Annotator Agreement）と同等の相関（Cohen's κ ≈ 0.7-0.8）を達成する。ただし、前述のバイアスが存在するため、重要な意思決定（モデルの本番切り替え等）では必ず人間による最終検証を行うべきである。Judge プロンプトの設計品質がスコアの信頼性に直結するため、プロンプトのA/Bテストと校正データによるJudge自体の評価も重要である。

Q3: 評価データセットはどのくらいの頻度で更新すべきか？

最低でも四半期に1回の見直しを推奨する。ユーザーの入力パターンは時間とともに変化し、固定データセットでは新しいパターンやエッジケースを捕捉できなくなる。本番ログから定期的にサンプリングし、失敗ケース（低評価・クレーム）を重点的に追加することで、評価データセットの鮮度と網羅性を維持する。また、モデルの学習カットオフ以降の情報を含むケースを意図的に追加し、知識の新しさも評価対象に含めるべきである。