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

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

備考

プレビュー

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

important

この記事では、 カスタム モデルの推論テーブルに適用されるトピックについて説明します。 外部モデルまたはプロビジョニングされたスループット ワークロードの場合は、 AI Gateway 対応の推論テーブルを使用します。

この記事では、モニタリング提供モデルの推論テーブルについて説明します。 次の図は、推論テーブルを使用した一般的なワークフローを示しています。 推論テーブルは、モデルサービング エンドポイントの受信要求と送信応答を自動的にキャプチャし、それらを 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 状態を示します。 これが発生した場合、推論テーブルを引き続き使用するには、新しいエンドポイントを作成する必要があります。

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

  1. Databricks Mosaic AI UI で [サービス] をクリックします。

  2. [ サービングエンドポイントの作成 ]をクリックします。

  3. [ 推論テーブルを有効にする ] を選択します。

  4. ドロップダウンメニューで、テーブルを配置するカタログとスキーマを選択します。

    推論テーブルのカタログとスキーマ

  5. デフォルトのテーブル名は <catalog>.<schema>.<endpoint-name>_payloadです。 必要に応じて、カスタムテーブルの接頭辞を入力できます。

  6. [ サービングエンドポイントの作成 ]をクリックします。

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

  1. エンドポイント ページに移動します。
  2. [ Edit configuration ] をクリックします。
  3. ステップ 3 から始まる前の指示に従います。
  4. 完了したら、[ 配信エンドポイントの更新 ] をクリックします。

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

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

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

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

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

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

Starter ノートブック for モニタリング an inference table​

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

Inference table レイクハウスモニタリング starter ノートブック

Open notebook in new tab

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

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

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

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 生成要求識別子。

文字列

client_request_id

モデルサービング要求本文で指定できるオプションのクライアント生成要求識別子。 詳細については、「client_request_idの指定」を参照してください。

文字列

date

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

日付

timestamp_ms

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

ロング

status_code

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

INT

sampling_fraction

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

double

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 として表示されます。

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 アカウントチームにお問い合わせください。

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

に最終更新