本番運用モニタリングをセットアップする

備考

ベータ版

この機能はベータ版です。ワークスペース管理者は、 プレビュー ページからこの機能へのアクセスを制御できます。「Databricks プレビューの管理」を参照してください。

本番運用モニタリングを使用すると、エージェントからのトレースに対して MLflow 3 スコアラーを自動的に実行して、品質を継続的に評価できます。MLflow エクスペリメントに対してスコアラーをスケジュールすると、モニタリング サービスが着信トレースの構成可能なサンプルを評価します。結果はフィードバックとして評価済みトレースにアタッチされます。

本番運用モニタリングには次の内容が含まれます。

• 会話全体を評価するためのマルチターン審査員を含む、組み込みまたはカスタムのスコアラーを使用した自動品質評価。
• サンプリング レートを設定できるため、カバレッジと計算コストのトレードオフを制御できます。
• 一貫した評価を確保するために、開発と本番運用で同じスコアラーを使用します。
• バックグラウンドで実行されるモニタリングによる継続的な品質評価。

注記

MLflow 3 本番運用 モニタリングは、 MLflow 2 からログに記録されたトレースと互換性があります。

前提 条件

本番運用モニタリングを設定する前に、次のことを確認してください。

• MLflowエクスペリメント : トレースが記録されるMLflowエクスペリメント。 エクスペリメントが指定されていない場合は、アクティブなエクスペリメントが使用されます。

• 計測可能になっている本番運用アプリケーション : エージェントはMLflow Tracingを使用してトレースをログに記録する必要があります。本番運用のトレーシングガイドを参照してください。

• 定義済みのスコアラー : アプリケーションのトレースの形式で動作するテスト済みのスコアラー。開発中に本番運用アプリをmlflow.genai.evaluate()のpredict_fnとして使用した場合、スコアラーは既に互換性がある可能性があります。

• サーバレス予算ポリシー ：ワークスペースでデフォルトのサーバレス予算ポリシーが許可されていない場合は、スコアラーを登録する前にMLflowエクスペリメントでポリシーを設定してください。MLflowエクスペリメントのサーバレス予算ポリシーを構成するを参照してください。

• SQLウェアハウスID (Unity Catalogのトレース用) ：トレースが Unity Catalog に保存されている場合、モニタリング機能が動作するようにSQLウェアハウスIDを設定する必要があります。「Unity Catalog用のSQLウェアハウスの設定」を参照してください。

Unity Catalog トレース用の SQL ウェアハウスを設定する

トレースが Unity Catalog に保存されている場合、モニタリングジョブは SQL Warehouse を介して Unity Catalog テーブルに対してスコアラークエリーを実行します。スコアラーを登録する前にエクスペリメントで warehouse ID を設定してください。そうしないと、mlflow.monitoring.sqlWarehouseId タグが見つからないことを示すエラーが発生してモニタリングジョブが失敗します。

Set the SQLウェアハウス ID using set_databricks_monitoring_sql_warehouse_id().This helper stores the ID in the mlflow.monitoring.sqlWarehouseId experiment タグ, which is where the モニタリング ジョブ reads it from:

Python

from mlflow.tracing import set_databricks_monitoring_sql_warehouse_id

# Set the SQL warehouse ID for monitoring
set_databricks_monitoring_sql_warehouse_id(
    sql_warehouse_id="<SQL_WAREHOUSE_ID>",
    experiment_id="<EXPERIMENT_ID>"  # Optional, uses active experiment if not specified
)

注記

ノートブックまたはアプリケーションで MLFLOW_TRACING_SQL_WAREHOUSE_ID 環境変数を設定しても、代わりにはなりません。設定したプロセスにのみ適用されます。モニタリングジョブは個別に実行され、エクスペリメントタグから warehouse ID を読み取ります。set_databricks_monitoring_sql_warehouse_id() を使用して、エクスペリメントに warehouse ID が維持されるようにします。

Unity Catalog トレースのモニタリングを構成するには、次のワークスペースレベルの権限が必要です。

• CAN USE SQLウェアハウス上で。
• CAN EDIT MLflowエクスペリメントで。
• モニタリングジョブに対する権限（最初のスコアラーを登録したときに自動的に付与されます）。

このモニタリングジョブは、エクスペリメントに最初にスコアラーを登録したユーザーのIDで実行されます。このユーザーの権限によって、モニタリングジョブがアクセスできる内容が決まります。

さあ始めましょう

モニタリングは、スコアラーを起動した瞬間から開始されます。.register() および .start() パターンを使用して、エクスペリメントにスコアラーを登録し、サンプリング構成で起動します。

Python

from mlflow.genai.scorers import Safety, ScorerSamplingConfig

# Register and start a built-in judge
safety_judge = Safety().register(name="safety")
safety_judge = safety_judge.start(sampling_config=ScorerSamplingConfig(sample_rate=0.7))

この2ステップのパターンは、組み込みジャッジ、カスタムジャッジ、コードベースのスコアラー、マルチターンジャッジなど、すべてのスコアラータイプで機能します。

利用可能なスコアラーとジャッジの種類については、スコアラーとジャッジを参照してください。

注記

いつでも、最大20個のスコアラーをエクスペリメントに関連付けて、継続的な品質モニタリングを行うことができます。

結果を見る

スコアラーをスケジュールした後、初期処理に15〜20分かかります。そうしたら：

1. MLflowエクスペリメントに移動します。
2. トレース タブを開いて、トレースに添付された評価を確認します。
3. モニタリングダッシュボードを使用して、品質の傾向を追跡します。

複数ターンの審査員の場合、評価は各セッションの最初のトレースに添付されます。詳細については、 「評価の保存方法」を参照してください。

おすすめの方法

サンプリング戦略

• 安全性やセキュリティのチェックなどの重要なスコアラーには、 sample_rate=1.0使用します。

• 複雑な LLM ジャッジなどの高価なスコアラーの場合は、より低いサンプル レート (0.05 ～ 0.2) を使用します。

• 開発中の反復的な改善には、中程度のレート (0.3 ～ 0.5) を使用します。

• 次の例に示すように、カバレッジとコストのバランスをとってください。

  Python

  # High-priority scorers: higher sampling
  safety_judge = Safety().register(name="safety")
  safety_judge = safety_judge.start(sampling_config=ScorerSamplingConfig(sample_rate=1.0))  # 100% coverage for critical safety
  
  # Expensive scorers: lower sampling
  complex_scorer = ComplexCustomScorer().register(name="complex_analysis")
  complex_scorer = complex_scorer.start(sampling_config=ScorerSamplingConfig(sample_rate=0.05))  # 5% for expensive operations

トレースをフィルタリング

ScorerSamplingConfigのfilter_string問題を使用して、スコアラーがどのトレースを評価するかを制御します。 これはmlflow.search_traces()と同じフィルタ構文を使用します。

Python

from mlflow.genai.scorers import Safety, ScorerSamplingConfig

# Only evaluate traces that completed successfully
safety_judge = Safety().register(name="safety")
safety_judge = safety_judge.start(
    sampling_config=ScorerSamplingConfig(
        sample_rate=1.0,
        filter_string="attributes.status = 'OK'"
    ),
)

複数の条件を組み合わせることができます。

Python

import time

# Evaluate successful traces from the last 24 hours
one_day_ago = int((time.time() - 86400) * 1000)
safety_judge = safety_judge.start(
    sampling_config=ScorerSamplingConfig(
        sample_rate=0.5,
        filter_string=f"attributes.status = 'OK' AND attributes.timestamp_ms > {one_day_ago}"
    ),
)

カスタムスコアラーのデザイン

次の例に示すように、カスタムスコアラーを自己完結型のままにします。

Python

@scorer
def well_designed_scorer(inputs, outputs):
    # All imports inside the function
    import re
    import json

    # Handle missing data gracefully
    response = outputs.get("response", "")
    if not response:
        return 0.0

    # Return consistent types
    return float(len(response) > 100)

トラブルシューティング

スコアラーが実行されない

スコアラーが実行されていない場合は、次の点を確認してください。

1. エクスペリメントのチェック : トレースが個々の実行ではなくエクスペリメントに記録されていることを確認します。
2. サンプリング レート : サンプリング レートが低い場合、結果が表示されるまでに時間がかかることがあります。
3. フィルター文字列を確認してください : filter_stringが実際のトレースと一致していることを確認してください。

シリアル化の問題

本番運用モニタリングのカスタム スコアラーはシリアル化されているため、モニタリング サービスによってリモートで実行できます。 これにはいくつかの制約が課せられます。

• ノートブックの要件 : カスタム@scorer関数を定義し、 Databricksノートブックから登録する必要があります。 シリアル化メカニズムはノートブック環境に依存します。
• 自己完結型関数 : すべてのインポートは関数本体内にインラインで記述する必要があります。関数外で定義された外部変数、モジュール、またはオブジェクトへの参照は、シリアル化中にキャプチャされません。
• クラスベースのスコアラーはありません 。登録できるのは@scorerのデコレータベースのスコアラーのみです。クラスベースのScorerサブクラスは、リモート実行用にシリアル化できません。
• インポートを必要とする型ヒントがありません : 関数シグネチャ内にインポート ステートメントを必要とする型ヒント (たとえば、 List from typing ) があると、シリアル化が失敗します。

カスタムスコアラーを作成するときは、関数定義にインポートを含めます。

Python

# Avoid external dependencies
import external_library  # Outside function

@scorer
def bad_scorer(outputs):
    return external_library.process(outputs)

# Include imports in the function definition
@scorer
def good_scorer(outputs):
    import json  # Inside function
    return len(json.dumps(outputs))

# Avoid using type hints in scorer function signature that requires imports
from typing import List

@scorer
def scorer_with_bad_types(outputs: List[str]):
    return False

# Class-based scorers are not supported for production monitoring
class MyScorer(Scorer):
    name: str = "my_scorer"
    def __call__(self, outputs):
        return len(outputs) > 10

次のステップ： 本番運用スコアラーの管理

その他のリソース

• 過去のトレースにスコアラーを遡及的に適用する- 過去のトレースにスコアラーを遡及的に適用します。
• コードベースのスコアラー- ニーズに合わせてカスタマイズされたスコアラーを構築します。
• 会話を評価する- マルチターンの会話評価とマルチターンの審査員について学びます。
• MLflow評価データセットの構築- モニタリング結果を活用して品質を向上させる。

リファレンスガイド

• 本番用スコアラーの管理 - スコアラーのライフサイクル管理に関する API リファレンス。
• 採点者とLLM審査員- モニタリングを強化するメトリクスを理解します。
• エージェントの評価 - オフライン評価と本番運用の関係について。