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

継続的なモニタリングでは、自動化されたプロセスがパフォーマンスの問題とモデルの問題を監視および検出します。その後、所有者は潜在的な問題や脅威をリアルタイムで特定して、迅速に対処できます。

継続的なモニタリングは、データ品質、分散シフト、モデル概念シフト、モデル品質の低下など、モデルに起こり得る問題を明らかにします。継続的モニタリングには、飽和、レイテンシー、トラフィック、エラーなどの従来のシステムメジャーの包括的なログ記録も含まれます。実用的な通知とアラート戦略は、問題が発生したときに所有者に通知するように設定されています。

6.1 モデルモニタリング: データ品質検出	ルールベースのモニタリングは、受信データがモデルトレーニングデータから逸脱したときを知るために用意されています。このタイプのモニタリングは、トレーニングデータからスキーマを作成し、そのスキーマに基づいて制約を設定し、違反が発生したときに例外を実行します。
6.2 モデルモニタリング: 分散シフト	モニタリングは、受信データディストリビューションを確認し、モデルトレーニングデータディストリビューションから逸脱していないことを確認するように設定されます。例えば、受信データは、推論データを移動ウィンドウとして にサンプリングされます。次に、ジョブを実行して、サンプリングされたディストリビューションとトレーニングディストリビューションをテストし、それらが同じかどうかを確認します。
6.3 モデルモニタリング: モデル概念ドリフト	概念ドリフトチェックでは、モデルの入力とターゲット変数の関係が、トレーニングデータから変更されないままになるよう探します。追加のチェックでは、相対的な特徴とその重要性が変更されないことを確認します。
6.4 モデルモニタリング: モデル評価チェック	これは、モデルの品質が低下しているかどうかを評価するモニタリングチェックです。モデル評価チェックでは、トレーニング時間のベースライン評価メトリクスと受信結果を比較し、新しいデータでモデルの精度レベルが低下したかどうかを評価します。精度メトリクスを計算するため、このチェックでは、推論後に新しいデータのグラウンドトゥルースが利用可能である必要があります。
6.5 システムキャプチャ: 入力スキーマ	ML システムは、トレーニング、テスト、検証データのスキーマをキャプチャします。スキーマは、入力に関する情報を提供するだけでなく、その歪みと完全性に関する統計も提供します。  スキーマは、本番環境での即時テストとデータ品質モニタリングチェックに使用されます。
6.6 システムキャプチャ: 評価結果と統計	ML システムは、検証データとトレーニングデータに関する精度情報を出力します。検証とトレーニングの実行から予測と真のラベルを出力できます。これらは、実稼働モデルのモニタリング制約として使用されます。
6.7 システムキャプチャ: 異常	受信データストリームの異常にフラグを付ける追跡メカニズムが設定されています。受信データで外れ値が発生した場合、または指定された時間枠内にキー機能の分散が変更された場合、システムはこれを異常として認識し、フラグを付けます。
6.8 ログ記録: 飽和とリソース	システム全体のログ記録があります。リソースと飽和度メトリクスは、CPU 使用率、グラフィックスプロセッシングユニット (GPU) 使用率、メモリ使用率、ディスク使用率に焦点を当てる必要があります。これらのメトリクスは時系列形式で使用でき、パーセンタイルで測定できる必要があります。バッチジョブの場合、これによりスループットに関する情報が提供されます。スループットは、システムが各時間で処理できる情報ユニットの数を示します。
6.9 ログ記録: レイテンシー	ネットワーク通信の遅延やリクエストの処理にかかる時間を測定するには、ログ記録が必要です。エンジニアは、推論モデルが予測を処理するのにかかる時間と、モデルのロードにかかる時間を判断できる必要があります。
6.10 ログ記録: トラフィック	トラフィックのログ記録設定は、各インスタンスのトラフィック量を測定します。トラフィックは、HTTP リクエストの数と、一定時間内に送受信されたバイトまたはパケットの数によって測定されます。トラフィックのログ記録は、システムに配置されたワークロードの合計に関するインサイトを提供します。
6.11 ログ記録: エラー	エラーのログ記録設定は、失敗したリクエストの数をキャプチャします。失敗のタイプは次のとおりです。 明示的 (HTTP 500 エラーなど） 暗黙的 (例: 間違ったコンテンツと結合された HTTP 200 成功レスポンス） ポリシー (たとえば、1 秒の応答時間をコミットする場合、1 秒を超えるリクエストはエラーです） プロトコルレスポンスコードがすべての障害状態を表現するには不十分な場合、部分的な障害モードを追跡するためにセカンダリ (内部) プロトコルが必要になる場合があります。
6.12 通知とアラート	通知とアラートはモニタリングから設定されます。通知には、Slack、E メール通知、ページ、ショートメッセージサービス (SMS) メッセージを取得する機能が含まれます。アラートとは、すべての違反の可能性について通知を送信することを意味するものではありません。代わりに、開発チームにとって有益で重要な特定の例外にアラートを設定することを意味します。これにより、アラートの疲労を回避できます。