ストーリー
田
田中VPoE
ログ収集の基盤ができた。次は「何を測るか」だ。CS部門から「AIの回答品質が落ちている」という報告があるが、客観的に測定できていない
あなた
「品質が落ちている」というのは感覚的なものですよね。数値で測る方法があるんですか?
あ
田
田中VPoE
ある。LLMの応答品質を自動的に評価するメトリクスがいくつか確立されている。人間の評価に頼らず、大量のリクエストに対して品質を計測し続ける仕組みを作ろう
LLM品質メトリクスの体系
メトリクスの分類
LLM品質メトリクス:
定量メトリクス(自動計測)
├── パフォーマンス系
│ ├── レイテンシ(P50/P95/P99)
│ ├── TTFT(Time To First Token)
│ ├── トークンスループット(tokens/sec)
│ └── エラー率
├── 品質系
│ ├── Faithfulness(忠実性)
│ ├── Relevance(関連性)
│ ├── Coherence(一貫性)
│ └── Toxicity(有害性)
└── ビジネス系
├── ユーザー満足度(thumbs up/down)
├── エスカレーション率
└── タスク完了率
定性メトリクス(人間評価)
├── ドメイン正確性
├── トーン・スタイルの適切さ
└── ユーザーインタビュー
主要品質メトリクス
1. Faithfulness(忠実性)
RAGシステムにおいて、応答が検索されたコンテキストに忠実かどうかを測定します。
| 項目 | 内容 |
|---|
| 定義 | 応答の各主張がコンテキスト(RAG検索結果)によって裏付けられているか |
| スコア | 0.0(完全に非忠実)〜 1.0(完全に忠実) |
| 閾値 | 0.85以上を合格ラインとする |
| 計測方法 | LLM-as-a-Judge(別のLLMに評価させる) |
Faithfulness の評価フロー:
1. 応答から主張(Claims)を抽出
応答: 「当社の返品期限は30日間です。送料は無料です。」
→ 主張1: 返品期限は30日間
→ 主張2: 送料は無料
2. 各主張をコンテキストと照合
コンテキスト: 「返品期限は購入日から30日以内です」
→ 主張1: 裏付けあり(Supported)
→ 主張2: 裏付けなし(Not Supported)
3. スコア計算
Faithfulness = Supported / Total = 1/2 = 0.50
2. Relevance(関連性)
応答がユーザーの質問に適切に回答しているかを測定します。
| 項目 | 内容 |
|---|
| 定義 | 応答がユーザーの質問の意図に対して関連性が高いか |
| スコア | 0.0〜1.0 |
| 閾値 | 0.80以上を合格ラインとする |
| 計測方法 | LLM-as-a-Judge |
3. ユーザー満足度
| 収集方法 | 実装 | 分析 |
|---|
| Thumbs up/down | 応答の末尾にフィードバックボタン | 満足率 = up / (up + down) |
| 5段階評価 | 対話終了後にレーティング | 平均スコアとトレンド |
| 自由記述 | 不満足時にコメント入力欄 | テキスト分析でカテゴリ分類 |
4. エスカレーション率
| 定義 | AIが回答できず人間オペレーターにエスカレーションされた割合 |
|---|
| 計算 | エスカレーション数 / 全リクエスト数 |
| 目標値 | CS-AI: 20%以下(現在測定していない) |
| 分析方法 | エスカレーション理由の分類(知識不足/品質不足/ユーザー要求) |
LLM-as-a-Judgeの実装
評価用プロンプトの設計
# Faithfulness 評価プロンプト
evaluation_prompt:
system: |
あなたはAI応答の品質を評価する専門家です。
与えられたコンテキスト(参照情報)と応答を比較し、
応答の忠実性を0.0〜1.0で評価してください。
評価基準:
- 応答のすべての主張がコンテキストに裏付けられている: 1.0
- ほとんどの主張が裏付けられている: 0.7-0.9
- 半分程度が裏付けられている: 0.4-0.6
- ほとんど裏付けがない: 0.1-0.3
- コンテキストと矛盾する内容がある: 0.0
user: |
## コンテキスト
{context}
## ユーザーの質問
{question}
## AIの応答
{answer}
## 評価
以下のJSON形式で回答してください:
{"score": 0.0-1.0, "reasoning": "評価理由"}
評価の自動化
| 項目 | 設計 |
|---|
| 評価頻度 | リクエストの10%をサンプリングして評価(コスト考慮) |
| 評価モデル | GPT-4o-mini(コスト効率。評価タスクに十分な品質) |
| バッチ処理 | 非同期で1時間ごとにバッチ評価 |
| 結果保存 | Langfuseのスコア機能で紐づけ |
| アラート | Faithfulnessが0.80を下回ったらSlack通知 |
メトリクスダッシュボード
主要KPI
| KPI | 計算方法 | 目標値 | アラート閾値 |
|---|
| 平均Faithfulness | 直近24時間の平均スコア | > 0.85 | < 0.80 |
| 平均Relevance | 直近24時間の平均スコア | > 0.80 | < 0.75 |
| ユーザー満足率 | thumbs up / (up + down) | > 80% | < 70% |
| エスカレーション率 | エスカレーション / 全リクエスト | < 20% | > 30% |
| P95レイテンシ | 直近1時間のP95 | < 5秒 | > 8秒 |
| エラー率 | エラー / 全リクエスト | < 1% | > 3% |
まとめ
| ポイント | 内容 |
|---|
| メトリクス体系 | パフォーマンス系、品質系、ビジネス系の3分類 |
| Faithfulness | RAG応答がコンテキストに忠実かを自動評価する最重要メトリクス |
| LLM-as-a-Judge | LLMに品質評価を行わせる手法。サンプリング+バッチで効率化 |
| ダッシュボード | 主要KPIを常時モニタリングし、閾値違反でアラート |
チェックリスト
推定読了時間: 30分