重要
カスタム モデル サービス エンドポイントでレガシ推論テーブル エクスペリエンスが必要な場合は、「 モデルの監視とデバッグのための推論テーブル」を参照してください。
この記事では、提供されるモデルを監視するための AI ゲートウェイ対応推論テーブルについて説明します。 推論テーブルは、エンドポイントの受信要求と送信応答を自動的にキャプチャし、Unity カタログ デルタ テーブルとしてログに記録します。 この表のデータを使用して、機械学習モデルの監視、評価、比較、および微調整を行うことができます。
AI ゲートウェイ対応推論テーブルとは
AI ゲートウェイ対応の推論テーブルでは、モザイク AI モデル サービス エンドポイントからの要求入力と応答 (予測) を継続的にログに記録し、Unity カタログの Delta テーブルに保存することで、モデルの監視と診断が簡素化されます。 その後、Databricks SQL クエリやノートブックなど、Databricks プラットフォームのすべての機能を使用して、モデルの監視、デバッグ、最適化を行うことができます。
既存または新しく作成されたモデル サービス エンドポイントで推論テーブルを有効にすることができ、そのエンドポイントへの要求は Unity カタログのテーブルに自動的に記録されます。
推論テーブルの一般的なアプリケーションを次に示します。
- トレーニング コーパスを作成します。 推論テーブルをグラウンド トゥルース ラベルと結合することで、モデルの再トレーニングまたは微調整と改善に使用できるトレーニング コーパスを作成できます。 Lakeflow ジョブを使用すると、継続的なフィードバック ループを設定し、再トレーニングを自動化できます。
- データとモデルの品質を監視します。 Lakehouse 監視を使用して、モデルのパフォーマンスとデータドリフトを継続的に監視できます。 Lakehouse Monitoring では、関係者と共有できるデータとモデルの品質ダッシュボードが自動的に生成されます。 さらに、受信データの変化やモデルのパフォーマンスの低下に基づいて、モデルを再トレーニングする必要があるタイミングをアラートで把握できます。
- 運用環境の問題をデバッグします。 推論テーブルでは、HTTP 状態コード、要求と応答の JSON コード、モデルの実行時間、モデルの実行時に 出力 トレースなどのデータがログに記録されます。 このパフォーマンス データは、デバッグ目的で使用できます。 推論テーブルの履歴データを使用して、履歴要求のモデル パフォーマンスを比較することもできます。
- デプロイされた AI エージェントを監視します。 推論テーブルには、問題のデバッグとパフォーマンスの監視に役立つ AI エージェントの MLflow トレースを格納することもできます。
要件
- AI ゲートウェイ対応の推論テーブルは、次のいずれかに対応するエンドポイントでサポートされています。
- プロビジョニング済みスループットのワークロード
- トークンごとの支払い モデル
- 外部モデル
- デプロイされた AI エージェント
- カスタム モデル
- モデルの提供がサポートされているリージョンの Databricks ワークスペース。 リージョンの 可用性に対応するモデルを参照してください。
- Unity カタログ ストレージ アカウントでプライベート接続が構成されているワークスペースの場合は、「 Azure リソースへのプライベート接続を構成する」の手順に従います。
- Databricks では、推論テーブルのパフォーマンスを最適化するために、予測最適化 を有効 することをお勧めします。
- ワークスペースで Unity カタログが有効になっている必要があります。
- エンドポイントの作成者と修正者の両方に、エンドポイントに対する管理可能アクセス許可が必要です。 「アクセス制御リスト」を参照してください。
- エンドポイントの作成者と修飾子の両方に、Unity カタログで次の アクセス許可 が必要です。
- 指定したカタログに対する
USE CATALOGアクセス許可。 - 指定したスキーマに対するアクセス許可は
USE SCHEMAです。 - スキーマでの
CREATE TABLEアクセス許可。
- 指定したカタログに対する
警告
次のいずれかの操作を行うと、推論テーブルがデータのログ記録を停止したり、破損したりする可能性があります。
- テーブル スキーマを変更します。
- テーブル名を変更します。
- テーブルを削除します。
- Unity カタログ カタログまたはスキーマへのアクセス許可が失われます。
- テーブル所有者を変更または削除します。
推論テーブルの有効化と無効化
このセクションでは、Serving UI を使用して推論テーブルを有効または無効にする方法について説明します。 推論テーブルの所有者は、エンドポイントを作成したユーザーです。 テーブルのすべてのアクセス制御リスト (ACL) は、標準の Unity カタログのアクセス許可に従い、テーブル所有者が変更できます。
エンドポイントの作成時に推論テーブルを有効にするには、次の手順に従います。
- Databricks Mosaic AI の UI で [サービング] をクリックします。
- [サービング エンドポイントの作成] をクリックします。
- [AI Gateway] セクションで、[推論テーブル を有効にする]選択します。
既存のエンドポイントで推論テーブルを有効にすることもできます。 既存のエンドポイント構成を編集するには、次の操作を行います。
- [AI Gateway] セクションで、[AI Gateway 編集] をクリックします。
- [推論テーブルを有効にする] を選びます。
推論テーブルを無効にするには、次の手順に従います。
- エンドポイント ページに移動します。
- [AI ゲートウェイの編集] をクリックします。
- チェック マーク 削除するには、[推論テーブル を有効にする] をクリックします。
- AI ゲートウェイの仕様に問題がなければ、[更新] をクリックします。
AI エージェントの推論テーブルを有効にする
デプロイされた AI エージェントの推論テーブルを有効にすることもできます。これらの推論テーブルにはペイロードと要求の詳細、および MLflow トレース ログが格納されます。
次の方法を使用して、AI エージェントの推論テーブルを有効にします。
-
mlflow.deploy()API を使用してデプロイされたエージェントでは、推論テーブルが自動的に有効になります。 生成 AI アプリケーションのエージェントのデプロイを参照してください。 - プログラムによるデプロイの場合は、
ENABLE_MLFLOW_TRACING環境変数をエンドポイント構成でTrueするように設定します。 「プレーンテキスト環境変数の追加」を参照してください。
MLflow エージェントのトレースの詳細については、 MLflow トレース - 生成 AI の可観測性に関するページを参照してください。
推論テーブルで結果のクエリと分析を行う
提供されたモデルの準備ができたら、モデルに対して行われたすべての要求が、応答と共に推論テーブルに自動的に記録されます。 UI でテーブルを表示したり、Databricks SQL またはノートブックからテーブルに対してクエリを実行したり、REST API を使用してテーブルにクエリを実行することができます。
UI でテーブルを表示するには、[エンドポイント] ページで、推論テーブルの名前をクリックしてカタログ エクスプローラーでテーブルを開きます。
エンドポイント ページ 
Databricks SQL または Databricks ノートブックからテーブルにクエリを実行するには: 次のようなコードを実行して推論テーブルにクエリを実行できます。
SELECT * FROM <catalog>.<schema>.<payload_table>
推論テーブルのデータを、エンドポイントで提供される基になる基盤モデルに関する詳細と結合するには: 基盤モデルの詳細は、 system.serving.served_entities システム テーブルにキャプチャされます。
注
system.serving.served_entities システム テーブルは、トークンごとの支払いエンドポイントではサポートされていませんが、推論テーブルと使用状況テーブルを結合して同様の詳細を取得できます。
SELECT * FROM <catalog>.<schema>.<payload_table> payload
JOIN system.serving.served_entities se on payload.served_entity_id = se.served_entity_id
AI ゲートウェイ対応スキーマ推論テーブル
AI Gateway を使用して有効になっている推論テーブルには、次のスキーマがあります。
AI エージェント推論テーブルスキーマ
AI エージェントの場合、Databricks はデプロイごとに 3 つの推論テーブルを作成し、モデル サービス エンドポイントとの間の要求と応答をログに記録します。
| 推論テーブル | Azure Databricks テーブル名の例 | テーブルの内容 |
|---|---|---|
| ペイロード | {catalog_name}.{schema_name}.{model_name}_payload |
未処理の JSON 要求と応答のペイロード |
| ペイロード要求ログ | {catalog_name}.{schema_name}.{model_name}_payload_request_logs |
フォーマット化された要求と応答、MLflow トレース |
| ペイロード評価ログ | {catalog_name}.{schema_name}.{model_name}_payload_assessment_logs |
レビュー アプリで提供されているフォーマット化されたフィードバック (要求ごと) |
ユーザーは、サービス エンドポイントと対話してから 1 時間以内にペイロード テーブル内のデータを期待できます。 ペイロード要求ログと評価ログの設定に時間がかかる場合があり、生のペイロード テーブルから派生します。 ペイロード テーブルから要求と評価のログを自分で抽出できます。 ペイロード テーブルの削除と更新は、ペイロード要求ログまたはペイロード評価ログには反映されません。
注
Azure Storage ファイアウォールを有効にしている場合は、Databricks アカウント チームに連絡して、エンドポイントの推論テーブルを有効にします。
ペイロード要求ログ テーブルのスキーマを次に示します。
| 列名 | 説明 | タイプ |
|---|---|---|
databricks_request_id |
Azure Databricks によって生成された要求識別子は、要求を処理するすべてのモデルにアタッチされます。 | 糸 |
client_request_id |
モデル サービス要求本文で指定できる、オプションのクライアント生成要求識別子。 | 糸 |
date |
モデル サービス要求を受信した UTC 日付。 | 日付 |
timestamp_ms |
モデル サービス要求を受信したときのタイムスタンプ (エポックミリ秒)。 | 長い |
timestamp |
要求のタイムスタンプ。 | タイムスタンプ |
status_code |
モデルから返された HTTP 状態コード。 | INT |
sampling_fraction |
要求がダウンサンプリングされた場合に使用されるサンプリング率。 この値は 0 から 1 の間です。1 は、受信要求の 100% が含まれていることを表します。 | ダブル |
execution_time_ms |
モデルが推論を実行した実行時間 (ミリ秒単位)。 これには、オーバーヘッド ネットワーク待機時間は含まれません。また、モデルが予測を生成するのにかかった時間のみを表します。 | 長い |
conversation_id |
要求ログから抽出された会話 ID。 | 糸 |
request |
ユーザーの会話からの最後のユーザー クエリ。 | 糸 |
response |
ユーザーへの最後の応答。 | 糸 |
request_raw |
要求の文字列形式。 | 糸 |
response_raw |
応答の文字列表現。 | 糸 |
trace |
応答構造体の databricks_options から抽出されたトレースの文字列表現。 |
糸 |
request_metadata |
要求に関連付けられたモデル サービス エンドポイントに関連するメタデータのマップ。 このマップには、エンドポイントに使用されるエンドポイント名、モデル名、およびモデル バージョンが含まれています。 | マップ<文字列、文字列> |
schema_version |
スキーマバージョン。 | 糸 |
ペイロード評価ログ テーブルのスキーマを次に示します。
| 列名 | 説明 | タイプ |
|---|---|---|
request_id |
Databricks 要求 ID。 | 糸 |
step_id |
取得評価から得られたステップ ID。 | 糸 |
source |
評価を作成したユーザーに関する情報を含む構造体フィールド。 | 構造 |
timestamp |
要求のタイムスタンプ。 | タイムスタンプ |
text_assessment |
レビューアプリによるエージェントの応答に関するフィードバックデータ。 | 糸 |
retrieval_assessment |
応答のために取得されたドキュメントに関するフィードバックのデータ。 | 糸 |
制限事項
- プロビジョニング済みスループットのワークロード:
- プロビジョニングされたスループットを使用するエンドポイントを提供する新しいモデルを作成する場合は、AI ゲートウェイが有効な推論テーブルのみがサポートされます。
- プロビジョニングされたスループットを使用するエンドポイントを提供する既存のモデルがあり、 以前にレガシ推論テーブルが構成されていない場合は、AI ゲートウェイ対応の推論テーブルを使用するように更新できます。
- プロビジョニングされたスループットを使用するエンドポイントを提供する既存のモデルがあり、 現在または以前に構成されているレガシ推論テーブルがある場合、AI ゲートウェイ対応の推論テーブルを使用するように更新 することはできません 。
- ストリーミング AI エージェント応答ログの場合、ChatCompletion と互換性のあるフィールドとトレースのみが集計されます。
- カスタム モデル ワークロード:
- カスタム モデルを提供するエンドポイントを提供する新しいモデルを作成する場合、Databricks では AI ゲートウェイ対応の推論テーブルを使用することをお勧めします。 レガシ推論テーブルのエクスペリエンスが必要な場合は、REST API を使用して AI Gateway の新しいエンドポイントのみを構成できます。
- カスタム モデルを提供するエンドポイントを提供する既存のモデルがあり、 推論テーブルが構成されていない場合は、AI Gateway 対応の推論テーブルを使用するように更新できます。
- カスタム モデルを提供するエンドポイントを提供する既存のモデルがあり、 レガシ推論テーブルが構成されている場合は、AI ゲートウェイ対応の推論テーブルを使用するようにエンドポイントを更新する前に、レガシ推論テーブルを無効にする必要があります。
- AI ゲートウェイ対応の推論テーブルが有効になった後は、レガシ推論テーブルに切り替 えることはできません 。
- 推論テーブルによる model のログ配信は、Foundation Model API ワークロードや外部モデル、およびエージェントにサービスを提供するエンドポイントに対して、現在可能な限りで行われています。 要求から 1 時間以内にログを使用できることを期待できます。 詳細については、Databricks アカウント チームにお問い合わせください。
- ログに記録される要求と応答の最大サイズは 1 MiB (1,048,576 バイト) です。 これを超える要求ペイロードと応答ペイロードは
nullとしてログに記録され、logging_error_codesにはMAX_REQUEST_SIZE_EXCEEDEDまたはMAX_RESPONSE_SIZE_EXCEEDEDが設定されます。 - エンドポイントを提供する ルート最適化モデルの 推論テーブルは 、パブリック プレビュー段階にあります。
AI Gateway に固有の制限事項については、「制限事項」を参照してください。 一般的なモデル サービス エンドポイントの制限については、「モデル サービスの制限とリージョンの」を参照してください。