これで、ユニコーン モデルをデプロイしました。モデルは問題なく 24 時間 365 日稼働する必要があります。これを実現するには、ML パイプラインをモニタリングする必要があります。
データスキーマを記述して元データを検証する
データをモニタリングするには、データが満たす必要があるルールを記述して、想定される統計値と継続的に照合する必要があります。このルールのコレクションはデータスキーマと呼ばれます。次の手順でデータスキーマを定義します。
特徴の範囲と分布を把握します。カテゴリ型特徴の場合は、有効な値のセットを確認します。
理解したことをデータスキーマにエンコードします。ルールの例を以下に示します。
- ユーザーが送信した評価が常に 1 ～ 5 の範囲内であることを確認します。
- 英語のテキスト機能の場合、単語「the」が最も頻繁に出現することを確認します。
- 各カテゴリ特徴が、取り得る値の固定されたセットの値に設定されていることを確認します。
データスキーマに対してデータをテストします。スキーマは、次のようなデータエラーをキャッチする必要があります。
- 異常
- カテゴリ変数の予期しない値
- 予期しないデータ分布
特徴量エンジニアリングを検証する単体テストを作成する
元のデータはデータスキーマを満たしている可能性がありますが、モデルは元のデータでトレーニングされません。モデルは、特徴エンジニアリングされたデータでトレーニングされます。たとえば、モデルは未加工の数値データではなく、正規化された数値特徴量でトレーニングされます。特徴量エンジニアリングされたデータは元の入力データと大きく異なる可能性があるため、特徴量エンジニアリングされたデータは元の入力データのチェックとは別にチェックする必要があります。
特徴量エンジニアリングされたデータの理解に基づいて単体テストを作成します。たとえば、次のような条件を確認する単体テストを作成できます。
- すべての数値特徴は、0 ～ 1 などの範囲にスケーリングされます。
- ワンホット エンコードされたベクトルには、1 つの 1 と N-1 個のゼロのみが含まれます。
- 変換後の分布が期待どおりである。たとえば、Z スコアを使用して正規化した場合、Z スコアの平均は 0 になります。
- 外れ値は、スケーリングやクリッピングなどで処理されます。
重要なデータスライスの指標を確認する
全体が成功しても、サブセットが失敗していることがあります。つまり、全体的な指標が優れたモデルでも、特定の状況ではひどい予測を行う可能性があります。例:
ユニコーン モデルは全体的に優れたパフォーマンスを発揮しますが、サハラ砂漠の予測ではパフォーマンスが低下します。
全体的に優れた AUC に満足しているエンジニアであれば、サハラ砂漠でのモデルの問題に気付かない可能性があります。すべてのリージョンで優れた予測を行うことが重要である場合は、すべてのリージョンのパフォーマンスをトラッキングする必要があります。サハラ砂漠に対応するデータのサブセットは、データスライスと呼ばれます。
関心のあるデータスライスを特定します。次に、これらのデータスライスのモデル指標をデータセット全体の指標と比較します。モデルがすべてのデータスライスで良好に機能することを確認すると、バイアスを除去できます。詳細については、公平性: バイアスの評価をご覧ください。
実際の指標を使用する
モデル指標は、モデルの実際の影響を測定するものではありません。たとえば、ハイパーパラメータを変更するとモデルの AUC は向上する可能性がありますが、その変更はユーザー エクスペリエンスにどのように影響しましたか？実世界への影響を測定するには、個別の指標を定義する必要があります。たとえば、モデルのユーザーにアンケートを実施して、モデルが予測したときにユーザーが本当にユニコーンを見たのかを確認できます。
トレーニング サービング スキューを確認する
トレーニング / サービング スキューとは、トレーニング中の入力データがサービング中の入力データと異なることを意味します。次の表に、重要な 2 種類のスキューを示します。
| タイプ | 定義 | 例 | ソリューション |
|---|---|---|---|
| スキーマの偏り | トレーニング データとサービング データが同じスキーマに準拠していません。 | モデルが古いデータでトレーニングを継続している間に、サービング データの形式または分布が変更される。 | 同じスキーマを使用して、トレーニング データとサービング データを検証します。欠損値の割合など、スキーマでチェックされていない統計量を別途確認してください。 |
| 特徴の偏り | エンジニアリングされたデータは、トレーニングとサービングで異なります。 | 特徴量エンジニアリング コードはトレーニングとサービングで異なるため、生成されるエンジニアリング データも異なります。 | スキーマ スキューと同様に、トレーニング データとサービング データに同じ統計ルールを適用します。検出されたスキュー特徴の数と、特徴あたりのスキューサンプルの比率を追跡します。 |
トレーニング サービング スキューの原因は微妙な場合があります。予測時にモデルで使用できるデータは常に検討してください。トレーニング中は、サービング時に使用できる特徴のみを使用します。
演習: 理解度を確認する
オンライン ショップを運営していて、特定の日にどれだけの収益を得られるかを予測したいとします。ML の目標は、顧客数を特徴として使用して 1 日の収益を予測することです。
回答: 問題は、当日の売り上げが完了する前に、予測時に顧客数を把握できないことです。そのため、この機能は、1 日の収益を強く予測できる場合でも、有用ではありません。関連して、モデルをトレーニングして優れた評価指標（0.99 AUC など）を取得した場合は、ラベルに混入する可能性があるこのような特徴を探します。
ラベルの漏洩を確認する
ラベルの漏洩とは、予測しようとしているグラウンド トゥルースラベルが、トレーニング機能に誤って入力されていることを意味します。ラベル漏洩は、検出が非常に難しい場合があります。
演習: 理解度を確認する
新しい病院患者ががんであるかどうかを予測するバイナリ分類モデルを構築するとします。モデルは次のような特徴を使用します。
- 患者の年齢
- 患者の性別
- 過去の健康状態
- 病院名
- バイタルサイン
- テスト結果
- 遺伝
ラベルは次のとおりです。
- ブール値: 患者はがん患者ですか？
データを慎重に分割し、トレーニング セットが検証セットとテストセットから十分に分離されるようにします。モデルは検証セットとテストセットで非常に優れたパフォーマンスを発揮し、指標は素晴らしいものになっています。残念ながら、このモデルは実際の新しい患者に対して非常に悪いパフォーマンスを示します。
回答: モデルの特徴の 1 つは病院名です。 がんの治療に特化した病院もあります。トレーニング中に、特定の病院に割り当てられた患者はがんである可能性が高いことをモデルはすぐに学習しました。そのため、病院名は重み付けの高い特徴量になりました。
推論時、ほとんどの患者はまだ病院に割り当てられていませんでした。 結局のところ、このモデルの目的は、がんの有無を診断し、その診断結果に基づいて患者を適切な病院に割り当てることです。そのため、推論中に病院名の特徴量はまだ使用できず、モデルは他の特徴量に依存せざるを得ませんでした。
パイプライン全体でモデルの年齢をモニタリングする
サービング データが時間とともに変化しても、モデルが定期的に再トレーニングされない場合、モデルの品質は低下します。新しいデータでモデルが再トレーニングされてからの経過時間を追跡し、アラートのしきい値の年齢を設定します。サービング時のモデルの年齢をモニタリングするだけでなく、パイプライン全体でモデルの年齢をモニタリングして、パイプラインの停止を検出する必要があります。
モデルの重みと出力が数値的に安定していることをテストする
モデルのトレーニング中、重みとレイヤの出力は NaN（数値以外）または Inf（無限大）であってはなりません。重みとレイヤ出力の NaN 値と Inf 値を確認するテストを作成します。また、レイヤの出力の半分以上がゼロでないことを確認します。
モデルのパフォーマンスをモニタリングする
ユニコーンの出現予測ツールが予想以上に人気を集めています。予測リクエストが大量に発生し、トレーニング データも大量に生成されています。モデルのトレーニングに必要なメモリと時間がどんどん増えていることに気づくまで、これは素晴らしいことだと考えています。次の手順でモデルのパフォーマンスをモニタリングすることにしました。
- コード、モデル、データのバージョンごとにモデルのパフォーマンスを追跡します。このようなトラッキングを行うと、パフォーマンスの低下の正確な原因を特定できます。
- 新しいモデル バージョンの 1 秒あたりのトレーニング ステップを、以前のバージョンと固定のしきい値と比較してテストします。
- メモリ使用量のしきい値を設定して、メモリリークを検出します。
- API レスポンス時間をモニタリングし、パーセンタイルを追跡します。API の応答時間は制御できない場合がありますが、応答が遅いと、実際の指標が低下する可能性があります。
- 1 秒あたりに回答されたクエリの数をモニタリングします。
サービング データでライブモデルの品質をテストする
モデルを検証しました。ただし、検証データを記録した後に、ユニコーンの動作などの実際のシナリオが変更された場合はどうなりますか？その場合、提供されるモデルの品質が低下します。ただし、実際のデータはラベル付けされていないため、サービング時の品質をテストすることは困難です。サービング データにラベルが付いていない場合は、次のテストを検討してください。
予測に統計的に有意なバイアスが示されているモデルを調査します。分類: 予測バイアスをご覧ください。
モデルの実世界の指標を追跡します。たとえば、スパムを分類する場合は、予測結果をユーザーが報告したスパムと比較します。
クエリの一部で新しいモデル バージョンをサービングすることで、トレーニング データとサービング データの潜在的な差異を軽減します。新しいサービング モデルを検証しながら、すべてのクエリを新しいバージョンに段階的に切り替えます。
これらのテストを使用して、予測品質の急激な低下と緩やかな低下の両方をモニタリングしてください。
ランダム化
データ生成パイプラインを再現可能にします。特徴を追加してモデルの品質にどのような影響があるかを確認したいとします。公正なテストを行うには、この新機能以外はデータセットが同じである必要があります。その観点から、データ生成のランダム化を確定的に行うようにします。
- 乱数ジェネレータ（RNG）にシードを設定する。シードを使用すると、RNG を実行するたびに同じ値が同じ順序で出力され、データセットが再作成されます。
- 不変のハッシュキーを使用する。ハッシュ化は、データを分割またはサンプリングする一般的な方法です。各サンプルをハッシュし、結果の整数を使用して、サンプルを配置する分割を決定できます。ハッシュ関数への入力は、データ生成プログラムを実行するたびに変更しないでください。ハッシュに現在時刻や乱数を使用しないでください（ハッシュをオンデマンドで再作成する場合など）。
上記のアプローチは、データのサンプリングと分割の両方に適用されます。
ハッシュ化に関する考慮事項
検索クエリを収集し、ハッシュを使用してクエリを追加または除外していたことを考えてみましょう。ハッシュキーでクエリのみが使用されている場合、複数日のデータ全体で、そのクエリを常に含めるか、常に除外します。クエリを常に含めるか、常に除外することはおすすめしません。その理由は次のとおりです。
- トレーニング セットのクエリの多様性が低下します。
- 評価セットはトレーニング データと重複しないため、人為的に難易度が高くなります。実際には、サービング時にトレーニング データにライブ トラフィックの一部が含まれているため、評価にはそのことを反映する必要があります。
代わりに、クエリと日付でハッシュ化すると、日ごとに異なるハッシュ化結果が得られます。
