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

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

備考

新しい Unity AI ゲートウェイ ベータ版をお試しください

新しいUnity AI Gatewayエクスペリエンスがベータ版で利用可能です。新しいUnity AI Gatewayは、拡張された機能を持つLLMエンドポイントとコーディングエージェントを管理するためのエンタープライズコントロールプレーンです。Unity AI GatewayでのAIガバナンスを参照してください。

この記事では、提供されるモデルのモニタリング用AI Gateway対応推論テーブルについて説明します。推論テーブルは、エンドポイントの受信リクエストと送信応答を自動的にキャプチャし、それらをUnity Catalog Deltaテーブルとしてログに記録します。このテーブルのデータを使用して、機械学習モデルの監視、評価、比較、ファインチューニングを行うことができます。

AI Gateway 対応の推論テーブルとは何ですか?

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

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

推論テーブルの一般的なアプリケーションは次のとおりです。

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

要件

  • Unity AI Gatewayで有効化された推論テーブルは、以下のいずれかを提供するエンドポイントでのみサポートされています。

  • モデルサービングがサポートされているリージョンのDatabricksワークスペース。モデルサービング機能の利用可能性を参照してください。

  • ワークスペースでサーバレスコンピュートを有効にする必要があります。

  • Databricksは、推論テーブルのパフォーマンスを最適化するために、予測的最適化を有効にすることを推奨しています。

  • ワークスペースはUnity Catalogが有効になっていなければなりません。

  • エンドポイントの作成者と変更者の両方が、エンドポイントに対する Can Manage 権限を持っている必要があります。「アクセス制御リスト」を参照してください。

  • エンドポイントの作成者と変更者の両方が、Unity Catalogで以下の権限を持っている必要があります。

    • USE CATALOG 指定されたカタログに対するアクセス許可。
    • USE SCHEMA 指定されたスキーマに対する権限
    • CREATE TABLE スキーマ内の権限。
  • このカタログは、現在のメタストアに対してOpenSharingカタログであってはなりません。

注記

既存のテーブルを指定することはサポートされていません。エンドポイントを作成するか、推論テーブルの設定を有効にしてUnity AI Gateway構成を更新すると、Databricksは新しい推論テーブルを自動的に作成します。

警告

推論テーブルがデータのロギングを停止したり、破損したりする可能性があります。

  • テーブルスキーマを変更します。
  • テーブル名を変更します。
  • テーブルを削除します。

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

このセクションでは、Serving UI を使用して推論テーブルを有効化または無効化する方法を説明します。推論テーブルの所有者は、推論テーブルを有効にしたユーザーです。テーブル上のすべてのアクセス制御リスト(ACL)は、標準のUnity Catalog権限に従い、テーブル所有者によって変更できます。

エンドポイントの作成時に推論テーブルを有効にするには、次のステップを使用します。

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

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

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

推論テーブルを無効にするには、以下の手順に従ってください。

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

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

デプロイされたAIエージェントの推論テーブルを有効にすることもできます。これらの推論テーブルには、ペイロードとリクエストの詳細、およびMLflow Traceログが保存されます。

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

MLflow エージェントのトレースの詳細については、MLflow Tracing - GenAI のオブザーバビリティを参照してください。

推論テーブルで結果をクエリして分析する

提供されたモデルの準備が整うと、モデルに対するすべてのリクエストは、応答とともに推論テーブルに自動的にログ記録されます。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

Unity AI Gatewayが有効になっている推論テーブルスキーマ

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

列名

説明

Type

request_date

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

DATE

databricks_request_id

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

STRING

client_request_id

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

STRING

request_time

リクエストが受信されたタイムスタンプ。

TIMESTAMP

status_code

モデルから返されたHTTPステータスコードです。

INT

sampling_fraction

リクエストがダウンサンプリングされた場合に適用されるサンプリング割合。この値は0から1の間で、1は受信リクエストの100%が含まれたことを表します。

DOUBLE

execution_duration_ms

モデルが推論を実行したミリ秒です。これにはオーバーヘッドネットワークレイテンシは含まれず、モデルが推論を生成するのにかかった時間のみを表します。

BIGINT

request

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

STRING

response

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

STRING

served_entity_id

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

STRING

logging_error_codes

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

Array

requester

サービングエンドポイントの呼び出しリクエストに使用される権限を持つユーザーまたはサービスプリンシパルのID。このフィールドは、ルート最適化されたカスタムモデルエンドポイントに対してNULLを返します。

STRING

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時間以内にペイロードテーブルにデータがあることを期待できます。ペイロードリクエストログと評価ログは、入力に時間がかかる場合があり、生ペイロードテーブルから派生しています。ペイロードテーブルから、リクエストログと評価ログを抽出できます。ペイロードテーブルに対する削除と更新は、ペイロードリクエストログまたはペイロード評価ログには反映されません。

次に、ペイロードリクエストログテーブルのスキーマを示します。

列名

説明

Type

databricks_request_id

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

STRING

client_request_id

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

STRING

date

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

DATE

timestamp_ms

モデルサービング要求を受信した時刻のエポックミリ秒単位のタイムスタンプ。

LONG

timestamp

リクエストのタイムスタンプです。

TIMESTAMP

status_code

モデルから返されたHTTPステータスコードです。

INT

sampling_fraction

リクエストがダウンサンプリングされた場合に適用されるサンプリング割合。この値は0から1の間で、1は受信リクエストの100%が含まれたことを表します。

DOUBLE

execution_time_ms

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

LONG

conversation_id

リクエストログから抽出された会話 ID。

STRING

request

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

STRING

response

ユーザーへの最後の応答。

STRING

request_raw

リクエストの文字列表現。

STRING

response_raw

「response」の文字列形式です。

STRING

trace

レスポンス構造のdatabricks_optionsから抽出されたトレースの文字列表現。

STRING

request_metadata

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

MAP<STRING, STRING>

schema_version

スキーマのバージョン。

STRING

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

列名

説明

Type

request_id

DatabricksリクエストID。

STRING

step_id

検索評価から派生したステップID。

STRING

source

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

構造体

timestamp

リクエストのタイムスタンプ。

TIMESTAMP

text_assessment

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

STRING

retrieval_assessment

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

STRING

サンプリング

注記

サンプリングは、CPU モデルサービングエンドポイントの推論テーブルに適用されます。ここでは、ペイロードがエンドポイントのテレメトリを通じて配信されます。プロビジョニング済みスループット、外部モデル、基盤モデル API ワークロード、またはエージェントを提供するエンドポイントは、制限事項に記載されている配信動作に従います。

CPU モデルサービングエンドポイントの場合、推論テーブルにログ記録されるリクエストの割合を設定できます。サンプリングにより、高スループットエンドポイントでのログボリュームとストレージコストが削減され、トラフィックの代表的なサンプルを維持できます。

  • **デフォルト**: 100%。レートを低く設定しない限り、すべてのリクエストがログに記録されます。
  • 範囲 :0%~100%、sampling_fractionとして0から1の間に保存されます。
  • 各ログ行は、適用されたレートをその sampling_fraction 列に記録します。

UIでレートを設定するには、AI Gatewayセクションで推論テーブルを有効にする際に「 サンプリングレート(%) 」と入力します。プログラムで設定するには、エンドポイントのテレメトリ構成でsampling_fractionを指定します。

制限事項

  • カスタムモデルを提供するモデルサービングエンドポイントの推論テーブルログ配信には、約2時間かかります。

  • 基盤モデルAPIワークロード、外部モデル、またはエージェントを提供するモデルサービングエンドポイント向けの推論テーブルのログ配信は、現在ベストエフォートです。リクエストから1時間以内にログが利用可能になります。詳細については、Databricksアカウントチームにお問い合わせください。

  • ログに記録されるリクエスト、レスポンス、トレースの最大サイズは 1 MiB (1,048,576 バイト) です。この値を超過するペイロードは null としてログに記録され、logging_error_codesMAX_REQUEST_SIZE_EXCEEDED または MAX_RESPONSE_SIZE_EXCEEDED が入力されます。

  • モデルサービングエンドポイントのルート最適化された推論テーブルはパブリックプレビューです。

  • モデルサービング エンドポイントがエラーを返した場合、推論テーブルのログが必ずしも記録されるとは限りません。

    • カスタムモデルエンドポイントの場合、4xxまたは5xxエラーのログは記録されない場合があります。
    • その他のエンドポイントでは、401、403、429、または500エラーのログは記録されない場合があります。

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