メインコンテンツまでスキップ

AI Gateway 対応の推論テーブルを使用して、提供されたモデルを監視する

備考

プレビュー

この機能は パブリック プレビュー段階です。

important

この記事では、外部モデル、プロビジョニングされたスループットワークロード、またはエージェントモデルの推論テーブルに適用されるトピックについて説明します。 カスタムモデルについては、モニタリングモデルとデバッグモデルの推論テーブルを参照してください。

この記事では AI モニタリング提供モデルのゲートウェイ対応推論テーブルについて説明します。 推論テーブルは、エンドポイントの受信要求と送信応答を自動的にキャプチャし、それらを Unity Catalog Delta テーブルとしてログに記録します。 この表のデータを使用して、機械学習モデルを監視、評価、比較、および微調整できます。

AI Gateway 対応推論テーブルとは​

AI Gateway 対応の推論テーブルは、Mosaic AI Model Serving エンドポイントからのサービングリクエストの入力と応答(予測)を継続的にログに記録し、それらを Unity Catalog の Delta テーブルに保存することで、モデルのモニタリングと診断を簡素化します。 その後、Databricks SQL クエリやノートブックなど、Databricks プラットフォームのすべての機能を使用して、モデルを監視、デバッグ、最適化できます。

既存または新しく作成されたモデルサービングエンドポイントで推論テーブルを有効にでき、そのエンドポイントへのリクエストは Unity Catalogのテーブルに自動的に記録されます。

推論テーブルの一般的なアプリケーションには、次のようなものがあります。

  • トレーニング コーパスを作成します。 推論テーブルをグラウンドトゥルースラベルと結合することで、モデルの再トレーニングや微調整、改善に使用できるトレーニングコーパスを作成できます。 Databricks ジョブを使用すると、継続的なフィードバックループを設定し、再トレーニングを自動化できます。
  • データとモデルの品質を監視します。 レイクハウスモニタリングを使用して、モデルのパフォーマンスとデータドリフトを継続的に監視できます。 レイクハウスモニタリングは、関係者と共有できるデータとモデル品質ダッシュボードを自動的に生成します。 さらに、アラートを有効にして、受信データのシフトやモデルのパフォーマンスの低下に基づいてモデルを再トレーニングする必要があるタイミングを知ることができます。
  • 本番運用の問題をデバッグします。 推論テーブルは、HTTP ステータスコード、リクエストとレスポンスの JSON コード、モデルの実行時間、モデルの実行時間中の トレース出力 などのデータをログに記録します。 このパフォーマンス・データは、デバッグ目的で使用できます。 また、推論テーブルでヒストリカルデータを使用して、履歴リクエストに対するモデルのパフォーマンスを比較することもできます。
  • デプロイされた AI エージェントを監視します。 推論テーブルには、AI エージェントの MLflow トレースも格納できるため、問題のデバッグとパフォーマンスの監視に役立ちます。

必要条件​

警告

推論テーブルは、次のいずれかの操作を行うと、データのログ記録を停止したり、破損したりする可能性があります。

  • テーブル スキーマを変更します。
  • テーブル名を変更します。
  • テーブルを削除します。
  • Unity Catalogカタログまたはスキーマに対する権限を失います。

推論テーブルの有効化と無効化​

このセクションでは、Serving UI を使用して推論テーブルを有効または無効にする方法を示します。 推論テーブルの所有者は、エンドポイントを作成したユーザーです。 テーブル上のすべてのアクセス制御リスト (ACL) は、標準の Unity Catalog アクセス許可に従い、テーブルの所有者が変更できます。

エンドポイントの作成時に推論テーブルを有効にするには、次の手順に従います。

  1. Databricks Mosaic AI UI で サービング をクリックします。
  2. サービングエンドポイントの作成 をクリックします。
  3. AI Gatewayセクションで、 推論テーブルを有効にする を選択します。

既存のエンドポイントで推論テーブルを有効にすることもできます。 既存のエンドポイント設定を編集するには、次の手順を実行します。

  1. AI Gatewayセクションで、 Edit AI Gateway をクリックします。
  2. 推論テーブルを有効にする を選択します。

推論テーブルを無効にするには、次の手順に従います。

  1. エンドポイント ページに移動します。
  2. AI Gatewayの編集 をクリックします。
  3. 推論テーブルを有効にする をクリックして、チェックマークを外します。
  4. AI Gateway の仕様に問題がなければ、 更新 をクリックします。

AI エージェントの推論テーブルを有効にする​

また、デプロイされた AI エージェントの推論テーブルを有効にすることもでき、これらの推論テーブルにはペイロードと要求の詳細、MLflow トレース ログが格納されます。

次の方法を使用して、AI エージェントの推論テーブルを有効にします。

MLflow エージェントのトレースの詳細については、「 推論テーブルを使用してデプロイされたエージェントを監視する」を参照してください。

推論テーブル内の結果のクエリと分析​

提供したモデルの準備ができたら、モデルに対して行われたすべてのリクエストは、レスポンスとともに推論テーブルに自動的に記録されます。 UI でテーブルを表示したり、Databricks SQL またはノートブックからテーブルをクエリしたり、REST API を使用してテーブルをクエリしたりできます。

UI でテーブルを表示するには、次のようにします。 エンドポイントページで、推論テーブルの名前をクリックして、カタログエクスプローラーでテーブルを開きます。

エンドポイントページの推論テーブル名へのリンク

Databricks SQL または Databricks ノートブックからテーブルをクエリするには: 次のようなコードを実行して、推論テーブルをクエリできます。

SQL
SELECT * FROM <catalog>.<schema>.<payload_table>

推論テーブルのデータを、エンドポイントで提供される基盤となる基盤モデルの詳細と結合するには、次のようにします。 基盤モデルの詳細はシステムテーブルsystem.serving.served_entitiesにキャプチャされます 。

SQL
SELECT * FROM <catalog>.<schema>.<payload_table> payload
JOIN system.serving.served_entities se on payload.served_entity_id = se.served_entity_id

AI Gateway 対応推論テーブル スキーマ​

AI Gateway を使用して有効にした推論テーブルには、次のスキーマがあります。

列名

説明

タイプ

request_date

モデルサービングリクエストが受信されたUTCの日付。

日付

databricks_request_id

すべてのモデルサービング要求にアタッチされる Databricksが生成するリクエストの識別子。

文字列

client_request_id

モデルサービング要求本文で指定できるユーザー指定のリクエスト識別子。

文字列

request_time

要求が受信されたタイムスタンプ。

Timestamp

status_code

モデルから返された HTTP 状態コード。

INT

sampling_fraction

要求がダウンサンプリングされた場合に使用されるサンプリングの割合。 この値は 0 から 1 までで、1 は受信要求の 100% が含まれていたことを表します。

double

execution_duration_ms

モデルが推論を実行した時間 (ミリ秒単位)。 これには、オーバーヘッド ネットワークの待機時間は含まれず、モデルが予測を生成するのにかかった時間のみを表します。

BIGINT

request

モデルサービング エンドポイントに送信された未加工の要求 JSON 本文。

文字列

response

モデルサービングエンドポイントによって返された未加工のレスポンス JSON 本文。

文字列

served_entity_id

提供されたエンティティの一意の ID。

文字列

logging_error_codes

データをログに記録できなかったときに発生したエラー。 エラーコードには、 MAX_REQUEST_SIZE_EXCEEDED と MAX_RESPONSE_SIZE_EXCEEDEDが含まれます。

ARRAY

requester

サービスエンドポイントの呼び出しリクエストにアクセス許可が使用されるユーザーまたはサービスプリンシパルの ID。

文字列

AIエージェント推論テーブルスキーマ​

AI エージェントの場合、Databricks はデプロイごとに 3 つの推論テーブルを作成し、モデルサービングエンドポイントとの間の要求と応答をログに記録します。

推論テーブル

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 時間以内にペイロード テーブルのデータを期待できます。 ペイロード要求ログと評価ログは、入力に時間がかかる場合があり、未加工のペイロード テーブルから派生します。 ペイロード テーブルから要求ログと評価ログを自分で抽出できます。 ペイロード テーブルの削除と更新は、ペイロード要求ログまたはペイロード評価ログには反映されません。

以下は、ペイロードリクエストログテーブルのスキーマを示しています。

列名

説明

タイプ

databricks_request_id

すべてのモデルサービング要求にアタッチされる Databricksが生成するリクエストの識別子。

文字列

client_request_id

モデルサービング要求本文で指定できるオプションのクライアント生成要求識別子。

文字列

date

モデルサービングリクエストが受信されたUTCの日付。

日付

timestamp_ms

モデルサービング リクエストが受信されたときのタイムスタンプ (エポックミリ秒)。

ロング

timestamp

要求のタイムスタンプ。

Timestamp

status_code

モデルから返された HTTP 状態コード。

INT

sampling_fraction

要求がダウンサンプリングされた場合に使用されるサンプリングの割合。 この値は 0 から 1 までで、1 は受信要求の 100% が含まれていたことを表します。

double

execution_time_ms

モデルが推論を実行した実行時間 (ミリ秒単位)。 これには、オーバーヘッド ネットワークの待機時間は含まれず、モデルが予測を生成するのにかかった時間のみを表します。

ロング

conversation_id

要求ログから抽出された会話 ID。

文字列

request

ユーザーの会話からの最後のユーザー クエリ。

文字列

response

ユーザーに対する最後の応答。

文字列

request_raw

request の文字列表現。

文字列

response_raw

応答の文字列表現。

文字列

trace

応答 Struct の databricks_options から抽出されたトレースの文字列表現。

文字列

request_metadata

要求に関連付けられたモデルサービングエンドポイントに関連するメタデータのマップ。 このマップには、エンドポイントに使用されているエンドポイント名、モデル名、およびモデル バージョンが含まれています。

MAP<文字列, 文字列>

schema_version

スキーマのバージョン。

文字列

次に、ペイロード評価ログテーブルのスキーマを示します。

列名

説明

タイプ

request_id

Databricks 要求 ID。

文字列

step_id

取得評価から派生したステップ ID。

文字列

source

評価を作成したユーザーに関する情報を含む構造体フィールド。

構造体

timestamp

要求のタイムスタンプ。

Timestamp

text_assessment

レビューアプリからのエージェントの応答に関するフィードバックのデータ。

文字列

retrieval_assessment

応答のために取得されたドキュメントに関するフィードバックのデータ。

文字列

制限​

  • プロビジョニングされたスループットワークロード:

    • プロビジョニングされたスループットを使用する新しいモデルサービングエンドポイントを作成する場合は、AI Gateway 対応の推論テーブルのみがサポートされます。
    • プロビジョニング スループットを使用する既存のモデルサービング エンドポイントがあり、 以前に推論テーブルが設定されていなかった 場合は、 AI ゲートウェイ対応推論テーブルを使用するように更新できます。
    • プロビジョニングされたスループットを使用する既存のモデルサービングエンドポイントがあり、 現在または以前に推論テーブルが設定されている場合 、AI Gateway 対応推論テーブルを使用するように更新 することはできません 。
    • ストリーミング AI エージェントの応答ログの場合、ChatCompletion と互換性のあるフィールドとトレースのみが集計されます。

  • 推論テーブルのログ配信は現在ベストエフォートですが、リクエストから 1 時間以内にログが利用可能になることが期待できます。 詳細については、 Databricks アカウントチームにお問い合わせください。

  • ログに記録される要求と応答の最大サイズは 1 MiB (1,048,576 バイト) です。 これを超える要求ペイロードと応答ペイロードは null としてログに記録され、 logging_error_codes には MAX_REQUEST_SIZE_EXCEEDED または MAX_RESPONSE_SIZE_EXCEEDEDが入力されます。

AI Gateway に固有の制限については、 制限事項を参照してください。一般的なモデルサービングエンドポイントの制限については、 モデルサービングの制限とリージョンを参照してください。

に最終更新