Databricks Certified Generative AI Engineer Associate 教科書
第5章 評価とモニタリング(Evaluation and Monitoring, 12%)
🎯 この節の学習目標
単純な1回のLLM呼び出しなら「入力と出力」を見れば十分でした。しかしエージェント(第3章)は多段の処理です。1つのリクエストの裏で、次のような一連のステップが実行されます。
最終出力だけを見て「回答が間違っている」と分かっても、どの段で間違えたのか(ツール選択?検索結果?最終生成?)は分かりません。途中経過が見えなければ、デバッグも改善もできないのです。この「実行の内部を観測可能にする」ことをオブザーバビリティ(observability)と呼び、その中核技術がトレーシングです。
MLflow Tracing は、エージェントやチェーンの実行をステップ(span)の木構造として自動記録する仕組みです。MLflow 3 の統合評価フレームワークの中核機能として位置付けられており、開発時のデバッグだけでなく、本番トレースの収集(5-5)・評価(スコアラーはトレースを入力に取れる)・人間フィードバックの紐付けまで、同じトレースを軸に回します。各 span には次が記録されます。
導入は自動計装(autologging)が基本です。対応ライブラリなら1行で、以降の実行がすべてトレースされます。
import mlflow
# LangChain / LangGraph アプリの実行を自動でトレース
mlflow.langchain.autolog()
# 対応ライブラリごとに同様の自動計装がある(例:OpenAI SDK)
# mlflow.openai.autolog()
# 自作コードの任意の関数を span として記録したい場合
@mlflow.trace
def lookup_order(order_id: str) -> dict:
...
記録されたトレースは MLflow の UI で木構造として閲覧でき、各 span をクリックして入出力を確認できます。
💼 例:トレースで原因を突き止める
症状:「注文状況を教えて」への回答が的外れになることがある。
トレースを見ると:
診断:失敗の根本原因は span 1 のツール選択ミス。対策は最終生成のプロンプトではなく、ツールの説明文(description)を明確化して選択精度を上げること(3章の知識と接続)。最終出力だけを見ていたら「生成が悪い」と誤診していたところです。
📝 試験のポイント
「多段のエージェントで、どのステップが失敗・遅延しているかを特定したい」→ MLflow Tracing。「LangChain アプリのトレースを最小の手間で有効化したい」→ mlflow.langchain.autolog()。トレースは「どのツールが呼ばれたか」「検索で何が返ったか」「どの段でレイテンシ・エラーが発生したか」を診断できる、という対応を押さえましょう。
自動評価(5-2)だけでなく、人間の判断を改善に取り込みます。Databricks では次の2経路が代表的です。
フィードバックがトレースに紐付いていることが重要です。MLflow 3 では人間フィードバック(Human feedback)が統合評価フレームワークの一要素として扱われ、👍/👎 や SME の評価をフィードバックAPI経由で該当トレースに直接記録できます。「👎 が付いた応答」のトレースを開けば、そのときどのツールが呼ばれ、何が検索され、どんなプロンプトで生成されたかをそのまま再現・調査できます。低評価の事例は評価データセット(5-2・5-3)に追加し、修正が効いたかを回帰テストで確認します。
5-1の観点(関連性・忠実性など)は最終出力の評価でした。エージェントではプロセスの正しさも測ります。
| 指標 | 測るもの | 低いときに疑うこと |
|---|---|---|
| タスク完了率 | ユーザーの依頼を最終的に達成できた割合 | 能力不足、ツール不足、途中段の失敗の蓄積 |
| ツール呼び出しの正しさ | 適切なツールを適切な引数で呼べたか | ツールの説明文が曖昧、ツール数が多すぎて選択を誤る |
| ステップ数・ループ検知 | 完了までのステップ数が妥当か。同じ処理を繰り返すループ暴走をしていないか | 終了条件の設計不備。ステップ数はコストとレイテンシに直結するため上限(max iterations)を設ける |
これらはトレースがあって初めて計算できる指標です。たとえば「ツール呼び出しの正しさ」は、トレースに記録されたツール名・引数を期待値と比較して評価します(トレースを入力に取るカスタムスコアラー、5-3)。
本章で学んだ部品を組み合わせると、エージェントの継続的改善サイクルが完成します。
mlflow.genai.evaluate() を再実行し、改善を確認してからデプロイ(4章)。以後1に戻る「デプロイして終わり」ではなく、本番データが次の評価データセットを育て、評価が次の改善を導くループを回し続けることが、生成AIアプリ運用の本質です。このループを MLflow 3 の部品で表すと次のようになります。
図:MLflow 3 を軸にした評価→改善ループ
✅ この節のまとめ
mlflow.langchain.autolog() などの自動計装で導入できる。問1. 複数のツールを使うエージェントの回答が時々おかしくなる。「どのステップ(ツール選択、検索、生成)に原因があるか」を特定するために最も適切な方法はどれか。
正解:B
「どの段で失敗したか」という診断には、途中経過を記録するトレーシングが必要です。Aの correctness ジャッジは最終出力の正誤しか分からず、原因の段を特定できません。CのQPSは負荷の指標で品質診断には使えません。Dは出力のばらつきを抑えるだけで、原因特定の手段ではありません。
問2. LangChain で構築したエージェントについて、コード変更を最小限にして全実行のトレースを MLflow に記録したい。最も適切な方法はどれか。
正解:B
mlflow.langchain.autolog() による自動計装は、対応ライブラリの実行を1行で span の木構造として記録します。Aの print はレイテンシや親子関係が構造化されず、検索・分析もできません。Cは自動計装で済むものを手作業で作る過剰な実装です。Dのような自作プロキシは不要です。
問3. 本番アプリのUIに 👍/👎 ボタンを設けた。このフィードバックを改善に最も効果的に活かす設計はどれか。
正解:B
フィードバックはトレースに紐付いてこそ「そのときどのツールが呼ばれ、何が検索されたか」を調査でき、原因特定→評価データセットへの還元→回帰テストという改善ループに乗せられます。Aは件数の増減しか分からず原因に到達できません。Cは記録を消してしまい分析を不可能にします。Dのような自動改善の仕組みは存在せず、フィードバックは人間とパイプラインが活用して初めて価値になります。
問4. エージェントが同じ検索ツールを何度も繰り返し呼び出し、応答に時間がかかりコストも膨らむ事象が報告された。監視と対策の組み合わせとして最も適切なのはどれか。
正解:A
同一処理の繰り返しはループ暴走であり、トレースに記録されるステップ数・ツール呼び出し履歴から検知できます。対策は反復回数の上限設定など終了条件の設計です。Bの groundedness は回答の根拠性の指標でループとは無関係、Cのチャンクサイズは検索品質の調整手段です。Dは誤りで、ループは正常応答として完了することも多く、エラー率には現れないことがあります。
問5. MLflow 3 における Tracing の位置付けとして最も適切なのはどれか。
正解:B
MLflow 3 では Tracing が統合評価フレームワーク(Tracing / Evaluation / LLM judges / Human feedback / Scorers)の中核に置かれ、開発時のデバッグ、本番トレースの収集(5-5)、フィードバックの紐付け、トレースを入力に取るスコアラーによる評価までを一貫して支えます。Aは誤りで、本番でもトレースを収集してオンライン評価につなげられます。Cは誤りで、mlflow.langchain.autolog() などの自動計装が基本です。Dは誤りで、ペイロードロギング(何を答えたかの記録)と Tracing(どう動いたかの記録)は補完関係にあり併用します。