モデル モニタリングの概要

このドキュメントでは、BigQuery ML がモデルで使用するデータの評価と比較を通じて、ML モデルのモニタリングをサポートする方法について説明します。ここでは、モデルのサービング データとトレーニング データの比較、新しいサービング データと以前に使用したサービング データの比較などを行います。

モデルで使用されるデータはモデルのパフォーマンスに影響するため、このデータを理解することは ML の重要な作業となります。モデルの正確性を常に維持するには、トレーニング データとサービング データの差異を把握することが特に重要となります。モデルは、トレーニング データと類似したデータで最高のパフォーマンスを発揮します。サービング データがモデルのトレーニングに使用したデータから逸脱すると、モデル自体に変化がなくても、モデルのパフォーマンスが低下する可能性があります。

BigQuery ML には、トレーニング データとサービング データのデータスキューやデータドリフトの分析に役立つ関数があります。

  • データスキューは、トレーニング データの特徴値の分布が、本番環境のサービング データと大きく異なる場合に発生します。モデルのトレーニング中にモデルのトレーニング統計情報が保存されるため、スキューの検出に元のトレーニング データは必要ありません。
  • データドリフトは、本番環境での特徴データの分布が時間の経過とともに大きく変化した場合に発生します。ドリフトの検出は、連続したデータスパンでサポートされます(たとえば、サービング データの異なる期間)。これにより、データセットが大きく変化してモデルの再トレーニングができなくなる前に、サービング データの変化に関する通知を受け取ることができます。

BigQuery ML でモデルをモニタリングするには、次の関数を使用します。

  • ML.DESCRIBE_DATA: 一連のトレーニング データまたはサービング データの記述統計を計算します。
  • ML.VALIDATE_DATA_SKEW: 一連のサービング データの統計情報を計算し、BigQuery ML モデルのトレーニング時に計算されたトレーニング データの統計情報と比較して、2 つのデータセット間の異常な差異を特定します。パフォーマンスの向上とコスト削減のため、トレーニング データの特徴列と一致するサービング データの特徴列に対してのみ統計情報が計算されます。
  • ML.VALIDATE_DATA_DRIFT: 2 つのデータセットのサービング データの統計を計算して比較し、2 つのデータセット間の異常な差異を特定します。
  • ML.TFDV_DESCRIBE: 一連のトレーニング データまたはサービング データの詳細な記述統計を計算します。この関数は、TensorFlow tfdv.generate_statistics_from_csv API と同じ動作をします。
  • ML.TFDV_VALIDATE: トレーニング データとサービング データの統計情報、または 2 つのサービング データの統計情報を比較し、2 つのデータセット間の異常な差異を特定します。この関数は、TensorFlow validate_statistics API と同じ動作をします。

モニタリング ユースケース

このセクションでは、一般的なモニタリング ユースケースで BigQuery ML モデル モニタリング関数を使用する方法について説明します。

データスキューの基本的なモニタリング

このユースケースは、データスキュー検出用のモデルを迅速に開発してモニタリングし、既存のモニタリング ソリューションと統合するためのきめ細かいスキュー統計情報を必要としない場合に適しています。

このユースケースの一般的な手順は次のとおりです。

  1. トレーニング データとサービスデータに対して ML.DESCRIBE_DATA 関数を実行し、両方のデータセットが適切に比較され、想定されたパラメータ内に収まるようにします。
  2. BigQuery ML モデルを作成し、トレーニング データでトレーニングします。
  3. ML.VALIDATE_DATA_SKEW 関数を実行して、サービング データの統計情報と、モデル作成中に計算されたトレーニング データの統計情報を比較し、データスキューがあるかどうかを確認します。
  4. データスキューがある場合は、根本原因を調査し、トレーニング データを適切に調整してから、モデルを再トレーニングします。

データドリフトの基本的なモニタリング

このユースケースは、データドリフト検出用のモデルを迅速に開発してモニタリングし、既存のモニタリング ソリューションと統合するためのきめ細かいドリフト統計情報を必要としない場合に適しています。

このユースケースの一般的な手順は次のとおりです。

  1. トレーニング データとサービスデータに対して ML.DESCRIBE_DATA 関数を実行し、両方のデータセットが適切に比較され、想定されたパラメータ内に収まるようにします。
  2. BigQuery ML モデルを作成し、トレーニング データでトレーニングします。
  3. ML.VALIDATE_DATA_DRIFT 関数を実行して、2 つの異なるサービング データセットの統計情報を比較し、データドリフトがあるかどうか確認します。たとえば、現在のサービング データをテーブル スナップショットの過去のサービング データと比較します。また、ML.FEATURES_AT_TIME 関数で取得した特定の時点の特徴と比較します。
  4. データドリフトがある場合は、根本原因を調査し、トレーニング データを適切に調整してから、モデルを再トレーニングします。

データスキューまたはドリフトの高度なモニタリング

このユースケースは、スキューやドリフトの詳細な統計情報を既存のモニタリング ソリューションと統合する場合などに適しています。

このユースケースの一般的な手順は次のとおりです。

  1. モニタリング ソリューションに適した間隔で、トレーニング データとサービング データに ML.TFDV_DESCRIBE 関数を実行し、クエリ結果を保存します。このステップでは、将来のサービング データを過去のトレーニング データやサービスデータと比較します。
  2. トレーニング データとサービング データの統計情報、または 2 つのサービング データの統計情報に対して ML.TFDV_VALIDATE 関数を実行し、データスキューまたは特徴のドリフトを評価します。トレーニング データとサービング データは、JSON 形式の TensorFlow DatasetFeatureStatisticsList プロトコル バッファとして提供する必要があります。ML.TFDV_DESCRIBE 関数を実行すると、正しい形式のプロトコル バッファを生成できます。また、BigQuery の外部から読み込むこともできます。次の例は、特徴のスキューを評価する方法を示しています。

    DECLARE stats1 JSON;
    DECLARE stats2 JSON;
    
    SET stats1 = (
      SELECT * FROM ML.TFDV_DESCRIBE(TABLE `myproject.mydataset.training`)
    );
    SET stats2 = (
      SELECT * FROM ML.TFDV_DESCRIBE(TABLE `myproject.mydataset.serving`)
    );
    
    SELECT ML.TFDV_VALIDATE(stats1, stats2, 'SKEW');
    
    INSERT `myproject.mydataset.serve_stats`
      (t, dataset_feature_statistics_list)
    SELECT CURRENT_TIMESTAMP() AS t, stats1;
  3. データスキューまたはデータドリフトがある場合は、根本原因を調査し、トレーニング データを適切に調整してから、モデルを再トレーニングします。

モニタリングの自動化

スケジュールされたクエリでモニタリング関数を実行し、出力を評価して、異常が検出された場合にモデルを再トレーニングするようにモニタリングを自動化できます。スケジュール クエリの設定で、メール通知を有効にする必要があります。

ML.VALIDATE_DATA_SKEW 関数を自動化する方法の例については、スキュー検出を自動化するをご覧ください。