これで完了です。グローバルなユニコーンの外観予測ツールのデプロイが完了しました。予測器を中断することなく 24 時間 365 日実行する必要があります。その場合、ML パイプラインのモニタリングが必要であることにすぐに気づきます。すべてのコンポーネントをモニタリングすることは困難なように思えるかもしれませんが、要件とソリューションを見てみましょう。
トレーニング / サービング スキューを確認する
トレーニング / サービング スキューとは、入力データとトレーニング サービングの間で差異があることを意味します。次の表に、2 つの重要なスキューのタイプを示します。
| タイプ | 定義 | 例 | ソリューション |
|---|---|---|---|
| スキーマ スキュー | 入力データのトレーニングと提供は同じスキーマに準拠していません。 | モデルで古いデータが引き続き学習されるときに、提供データの形式や分布が変化します。 | 同じスキーマを使用して、トレーニング データとサービング データを検証します。欠損値の割合など、スキーマでチェックされていない統計情報を個別に確認してください。 |
| 特徴の偏り | エンジニアリングされるデータは、トレーニングとサービス提供によって異なります。 | 特徴量エンジニアリング コードは、トレーニングとサービングの間で異なり、異なるエンジニアリング データを生成します。 | スキーマ スキューと同様に、トレーニング データとサービング エンジニアリング データの両方に同じ統計ルールを適用します。検出されたスキュー特徴の数と、特徴ごとのスキュー サンプルの割合を追跡します。 |
モデルの経過時間パイプラインをモニタリングする
サービング データが時間とともに進化しても、モデルを定期的に再トレーニングしないと、モデルの品質が低下します。モデルが新しいデータで再トレーニングされてからの時間を追跡し、アラートにしきい値の経過時間を設定する。サービス提供時のモデルの経過時間をモニタリングするだけでなく、パイプライン全体でモデルの経過時間をモニタリングして、パイプラインのストールを検出する必要があります。
モデルの重みと出力が数値的に安定していることをテストする
モデルのトレーニング中、重みとレイヤの出力は NaN または Inf にしないでください。重みとレイヤ出力の NaN と Inf の値をチェックするテストを作成します。さらに、レイヤの出力の半分以上がゼロでないこともテストします。
モデルのパフォーマンスのモニタリング
ユニコーンの外観の予測因子は予想以上に人気があります。予測リクエストが多く、さらに多くのトレーニング データを受け取っています。モデルのトレーニングに多くのメモリと時間がかかっていることがわかると、とても便利だと思います。モデルのパフォーマンスをモニタリングするには、次の手順を行います。
- コード、モデル、データのバージョンごとにモデルのパフォーマンスを追跡します。このようなトラッキングにより、パフォーマンスの低下の正確な原因を特定できます。
- 新しいモデル バージョンについて、以前のバージョンと固定しきい値で 1 秒あたりのトレーニング ステップをテストします。
- メモリ使用量のしきい値を設定して、メモリリークをキャッチします。
- API レスポンス時間をモニタリングし、パーセンタイルを追跡します。API のレスポンス タイムが制御できない可能性がありますが、レスポンスが遅いと実際の指標の質が低下する可能性があります。
- 1 秒あたりに回答されたクエリの数をモニタリングします。
提供データに対するライブモデルの品質のテスト
モデルの検証が完了しました。しかし、検証データを記録した後、現実のシナリオ（ユニコーンの行動など）が変化するとしたらどうでしょうか。その後、サービング モデルの品質が低下します。ただし、実際のデータに常にラベルを付けるわけではないため、提供品質のテストは困難です。サービング データにラベルが付いていない場合は、次のテストを検討してください。
予測に有意な統計的バイアスを示すモデルを調査します。分類: 予測バイアスをご覧ください。
モデルの実際の指標を追跡します。たとえば、スパムを分類する場合は、予測をユーザーから報告されたスパムと比較します。
クエリの一部で新しいモデル バージョンを提供することで、トレーニング データとサービング データの相違の可能性を緩和します。新しいサービスモデルを検証する際は、すべてのクエリを段階的に新しいバージョンに切り替えます。
これらのテストを使用して、予測品質の急激な低下と遅い低下の両方をモニタリングします。