LLM の モニタリング（監視） & 評価基盤 は、LLM アプリを安定運用するうえで必須です。
しかし「何を測ればよいか？どう設計するか？」が分かりにくいので、ここでは 基本概念 → 監視すべき指標 → 評価方法 → 実装例 → 最低限の構成 を、プロダクション経験ベースでまとめます。
🧭 1. なぜ LLM のモニタリングが必要か
LLM アプリは従来のAPIと違い、確率的で、コストが高く、品質が揺れるため、以下が発生します：
品質劣化（アップデートで回答が変わる）
幻覚（hallucination）増加
レイテンシが不安定（ピーク時間、高負荷バッチ）
API コストの急増（ユーザ増加、不必要なリクエスト）
ユーザ行動による prompt の悪化
モデル変更による regressions（品質後退）
→ つまり「品質 × コスト × 安定性」を可視化して、
問題を自動で発見できる状態にすることが目的です。
🎯 2. モニタリングすべき指標（必須 + 追加）
🔥 必須（LLM の “健康状態”）
① レイテンシ
p50 / p90 / p95 / p99
prefill（入力処理）/ decode（生成処理）の分離計測
（vLLM などでは prefill がボトルネック）
② トークン使用量
入力トークン（prompt_tokens）
出力トークン（completion_tokens）
合計 tokens/request
→ コスト最適化に直結
③ コスト
cost_per_request
daily_cost
model別コスト
→ アラート設定（例：1日$20超えたら通知）
④ エラー率
API エラー
タイムアウト
リトライ状況
→ レイテンシ異常の早期発見に必要
🧠 品質指標（最重要）
⑤ ユーザ満足度（explicit / implicit）
👍👎 のフィードバック
返答内容の採用率 (“answer accepted”)
再質問率（re-ask rate）
⑥ LLM-as-a-judge による自動品質評価
モデル自身で評価する手法。
例：「この回答はユーザ質問に正確に答えているか？ 1〜5で採点せよ。」
評価軸例：
usefulness
correctness
harm / safety
hallucination score
style consistency
⑦ 目標タスク特化の自動評価（RAG/QA など）
RAG：groundedness（出典との整合性）
QA：exact match / F1
要約：faithfulness / conciseness
会議議事録：情報欠落率
🧩 RAG 特有の指標（RAG を使うなら必須）
Retrieval hit-rate（正しいドキュメントが取得されたか）
コサイン類似度分布
chunk 取得数の分布
recall@k
hallucination index（回答に出典が含まれる率）
🏗️ 3. 評価基盤の構成（4層）
[1] ログ収集層
LLM 呼び出しログ、tokens、latency、prompt、response
[2] データレイク層
Athena, BigQuery, S3, PostgreSQL など
[3] 評価層
・LLM-as-a-judge（自動評価）
・ユーザフィードバック分析
・品質テスト（regression test）
・RAG の retrieval 評価
[4] 可視化/アラート層
Grafana / Kibana / Metabase / Looker
🛠️ 4. 具体的なログフォーマット例（おすすめ）
{
“timestamp”: 1712345678,
“user_id”: “abc123”,
“model”: “gpt-4o-mini”,
“prompt”: “会議の議事録を要約してください”,
“response”: “要約：…”,
“prompt_tokens”: 243,
“completion_tokens”: 89,
“latency_ms”: 1130,
“error”: null,
“rating_user”: null,
“rating_llm”: {
“usefulness”: 4,
“correctness”: 5,
“groundedness”: 3
}
}
→ prompt / response は別ストレージに分離保存する（情報漏洩リスク対策）。
📊 5. 可視化ダッシュボードの例（Grafana）
最低限以下のメトリクスを表示：
◆ 時系列
cost/day
tokens/day
latency (p95)
error rate
user satisfaction
◆ ヒートマップ
RAG の類似度分布
ユーザ行動（どの prompt が最もコストを増やしているか）
◆ テーブル
リクエスト上位の prompt
コストの高いプロンプト
評価低スコアの回答
🔍 6. 自動評価（LLM-as-a-judge）の例
例：回答品質を自動採点
judge_prompt = f”””
以下のユーザ質問とAI回答の品質を評価してください。
[質問]
{question}
[AI回答]
{answer}
以下の項目を1〜5で採点し、JSONで返してください。
– correctness（正確性）
– helpfulness（有用性）
– logical_consistency（論理的一貫性）
– hallucination（幻覚の少なさ）※少ないほど高得点
“””
→ モデルに評価を返させる。
→ 毎日/毎週のモデルの品質変動を数値化できる。
🧪 7. 回帰テスト（Regression Test）
「モデル変更で品質が下がってないか？」を自動チェックする仕組み。
例）
代表質問セット（100〜300問）
様々な prompt パターン
正解または期待動作があるケース
評価方法：
EM（Exact Match）
similarity（回答文の埋め込み類似度）
LLM-as-a-judge スコア差分
🧰 8. 最低限これだけあれば OK（スターター構成）
✔ ① 呼び出しログ（DBに保存）
prompt_tokens, completion_tokens
latency
model
error
✔ ② 可視化（Metabase / Grafana）
日次トークン量、日次コスト
p95 latency
error 率
✔ ③ ユーザの thumbs up/down
回答の直接品質
✔ ④ 代表質問セット（回帰テスト）
モデル更新時の品質チェック
🌟 さらに進めると…
LLM Guardrails（安全性検査）
異常検知（急激なコスト増・hallucination spike）
prompt 最適化の自動探索（prompt tuning ops）
retriever の self-monitoring（RAG で重要）
