6. 継続的なモニタリング

6.1 モデルモニタリング: データ品質検出

受信データがモデルトレーニングデータからいつ逸脱したかを把握するため、ルールベースのモニタリングが設定されています。このタイプのモニタリングは、トレーニングデータからスキーマを作成し、そのスキーマに基づいて制約を設定し、違反が発生したときに例外を実行します。

6.2 モデルモニタリング: 分布シフト

モニタリングは、受信データの分布を確認し、モデルトレーニングデータ分布から逸脱していないことを確認するように設定されます。例えば、受信データは推論データの移動ウィンドウとしてサンプリングされます。次に、ジョブを実行して、サンプリングされた分布とトレーニング分布をテストし、それらが同じかどうかを確認します。

6.3 モデルモニタリング: モデル概念ドリフト

概念ドリフトチェックでは、モデルの入力とターゲット変数の関係がトレーニングデータから変化していないことを確認します。もう 1 つのチェック項目は、相対的な特徴とその重要性が変化していないことを確認することです。

6.4 モデルモニタリング: モデル評価チェック

これは、モデルの品質が低下しているかどうかを評価するモニタリングチェックです。モデル評価チェックでは、トレーニング時間のベースライン評価メトリクスと受信結果を比較し、モデルの精度レベルが新しいデータで低下したかどうかを評価します。精度メトリクスを計算するため、このチェックでは、推論後に新しいデータのグラウンドトゥルースを利用できるようにする必要があります。

6.5 システムキャプチャ: 入力スキーマ

ML システムは、トレーニング、テスト、検証データのスキーマをキャプチャします。スキーマは、入力に関する情報を提供するだけでなく、スキューと完全性に関する統計も提供します。  スキーマは、本番環境での即時テストとデータ品質モニタリングチェックに使用されます。

6.6 システムキャプチャ: 評価結果と統計

ML システムは、検証データとトレーニングデータに関する精度情報を出力します。検証とトレーニングの実行から予測ラベルと正解ラベルを出力できます。これらは、ライブ本番環境モデルのモニタリング制約として使用されます。

6.7 システムキャプチャ: 異常

受信データストリームの異常にフラグを付ける追跡メカニズムが設定されています。受信データで外れ値が発生した場合、または指定された期間中に主要な特徴量の分布が変化した場合、システムはこれを異常として認識し、フラグを付けます。

6.8 ログ記録: 飽和とリソース

システム使用率のログ記録が設定されています。リソースと飽和メトリクスでは、CPU 使用率、グラフィックス処理ユニット (GPU) 使用率、メモリ使用率、ディスク使用率に焦点を当てる必要があります。これらのメトリクスは時系列形式で利用でき、パーセンタイル単位で測定できます。バッチジョブの場合、これによりスループットに関する情報が提供されます。スループットは、システムが各時間で処理できる情報ユニットの数を示します。

6.9 ログ記録: レイテンシー

ネットワーク通信の遅延やリクエストの処理にかかる時間を測定するには、ログ記録が必要です。エンジニアは、推論モデルが予測を処理するのにかかる時間と、モデルのロードにかかる時間を判断できます。

6.10 ログ記録: トラフィック

トラフィックのログ記録の設定では、各インスタンスのトラフィック量を測定します。トラフィックは、一定の時間内に送受信された HTTP リクエストの数とバイトまたはパケットの数によって測定されます。トラフィックのログ記録は、システムにかかるワークロードの合計に関するインサイトを提供します。

6.11 ログ記録: エラー

エラーのログ記録の設定では、失敗したリクエストの数をキャプチャします。失敗のタイプは次のとおりです。

プロトコル応答コードがすべての障害状態を表現するには不十分な場合、部分的な障害モードを追跡するためにセカンダリ (内部) プロトコルが必要になる場合があります。

6.12 通知とアラート

通知とアラートはモニタリングから設定されます。通知には、Slack、E メール通知、ページ、ショートメッセージサービス (SMS) のメッセージを取得する機能が含まれます。アラート機能は、すべての違反に対して通知を送信するわけではありません。そうではなく、開発チームにとって有益で重要な特定の例外に対してアラートを設定することを意味します。これにより、アラート疲れを回避できます。