Databricks Certified Generative AI Engineer Associate 教科書
第5章 評価とモニタリング(Evaluation and Monitoring, 12%)
🎯 この節の学習目標
第4章でアプリを Model Serving エンドポイントとしてデプロイしました。しかし本番運用が始まると、開発時の評価だけでは見えなかった問題が発生します。
これらに対応するための第一歩が、本番のリクエストとレスポンスを記録することです。記録がなければ、分析も評価も改善もできません。
推論テーブルは、Model Serving エンドポイントに届いたリクエストと返したレスポンスを、自動的に Unity Catalog 管理下の Delta テーブルへ記録する機能です。現在はエンドポイントのガバナンス層である Unity AI Gateway(旧 Mosaic AI Gateway)のペイロードロギング(payload logging)として位置付けられており、レート制限や使用状況トラッキング(5-7)と同じくゲートウェイの設定として有効化します。有効化するだけで、アプリ側のコード変更なしにログが蓄積されます。
Delta テーブルとして残ることが重要です。つまりSQL や Spark でそのまま分析できるということであり、Databricks のレイクハウス上で他のデータと同じ道具立てで扱えます。
| 用途 | 内容 |
|---|---|
| 本番品質の事後分析 | 実際の質問と回答を調べ、失敗パターン(答えられなかった質問、不適切応答)を特定する |
| 評価データセットの種 | 実ユーザーの質問から評価ケースを作る(5-2・5-4のデータセットは本番ログから育てるのが理想) |
| ドリフト検知 | 質問の傾向・応答の特性が時間とともに変化していないかを監視する |
| 監査 | 「いつ・誰が・何を聞き・何と答えたか」の記録をコンプライアンス対応に使う |
📝 試験のポイント
「本番エンドポイントのリクエストと応答を記録して後から分析したい。どうするか?」→ 推論テーブル(Inference Tables)を有効化する。これは本章で最も出題されやすい一問一答です。「自前でログ収集アプリを別途開発する」「クライアント側で全ログを保存させる」といった選択肢は、組み込み機能で足りるため誤答になります。
品質(何を答えたか)とは別に、サービスとしての健全性を示す運用メトリクスを監視します。Model Serving はエンドポイントごとにこれらのメトリクスを提供します。
| メトリクス | 意味 | 異常時に疑うこと |
|---|---|---|
| レイテンシ | リクエストから応答までの時間 | モデルの過負荷、コンテキスト長の肥大、下流サービスの遅延 |
| QPS(スループット) | 単位時間あたりのリクエスト数 | 急増ならスパイク(スケール設定の見直し)、急減ならクライアント側障害 |
| エラー率 | 4xx/5xx応答の割合 | 入力形式の不整合、レート制限超過、依存サービス障害 |
| スケーリング状況 | プロビジョニングされた計算資源の利用状況 | 容量不足(レイテンシ悪化)、過剰プロビジョニング(コスト浪費、4-7) |
運用メトリクスは「サービスが動いているか」を、品質メトリクスは「良い答えを返しているか」を見ます。両方が揃って初めて本番監視です。レイテンシが正常でも品質が劣化していることはあり得ますし、その逆もあります。
推論テーブルは「記録」までを担います。その上で品質を継続的に測る仕組みを重ねます。
推論ログは Delta テーブルなので、Lakehouse Monitoring でテーブル上の統計・品質メトリクスを定期計算できます。応答の長さやトピックの分布などの変化(ドリフト)を時系列で追い、ダッシュボードで可視化し、しきい値超過でアラートを出す、という監視を、テーブル監視の標準機能として構成できます。
開発時に使った評価(5-2)を本番にも適用するパターンです。推論テーブルに蓄積された実際のリクエスト/レスポンスに対して、定期的に(あるいはサンプリングして)LLMジャッジを実行し、関連性・安全性などのスコアを記録し続けます。
# 概念イメージ:推論テーブルの直近ログをジャッジで採点する定期ジョブ
recent_logs = spark.read.table("prod.app.inference_log") \
.filter("date >= current_date() - 1")
results = mlflow.genai.evaluate(
data=to_eval_records(recent_logs), # 質問・応答・コンテキストに整形
scorers=[RelevanceToQuery(), Safety()], # 期待回答不要のスコアラーを使う
)
本番トラフィックには期待回答が存在しないため、リファレンス不要のジャッジ(relevance、groundedness、safety、guidelines)を使うのがポイントです(5-1・5-2の知識との接続)。品質スコアの時系列が下がり始めたら、データやユーザー行動の変化を調査するトリガーになります。
MLflow 3 では、この流れをさらに一歩進められます。開発時に使った MLflow Tracing(5-6)を本番エンドポイントでも有効化すると、リクエスト/レスポンスだけでなく実行の内部(どのツールが呼ばれ、何が検索されたか)まで含む本番トレースが MLflow に収集されます。収集した本番トレースには、開発時と同じスコアラー(組み込みジャッジ・5-3のカスタムスコアラー)をそのまま継続適用でき、「本番トレースの収集 → スコアラーによるオンライン評価 → 低スコア事例の分析」までを MLflow 3 の統合フレームワークの上で一貫して構成できます。ペイロードロギング(何を答えたかの記録)と Tracing(どう動いたかの記録)は補完関係にあり、併用が基本です。
💼 例:社内QAボットの本番監視構成
✅ この節のまとめ
問1. 本番運用中のRAGチャットボットについて、「実際のユーザーのリクエストとモデルの応答を記録し、後からSQLで分析できるようにしたい」。最も適切な方法はどれか。
正解:B
推論テーブルは、エンドポイントのリクエスト/レスポンスをアプリ改修なしで自動的に Delta テーブルへ記録する組み込み機能で、SQL/Sparkでそのまま分析できます。Aは自前実装の手間と漏れのリスクがあり、組み込み機能がある以上不適切です。Cは開発時評価の記録であり本番トラフィックの記録ではありません。Dは運用メトリクスで、リクエスト/レスポンスの内容は記録されません。
問2. 推論テーブルの用途として適切でないものはどれか。
正解:D
推論テーブルは本番稼働後のリクエスト/レスポンスを記録する仕組みなので、デプロイ前の事前保証には使えません(デプロイ前の品質確認は5-2の開発時評価の役割です)。A・B・Cはいずれも推論テーブルの代表的な用途です。特にBの「本番ログを評価データセットに還元する」流れは継続的改善の要点として覚えておきましょう。
問3. エンドポイントの運用モニタリングで「レイテンシとエラー率は正常だが、ユーザーから『最近回答の質が落ちた』という声が増えている」。この状況の説明と対応として最も適切なのはどれか。
正解:B
レイテンシ・エラー率は「サービスが動いているか」を示す運用メトリクスであり、「良い答えを返しているか」という品質は別軸です。品質は推論ログに対してLLMジャッジを回すオンライン評価で測ります。AとCは運用メトリクスと品質メトリクスを混同しています。Dのレイテンシと回答品質に直接の因果はありません。
問4. 本番の実応答に対して定期的にLLMジャッジを実行するオンライン評価を設計する。開発時評価との違いとして最も重要な考慮点はどれか。
正解:A
本番の実リクエストには ground truth(期待回答)が存在しないため、リファレンスなしで動くジャッジ(relevance、groundedness、safety、guidelines)を使うのが設計の要点です。Bの correctness は期待回答が必要なので本番トラフィックにはそのまま適用できません。Cはコストの観点からサンプリング評価が一般的で「必ず全件」は誤り。Dはスコアを時系列で保存してこそ劣化検知ができるため誤りです。