Databricks Certified Generative AI Engineer Associate 教科書
第5章 評価とモニタリング(Evaluation and Monitoring, 12%)
🎯 この節の学習目標
LLMの利用コストは、基本的に処理したトークン量に比例します。課金対象は入力トークン(プロンプト全体)と出力トークン(生成された応答)の合計です。ここで見落とされがちなのが入力側の内訳です。
つまり、設計(top-k、チャンクサイズ、履歴の保持量)の小さな変更がコストに直結します。しかも従量課金は使った分だけ青天井なので、可視化していないと「月末に請求を見て驚く」「特定機能の暴走で予算を使い切る」といった事態が起きます。測定できないものは管理できない——品質と同じことがコストにも当てはまります。
Databricks では、エンドポイントの利用量を組み込み機能で追跡できます。
Model Serving エンドポイントの Unity AI Gateway には使用状況トラッキング(usage tracking)があり、有効化するとリクエストごとの利用状況(トークン数を含む)が記録され、システムテーブル経由で集計できるようになります。5-5のペイロードロギング(推論テーブル)と並ぶ、Unity AI Gateway の運用機能の1つです。ゲートウェイを経由する限り、Databricksがホストする基盤モデル・外部モデル(external models)・エージェントのエンドポイントを横断して、利用状況を一元的に可視化できる点が重要です。プロバイダーごとにバラバラの管理画面を見る必要がなく、組織全体の生成AI利用を1か所で把握できます。
記録された利用状況はシステムテーブル(system カタログ配下の serving 関連テーブル)に蓄積され、通常のテーブルとしてSQLで集計できます。エンドポイント別・時間帯別・利用者別のトークン消費を、ダッシュボードやアドホック分析でそのまま扱えるのが利点です。
-- 概念イメージ:エンドポイント別に日次のトークン消費を集計する
SELECT
served_entity_name,
DATE(request_time) AS d,
SUM(input_token_count) AS input_tokens,
SUM(output_token_count) AS output_tokens
FROM system.serving.endpoint_usage
GROUP BY served_entity_name, DATE(request_time)
ORDER BY d DESC;
「どの部門・どの機能がコストを使っているか」まで掘るには、リクエスト内容が残る推論テーブル(5-5)が役立ちます。リクエスト単位のトークン数・呼び出し元の情報を分析すれば、「サポートボットの要約機能だけが全体の半分のトークンを消費している」といった内訳が見えます。
📝 試験のポイント
「部門別・ユーザー別にLLMの利用コストを把握したい」→ Unity AI Gateway の使用状況トラッキングを有効化し、システムテーブルをSQLで集計する。この対応付けが本節の最重要ポイントです。「各アプリに手作業でカウンターを実装する」といった選択肢は、組み込み機能があるため誤答になります。
可視化の次は、異常を早く見つけ、被害を限定する仕組みです。
💼 例:コスト暴走の検知から対処まで
状況:ある朝、日次トークン消費のアラートが発火。前日比8倍の消費。
「可視化(気づく)→ 分析(特定する)→ 制限(被害を限定する)」の3点セットで運用します。
モニタリングで「どこが高いか」が分かったら、削減レバーを引きます。本教科書で学んだ手段を、コストの観点から一覧に整理します(4-7の内容との対応)。
| レバー | 効き方 | 注意点 |
|---|---|---|
| モデルサイズの見直し | タスクに足りる範囲で小型モデルに切り替え、トークン単価そのものを下げる | 品質を評価(5-2)で確認してから切り替える |
| プロンプト長の削減 | システムプロンプトの冗長部分削減、会話履歴の要約・打ち切りで入力トークンを減らす | 必要な指示・文脈まで削ると品質が落ちる |
| キャッシュ | 同一・類似リクエストの応答を再利用し、LLM呼び出し自体を減らす | 鮮度が重要な回答には不向き |
| top-k の適正化 | RAGで挿入するチャンク数を減らし、毎回の入力トークンを削減 | 減らしすぎると Recall が低下(5-4のトレードオフ) |
| max_tokens の設定 | 出力トークンの上限を設け、過剰に長い生成を防ぐ | 低すぎると回答が途中で切れる |
| scale-to-zero | アイドル時にサービング資源をゼロにスケールし、待機コストを削減(4-7) | コールドスタートで初回レイテンシが増える |
どのレバーにもトレードオフがあるため、コストの変化と品質の変化(5-2の評価)をセットで確認しながら調整するのが正しい進め方です。
本章の締めくくりとして、モニタリングの3つの軸を整理します。
| 軸 | 問い | 主な手段 |
|---|---|---|
| 品質 | 良い答えを返しているか | LLMジャッジ・カスタムスコアラー(5-1〜5-4)、オンライン評価(5-5)、トレース(5-6) |
| 運用 | 安定して動いているか | レイテンシ・QPS・エラー率の監視(5-5) |
| コスト | 持続可能な費用か | 使用状況トラッキング+システムテーブル、推論テーブル分析、アラート+レート制限(本節) |
3つの軸はトレードオフの関係にあります(大型モデルは品質が上がるがコストも上がる、など)。3軸を同じダッシュボードで見られる状態を作ることが、生成AIアプリ運用のゴールです。
✅ この節のまとめ
問1. 複数の部門が共有するLLMエンドポイントについて、「部門・ユーザーごとのトークン消費量を定期的にSQLで集計し、コストを按分したい」。最も適切な方法はどれか。
正解:B
使用状況トラッキングを有効化すれば、エンドポイントの利用量・トークン数がシステムテーブルに記録され、利用者の軸でSQL集計できます。Aは全アプリに実装を強いる上に漏れが生じやすく、組み込み機能がある以上不適切です。Cは実際の利用量を反映しない按分で目的を満たしません。Dのレイテンシは時間の指標であり、トークン消費・コストの集計にはなりません。
問2. RAGチャットボットの月次コストが想定を大きく超えた。調査の結果、ユーザーの質問は短いにもかかわらず、1リクエストあたりの入力トークンが非常に多いことが分かった。最も可能性の高い原因はどれか。
正解:B
RAGでは質問が短くても、システムプロンプト・会話履歴・検索で取得した複数チャンクが毎回入力に含まれるため、入力トークンが膨らみます。対策は top-k の適正化、チャンクサイズ・履歴保持量の見直しなどです。Aの max_tokens は出力側の上限で、入力トークン増加の原因にはなりません。Cの scale-to-zero はむしろアイドル時のコスト削減機能、Dのユーザー数の少なさは「1リクエストあたりの入力が多い」ことの説明になりません。
問3. クライアントのバグによるリクエスト暴走で、一晩で大量のトークンが消費される事故が起きた。「早期に気づく」仕組みと「被害をそもそも頭打ちにする」仕組みの組み合わせとして最も適切なのはどれか。
正解:B
検知はトークン消費・リクエスト数のしきい値アラート(システムテーブルの集計に対するSQLアラート等)、抑制はUnity AI Gatewayのレート制限で利用量の上限を事前に強制する、という組み合わせが定石です。金額ベースで被害を頭打ちにしたい場合は、スペンドキャップ(ハードなコスト上限)も併用できます。Aの月次確認では一晩の暴走に間に合いません。Cは検知が受動的すぎる上、常時停止ではサービスが成立しません。Dのレイテンシは消費量の指標ではなく、temperature はコスト抑制手段ではありません。
問4. コスト削減レバーとその効果の組み合わせとして誤っているものはどれか。
正解:D
temperature は出力のランダム性(多様性)を制御するパラメータであり、生成速度やトークン単価には影響しません。コスト削減レバーではないものを紛れ込ませた誤答肢です。A(top-k適正化)、B(max_tokens)、C(scale-to-zero)はいずれも正しい組み合わせです。ただしAはRecall低下、Bは回答の打ち切り、Cはコールドスタートというトレードオフがあるため、品質評価とセットで調整します。