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