Databricksレイクハウスモニタリングで高品質な予測を確保する

July 18, 2024 in プラットフォームブログ

Share this post

予測モデルは、多くの企業が将来のトレンドを予測するために重要ですが、その精度は入力データの品質に大きく依存します。データの品質が低いと、予測が不正確になり、最適な意思決定ができなくなる可能性があります。ここで、 Databricksレイクハウスモニタリングが登場します。これは、予測モデルに流入するデータの品質とモデルのパフォーマンス自体の両方を監視するための統合ソリューションを提供します。

モニタリングは、予測モデルにとって特に重要です。予測は時系列データを扱うため、データの時間的コンポーネントとシーケンシャルな性質により、複雑さが増します。入力データの統計的プロパティが時間の経過とともに変化するデータドリフトなどの問題は、迅速に検出および対処しないと、予測精度を大幅に低下させる可能性があります。

さらに、予測モデルのパフォーマンスは、予測値と実際の値を比較する平均絶対パーセント誤差 (MAPE) などのメトリクスによって測定されることがよくあります。ただし、グラウンドトゥルース値はすぐには利用できず、予測期間が経過した後にのみ到着します。この遅延フィードバックループにより、潜在的な問題を早期に特定するために、入力データの品質とモデル出力を積極的にモニタリングすることがさらに重要になります。

最近のデータを使用して統計予測モデルを頻繁に再トレーニングすることは一般的ですが、モニタリングはドリフトを早期に検出し、不必要な計算コストを回避するために依然として価値があります。 PatchTSTのようなディープラーニングを使用し、GPU を必要とする複雑なモデルの場合、リソースの制約により再トレーニングの頻度が低くなる可能性があり、モニタリングがさらに重要になります。

自動ハイパーチューニングを使用すると、実行全体にわたってモデルのパフォーマンスに偏りが生じ、一貫性がなくなる可能性があります。モニタリングにより、モデルのパフォーマンスが低下したタイミングを迅速に特定し、ハイパーパラメータを手動で調整したり、入力データに異常がないか調査するなどの修正アクションを実行できます。さらに、モニタリングは、モデルのパフォーマンスと計算コストの間で適切なバランスをとるのに役立ちます。自動チューニングは、特に再トレーニングサイクルごとに盲目的に実行される場合、リソースを大量に消費する可能性があります。モデルのパフォーマンスを長期にわたって監視することで、自動チューニングによって実際に大幅な改善がもたらされているのか、それとも不要なオーバーヘッドが追加されているだけなのかを判断できます。この知見により、モデルのトレーニングパイプラインを最適化できます。

Databricksレイクハウスモニタリングは、すべてのテーブルにわたるデータの統計的特性と品質を監視するために構築されていますが、モデルの入力と予測を含むモニタリング推論テーブルを介して機械学習モデルのパフォーマンスを追跡するために調整された特定の機能も含まれています。予測モデルの場合、これにより次のことが可能になります。

ベースラインと比較して、時間の経過に伴う入力フィーチャのデータドリフトをモニタリングする
予測ドリフトと予測の分布の追跡
実績値が利用可能になったときの MAPE、バイアスなどのモデルパフォーマンスメトリクスの測定
データ品質またはモデルのパフォーマンスが低下した場合のアラートの設定

Databricks での予測モデルの作成

予測モデルを監視する方法について説明する前に、Databricks プラットフォームで予測モデルを開発する方法について簡単に説明します。 Databricks 、時系列予測モデルを含む機械学習モデルを大規模に構築、トレーニングし、デプロイするための統合環境を提供します。

予測を生成するために使用できる一般的なライブラリやテクニックがいくつかあります。たとえば、次のとおりです。

Prophet : 使いやすく調整しやすい時系列予測用のオープンソースライブラリ。季節的な影響が強いデータの処理に優れており、外れ値を平滑化することで乱雑なデータにもうまく対応します。 Prophet のシンプルで直感的な API により、専門家以外の人でも利用できます。 PySpark を使用すると、クラスター全体で Prophet モデルのトレーニングを並列化し、製品と店舗の組み合わせごとに何千ものモデルを構築できます。ブログ
ARIMA/SARIMA: 時系列予測のための古典的な統計手法。 ARIMA モデルは、データ内の自己相関を記述することを目的としています。 SARIMA は ARIMA を拡張して季節性をモデル化します。最近のベンチマーク調査では、SARIMAは他のアルゴリズムと比較して、小売売上高データで優れたパフォーマンスを示しました。ブログ

予測を生成するための Prophet や ARIMA/SARIMA などの一般的なライブラリに加えて、Databricks は予測用のAutoMLも提供しています。 AutoML 、アルゴリズムの選択、ハイパーチューニング、分散トレーニングなどのタスクを自動的に処理することで、予測モデルの作成プロセスを簡素化します。 AutoML を使用すると、次のことが可能になります。

ユーザーフレンドリーなUIを通じてベースライン予測モデルとノートブックを素早く生成
ProphetやAuto-ARIMAなどの複数のアルゴリズムを内部で活用
Sparkを使用して、データの準備、モデルのトレーニングとチューニング、分散計算を自動的に処理します。

AutoMLを使用して作成されたモデルを、エクスペリメント追跡のためのMLflowと、デプロイとモニタリングのためのDatabricksモデルサービングと簡単に統合できます。生成されたノートブックは、カスタマイズして本番運用ワークフローに組み込むことができるコードを提供します。

モデル開発ワークフローを効率化するには、機械学習ライフサイクル用のオープンソースプラットフォームであるMLflow を活用できます。 MLflow 、 Prophet 、 ARIMA 、およびその他のモデルをすぐに使用できるようにサポートし、時系列エクスペリメントに最適なエクスペリメントトラッキングを可能にし、各種、メトリクス、およびアーティファクトのロギングを可能にします。これによりモデルのデプロイが簡素化され、再現性が促進されますが、レイクハウスモニタリングではMLflowの使用はオプションです。MLflow を使用せずにモデルをデプロイしても、レイクハウスモニタリングは引き続きモデルを追跡できます。

トレーニング済みの予測モデルを作成したら、ユースケースに応じて推論のためにデプロイする方法に柔軟性を持たせることができます。今後予測の場合、 Databricksモデルサービングを使用して、わずか数行のコードでモデルを低遅延RESTエンドポイントとしてデプロイできます。モデルがリアルタイム推論用にデプロイされると、Databricks は入力機能と予測を推論ログテーブルと呼ばれる管理された Delta テーブルに自動的に記録します。このテーブルは、レイクハウスモニタリングを使用して本番運用でモデルをモニタリングするための基盤として機能します。

しかし、予測モデルは、スケジュールに従って予測が生成されるバッチスコアリングシナリオで使用されることが多い（例：翌日の予報を毎晩生成します)。この場合、データのバッチに対してモデルにスコアを付け、その結果を Delta テーブルに記録する別のパイプラインを構築できます。モデルを Databricks クラスターに直接ロードし、そこでデータのバッチにスコアを付ける方がコスト効率が高くなります。このアプローチにより、 API背後にモデルをデプロイし、複数の場所でコンピュートリソースを支払うオーバーヘッドが回避されます。ログに記録されたバッチ予測のテーブルは、引き続き推論テーブルと同じようにレイクハウスモニタリングを使用して監視できます。

予測モデルにリアルタイム推論とバッチ推論の両方が必要な場合は、リアルタイムのユースケースにモデルサービングを使用し、バッチスコアリングのためにモデルをクラスターに直接ロードすることを検討できます。このハイブリッドアプローチにより、必要な機能を提供しながらコストを最適化します。 Lakeviewダッシュボードを活用して、インタラクティブな視覚化を構築し、予測レポートに関する知見を共有できます。電子メールの購読を設定して、スケジュールに従ってダッシュボードのスナップショットを自動的に送信することもできます。

どちらのアプローチを選択した場合でも、モデルの入力と出力を標準化された Delta テーブル形式で保存することで、データドリフトを監視し、予測の変化を追跡し、時間の経過に伴う精度を測定することが容易になります。この可視性は、本番運用において信頼性の高い予測パイプラインを維持するために非常に重要です。

Databricksで時系列予測モデルを構築してデプロイする方法を説明したので、レイクハウスモニタリングを使用して時系列予測モデルをモニタリングする重要な側面を見ていきましょう。

データドリフトの監視とパフォーマンスのモデル化

本番運用において予測モデルが引き続き良好なパフォーマンスを発揮できるようにするには、入力データとモデル予測の両方を監視して潜在的な問題がないか確認することが重要です。 Databricksレイクハウスモニタリングを使用すると、入力特徴量テーブルと推論ログテーブルにモニターを作成できるため、これが簡単になります。レイクハウスモニタリングは、データを管理および監視するための統一された方法としてUnity Catalog上に構築されており、ワークスペースでUnity Catalogを有効にする必要があります。

推論プロファイルモニタの作成

予測モデルを監視するには、モデルの入力特徴、予測、およびオプションでグラウンドトゥルースラベルを含む推論プロファイルモニターをテーブルに作成します。 Databricks UI または Python API を使用してモニターを作成できます。

UI で推論テーブルに移動し、「品質」タブをクリックします。「開始する」をクリックし、モニターの種類として「推論プロファイル」を選択します。次に、次のキーを構成します。

問題の種類: 予測モデルの回帰を選択します
タイムスタンプ列: 各予測のタイムスタンプを含む列。これは推論のタイムスタンプであり、データ自体のタイムスタンプではありません。
予測列: モデルの予測値を含む列
ラベル列 (オプション): 実際の値を含む列。これは、実績が到着したときに後で入力できます。
モデル ID 列: 各予測を行ったモデルバージョンを識別する列
粒度: メトリクスを集計するための時間枠。例: 毎日または毎週

オプションで、次の項目も指定できます。

トレーニングセットのような参照データを含むベースラインテーブル。データドリフトを比較するために使用します。
異なる製品カテゴリなど、監視するデータのサブセットを定義するスライス式
SQL式で定義された、計算するカスタムメトリクス
更新スケジュールを設定する

Python REST APIを使用すると、次のようなコードで同等のモニターを作成できます。

databricks.sdk から WorkspaceClient をインポートします
databricks.sdk.service.catalog から MonitorInferenceLog をインポート、
モニター推論ログ問題タイプ、モニターメトリック、モニターメトリックタイプ
PySpark .sqlからtypesをTとしてインポートします

w = ワークスペースクライアント()

 w.quality_monitors.create() 関数は、
 table_name=f"{catalog}です。{schema}です。{table_name}", inference_log=MonitorInferenceLog(
        timestamp_col="ts",
        model_id_col="model_version", 
        prediction_col="予測",
        label_col="actual",
        problem_type=MonitorInferenceLogProblemType.PROBLEM_TYPE_REGRESSION、
        granularities=["1日", "1週間"]
    ),
    output_schema_name=f"{catalog}です。{schema}", assets_dir= f"/ワークスペース/Users/{user_email}/databricks_lakehouse
モニタリング/{catalog}.{schema}.{table_name}",
 ベースラインテーブル="my_training_table",
 slicing_exprs=["製品"],
カスタムメトリック=[
モニターメトリック(
タイプ=MonitorMetricType.CUSTOM_METRIC_TYPE_AGGREGATE、
 name="許容範囲内のパーセント",
 input_columns=[":テーブル"],
定義="100.0 * 合計(絶対値(予測値 - 実測値)の場合) /
実際 <= 0.1 の場合は 1、それ以外の場合は 0 終了) / count(*)"
 output_data_type=T.StructField("output", T.DoubleType()) JSON (),
 ）、
モニターメトリック(
タイプ=MonitorMetricType.CUSTOM_METRIC_TYPE_AGGREGATE、
名前="weighted_mae",
 input_columns=[":テーブル"],
定義="sum(abs(予測 - 実績) * 製品) /
製品
output_data_type=T.StructField("output", T.DoubleType()) JSON (),
 ）、
モニターメトリック(
タイプ=MonitorMetricType.CUSTOM_METRIC_TYPE_AGGREGATE、
名前="qoq_pct_change",
 input_columns=[":テーブル"],
定義="""
 (sum(case when extract(quarter from ts) = extract(quarter
 current_timestampから)およびextract(year from ts) = extract(
年（current_timestamp から）実際、それ以外は 0 終了）/
 nullif(sum(case when extract(quarter from ts) = extract(
四半期から現在のタイムスタンプ) - 1 を抽出し、年を抽出します
ts) = (現在のタイムスタンプから年を抽出) then 実際の値 else
 0 終了）、0） - 1） * 100
 「」
 output_data_type=T.StructField("output", T.DoubleType()) JSON (),
 ),
    ] 
)

ベースラインテーブルは、本番運用データと比較するための、モデルのトレーニングデータなどの参照データセットを含むオプションのテーブルです。繰り返しになりますが、予測モデルの場合、モデルは頻繁に再トレーニングされるため、モデルが頻繁に変更されるため、ベースラインの比較は必要ないことがよくあります。以前の時間枠との比較を行うことができ、ベースラインの比較が必要な場合は、ハイパーチューニングや実績値の更新など、より大きな更新がある場合にのみベースラインを更新します。

予測におけるモニタリングは、再トレーニングの頻度が毎週や毎月など事前に設定されているシナリオでも役立ちます。このような場合でも、予測メトリクスが実績から逸脱したり、実績が予測と一致しなくなったりしたときに、例外ベースの予測管理を行うことができます。これにより、基になる時系列を再診断する必要があるかどうか (再トレーニングの正式な予測言語であり、計量経済学モデルを使用する場合にトレンド、季節性、周期性が個別に識別されます)、または個々の偏差を異常または外れ値として分離できるかどうかを判断できます。後者の場合、再診断はしませんが、偏差を外れ値としてマークし、将来、カレンダーイベントまたは外生変数をモデルにアタッチする可能性があります。

レイクハウスモニタリングは、入力特徴の統計的プロパティを長期にわたって自動的に追跡し、ベースラインまたは以前の時間枠と比較して重大なドリフトが検出された場合はアラートを追跡します。これにより、予測の精度を低下させる可能性のあるデータ品質の問題を特定できます。例えば：

売上高などの主要な入力機能の分布を監視します。突然のシフトがある場合は、予測精度を低下させる可能性のあるデータ品質の問題を示している可能性があります。
欠損値または外れ値の数を追跡します。最近の期間の欠落データの増加は、予測を歪める可能性があります。

安心メトリクスに加えて、 SQL式を使用してカスタムメトリクスを定義し、ビジネス固有のロジックや複雑な比較をキャプチャできます。予測に関連する例をいくつか示します。

季節や年をまたいだメトリクスの比較。例: 現在の四半期と前年同期の平均売上高の差の計算
予測される項目に基づいて誤差の重み付けが異なる (例: 高価値製品のエラーに対する罰則を強化する
許容誤差許容範囲内の予測の割合を追跡する

カスタムメトリクスには次の 3 つのタイプがあります。

推論テーブルの列から計算された集計メトリクス
他の集計メトリクスから計算された派生メトリクス
時間枠全体またはベースラインと集計または派生メトリクスを比較するドリフトメトリクス

これらのカスタムメトリクスの例は、上記のPython API例に示されています。特定の予測ユースケースに合わせてカスタマイズされたカスタムメトリックを組み込むことで、モデルのパフォーマンスとデータ品質に関するより深く関連性の高い知見を得ることができます。

重要な考え方は、モデルの入力特徴、予測、およびグラウンドトゥルースラベルを 1 つの推論ログテーブルにまとめることです。レイクハウスモニタリングは、データのドリフト、予測のドリフト、パフォーマンスメトリクスを時間の経過とともに指定したディメンションごとに自動的に追跡します。

予測モデルがの外部で提供されている場合は、リクエストDatabricks ETLDeltaログをテーブルに、それにモニタリングを適用できます。これにより、外部モデルであってもモニタリングを一元化できます。

時系列モニターまたは推論プロファイルモニターを初めて作成するときは、モニターの作成前の 30 日間のデータのみが分析されることに注意してください。このカットオフにより、最初の解析ウィンドウは部分的になる場合があります。たとえば、30 日の制限が週または月の半ばに当たる場合、週全体または月全体は含まれません。

この 30 日間のルックバック制限は、モニターが作成されたときの初期ウィンドウにのみ影響します。その後、推論テーブルに流入するすべての新しいデータは、指定された粒度に従って完全に処理されます。

メトリクスを更新するためのモニターの更新

予測モデルの推論プロファイルモニターを作成した後は、定期的に更新して、メトリックを最新のデータに更新する必要があります。モニターを更新すると、推論ログテーブルの現在の内容に基づいて、プロファイルテーブルとドリフトメトリックテーブルが再計算されます。次の場合にはモニターを更新する必要があります。

新しい予測はモデルからログに記録されます
以前の予測には実際の値が追加されます
推論テーブルスキーマの変更 (新しい機能列の追加など)
カスタムメトリクスを追加するなど、モニター設定を変更する

モニターを更新するには、スケジュールに従って更新する方法と手動で更新する方法の 2 つがあります。

更新スケジュールを設定するには、UI またはPython APIを使用してモニターを作成するときにスケジュールを指定します。

databricks.sdk から WorkspaceClient をインポートします
databricks.sdk.service.catalog から MonitorInferenceLog をインポート、
モニター推論ログ問題タイプ、モニターCronSchedule

 w = ワークスペースクライアント()

 w.quality_monitors.create() 関数は、
 table_name=f"{catalog}です。{schema}です。{table_name}", inference_log=MonitorInferenceLog(...)、
    schedule=MonitorCronSchedule(quartz_cron_expression="0 0 * * *") 
    #毎日深夜
    skip_builtin_dashboard=False # ダッシュボードが
    作成済み
    output_schema_name=f"{catalog}です。{schema}", assets_dir= f"/ワークスペース/Users/{user_email}/databricks_lakehouse
モニタリング/{catalog}.{schema}.{table_name}",
)

`CronSchedule` を使用すると、毎日、毎時間などの更新頻度を定義する cron 式を指定できます。「skip_builtin_dashboard」をTrueに設定すると、モニターの新しいダッシュボードの生成がスキップされます。これは、ダッシュボードを既に作成している場合や、ダッシュボードに保持したいカスタムグラフがあり、新しいグラフが必要ない場合に特に便利です。

あるいは、UI または Python API を使用してモニターを手動で更新することもできます。 Databricks UI で、推論テーブルの [品質] タブに移動し、モニターを選択して、[メトリクスを更新] をクリックします。

Python API を使用すると、モデルの再トレーニング後など、アクション駆動型になるようにモニターを更新するパイプラインを作成できます。ノートブックのモニターを更新するには、実行関数を使用します。

databricks.sdk から WorkspaceClient をインポートします

w = ワークスペースクライアント()

 w.quality_monitors.実行(
 table_name=f"{catalog}です。{schema}です。{table_name}")

これにより、サーバーレスジョブが送信され、モニターのメトリクステーブルが更新されます。バックグラウンドで更新が実行されている間も、ノートブックを引き続き使用できます。

更新が完了すると、 SQL使用して、更新されたプロファイルとドリフトメトリクステーブルをクエリできます。ただし、生成されたダッシュボードは個別に更新されることに注意してください。これは、DBSQL ダッシュボード自体の「更新」ボタンをクリックすることで実行できます。同様に、ダッシュボードで「更新」をクリックしても、モニターの計算はトリガーされません。代わりに、ダッシュボードが視覚化を生成するために使用するメトリクステーブルに対してクエリを実行します。ダッシュボードに表示される視覚化を作成するために使用されるテーブル内のデータを更新するには、モニターを更新してからダッシュボードを更新する必要があります。

モニタリングの出力を理解する

予測モデルの推論プロファイルモニターを作成すると、レイクハウスモニタリングは、データドリフト、モデルのパフォーマンス、パイプラインの全体的な健全性を追跡するのに役立ついくつかの重要な資産を生成します。

プロファイルとドリフトのメトリクステーブル

レイクハウスモニタリングは 2 つの主要なメトリクステーブルを作成します。

プロファイルメトリクステーブル: 時間枠とスライスごとにグループ化された、各特徴列と予測の概要統計が含まれます。予測モデルの場合、これには次のようなメトリクスが含まれます。
- 数値列の count、mean、stddev、min、max
- count、null の数、categorical 列の個別の値の数
- 予測列の count、mean、stddev、min、max
ドリフトメトリクステーブル: ベースラインと比較して、データと予測分布の変化を経時的に追跡します。予測のための主要なドリフトメトリクスには次のものがあります。
- 数値列の場合は Wasserstein 距離 (分布形状の違いを測定し、予測列の場合は予測分布のシフトを検出します)
- カテゴリカル列のJensen-Shannon発散、確率分布間の差の定量化

次のような特定の質問を調査するために、SQL を使用して直接クエリを実行できます。

平均的な予測はどのくらいで、前週比でどのように変化しましたか?
製品カテゴリー間でモデルの精度に違いはありますか?
昨日の主要な入力機能とトレーニングデータには、欠損値がいくつありましたか?

モデルパフォーマンスダッシュボード

メトリクステーブルに加えて、レイクハウスモニタリングは、予測モデルのパフォーマンスを経時的に視覚化するためのインタラクティブなダッシュボードを自動的に生成します。ダッシュボードには、いくつかの主要なコンポーネントが含まれています。

モデルパフォーマンスパネル: MAPE、RMSE、バイアスなど、予測モデルの主要な精度メトリクスを表示します。これらのメトリクスは、予測値と実際の値を比較することによって計算され、遅延して提供されることもあります（例： daily actuals for a daily forecast) です。パネルには、メトリクスが時間の経過とともに、製品カテゴリや地域などの重要なスライスごとに表示されます。
ドリフトメトリクスパネル: 選択した特徴と予測列のドリフトメトリクスを経時的に視覚化します。
データ品質パネル: 欠損値の割合、NAS の割合、カウント、平均、最小値、最大値などのさまざまな統計、および時間の経過に伴う数値機能とカテゴリ機能の両方のその他のデータ異常などのさまざまなメトリックを表示します。これにより、予測精度を低下させる可能性のあるデータ品質の問題をすばやく見つけることができます。

ダッシュボードは高度にインタラクティブで、時間範囲でフィルタリングしたり、特定の機能やスライスを選択したり、個々のメトリックにドリルダウンしたりできます。ダッシュボードは、多くの場合、作成後にカスタマイズされ、組織が見慣れているビューやグラフが含まれます。ダッシュボードで使用されるクエリはカスタマイズして保存することができ、任意のビューから「クエリの表示」をクリックしてから「アラートの作成」をクリックすることでアラートを追加できます。本稿執筆時点では、ダッシュボード用にカスタマイズされたテンプレートはサポートされていません。

これはdata scientistsモデルのパフォーマンスをデバッグするのにも、ビジネス関係者が予測の信頼を維持するのにも役立つ貴重なツールです。

正確さのために実績を活用するモニタリング

MAPE のようにモデルパフォーマンスメトリクスを計算するには、モニタリングシステムが各予測の実際の値にアクセスする必要があります。ただし、予測では、多くの場合、予測が行われてからしばらく経つまで実績を使用できません。

1 つの戦略は、実際の値が利用可能になったときに推論ログテーブルに実際の値を追加する別のパイプラインを設定し、その後モニターを更新してメトリクスを更新することです。たとえば、毎日の予測を生成する場合、前日の予測の実際の値を追加するために毎晩実行されるジョブを作成できます。

実績をキャプチャし、モニターを定期的に更新することで、予測精度を経時的に追跡し、パフォーマンスの低下を早期に特定できます。これは、予測パイプラインの信頼性を維持し、情報に基づいたビジネス上の意思決定を行うために非常に重要です。

さらに、実績と予測を個別にモニタリングすることで、強力な例外管理機能が可能になります。例外管理は、需要計画で一般的な手法であり、期待される結果からの大幅な逸脱を事前に特定して解決します。メトリクス上で予測精度やバイアスなどのアラートを設定すると、モデルのパフォーマンスが低下した時期をすぐに特定し、モデルの調整や入力データの異常の調査などの修正措置を講じることができます。

レイクハウスモニタリングは、主要なメトリクスを自動的に追跡し、カスタマイズ可能なアラートを提供することで、例外管理を簡単にします。プランナーは、山のようなデータをふるいにかけるのではなく、最も影響力のある例外に注意を向けることができます。この的を絞ったアプローチにより、効率が向上し、最小限の手動介入で高い予測品質を維持できます。

要約すると、レイクハウスモニタリングは、本番運用で予測モデルをモニタリングするための包括的なツールセットを提供します。生成されたメトリクステーブルとダッシュボードを活用することで、データ品質の問題をプロアクティブに検出し、モデルのパフォーマンスを追跡し、ドリフトを診断し、ビジネスに影響が出る前に例外を管理することができます。製品、地域、時間などのディメンションにわたってメトリックを細分化できるため、問題の根本原因をすばやく特定し、予測の健全性と精度を維持するための的を絞ったアクションを実行できます。

モデルメトリクスにアラートを設定する

予測モデルに推論プロファイルモニターを設定したら、主要なメトリックに対してアラートを定義して、ビジネス上の意思決定に影響する前に問題を事前に特定できます。 DatabricksレイクハウスモニタリングはDatabricks SQLと統合されており、生成されたプロファイルとドリフトメトリクステーブルに基づいてアラートを作成できるようになります。

予測モデルのアラートを設定する一般的なシナリオには、次のようなものがあります。

ローリング 7 日間の平均予測誤差 (MAPE) が 10% を超えた場合はアラート。これは、モデルが正確でなくなり、再トレーニングが必要になる可能性があることを示している可能性があります。
アラートは、キー入力特徴の欠損値の数がトレーニングデータと比較して大幅に増加した場合に発生します。データが欠落していると、予測が歪む可能性があります。
特徴の分布がベースラインに対してしきい値を超えた場合に通知します。これは、データ品質の問題を示しているか、新しいデータパターンに合わせてモデルを更新する必要があることを示している可能性があります。
過去 24 時間に新しい予測が記録されなかった場合はアラート。これは、推論パイプラインが失敗し、注意が必要であることを意味している可能性があります。
モデルのバイアス (平均誤差) が一貫して正または負であるかどうかを示します。これは、モデルが体系的に予測を上回っているか、または下回っていることを示している可能性があります。

ダッシュボードのビューを構築するためにすでに生成された組み込みクエリがあります。アラートを作成するには、プロファイルまたはドリフトメトリクステーブルから監視するメトリクスを計算するSQLクエリに移動します。次に、 Databricks SQLクエリエディターで [アラートの作成] をクリックし、MAPE が 0.1 を超えたときにトリガーするなどのアラート条件を構成します。アラートを1時間ごとや毎日などのスケジュールで実行するように設定したり、通知の受信方法を指定したりすることができます（例：電子メール、Slack、PagerDuty)。

安心メトリクスのアラートに加えて、カスタムSQLクエリを記述して、特定のユースケースに合わせてオーダーメイドのメトリクスを計算できます。たとえば、高価値製品の MAPE が低価値製品とは異なるしきい値を超えた場合にアラートを発したい場合があります。プロファイルメトリクスを製品テーブルと結合して、MAPE 計算をセグメント化することができます。

重要なのは、すべての特徴データと予測データがメトリクステーブルで利用できるため、 SQL柔軟に作成してビジネスにとって意味のあるカスタムメトリクスを定義できることです。その後、同じプロセスを使用して、これらのカスタムメトリクスの上にアラートを作成できます。

予測モデルメトリクスにターゲットを絞ったアラートを設定すると、手動モニタリングなしでそのパフォーマンスを常に把握できます。アラートを使用すると、異常に迅速に対応し、モデルの予測に対する信頼を維持できます。レイクハウスモニタリングによって可能になる多次元分析と組み合わせることで、問題を効率的に診断して解決し、予測の品質を高く保つことができます。

レイクハウスモニタリング費用の監視

予測モデルに特有のものではありませんが、レイクハウスモニタリング自体の使用状況と費用を追跡する方法を理解することが重要です。レイクハウスモニタリングの使用を計画する場合、適切な予算を立てるために関連コストを理解することが重要です。レイクハウスモニタリングジョブはサーバレスコンピュートインフラ上で実行されるため、クラスターを自分で管理する必要はありません。レイクハウスモニタリングのコストを見積もるには、次のステップに従ってください。

作成する予定のモニターの数と頻度を決定します。各モニターはスケジュールに従って実行され、メトリクスを更新します。
モニターのデータ量と SQL 式の複雑さを見積もります。データサイズが大きく、クエリが複雑になると、より多くの DBU が消費されます。
層とクラウド DBUプロバイダーに基づいて、サーバーレスワークロードのレートを調べます。Databricks
推定 DBU に該当するレートを乗じて、レイクハウスモニタリングの推定コストを算出します。

実際のコストは、特定のモニター定義とデータによって異なり、時間の経過とともに変化する可能性があります。 Databricks 、 SQLハウスモニタリングコストを監視する 2 つの方法を提供します。SQL クエリを使用する方法と、請求ポータルを使用する方法です。詳細については、 https://docs.databricks.com/ja/lakehouse-monitoring/expense.htmlを参照してください。

Databricksレイクハウスモニタリングを使用して予測モデルのモニタリングを開始する準備はできていますか? まずは無料トライアルにサインアップしてください。すでに Databricks の顧客ですか? 当社のドキュメントをチェックして、今すぐ最初の推論プロファイルモニターを設定してください。

Databricks 無料トライアル

使ってみる

Simplify Your Forecasting With Databricks AutoML

February 9, 2022 ジャスティン・キム、Lu Wang による投稿 in エンジニアリングのブログ

Last year, we announced Databricks AutoML for Classification and Regression and showed the importance of having a glass box approach to empower data...

プラットフォームブログ一覧へ