モニタリングモデルとデバッグモデルの推論テーブル

備考

プレビュー

important

この記事では、特定のプロビジョニングされたスループットとカスタムモデルエンドポイントにのみ関連する従来の推論テーブルのエクスペリエンスについて説明します。このエクスペリエンスはお勧めしません。Databricks では、カスタムモデル、基盤モデル、およびエージェントサービスエンドポイントでの可用性を確保するために、 AI Gateway 対応の推論テーブルを推奨しています。

注記

Databricksで生成AIアプリケーションをサービングしている場合、Databricks生成AIモニタリングを使用して、推論テーブルを自動的に設定し、アプリケーションの運用メトリクスと品質メトリクスの両方を追跡できます。

この記事では、モニタリング提供モデルの推論テーブルについて説明します。次の図は、推論テーブルを使用した一般的なワークフローを示しています。推論テーブルは、モデルサービングエンドポイントの受信要求と送信応答を自動的にキャプチャし、それらを Unity Catalog Delta テーブルとしてログに記録します。この表のデータを使用して、ML モデルをモニタリング、デバッグ、改善できます。

推論テーブルのワークフロー

推論テーブルとは

本番運用ワークフローにおけるモデルのパフォーマンスのモニタリングは、 AI および ML モデルのライフサイクルの重要な側面です。推論テーブルは、Mosaic AI Model Serving エンドポイントからのサービングリクエスト入力とレスポンス(予測)を継続的にログに記録し、それらを Unity Catalog の Delta テーブルに保存することで、モデルのモニタリングと診断を簡素化します。その後、 Databricks プラットフォームのすべての機能 ( Databricks SQL クエリ、ノートブック、レイクハウスモニタリングなど) を使用して、モデルのモニタリング、デバッグ、最適化を行うことができます。

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

推論テーブルの一般的な用途は次のとおりです。

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

必要条件

ワークスペースはUnity Catalogが有効になっていなければなりません。
エンドポイントの作成者と修飾子の両方に、エンドポイントに対する Can Manage アクセス許可が必要です。アクセス制御リストを参照してください。
エンドポイントの作成者と修飾子の両方に、Unity Catalog で次のアクセス許可が必要です。
- USE CATALOG 指定したカタログに対する権限。
- USE SCHEMA 指定したスキーマに対する権限。
- CREATE TABLE スキーマ内の権限。

推論テーブルを有効または無効にする

このセクションでは、Databricks UI を使用して推論テーブルを有効または無効にする方法を示します。 APIを使用することもできます。手順については、APIを使用してモデルサービングエンドポイントで推論テーブルを有効にするを参照してください。

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

警告

推論テーブルは、次のいずれかの操作を行うと破損する可能性があります。

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

この場合、エンドポイントステータスの auto_capture_config は、ペイロードテーブルの FAILED 状態を示します。これが発生した場合、推論テーブルを引き続き使用するには、新しいエンドポイントを作成する必要があります。

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

Databricks Mosaic AI UI で [サービス] をクリックします。
[ サービングエンドポイントの作成 ]をクリックします。
[ 推論テーブルを有効にする ] を選択します。
ドロップダウンメニューで、テーブルを配置するカタログとスキーマを選択します。
デフォルトのテーブル名は <catalog>.<schema>.<endpoint-name>_payloadです。必要に応じて、カスタムテーブルの接頭辞を入力できます。
[ サービングエンドポイントの作成 ]をクリックします。

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

エンドポイントページに移動します。
構成の編集 をクリックします。
ステップ 3 から始まる前の指示に従います。
完了したら、[ サービングエンドポイントの更新 ] をクリックします。

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

エンドポイントページに移動します。
構成の編集 をクリックします。
「 推論テーブルを有効にする 」をクリックして、チェックマークを外します。
エンドポイントの仕様に問題がなければ、[ 更新 ] をクリックします。

ワークフロー: 推論テーブルを使用したモデルのパフォーマンスのモニタリング

推論テーブルを使用してモデルのパフォーマンスを監視するには、次の手順に従います。

エンドポイントで推論テーブルを有効にするには、エンドポイントの作成中または後で更新します。
推論テーブル内の JSON ペイロードを処理するワークフローをスケジュールするには、エンドポイントのスキーマに従って JSON ペイロードをアンパックします。
(オプション)アンパックされた要求と応答をグラウンドトゥルースラベルで結合して、モデル品質メトリクスを計算できるようにします。
結果の Delta テーブルに対してモニターを作成し、メトリクスを更新します。

スターターノートブックは、このワークフローを実装します。

推論テーブル監視のスターターノートブック

次のノートブックは、上記の手順を実装して、レイクハウスモニタリング推論テーブルからリクエストをアンパックします。ノートブックは、オンデマンドで実行することも、 Databricks ジョブを使用して定期的なスケジュールで実行することもできます。

推論テーブルレイクハウスモニタリングスターターノートブック

Open notebook in new tab

LLM を提供するエンドポイントからのテキスト品質を監視するためのスターターノートブック

次のノートブックは、推論テーブルからの要求をアンパックし、テキスト評価メトリクスのセット (可読性や毒性など) をコンピュートし、これらのメトリクスに対するモニタリングを有効にします。ノートブックは、オンデマンドで実行することも、 Databricks ジョブを使用して定期的なスケジュールで実行することもできます。

LLM 推論テーブルレイクハウスモニタリングスターターノートブック

Open notebook in new tab

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

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

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

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

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

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

UI を使用して推論テーブルを有効にした場合、エンドポイントの作成時に割り当てたテーブル名は [ payload_table です。 API を使用して推論テーブルを有効にした場合、auto_capture_config レスポンスの state セクションに payload_table が報告されます。例については、「APIを使用してモデルサービングエンドポイントで推論テーブルを有効にする」を参照してください。

パフォーマンスノート

エンドポイントを呼び出すと、スコアリング要求を送信してから 1 時間以内に推論テーブルに記録された呼び出しを確認できます。さらに、Databricksはログの配信が少なくとも1回行われることを保証しているため、まれにですが、重複するログが送信される可能性があります。

Unity Catalog 推論テーブルスキーマ

推論テーブルに記録される各要求と応答は、次のスキーマで Delta テーブルに書き込まれます。

注記

入力のバッチを使用してエンドポイントを呼び出すと、バッチ全体が 1 行としてログに記録されます。

列名	説明	タイプ
`databricks_request_id`	すべてのモデルサービング要求にアタッチされた Databricks 生成要求識別子。	STRING
`client_request_id`	モデルサービング要求本文で指定できるオプションのクライアント生成要求識別子。詳細については、「`client_request_id`の指定」を参照してください。	STRING
`date`	モデルサービングリクエストが受信されたUTCの日付。	DATE
`timestamp_ms`	モデルサービングリクエストが受信されたときのタイムスタンプ (エポックミリ秒)。	LONG
`status_code`	モデルから返された HTTP 状態コード。	INT
`sampling_fraction`	要求がダウンサンプリングされた場合に使用されるサンプリングの割合。この値は 0 から 1 までで、1 は受信要求の 100% が含まれていたことを表します。	DOUBLE
`execution_time_ms`	モデルが推論を実行した実行時間 (ミリ秒単位)。これには、オーバーヘッドネットワークの待機時間は含まれず、モデルが予測を生成するのにかかった時間のみを表します。	LONG
`request`	モデルサービングエンドポイントに送信された未加工の要求 JSON 本文。	STRING
`response`	モデルサービングエンドポイントによって返された未加工のレスポンス JSON 本文。	STRING
`request_metadata`	要求に関連付けられたモデルサービングエンドポイントに関連するメタデータのマップ。このマップには、エンドポイントに使用されているエンドポイント名、モデル名、およびモデルバージョンが含まれています。	MAP<STRING, STRING>

指定: `client_request_id`

client_request_id フィールドは、ユーザーがモデルサービングリクエスト本文で指定できるオプションの値です。これにより、ユーザーは、 client_request_id の下の最終的な推論テーブルに表示されるリクエストに独自の識別子を指定でき、グラウンドトゥルースラベルの結合など、 client_request_idを使用する他のテーブルとリクエストを結合するために使用できます。 client_request_idを指定するには、そのを要求ペイロードの最上位キーとして含めます。client_request_idが指定されていない場合、値は要求に対応する行に null として表示されます。

JSON
{
  "client_request_id": "<user-provided-id>",
  "dataframe_records": [
    {
      "sepal length (cm)": 5.1,
      "sepal width (cm)": 3.5,
      "petal length (cm)": 1.4,
      "petal width (cm)": 0.2
    },
    {
      "sepal length (cm)": 4.9,
      "sepal width (cm)": 3,
      "petal length (cm)": 1.4,
      "petal width (cm)": 0.2
    },
    {
      "sepal length (cm)": 4.7,
      "sepal width (cm)": 3.2,
      "petal length (cm)": 1.3,
      "petal width (cm)": 0.2
    }
  ]
}

この client_request_id は、 client_request_idに関連付けられたラベルを持つ他のテーブルがある場合、後でグラウンドトゥルースラベル結合に使用できます。

制限

顧客管理キーはサポートされていません。
基盤モデルをホストするエンドポイントの場合、推論テーブルはプロビジョニングされたスループットワークロードでのみサポートされます。
AWS PrivateLink はデフォルトでサポートされていません。有効にするには、Databricks アカウントチームにお問い合わせください。
推論テーブルが有効になっている場合、1 つのエンドポイントで提供されるすべてのモデルの合計最大同時実行数の制限は 128 です。 Databricks アカウントチームに連絡して、この制限の引き上げをリクエストしてください。
推論テーブルに 500K を超えるファイルが含まれている場合、追加のデータはログに記録されません。この制限を超えないようにするには、 OPTIMIZE を実行するか、古いデータを削除してテーブルのリテンションを設定します。テーブル内のファイル数を確認するには、 DESCRIBE DETAIL <catalog>.<schema>.<payload_table>を実行します。
推論テーブルのログ配信は現在ベストエフォートですが、リクエストから 1 時間以内にログが利用可能になることが期待できます。詳細については、 Databricks アカウントチームにお問い合わせください。

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

推論テーブルとは​

必要条件​

推論テーブルを有効または無効にする​

ワークフロー: 推論テーブルを使用したモデルのパフォーマンスのモニタリング​

推論テーブル監視のスターターノートブック​

推論テーブルレイクハウスモニタリング スターターノートブック

LLM を提供するエンドポイントからのテキスト品質を監視するためのスターター ノートブック​

LLM 推論テーブル レイクハウスモニタリング スターター ノートブック

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

パフォーマンスノート​

Unity Catalog 推論テーブル スキーマ​

指定: client_request_id​

制限​