Amazon
Web Services
Microsoft Azure
Google Cloud Platformモデルのモニタリングおよびデバッグのための推論テーブル
プレビュー
この機能はパブリックプレビュー段階です。
この記事では、モニタリング対象モデルの推論テーブルについて説明します。 次の図は、推論テーブルを使用した一般的なワークフローを示しています。 推論テーブルは、モデルサービング エンドポイントの受信要求と送信応答を自動的にキャプチャし、それらを Unity Catalog Delta テーブルとしてログに記録します。 この表のデータを使用して、機械学習モデルの監視、デバッグ、および改善を行うことができます。
外部モデルをホストするモデルサービングエンドポイントの場合、 AI Gateway を使用してのみ推論テーブルを有効にできます。
推論テーブルとは
モニタリング 本番運用 ワークフローにおけるモデルのパフォーマンスは、 AI および ML モデルのライフサイクルの重要な側面です。 推論テーブルは、Mosaic AI Model Serving エンドポイントからのサービングリクエスト入力とレスポンス(予測)を継続的にログに記録し、それらを Unity Catalog の Delta テーブルに保存することで、モデルのモニタリングと診断を簡素化します。 その後、 Databricks プラットフォームのすべての機能 ( Databricks SQL クエリ、ノートブック、レイクハウスモニタリングなど) を使用して、モデルのモニタリング、デバッグ、最適化を行うことができます。
既存または新規に作成されたモデルサービングエンドポイントで推論テーブルを有効にすると、そのエンドポイントへのリクエストがUCのテーブルに自動的に記録されます。
推論テーブルの一般的なアプリケーションには、次のようなものがあります。
データとモデルの品質を監視します。 レイクハウスモニタリングを使用して、モデルのパフォーマンスとデータドリフトを継続的に監視できます。 レイクハウスモニタリングは、関係者と共有できるデータとモデル品質ダッシュボードを自動的に生成します。 さらに、アラートを有効にして、受信データのシフトやモデルのパフォーマンスの低下に基づいてモデルを再トレーニングする必要があるタイミングを知ることができます。
本番運用の問題をデバッグします。 推論テーブルは、HTTP ステータス コード、モデルの実行時間、要求と応答の JSON コードなどのデータをログに記録します。 このパフォーマンス データは、デバッグ目的で使用できます。 また、推論テーブルのヒストリカルデータを使用して、過去のリクエストに対するモデルのパフォーマンスを比較することもできます。
トレーニングコーパスを作成します。 推論テーブルをグラウンド トゥルース ラベルと結合することで、モデルの再トレーニングや微調整、改善に使用できるトレーニング コーパスを作成できます。 Databricks ジョブを使用すると、継続的なフィードバック ループを設定し、再トレーニングを自動化できます。
推論テーブルの有効化と無効化
このセクションでは、Databricks UI を使用して推論テーブルを有効または無効にする方法について説明します。 API を使用することもできます。手順については、「 API を使用してモデルサービングエンドポイントで推論テーブルを有効にする 」を参照してください。
推論テーブルの所有者は、エンドポイントを作成したユーザーです。 テーブル上のすべてのアクセス制御リスト (ACL) は、標準の Unity Catalog アクセス許可に従い、テーブルの所有者が変更できます。
警告
推論テーブルは、次のいずれかの操作を行うと破損する可能性があります。
テーブル スキーマを変更します。
テーブル名を変更します。
テーブルを削除します。
Unity Catalog カタログまたはスキーマに対するアクセス許可を失います。
この場合、エンドポイント ステータスの auto_capture_config には、ペイロード テーブルの FAILED 状態が表示されます。 このような場合は、推論テーブルを引き続き使用するには、新しいエンドポイントを作成する必要があります。
エンドポイントの作成時に推論テーブルを有効にするには、次の手順を使用します。
Databricks Mosaic AI UI で [サービス] をクリックします。
[ 配信エンドポイントを作成] をクリックします。
[ 推論テーブルを有効にする] を選択します。
ドロップダウンメニューで、テーブルを配置する目的のカタログとスキーマを選択します。
デフォルトのテーブル名は
<catalog>.<schema>.<endpoint-name>_payloadです。 必要に応じて、カスタムテーブル接頭辞を入力できます。[ 配信エンドポイントを作成] をクリックします。
また、既存のエンドポイントで推論テーブルを有効にすることもできます。 既存のエンドポイント設定を編集するには、次の手順を実行します。
エンドポイント ページに移動します。
「 構成の編集」をクリックします。
ステップ 3 から始まる上記の手順に従います。
完了したら、[ 配信エンドポイントの更新] をクリックします。
次の手順に従って、推論テーブルを無効にします。
エンドポイント ページに移動します。
「 構成の編集」をクリックします。
[ 推論テーブルを有効にする ] をクリックして、チェックマークを外します。
エンドポイントの仕様に問題がなければ、[ Update] をクリックします。
ワークフロー: 推論テーブルを使用したモデルのパフォーマンスの監視
推論テーブルを使用してモデルのパフォーマンスを監視するには、次の手順に従います。
エンドポイントで 推論テーブル を有効にするには、エンドポイントの作成時または後で更新します。
エンドポイントのスキーマに従って JSON ペイロードをアンパックすることで、推論テーブル内の JSON ペイロードを処理するワークフローをスケジュールします。
(オプション)アンパックされた要求と応答をグラウンドトゥルースラベルで結合して、モデル品質メトリクスを計算できるようにします。
結果の Delta テーブルに対してモニターを作成し、メトリクスを更新します。
スターター ノートブックは、このワークフローを実装します。
推論テーブルを使ったモニタリングの入門用ノートブック
次のノートブックは、レイクハウスモニタリング推論テーブルからのリクエストを解凍するために、上で概説したステップを実装します。 ノートブックは、オンデマンドで実行することも、 Databricks Jobsを使用して定期的なスケジュールで実行することもできます。
LLMを提供するエンドポイントからのテキスト品質をモニタリングするための入門用ノートブック
次のノートブックは、推論テーブルからのリクエストを解凍し、一連のテキスト評価メトリクス (可読性や有害性など) をコンピュートし、これらのメトリクスのモニタリングを可能にします。 ノートブックは、オンデマンドで実行することも、 Databricks Jobsを使用して定期的なスケジュールで実行することもできます。
推論テーブルの結果のクエリーと分析
提供されるモデルの準備が整うと、モデルに対して行われたすべてのリクエストが、応答とともに推論テーブルに自動的に記録されます。 UI でテーブルを表示したり、DBSQL またはノートブックからテーブルをクエリーしたり、REST API を使用してテーブルをクエリーしたりできます。
UI でテーブルを表示するには、次のようにします。 エンドポイントページで、推論テーブルの名前をクリックして、カタログエクスプローラーでテーブルを開きます。
![[エンドポイント] ページの推論テーブル名へのリンク](../../_images/inference-table-name.png)
DBSQLまたはDatabricksノートブックからテーブルをクエリー実行するには、次のようにします。 次のようなコードを実行して、推論テーブルをクエリーできます。
SELECT * FROM <catalog>.<schema>.<payload_table>
UI を使用して推論テーブルを有効にした場合、 payload_table はエンドポイントの作成時に割り当てたテーブル名です。 API を使用して推論テーブルを有効にした場合、payload_tableはauto_capture_configレスポンスの state セクションで報告されます。例については、「 API を使用してモデルサービングエンドポイントで推論テーブルを有効にする」を参照してください。
Unity Catalog推論テーブルスキーマ
推論テーブルに記録される各要求と応答は、次のスキーマを使用して Delta テーブルに書き込まれます。
注
入力のバッチを使用してエンドポイントを呼び出すと、バッチ全体が 1 行としてログに記録されます。
列名 |
説明 |
タイプ |
|---|---|---|
|
Databricks で生成された、すべてのモデルサービング要求にアタッチされた要求識別子。 |
文字列 |
|
モデルサービング要求本文で指定できるオプションのクライアント生成要求識別子。 詳細については、「 client_request_id' を指定する」 を参照してください。 |
文字列 |
|
モデルサービング要求が受信された UTC 日付。 |
日付 |
|
モデルサービング要求を受信した時点のタイムスタンプ (エポックミリ秒単位)。 |
ロング |
|
モデルから返された HTTP 状態コード。 |
INT |
|
要求がダウンサンプリングされた場合に使用されるサンプリングの割合。 この値は 0 から 1 の間で、1 は着信要求の 100% が含まれていたことを表します。 |
複 |
|
モデルが推論を実行した実行時間 (ミリ秒単位)。 これにはオーバーヘッド ネットワークの待機時間は含まれず、モデルが予測を生成するのにかかった時間のみを表します。 |
ロング |
|
モデルサービング エンドポイントに送信された未加工の要求 JSON 本文。 |
文字列 |
|
モデルサービング エンドポイントによって返された生の応答 JSON 本文。 |
文字列 |
|
要求に関連付けられているモデルサービング エンドポイントに関連するメタデータのマップ。 このマップには、エンドポイント名、モデル名、およびエンドポイントに使用されるモデル バージョンが含まれています。 |
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>を実行します。推論テーブルのログ配信は現在ベストエフォートですが、リクエストから 1 時間以内にログが利用可能になることが期待できます。 詳細については、 Databricks アカウントチームにお問い合わせください。
一般的なモデルサービング エンドポイントの制限については、 「モデルサービングの制限とリージョン」を参照してください。