予測モデルは、多くの企業が将来のトレンドを予測するために重要ですが、その精度は入力データの品質に大きく依存します。 データの品質が低いと、予測が不正確になり、最適な意思決定ができなくなる可能性があります。 ここで、 Databricksレイクハウスモニタリングが登場します。これは、予測モデルに流入するデータの品質とモデルのパフォーマンス自体の両方を監視するための統合ソリューションを提供します。
モニタリングは、予測モデルにとって特に重要です。 予測は時系列データを扱うため、データの時間的コンポーネントとシーケンシャルな性質により、複雑さが増します。 入力データの統計的プロパティが時間の経過とともに変化するデータ ドリフトなどの問題は、迅速に検出および対処しないと、予測精度を大幅に低下させる可能性があります。
さらに、予測モデルのパフォーマンスは、予測値と実際の値を比較する平均絶対パーセント誤差 (MAPE) などのメトリクスによって測定されることがよくあります。 ただし、グラウンド トゥルース値はすぐには利用できず、予測期間が経過した後にのみ到着します。 この遅延フィードバック ループにより、潜在的な問題を早期に特定するために、入力データの品質とモデル出力を積極的にモニタリングすることがさらに重要になります。
最近のデータを使用して統計予測モデルを頻繁に再トレーニングすることは一般的ですが、モニタリングはドリフトを早期に検出し、不必要な計算コストを回避するために依然として価値があります。 PatchTSTのようなディープラーニングを使用し、GPU を必要とする複雑なモデルの場合、リソースの制約により再トレーニングの頻度が低くなる可能性があり、モニタリングがさらに重要になります。
自動ハイパーチューニングを使用すると、実行全体にわたってモデルのパフォーマンスに偏りが生じ、一貫性がなくなる可能性があります。 モニタリングにより、モデルのパフォーマンスが低下したタイミングを迅速に特定し、ハイパーパラメータを手動で調整したり、入力データに異常がないか調査するなどの修正アクションを実行できます。 さらに、モニタリングは、モデルのパフォーマンスと計算コストの間で適切なバランスをとるのに役立ちます。 自動チューニングは、特に再トレーニング サイクルごとに盲目的に実行される場合、リソースを大量に消費する可能性があります。 モデルのパフォーマンスを長期にわたって監視することで、自動チューニングによって実際に大幅な改善がもたらされているのか、それとも不要なオーバーヘッドが追加されているだけなのかを判断できます。 この知見により、モデルのトレーニング パイプラインを最適化できます。
Databricksレイクハウスモニタリングは、すべてのテーブルにわたるデータの統計的特性と品質を監視するために構築されていますが、モデルの入力と予測を含むモニタリング推論テーブルを介して機械学習モデルのパフォーマンスを追跡するために調整された特定の機能も含まれています。 予測モデルの場合、これにより次のことが可能になります。
予測モデルを監視する方法について説明する前に、Databricks プラットフォームで予測モデルを開発する方法について簡単に説明します。 Databricks 、時系列予測モデルを含む機械学習モデルを大規模に構築、トレーニングし、デプロイするための統合環境を提供します。
予測を生成するために使用できる一般的なライブラリやテクニックがいくつかあります。たとえば、次のとおりです。
予測を生成するための Prophet や ARIMA/SARIMA などの一般的なライブラリに加えて、Databricks は予測用のAutoMLも提供しています。 AutoML 、アルゴリズムの選択、ハイパーチューニング、分散トレーニングなどのタスクを自動的に処理することで、予測モデルの作成プロセスを簡素化します。 AutoML を使用すると、次のことが可能になります。
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 で推論テーブルに移動し、「品質」タブをクリックします。 「開始する」をクリックし、モニターの種類として「推論プロファイル」を選択します。 次に、次のキーを構成します。
オプションで、次の項目も指定できます。
Python REST APIを使用すると、次のようなコードで同等のモニターを作成できます。
ベースライン テーブルは、本番運用データと比較するための、モデルのトレーニング データなどの参照データセットを含むオプションのテーブルです。 繰り返しになりますが、予測モデルの場合、モデルは頻繁に再トレーニングされるため、モデルが頻繁に変更されるため、ベースラインの比較は必要ないことがよくあります。 以前の時間枠との比較を行うことができ、ベースラインの比較が必要な場合は、ハイパーチューニングや実績値の更新など、より大きな更新がある場合にのみベースラインを更新します。
予測におけるモニタリングは、再トレーニングの頻度が毎週や毎月など事前に設定されているシナリオでも役立ちます。 このような場合でも、予測メトリクスが実績から逸脱したり、実績が予測と一致しなくなったりしたときに、例外ベースの予測管理を行うことができます。 これにより、基になる時系列を再診断する必要があるかどうか (再トレーニングの正式な予測言語であり、計量経済学モデルを使用する場合にトレンド、季節性、周期性が個別に識別されます)、または個々の偏差を異常または外れ値として分離できるかどうかを判断できます。 後者の場合、再診断はしませんが、偏差を外れ値としてマークし、将来、カレンダー イベントまたは外生変数をモデルにアタッチする可能性があります。
レイクハウスモニタリングは、入力特徴の統計的プロパティを長期にわたって自動的に追跡し、ベースラインまたは以前の時間枠と比較して重大なドリフトが検出された場合はアラートを追跡します。 これにより、予測の精度を低下させる可能性のあるデータ品質の問題を特定できます。 例えば:
安心メトリクスに加えて、 SQL式を使用してカスタム メトリクスを定義し、ビジネス固有のロジックや複雑な比較をキャプチャできます。 予測に関連する例をいくつか示します。
カスタム メトリクスには次の 3 つのタイプがあります。
これらのカスタム メトリクスの例は、上記のPython API例に示されています。 特定の予測ユースケースに合わせてカスタマイズされたカスタム メトリックを組み込むことで、モデルのパフォーマンスとデータ品質に関するより深く関連性の高い知見を得ることができます。
重要な考え方は、モデルの入力特徴、予測、およびグラウンド トゥルース ラベルを 1 つの推論ログ テーブルにまとめることです。 レイクハウスモニタリングは、データのドリフト、予測のドリフト、パフォーマンス メトリクスを時間の経過とともに指定したディメンションごとに自動的に追跡します。
予測モデルが の外部で提供されている場合は、リクエストDatabricks ETLDeltaログを テーブルに 、それに モニタリング を適用できます。これにより、外部モデルであってもモニタリングを一元化できます。
時系列モニターまたは推論プロファイルモニターを初めて作成するときは、モニターの作成前の 30 日間のデータのみが分析されることに注意してください。 このカットオフにより、最初の解析ウィンドウは部分的になる場合があります。 たとえば、30 日の制限が週または月の半ばに当たる場合、週全体または月全体は含まれません。
この 30 日間のルックバック制限は、モニターが作成されたときの初期ウィンドウにのみ影響します。 その後、推論テーブルに流入するすべての新しいデータは、指定された粒度に従って完全に処理されます。
予測モデルの推論プロファイル モニターを作成した後は、定期的に更新して、メトリックを最新のデータに更新する必要があります。 モニターを更新すると、推論ログ テーブルの現在の内容に基づいて、プロファイル テーブルとドリフト メトリック テーブルが再計算されます。 次の場合にはモニターを更新する必要があります。
モニターを更新するには、スケジュールに従って更新する方法と手動で更新する方法の 2 つがあります。
更新スケジュールを設定するには、UI またはPython APIを使用してモニターを作成するときにスケジュールを指定します。
`CronSchedule` を使用すると、毎日、毎時間などの更新頻度を定義する cron 式を指定できます。 「skip_builtin_dashboard」をTrueに設定すると、モニターの新しいダッシュボードの生成がスキップされます。 これは、ダッシュボードを既に作成している場合や、ダッシュボードに保持したいカスタムグラフがあり、新しいグラフが必要ない場合に特に便利です。
あるいは、UI または Python API を使用してモニターを手動で更新することもできます。 Databricks UI で、推論テーブルの [品質] タブに移動し、モニターを選択して、[メトリクスを更新] をクリックします。
Python API を使用すると、モデルの再トレーニング後など、アクション駆動型になるようにモニターを更新するパイプラインを作成できます。 ノートブックのモニターを更新するには、実行関数を使用します。
これにより、サーバーレス ジョブが送信され、モニターのメトリクス テーブルが更新されます。 バックグラウンドで更新が実行されている間も、ノートブックを引き続き使用できます。
更新が完了すると、 SQL使用して、更新されたプロファイルとドリフト メトリクス テーブルをクエリできます。 ただし、生成されたダッシュボードは個別に更新されることに注意してください。これは、DBSQL ダッシュボード自体の「更新」ボタンをクリックすることで実行できます。 同様に、ダッシュボードで「更新」をクリックしても、モニターの計算はトリガーされません。 代わりに、ダッシュボードが視覚化を生成するために使用するメトリクス テーブルに対してクエリを実行します。 ダッシュボードに表示される視覚化を作成するために使用されるテーブル内のデータを更新するには、モニターを更新してからダッシュボードを更新する必要があります。
予測モデルの推論プロファイル モニターを作成すると、レイクハウスモニタリングは、データ ドリフト、モデルのパフォーマンス、パイプラインの全体的な健全性を追跡するのに役立ついくつかの重要な資産を生成します。
レイクハウスモニタリングは 2 つの主要なメトリクス テーブルを作成します。
次のような特定の質問を調査するために、SQL を使用して直接クエリを実行できます。
メトリクス テーブルに加えて、レイクハウスモニタリングは、予測モデルのパフォーマンスを経時的に視覚化するためのインタラクティブなダッシュボードを自動的に生成します。 ダッシュボードには、いくつかの主要なコンポーネントが含まれています。
ダッシュボードは高度にインタラクティブで、時間範囲でフィルタリングしたり、特定の機能やスライスを選択したり、個々のメトリックにドリルダウンしたりできます。 ダッシュボードは、多くの場合、作成後にカスタマイズされ、組織が見慣れているビューやグラフが含まれます。 ダッシュボードで使用されるクエリはカスタマイズして保存することができ、任意のビューから「クエリの表示」をクリックしてから「アラートの作成」をクリックすることでアラートを追加できます。 本稿執筆時点では、ダッシュボード用にカスタマイズされたテンプレートはサポートされていません。
これはdata scientistsモデルのパフォーマンスをデバッグするのにも、ビジネス関係者が予測の信頼を維持するのにも役立つ貴重なツールです。
MAPE のようにモデル パフォーマンス メトリクスを計算するには、モニタリング システムが各予測の実際の値にアクセスする必要があります。 ただし、予測では、多くの場合、予測が行われてからしばらく経つまで実績を使用できません。
1 つの戦略は、実際の値が利用可能になったときに推論ログ テーブルに実際の値を追加する別のパイプラインを設定し、その後モニターを更新してメトリクスを更新することです。 たとえば、毎日の予測を生成する場合、前日の予測の実際の値を追加するために毎晩実行されるジョブを作成できます。
実績をキャプチャし、モニターを定期的に更新することで、予測精度を経時的に追跡し、パフォーマンスの低下を早期に特定できます。 これは、予測パイプラインの信頼性を維持し、情報に基づいたビジネス上の意思決定を行うために非常に重要です。
さらに、実績と予測を個別にモニタリングすることで、強力な例外管理機能が可能になります。 例外管理は、需要計画で一般的な手法であり、期待される結果からの大幅な逸脱を事前に特定して解決します。 メトリクス上で予測精度やバイアスなどのアラートを設定すると、モデルのパフォーマンスが低下した時期をすぐに特定し、モデルの調整や入力データの異常の調査などの修正措置を講じることができます。
レイクハウスモニタリングは、主要なメトリクスを自動的に追跡し、カスタマイズ可能なアラートを提供することで、例外管理を簡単にします。 プランナーは、山のようなデータをふるいにかけるのではなく、最も影響力のある例外に注意を向けることができます。 この的を絞ったアプローチにより、効率が向上し、最小限の手動介入で高い予測品質を維持できます。
要約すると、レイクハウスモニタリングは、本番運用で予測モデルをモニタリングするための包括的なツールセットを提供します。 生成されたメトリクス テーブルとダッシュボードを活用することで、データ品質の問題をプロアクティブに検出し、モデルのパフォーマンスを追跡し、ドリフトを診断し、ビジネスに影響が出る前に例外を管理することができます。 製品、地域、時間などのディメンションにわたってメトリックを細分化できるため、問題の根本原因をすばやく特定し、予測の健全性と精度を維持するための的を絞ったアクションを実行できます。
予測モデルに推論プロファイル モニターを設定したら、主要なメトリックに対してアラートを定義して、ビジネス上の意思決定に影響する前に問題を事前に特定できます。 DatabricksレイクハウスモニタリングはDatabricks SQLと統合されており、生成されたプロファイルとドリフト メトリクス テーブルに基づいてアラートを作成できるようになります。
予測モデルのアラートを設定する一般的なシナリオには、次のようなものがあります。
ダッシュボードのビューを構築するためにすでに生成された組み込みクエリがあります。 アラートを作成するには、プロファイルまたはドリフト メトリクス テーブルから監視するメトリクスを計算するSQLクエリに移動します。 次に、 Databricks SQLクエリ エディターで [アラートの作成] をクリックし、MAPE が 0.1 を超えたときにトリガーするなどのアラート条件を構成します。 アラートを1時間ごとや毎日などのスケジュールで実行するように設定したり、通知の受信方法を指定したりすることができます(例: 電子メール、Slack、PagerDuty)。
安心メトリクスのアラートに加えて、カスタムSQLクエリを記述して、特定のユースケースに合わせてオーダーメイドのメトリクスを計算できます。 たとえば、高価値製品の MAPE が低価値製品とは異なるしきい値を超えた場合にアラートを発したい場合があります。 プロファイル メトリクスを製品テーブルと結合して、MAPE 計算をセグメント化することができます。
重要なのは、すべての特徴データと予測データがメトリクス テーブルで利用できるため、 SQL柔軟に作成してビジネスにとって意味のあるカスタム メトリクスを定義できることです。 その後、同じプロセスを使用して、これらのカスタム メトリクスの上にアラートを作成できます。
予測モデル メトリクスにターゲットを絞ったアラートを設定すると、手動モニタリングなしでそのパフォーマンスを常に把握できます。 アラートを使用すると、異常に迅速に対応し、モデルの予測に対する信頼を維持できます。 レイクハウスモニタリングによって可能になる多次元分析と組み合わせることで、問題を効率的に診断して解決し、予測の品質を高く保つことができます。
予測モデルに特有のものではありませんが、レイクハウスモニタリング自体の使用状況と費用を追跡する方法を理解することが重要です。 レイクハウスモニタリングの使用を計画する場合、適切な予算を立てるために関連コストを理解することが重要です。 レイクハウスモニタリングジョブはサーバレスコンピュートインフラ上で実行されるため、クラスターを自分で管理する必要はありません。 レイクハウスモニタリングのコストを見積もるには、次のステップに従ってください。
実際のコストは、特定のモニター定義とデータによって異なり、時間の経過とともに変化する可能性があります。 Databricks 、 SQLハウスモニタリング コストを監視する 2 つの方法を提供します。SQL クエリを使用する方法と、請求ポータルを使用する方法です。 詳細については、 https://docs.databricks.com/ja/lakehouse-monitoring/expense.htmlを参照してください。
Databricksレイクハウスモニタリングを使用して予測モデルのモニタリングを開始する準備はできていますか? まずは無料トライアルにサインアップしてください。 すでに Databricks の顧客ですか? 当社のドキュメントをチェックして、今すぐ最初の推論プロファイルモニターを設定してください。