Continuous evaluation in production ─ tail-based sampling と judge drift
第1部 ch9 で「3 層 eval（outcome / trajectory / meta）」を扱った。本章では、それをproduction traffic に常時かける運用を扱う。
なぜ「production 上の eval」が必要か
開発時の eval（CI で goldens を回す）だけでは不十分な理由は 3 つ：
- ドリフト（ch3）：production の入力分布は CI の goldens と違う。日々変化する
- エッジケース：CI の goldens は典型ケースのみ。実 production は予想外のリクエストで埋まっている
- 判定基準の変化：ユーザーの期待、ビジネス要件、規制が時間経過で変わる
つまり「CI で eval が通った = production で品質が出る」は成立しない。
Continuous evaluation の枠組み
graph TB
P[Production Traffic]
Sample[Sampling]
Eval[Eval Pipeline]
Storage[(Eval Storage)]
Dash[Dashboard / Alert]
Feed[Feedback to dev]
P --> Sample
Sample --> Eval
Eval --> Storage
Storage --> Dash
Dash --> Feed
Feed -.改善.-> Pこのループを 毎日 / 1 時間ごとで回すのが Continuous evaluation だ。
軸 1：Sampling 戦略 ── tail-based が標準
production の全リクエストを eval にかけるとコストが破裂する。Sampling が必要だが、ランダムサンプリングは効率が悪い。
「tail-based sampling」が 2026 の標準パターン：
✅ Tail-based sampling
─────────
- happy path（成功・低コスト）：1〜5%
- error / 高コスト / 低 score：100%
- 異常検知 trigger：100%
- 新機能・新モデル：100%つまり「面白そうなところは全部、退屈なところは控えめに」。これでコストを抑えつつ、品質劣化の早期検知が可能になる。
軸 2：判定 ── LLM-as-judge と human の組み合わせ
LLM-as-judge は安価で速いが、信頼性に問題がある。
| 判定方式 | コスト | 速度 | 信頼性 |
|---|---|---|---|
| Human review | 高（$X / 件） | 遅（hours） | 高 |
| LLM-as-judge | 低（$0.01 / 件） | 速（s） | 中 |
| Programmatic check | ほぼ 0 | 即時 | 高（限定的） |
実本番では 3 つを併用する：
✅ Production eval の階層
─────────
Layer 1：Programmatic check（全件）
- 「答えに必須キーワード A が含まれているか」
- 「JSON が valid か」
- 「禁止語句がないか」
Layer 2：LLM-as-judge（5-10% sampling）
- faithfulness / answer relevancy / context precision（Ragas 系）
- 閾値：0.85-0.95
Layer 3：Human review（1-2% sampling、または異常時）
- LLM-as-judge と human の disagreement を月次で測定
- judge の信頼性が高い領域は human を減らす軸 3：Judge drift ── 評価器自身が drift する問題
LLM-as-judge は時間経過で drift する。同じ出力に対して、先月は 0.92、今月は 0.85、というように評価が動く。
原因：
- judge LLM のモデル更新（ch3 のモデルドリフト）
- judge prompt のドリフト（ch3 のプロンプトドリフト）
- 評価対象の分布変化（ch3 のデータドリフト）
対策：月次 calibration
✅ Judge calibration の運用
─────────
1. 月初に「calibration set」を作る
- 過去の human review 済みデータから 100 件抽出
- human の評価を ground truth とする
2. 現在の judge LLM で同じデータを評価
- human 評価との一致率を計算
- ≥ 90%：judge は健全
- 80-90%：judge prompt の見直し
- < 80%：判定方式の再設計
3. 月次でこれを繰り返すこれがないと、judge が壊れていることに気づかないまま production の品質が判定されるリスクがある。
軸 4：Capability-based canary
新バージョンの deploy では、全エージェントを一度に切り替えるのではなく、capability ごとにカナリア配布する。
graph TB
Old[Old Agent v1]
New[New Agent v2]
Cap1[Capability A<br/>tool: search]
Cap2[Capability B<br/>tool: send_email]
Cap3[Capability C<br/>tool: charge]
Old -.5%.-> Cap1
New -.95%.-> Cap1
Old -.50%.-> Cap2
New -.50%.-> Cap2
Old -.99%.-> Cap3
New -.1%.-> Cap3各 capability で異なるリスクなので、カナリア比率を独立に制御する。
✅ Capability-based canary の運用
─────────
- 低リスク capability（read 系）：新バージョンに 50% 以上で OK
- 中リスク（write 系）：5-20%
- 高リスク（不可逆操作）：0-1%
評価軸：
- 各 capability の TCR / DQR / TIE / CpT
- 古いバージョンと新バージョンの比較（A/B テスト）
- 異常検知の閾値（baseline -3% で deploy block）軸 5：Shadow deployment
「新バージョンを表に出さず、裏で並行実行して比較」する戦略。
graph LR
Req[User Request]
Old[Old Agent]
New[New Agent shadow]
Resp[Response to user]
Cmp[Comparison Storage]
Req --> Old --> Resp
Req -.shadow.-> New
Old --> Cmp
New --> Cmp特徴：
- ユーザーには Old の応答を返す
- New も並列実行し、結果を log
- 後で Old vs New を比較
- 副作用がある tool 呼び出しは New 側でモック化
用途：
- 新モデル（GPT-5 → 5.5）の挙動を本番データで検証
- プロンプト変更のリスク検証
- 高リスク capability で慎重に評価したいとき
注意点：
- コストが 2× になる（同じリクエストを 2 回処理）
- 副作用のモックが正確でないと評価が歪む
CI eval と Production eval の二層
第1部 ch9 で示した「3 層 eval」を、運用フェーズで CI と Production の二層に分離する。
graph TB
Dev[Dev: PR + CI]
Prod[Production: traffic + eval]
Dev -->|新バージョン| Canary[Canary deploy]
Canary --> Prod
Prod -.feedback.-> Dev
subgraph DevEval["CI eval"]
D1[Golden dataset]
D2[Unit eval]
D3[Regression test]
end
subgraph ProdEval["Production eval"]
P1[Tail-based sampling]
P2[LLM-as-judge]
P3[Programmatic check]
P4[Drift detection]
end
Dev --> DevEval
Prod --> ProdEval役割分担：
- CI eval：「変更前と変更後で品質が落ちていないか」を見る
- Production eval：「実トラフィックで品質が維持されているか」を見る
両方が必要。CI だけでは production の現実を映さず、Production だけでは変更時の早期検知ができない。
Online eval の主要ツール
第1部 ch9 でも触れたが、運用フェーズでの選び方を再整理。
| ツール | 強み | 用途 |
|---|---|---|
| LangSmith | LangChain/LangGraph 純正、trace → eval → デプロイ一気通貫 | LangGraph 中心の運用 |
| Langfuse | OSS、データ主権、API-first | self-host で運用したい |
| Arize Phoenix | OSS、ML-grade な eval、drift detection が成熟 | drift 重視の運用 |
| Braintrust | 開発者寄り、CI/CD ゲート、CI と production を統合 | CI/CD と continuous eval を統合 |
| Galileo | Luna-2 蒸留 evaluator、$0.02/1M tokens で常時 eval が経済的に成立 | 大量 production traffic |
A/B テストの運用
A/B テストを continuous eval と組み合わせる：
✅ A/B テストの設計
─────────
1. Baseline group：現バージョンに 80%
2. Treatment group：新バージョンに 20%
Eval：
- 各 group の TCR / DQR / TIE / CpT を測定
- 統計的有意性検定（chi-square / t-test）
- 7-14 日間のデータで判定
判定：
- Treatment が baseline 比 +3% 以上 → 段階的に拡大
- Treatment が baseline 比 -3% 以上 → 即時 rollback
- 中間 → 観測継続「動き続けながら壊れる」を捕捉する
ch2 で「動き続けながら壊れる（fail while continuing to work）」を中核概念に据えた。Continuous evaluation はこれを実装する仕組みだ。
- 古典 SRE：応答するか / しないか、を白黒で見る
- Continuous evaluation：応答の質を連続値で見る
これがないと、エージェントは「動いているのに間違っている」状態をalert なしで続ける。
❌ アンチパターン：「CI eval だけで production に出す」
症状
─────────
- CI eval は通っているのに、production でクレームが続出
- 本番のエッジケースで失敗するが、誰も気づかない
- judge LLM が drift して評価が当てにならなくなる
根本原因
─────────
- Production traffic 上の eval を組んでいない
- Tail-based sampling を理解していない
- Judge の calibration が無く、judge 自身が壊れていることに気づかない
- A/B テストとカナリアを使っていない
脱出法
─────────
1. CI eval + Production eval の二層に分離
2. Tail-based sampling を実装（happy 1-5%、error 100%、新機能 100%）
3. Judge を月次で calibrate（human review との一致率 ≥ 90%）
4. Capability-based canary + Shadow deployment
5. baseline -3% を deploy block 閾値に業務投入の観点で重要な 3 点
- CI と Production の二層 eval：Continuous evaluation は production 必須。CI だけは変更時の早期検知に閉じる
- Tail-based sampling と Judge calibration：「面白いところを 100%、退屈は控えめ」+ 月次で judge を再較正
- Capability-based canary：全エージェント一度に切り替えるのではなく、capability ごとにリスクに応じた比率で
次章への接続
ch9 では、ここまでで作った仕組みをインシデント対応の Runbookとして体系化する。「Agent が応答しない」「Agent が間違ったデータを出した」「Agent が暴走している」を 5 分で止められる手順、6 種のインシデント分類、on-call ローテーションを実装の解像度で扱う。
この章のまとめ
- CI eval だけでは不十分：Production traffic 上の continuous evaluation が必須
- Tail-based sampling：happy 1-5%、error / 異常時 / 新機能 100%
- Judge は月次 calibration：human review との一致率 ≥ 90% が健全ライン
- Capability-based canary：capability ごとにリスクに応じた canary 比率
- Shadow deployment：高リスク変更は新バージョンを並行実行し裏で比較
- A/B テストの判定：baseline ±3% を deploy block / promote の閾値に