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