メインコンテンツまでスキップ
に最終更新

推論テーブルを使用してモデルを監視する

備考

ベータ版

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

このページでは、推論テーブルを使用してAI Gateway (ベータ版)エンドポイントを監視する方法について説明します。

AI ゲートウェイ推論テーブルとは何ですか?​

AI ゲートウェイ推論テーブルは、AI ゲートウェイエンドポイントから Unity Catalog Delta テーブルへのリクエストと応答を記録します。このデータは、モニタリング、デバッグ、モデルの最適化に使用できます。


ユースケースの例：

  • デバッグ : リクエストとレスポンスのペイロードを分析して、問題をトラブルシューティングします。
  • モニタリング : モデルのパフォーマンスを追跡し、異常を特定します。
  • 最適化 : 相互作用を確認して、モデルのプロンプトと構成を改善します。
  • コンプライアンス : すべてのモデルインタラクションの監査ログを維持します。

要件​

  • お使いのアカウントで AI ゲートウェイ (ベータ版) プレビューが有効になっています。「Databricks プレビューの管理」を参照してください。

  • AI Gateway (ベータ) がサポートされているリージョン内の Databricks ワークスペース。

  • ワークスペースで Unity Catalog が有効になりました。「Unity Catalog のワークスペースを有効にする」を参照してください。

  • エンドポイントの作成者と変更者の両方に、エンドポイントに対する 「管理可能」 権限が必要です。

    • CREATE TABLE 指定された Unity Catalog カタログとスキーマの権限。
    • USE CATALOG 指定されたカタログに対する権限。
    • USE SCHEMA 指定されたスキーマに対する権限。

  • カタログは、現在のメタストアへのDelta Sharingカタログにすることはできません。

  • Databricks 、パフォーマンスを向上させるために予測的最適化を有効にすることをお勧めします。

推論テーブルを有効にする​

推論テーブルは、AI ゲートウェイ エンドポイントを作成した後にのみ構成できます。

推論テーブルを有効にするには:

  1. サイドバーで、 AI ゲートウェイ をクリックします。
  2. エンドポイント名をクリックすると、エンドポイント ページが開きます。
  3. 推論テーブル の横にある [セットアップ] をクリックします。
  4. 推論テーブルを保存するカタログとスキーマを指定します。
  5. 保存 をクリックします。

推論テーブルの所有者は、エンドポイントを作成したユーザーです。すべての ACL は標準のUnity Catalog権限に従い、テーブル所有者が変更できます。

注記

既存のテーブルの指定はサポートされていません。推論テーブルを有効にすると、Databricks によって新しい推論テーブルが自動的に作成されます。

警告

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

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

推論テーブルを無効にする​

推論テーブルを無効にするには:

  1. サイドバーで、 AI ゲートウェイ をクリックします。
  2. エンドポイント名をクリックすると、エンドポイント ページが開きます。
  3. 推論テーブル の横にある編集アイコンをクリックします。
  4. 推論テーブルを無効にするを クリックします。

推論テーブルをクエリする​

UI でテーブルを表示したり、Databricks SQL またはノートブックからテーブルをクエリしたりできます。

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

Databricks SQL またはノートブックからテーブルをクエリするには:

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

<catalog> 、 <schema> 、 <payload_table>テーブルの場所に置き換えます。

推論テーブルスキーマ​

AI ゲートウェイ推論テーブルのスキーマは次のとおりです。

列名

Type

説明

例

request_id

STRING

リクエストの一意の識別子。

7a99b43cb46c432bb0a7814217701909

request_tags

マップ

リクエストに関連付けられたタグ。

{"team": "engineering"}

event_time

TIMESTAMP

リクエストを受信した時のタイムスタンプ。

2024-05-17T13:47:13.282-07:00

status_code

INT

応答の HTTP ステータス コード。

200

sampling_fraction

DOUBLE

ダウンサンプリングが使用された場合のサンプリング率。値が 1 の場合、ダウンサンプリングは行われません。

1

latency_ms

LONG

合計遅延時間（ミリ秒）。

300

time_to_first_byte_ms

LONG

最初のバイトまでの時間（ミリ秒）。

200

request

STRING

生の JSON リクエスト ペイロード。

{"messages": [...], ...}

response

STRING

生の JSON 応答ペイロード。

{"choices": [...], ...}

destination_id

STRING

宛先モデルまたはプロバイダーの ID。

7a99b43c-b46c-432b-b0a7-814217701909

logging_error_codes

Array

ログ記録に失敗した場合のエラー コード (例: MAX_REQUEST_SIZE_EXCEEDED )。

["MAX_RESPONSE_SIZE_EXCEEDED"]

requester

STRING

リクエストを行ったユーザーまたはサービスプリンシパルのID。

databricks.engineer@databricks.com

schema_version

STRING

推論テーブル レコードのスキーマ バージョン。

0

制限事項​

  • ベスト エフォート配信 : ログは通常、リクエストから数分以内に利用可能になりますが、配信は保証されません。
  • 最大ペイロード サイズ : 10 MiB を超えるリクエストと応答はログに記録されません。logging_error_codes列は、これがMAX_REQUEST_SIZE_EXCEEDEDまたはMAX_RESPONSE_SIZE_EXCEEDEDでいつ発生するかを示します。
  • エラー応答 : 401、403、429、または 500 エラーを返すリクエストについては、ログが入力されない場合があります。

次のステップ​