LLM 評価 & 可観測性 完全ガイド: Eval Harness、LLM-as-Judge、Tracing、回帰防止 (2025)

Season 4 Ep 6 — Ep 1–5 は「どう作るか」。Ep 6 は「作ったものが本当に動いているか、どうやって知るか」。評価なき LLM プロダクトは目隠し運転の車である。

• Prologue — "LGTM 駆動開発" の終わり
• 1. 評価の 4 層
  • 1.1 Layer 0 — 構造 / スモークテスト
  • 1.2 Layer 1 — Golden Dataset 正解比較
  • 1.3 Layer 2 — 品質判定
  • 1.4 Layer 3 — 本番指標
• 2. Eval Dataset の作り方
  • 2.1 ソースの多様化
  • 2.2 規模
  • 2.3 ラベリング
  • 2.4 分割
• 3. LLM-as-Judge — 祝福と呪い
  • 3.1 基本アイデア
  • 3.2 メリット
  • 3.3 致命的な落とし穴
  • 3.4 補正テクニック
  • 3.5 人手評価との併走
• 4. 可観測性 3 層 — Trace / Span / Metric
  • 4.1 用語
  • 4.2 OpenTelemetry が事実上の標準
  • 4.3 LLM 専用属性
  • 4.4 集計指標
• 5. ベンダー比較
  • 5.1 LangSmith
  • 5.2 LangFuse
  • 5.3 Arize Phoenix
  • 5.4 Helicone
  • 5.5 Weights & Biases Weave
  • 5.6 選択ガイド
• 6. RAG 評価
  • 6.1 分離測定
  • 6.2 RAGAS などのフレームワーク
  • 6.3 Golden Q&A セット
• 7. エージェント評価
  • 7.1 メトリクス
  • 7.2 Trajectory 評価
  • 7.3 Replay ベース評価
• 8. CI/CD への評価組み込み
  • 8.1 PR 段階
  • 8.2 メインマージ後
  • 8.3 週 1 回の大規模
  • 8.4 Shadow & A/B
  • 8.5 Canary
• 9. 安全・バイアス・ハルシネーション測定
  • 9.1 Safety ベンチ
  • 9.2 Bias
  • 9.3 Hallucination
  • 9.4 Refusal の適正性
• 10. インシデント対応プレイブック
  • 10.1 SEV 定義
  • 10.2 対応順序
  • 10.3 チェックポイント
• 11. ユーザーフィードバックループ
  • 11.1 収集
  • 11.2 活用
  • 11.3 プライバシー
• 12. 日本語・現地環境の可観測性
  • 12.1 言語別指標の分離
  • 12.2 評価リソース
  • 12.3 規制・監査
  • 12.4 On-prem 可観測性
• 13. アンチパターン 10 選
  • 13.1 「数字が良さそう」で意思決定
  • 13.2 LLM-judge 単一モデルのみ使用
  • 13.3 Eval セットと訓練セットの混入
  • 13.4 PR に回帰テストなし
  • 13.5 PII をそのまま保存
  • 13.6 コストだけ見て品質を見ない
  • 13.7 Trace なし
  • 13.8 ユーザーフィードバック未収集
  • 13.9 "Test" Eval セットをチューニングに露出
  • 13.10 インシデント再発防止なし
• 14. チェックリスト — ローンチ前 12 項目
• 15. 次回予告 — Season 4 Ep 7: "ローカル LLM 時代"

Prologue — "LGTM 駆動開発" の終わり

2023 年までの LLM プロダクトの多くは "Looks Good To Me" 駆動開発だった。プロンプトを直し、数回動かし、「お、良くなった気がする」と言ってマージ。回帰しても「原因不明」で終わる。

2025 年はもう通用しない。理由は 3 つ:

1. プロダクト規模: 月数億コール、1 回の回帰で数万ユーザーに影響。
2. チーム規模: 複数エンジニアが同じプロンプト・モデルを触る → 責任が分散。
3. 競争: 1 ヶ月の停滞で競合に抜かれる → 高速反復が必須、それを可能にするのは評価基盤のみ。

つまり LLM プロダクトにおける評価は、ML モデル評価ではなくソフトウェアエンジニアリングのテスト自動化レベルで日常化しなければならない。

1. 評価の 4 層

1.1 Layer 0 — 構造 / スモークテスト

• 応答が有効な JSON か
• 必要フィールドが揃っているか
• 長さ・フォーマット制約を守っているか
• API が 200 で返っているか

基本中の基本。CI で毎 PR に実行。

1.2 Layer 1 — Golden Dataset 正解比較

• 答えが明確なタスク(分類、抽出): Accuracy/F1
• 自然言語生成: BLEU/ROUGE/METEOR (参考程度)
• 主に ユニットテスト 感覚

1.3 Layer 2 — 品質判定

• 人手評価または LLM-as-judge
• 「この応答は正確か / 有用か / 安全か」など主観軸
• 統計的有意性の検証が必要

1.4 Layer 3 — 本番指標

• 👍 / 👎、再質問率、会話離脱率
• タスク成功率(転換・解決)
• 遅延・コスト・エラー率などの運用指標

Layer が上がるほど シグナルは強いが、頻度・コスト・速度では不利。適切に組み合わせる。

2. Eval Dataset の作り方

2.1 ソースの多様化

• 本番ログサンプリング: 実分布を反映
• 過去インシデント再現: 「これが二度と起きないように」
• 難易度別合成: LLM で Easy/Medium/Hard を生成
• エッジケース専用: 安全性・バイアステスト

2.2 規模

• スタート: 100〜300 件で十分
• 安定運用: 1,000〜3,000 件
• 回帰防止スモーク: 10〜30 件を超高速で

2.3 ラベリング

• 単一正解なら簡単
• 複数正解が許される場合は rubric を明確化:
  • 「〜を含めば正解」「〜を含めば誤り」
• ラベラー間一致(Kappa)0.7 以上を目標

2.4 分割

• Train(プロンプトチューニング / Few-shot / Fine-tune 用)
• Dev(開発中の反復評価)
• Test(最終判断用。学習・チューニングに 絶対公開禁止)

3. LLM-as-Judge — 祝福と呪い

3.1 基本アイデア

大規模モデル(GPT-4o、Claude 3.5/4 など)に「この応答は正しいか?」を尋ねて自動評価する。

System: あなたは公正な評価者です。
User:   [質問] [応答]
        この応答は質問に正しく答えていますか? yes/no と理由を一行で。

3.2 メリット

• 人より数百倍速く安い
• 一貫した基準を適用できる
• 主観的判断も代わりに担当してくれる

3.3 致命的な落とし穴

1. Position bias: 「どちらが良いか?」で A/B 位置を入れ替えるだけで結果が反転
2. Length bias: 長い応答を良いと判定
3. Self-preference: GPT 生成を GPT がより良く評価(モデル間バイアス)
4. Rubric 揺れ: 同じ基準説明でも再実行ごとにスコア分散
5. Easy-to-game: 評価プロンプトが分かれば「判定を騙す」応答を学習

3.4 補正テクニック

• Position swap: A/B 順序を入れ替え 2 回評価 → 一致時のみ有効
• Multiple judges: 異なる 3 モデルで評価 → 多数決
• Pairwise > Scalar: 「何点?」より「A vs B どちらが良い?」が安定
• Chain-of-Thought: 判定前に理由を書かせる
• Rubric anchoring: 10 の代表例を「明確に良い / 悪い」で固定
• Calibration set: 人ラベル 200 件で judge の精度測定 → 補正係数適用

3.5 人手評価との併走

• 全体の 10〜20% は常に 人手で検査
• LLM-judge スコアと人スコアの相関を月次トラッキング
• 相関が 0.7 以下に落ちたら judge プロンプト・モデルを改修

4. 可観測性 3 層 — Trace / Span / Metric

4.1 用語

• Trace: 一回のユーザーリクエストの実行全体
• Span: Trace の単位(LLM 呼び出し、ツール呼び出し、DB クエリ等)
• Metric: 時系列集計(QPS、p95 遅延、日次コスト)

4.2 OpenTelemetry が事実上の標準

2025 年時点、LLM 可観測性も OpenTelemetry スキーマ(OpenLLMetry、OpenInference 等)に収束しつつある。どのベンダーでも OTEL SDK で計装しておけば移行・併用が容易。

4.3 LLM 専用属性

一般 trace に加えて記録:

• gen_ai.system: openai / anthropic / google / ...
• gen_ai.request.model, gen_ai.response.model
• gen_ai.usage.input_tokens, output_tokens, cache_read, cache_write
• gen_ai.temperature, top_p
• gen_ai.prompt(任意、PII マスク後): プロンプトサンプル
• gen_ai.response.content(任意): 応答サンプル
• コスト: USD 単位で自動計算

4.4 集計指標

• p50/p95/p99 遅延(first_token / total)
• QPS、エラー率、リトライ率
• 日次コスト、ユーザー当たりコスト、機能当たりコスト
• 品質: Eval セットスコアの日次推移

5. ベンダー比較

5.1 LangSmith

• LangChain 公式。ホステッド SaaS。
• Trace + 評価セット + フィードバック + プロンプトハブを統合。
• LangGraph / LangChain ユーザーは第一候補。

5.2 LangFuse

• オープンソース(セルフホスト可)、SaaS もあり。
• OpenTelemetry / OpenAI SDK 自動計装。
• プロンプトバージョニング、Eval 対応。
• エンタープライズのセルフホスト需要に強い。

5.3 Arize Phoenix

• オープンソース。Arize 本番プラットフォームと連携。
• 埋め込み・Drift・RAG 検索品質の可視化が特に強い。
• ローカルですぐ動く UI。

5.4 Helicone

• ゲートウェイ型(プロキシ)。SDK 挿入の代わりに URL を変えるだけ。
• コスト・遅延削減(キャッシュ、ルーティング)が標準装備。
• 低遅延観測が中心。

5.5 Weights & Biases Weave

• W&B の LLM 専用モジュール。
• 実験・評価・本番トラッキングを一元化。

5.6 選択ガイド

6. RAG 評価

6.1 分離測定

• Retrieval: 正しい文書を見つけたか(Hit@k、MRR、NDCG)
• Generation: 見つけた文書を活用したか(Faithfulness、Answer Relevancy)
• Context Quality: 不要文書が混ざっていないか(Context Precision/Recall)

Retrieval 失敗か Generation 失敗かを区別できないとチューニングは難しい。

6.2 RAGAS などのフレームワーク

• Faithfulness: 回答が文書に裏付けられているか
• Answer Relevancy: 回答が質問に実際に答えているか
• Context Precision: 取得文書中の実根拠の割合
• Context Recall: 必要な文書をどれだけ取得したか

OSS の RAGAS、DeepEval がこれらを自動算出。

6.3 Golden Q&A セット

• 質問、正解文書 ID、期待回答または含むべきキーワード
• これが無ければ RAG チューニングは推測。

7. エージェント評価

7.1 メトリクス

• Task success rate: 最終結果が正解か
• Step efficiency: 何ステップか(少ないほど良いが少な過ぎもダメ)
• Tool selection accuracy: 正しいツールを選んだか
• Cost / Latency 分布: p50/p95
• Safety: 禁止動作の試行・成功回数

7.2 Trajectory 評価

最終結果だけでなく 経路(trajectory) 自体が意味を持つ。

• 同一結果でも「不要ツール呼び出し 5 回」と「綺麗な 2 回」では運用コストが 3 倍差。

7.3 Replay ベース評価

• LangGraph / LangSmith のチェックポイントで過去実行を再生。
• 新モデル・プロンプトを同じ trajectory でシミュレーション → 回帰確認。

8. CI/CD への評価組み込み

8.1 PR 段階

• Layer 0(スモーク)20 件 — 2 分以内
• Layer 1(Golden Dataset)100 件 — 10 分以内
• 閾値未達で自動失敗

8.2 メインマージ後

• Layer 2(品質判定、LLM-judge)500 件 — 30 分
• 結果を Slack / Discord のチーム channel へ

8.3 週 1 回の大規模

• Layer 3(本番指標)週次レポート
• 前月比の品質・コスト・遅延変化

8.4 Shadow & A/B

• 新モデル・プロンプトを シャドウ で並行呼び出し、応答記録(ユーザーには従来応答)
• 一定期間の収集後に比較 → A/B で昇格

8.5 Canary

• トラフィック 1〜5% → 指標安定化 → 50% → 100%
• 自動ロールバック(p95 遅延 2 倍 or 品質 -5pp)

9. 安全・バイアス・ハルシネーション測定

9.1 Safety ベンチ

• RealToxicityPrompts、ToxiGen(英語)
• 韓国語・日本語は公開ベンチが不足 → 社内カスタムセット必須
• Jailbreak / プロンプトインジェクション自動テスト(Garak、PyRIT)

9.2 Bias

• 性別、年齢、地域、職業などの軸で「同じ質問に異なる回答」実験
• 各国固有軸(学歴、兵役、出身地等)も考慮

9.3 Hallucination

• 事実照合ベンチ(FEVER 等)
• RAG 環境では Faithfulness がハルシネーション指標のプロキシ

9.4 Refusal の適正性

• 正当な要求を過剰拒否していないか
• False refusal 率をモニタリング

10. インシデント対応プレイブック

10.1 SEV 定義

• SEV1: 多数ユーザーに影響、誤/危険な回答(即時)
• SEV2: 品質回帰 10% 以上(6 時間以内)
• SEV3: コスト / 遅延回帰、少数影響(週次処理)

10.2 対応順序

1. 遮断: 問題モデル / プロンプト / バージョンへのルーティング一時 OFF
2. 切り分け: どの構成が問題か特定(ログ・Trace から)
3. 緩和: 直前安定版へロールバック
4. ルート分析: Eval セット・ログ結合で原因究明
5. 再発防止: 当該失敗例を Eval セットに恒久追加
6. ポストモーテム: 24〜72 時間以内に内部公開

10.3 チェックポイント

• 全デプロイが即ロールバック可能か
• トラフィックゲーティングを秒単位で調整可能か
• 権限保有者(オンコール)が明確か

11. ユーザーフィードバックループ

11.1 収集

• 👍 / 👎 + 任意理由(チェックボックス + 自由記述)
• インライン(応答横)ボタンがダッシュボードより参加率が高い
• タスク完了直後が最適タイミング

11.2 活用

• 👎 ケース → Eval セット候補として検討
• 👍 ケース → DPO / Preference データ化
• 反復的に同一不満 → プロンプト・RAG チューニングトリガー

11.3 プライバシー

• 入出力保存同意、削除 API、保有期間ポリシー
• ユーザー識別子ハッシュ化、機微ドメインマスキング
• 各国法(個人情報保護法、仮名化)遵守

12. 日本語・現地環境の可観測性

12.1 言語別指標の分離

• 同一プロダクトでも日本語応答品質と英語品質は異なる
• ダッシュボードで言語別フィルタ必須

12.2 評価リソース

• 英語: MMLU、HELM
• 韓国語: KMMLU、HAE-RAE、LogicKor、KoBench、Ko-MT-Bench
• 日本語: JGLUE、JMMLU、Rakuda、Nejumi LLM リーダーボード
• 内部ベンチが最終判断基準

12.3 規制・監査

• 金融、医療では監査ログを 5〜10 年保持
• 外部 API 呼び出しの時刻・内容・応答をイミュータブルストレージに保存

12.4 On-prem 可観測性

• LangFuse、Phoenix、OpenTelemetry Collector を自社ホスト
• 外部送信遮断、内部監査のみ

13. アンチパターン 10 選

13.1 「数字が良さそう」で意思決定

統計的有意性(サンプル数、分散)未確認で判定。

13.2 LLM-judge 単一モデルのみ使用

Self-preference バイアス。多重 judge + 人手サンプル併用。

13.3 Eval セットと訓練セットの混入

Leakage。ハッシュベースで重複チェック。

13.4 PR に回帰テストなし

回帰が main に入ってから発覚。CI に Layer 0/1 は必須。

13.5 PII をそのまま保存

規制違反 + インシデント時の二次被害。

13.6 コストだけ見て品質を見ない

「安くなったが満足度低下」を見逃す。

13.7 Trace なし

エージェント失敗原因不明。デバッグ不可。

13.8 ユーザーフィードバック未収集

最も貴重なシグナルを無料で捨てる。

13.9 "Test" Eval セットをチューニングに露出

結果が膨らむ。次四半期に失望。

13.10 インシデント再発防止なし

同一失敗を 3 度起こすチームは評価体系が無い。

14. チェックリスト — ローンチ前 12 項目

• 評価 Layer 0/1/2/3 定義と各実行周期
• Eval セット 300 件以上、Train/Dev/Test 分離
• LLM-judge 使用時は position swap + 人手検査
• OpenTelemetry ベース Trace/Span/Metric 計装
• コスト・遅延ダッシュボード p50/p95/p99
• ユーザーフィードバック(👍 / 👎)収集 + 理由オプション
• インシデント対応プレイブック + オンコール指定
• Canary + 自動ロールバック方針
• 安全 / バイアス / ハルシネーション月次実行
• プライバシー方針(ログ保持、削除 API)
• 回帰テスト CI 実行 + 失敗時アラート
• 四半期 1 回の大規模人手評価(定性評価込み)

15. 次回予告 — Season 4 Ep 7: "ローカル LLM 時代"

2025 年は「ローカル LLM が実用圏に入った年」でもある。

• モデル: Llama 3.1/3.3、Qwen2.5/3、Mistral、Gemma 3、Phi
• エンジン: vLLM、TGI、SGLang、llama.cpp、Ollama、LMDeploy
• ハードウェア: RTX 4090/5090、H100、Apple Silicon(M3/M4 Ultra)
• 量子化: INT4/INT8、AWQ、GPTQ、SmoothQuant、EXL2
• 実用: 社内ナレッジボット、コードアシスタント、文書処理
• Privacy-first プロダクト: 個人情報を外部に出さない
• コスト・電力計算
• 日本語ローカルモデル選定
• 実戦ベンチマーク(tokens/sec、遅延、品質)

「外部 API にすべてを頼る時代」の終わり。 ローカル LLM が成立する条件と成立しない条件を明確に引く。

次回でお会いしましょう。

要約: 評価と可観測性は LLM プロダクトの 基盤インフラ。Layer 0〜3 に分けて頻度・コストを合わせ、LLM-as-judge は position swap・多重 judge・人手検査で補正し、OpenTelemetry ベースの Trace/Span/Metric を初日から仕込む。RAG・エージェント・Fine-tune はそれぞれ別の評価が必要で、インシデント対応プレイブックとユーザーフィードバックループが製品改善のエンジン。「測定なき AI はハンドル無き車」。