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

プレビュー

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

推論テーブルとは

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

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

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

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

要件

ワークスペースで Unity Catalog が有効になっている必要があります。
エンドポイントで推論テーブルを有効にするには、エンドポイントの作成者と修飾子の両方に次のアクセス許可が必要です。
- エンドポイントに対する CAN MANAGE 権限が必要です。
- USE CATALOG 指定したカタログに対するアクセス許可。
- USE SCHEMA 指定されたスキーマに対するアクセス許可。
- CREATE TABLE スキーマのアクセス許可。

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

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

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

警告

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

テーブルスキーマを変更します。
テーブル名を変更します。
テーブルを削除します。
Unity Catalog カタログまたはスキーマに対するアクセス許可を失います。

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

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

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

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

エンドポイントページに移動します。
「 構成の編集」をクリックします。
ステップ 3 から始まる上記の手順に従います。
完了したら、[ 配信エンドポイントの更新] をクリックします。

次の手順に従って、推論テーブルを無効にします。

重要

エンドポイントで推論テーブルを無効にすると、再度有効にすることはできません。推論テーブルを引き続き使用するには、新しいエンドポイントを作成し、そのエンドポイントで推論テーブルを有効にする必要があります。

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

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

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

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

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

Starter notebook for モニタリング an inference table

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

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

ノートブックを新しいタブで開く

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

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

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

ノートブックを新しいタブで開く

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

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

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

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

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

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

パフォーマンスに関する注意事項

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

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

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

注

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

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

`client_request_id` 指定

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

{
  "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 プライベートリンクはデフォルトではサポートされていません。 Databricks アカウントチームに連絡して有効にしてください。
推論テーブルが有効になっている場合、1 つのエンドポイントで提供されるすべてのモデルの合計最大同時実行数の制限は 128 です。 Databricks アカウントチームに連絡して、この制限の引き上げを依頼してください。
推論テーブルに 500K を超えるファイルが含まれている場合、追加のデータはログに記録されません。この制限を超えないようにするには、 OPTIMIZE を実行するか、古いデータを削除してテーブルの保持期間を設定します。テーブル内のファイルの数を確認するには、 DESCRIBE DETAIL <catalog>.<schema>.<payload_table>を実行します。

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