ML 可観測性：時間経過に伴うモデルの動作のモニタリング¶
モデルの動作は、基になるハードウェアやソフトウェアの変更、トラフィックの流動性などの通常の要因だけでなく、入力ドリフト、古くなったトレーニングの仮定、データパイプラインの問題などにより、時間の経過とともに変化する可能性があります。ML 可観測性を使用すると、パフォーマンス、ドリフト、ボリュームなどの複数の次元にわたって、Snowflake Model Registryを介してデプロイしたプロダクションモデルの品質を追跡できます。
現在、モデルモニターは回帰モデルとバイナリ分類モデルをサポートしています。
注釈
ML 可観測性 を使い始めるには、 クイックスタート をご参照ください。
ML 可観測性ワークフロー¶
Snowflake Model Registry にログされたモデルを推論に使用すると、推論メソッドに渡された入力 DataFrame のタイプに応じて、Snowpark または pandas DataFrame の形式で結果を受け取ります。このデータは通常Snowflakeで生成されます。推論をSnowflakeの外で実行する場合でも、結果をSnowflakeに保存するのが一般的です。ML 可観測性は、保存された推論データを操作することで、これらのシナリオの両方でモデルのパフォーマンスを監視することができます。典型的なワークフローを以下に示します。
モニタリングログは推論データと予測値を保存し、 ML 可観測性 機能が予測値の経時変化を観察できるようにします。モニタリングログは、 ID、タイムスタンプ、特徴、予測、および与えられた行が予測データであるか観測データであるかを示すグランドトゥルースラベルを含むテーブルに格納されます。基本構造を以下に示します。
モニターしたいモデルのバージョンごとに、明示的にモデルモニターオブジェクトを作成する必要があります。各モデルバージョンは正確に1つのモニターを持つことができ、各モニターは正確に1つのモデルバージョンを監視することができます。モニターオブジェクトは、ソースデータをクエリすることでモニターログを自動的に更新し、ログに基づいてモニタリングレポートを更新します。
各モニターは以下の情報をカプセル化しています。
モニターするモデルのバージョン。
モニターログが保存されているテーブル。
データを保存する最小の時間粒度（アグリゲーションウィンドウ）、現在は最小1日です。
ドリフトなどの比較指標演算のためのオプションのベースライン・テーブル。
前提条件¶
始める前に、以下をご確認ください。
Snowflakeアカウント。
snowflake-ml-pythonPythonパッケージのバージョン1.7.1以降。Snowflake Model Registry に精通していること。
モデルモニターの作成¶
CREATE MODEL MONITOR コマンドを使用してモデルモニターを作成します。モデルモニターは、モニターするモデルのバージョンと同じスキーマで作成する必要があります。モニターを作成するスキーマには CREATE MODEL MONITOR 権限が必要です。1アカウントにつき最大250人のモデルモニターを作成できます。
CREATE MODEL MONITOR コマンドの詳細は CREATE MODEL MONITOR をご参照ください。
Tip
モデルモニターで使用できる他の SQL コマンドの詳細については、 モデルモニターコマンド をご覧ください。
モニタリングの一時停止と再開¶
ALTER MODEL MONITOR ... SUSPEND を使ってモデルモニターをサスペンド（一時停止）することができます。監視を再開するには、 ALTER MODEL MONITOR ... RESUME を発行します。
リフレッシュ失敗時の自動停止¶
モデル・モニターは、ソース・テーブルに関連するリフレッシュに5回連続して失敗すると、自動的にリフレッシュを中断します。 DESCRIBE MODEL MONITOR コマンドを使用して、リフレッシュ・サスペンションのステータスと原因を表示できます。出力には以下の列などがあります。
aggregation_status：この列の値は JSON オブジェクトです。モデルモニターが中断されると、このオブジェクトの値の1つ以上が SUSPENDED になります。aggregation_last_error：この列の値は、中断の原因となった特定の SQL エラーを含む JSON オブジェクトです。
リフレッシュ失敗の根本原因を解決した後、 ALTER MODEL MONITOR ... RESUME を発行してモニターを再開します。
モニタリングレポートの表示¶
モニターレポートを表示するには、Snowsightの ML Monitoringダッシュボードにアクセスしてください。Snowsightのナビゲーションペインで、 AI & ML を選択し、 Models を選択します。結果のリストには、現在のロールがアクセスできるすべてのデータベースとスキーマのSnowflake Model Registry内のすべてのモデルが含まれます。
Models リストの該当行を選択して、モデルの詳細ページを開きます。詳細ページには、モデルの説明、タグ、バージョン、モニターなど、モデルのキー情報が表示されます。
詳細ページの Monitors のリストには、モデルモニターのリスト、そのモニターがアタッチされているモデルバージョン、ステータス、作成日が表示されます。
モニターリストで対応する行を選択して、モデルモニターダッシュボードページを開きます。ダッシュボードには、経時的なモデルのキー指標がグラフで表示されます。表示される正確なグラフは、モニターが基づいているモデルのタイプ（つまり、バイナリ分類または回帰）によって異なります。
ダッシュボードでは、以下のアクションを実行できます。
時間範囲セレクタをクリックして、グラフの範囲を変更します。
Settings ボタンをクリックして、表示されるグラフを変更します。(メトリック名にマウスカーソルを合わせると、そのメトリックの詳細情報が表示されます。)
モデルモニターを比較するには、 Compare モデルセレクタドロップダウンをクリックします。
Display monitor details を選択して、モデルモニターの詳細情報を表示します。
アクセス制御の要件¶
モデル・モニター・オブジェクトを扱うには、以下の権限が必要です。
コマンド |
必要な権限 |
|---|---|
CREATE MODEL MONITOR |
|
SHOW MODEL MONITORS |
モデル・モニター上の権限 |
DESCRIBE MODEL MONITOR |
モデル・モニター上の権限 |
ALTER MODEL MONITOR |
モデルモニター上の MODIFY |
DROP MODEL MONITOR |
モデルモニター上の OWNERSHIP |
モデルモニターダッシュボード |
モデルおよびモデルモニター上の USAGE |
既知の制限¶
Modeling Monitorには以下の制限があります。
モニターは、モニターするモデルのバージョンと同じデータベースとスキーマで作成する必要があります。
現在のところ、単出力の回帰モデルとバイナリ分類モデルのみがサポートされています。
少なくとも1つの予測列（クラスまたはスコア）が必要です。Actual列はオプションですが、精度メトリックを計算するために必要です。
ベースラインデータがプロバイダーされていない場合、ドリフトは計算できません。ベースラインデータを追加するには、モニターを削除して再度作成する必要があります。
指定された列はモニター内で一度しか使用できません。例えば、同じ列を ID としても予測としても使用することはできません。
モデル・モニターは、データにヌル、 NaNs 、+/-Inf、0-1 の範囲外の確率スコア、正確に 0 または 1 ではないクラス、 PREDICTION_CLASS_COLUMNS 列に 2 つ以上のクラスなどの無効な値が含まれていないことを期待します。このような問題は、モニターを故障させ、最終的には停止させる原因となります。
タイムスタンプ列は、 TIMESTAMP_NTZ または DATE のタイプでなければなりません。予測列と実際の列は、 NUMBER のタイプでなければなりません。
集計ウィンドウは日単位で指定する必要があります。
監視する機能の数は最大500個です。
作成できるモニターは最大250人です。
コストの考慮事項¶
- バーチャルウェアハウスコンピューティング
仮想ウェアハウスで稼働するモデルモニター。このウェアハウスは、ユーザーがサービスを作成するときと、モニターが更新されるたびにコストが発生します。関連するSnowsightダッシュボードをロードする際にも仮想ウェアハウスが使用され、料金が発生します。
- ストレージ
モデル・モニターは、ソース・データをアカウントに保存されたテーブルに実体化します。
- クラウドサービス コンピュート
Modeling Monitorsはクラウドサービスのコンピュートを使って、基になるオブジェクトが変更されたときにリフレッシュをトリガーします。クラウドサービスの計算コストは、1日のクラウドサービスコストがアカウントの1日のウェアハウスコストの10％を超える場合にのみ請求されます。