モデルの監視

モデルは、学習したときのデータの世界を前提にしています。時間がたって世の中が変わると、エラーは1つも出ないまま、精度だけが静かに落ちていきます。これがドリフトです。

データドリフトは入力だけを見れば気づけますが、コンセプトドリフトは入力が同じままでも起きるので、正解と比べないと分かりません。

検知の方法：

• 入力の分布を比べる：特徴量ごとに、学習データ（または直近の安定した期間）と今の分布を比べます。PSI（Population Stability Index）がよく使われ、よく使われる経験則では、0.1 未満は安定、0.1〜0.25 は注意、0.25 以上は大きな変化とされます。ただし値は区間の分け方やデータの量で変わるので、絶対の基準ではなく「見直すきっかけ」として使います。KS 検定なども使えますが、データが多いと小さな差でも「有意」になるので、差の大きさで判断します。
• データの品質を見る：欠損の割合・値の範囲・カテゴリの種類の数。ドリフトに見えて、実は上流のデータの不具合（列の単位が変わった・全部 NULL になった）ということもよくあります。
• 予測の分布を見る：予測のスコアの平均や、陽性と判定した割合の変化。正解がなくてもすぐ見られます。
• 精度を測る：正解が届いたら、実際の精度を期間ごとに計算します。コンセプトドリフトを確実に見つけられるのはこれだけです。

落とし穴：全部の特徴量にアラートを付けると、毎日どこかが鳴って誰も見なくなります。重要度の高い特徴量と予測の分布に絞り、ドリフトが見つかったら「本当に精度に影響しているか」を確かめてから再学習します。

本番で「モデルの精度が落ちた」と見えるものの多くは、実は上流のデータの不具合です。ドリフトより先に、データの品質を見ます。

これらはモデルの指標よりずっと早く、はっきり異常が出ます。上流のチームと「列の意味や単位を変えるときは事前に知らせる」約束（データの契約）を決めておくと、事故を減らせます。

学習の前のデータの検証

ML のサービスの監視は、普通のサービスと同じシステムの指標に、モデルの指標を足したものです。システムが正常でも、モデルがおかしな答えを返していることがあるからです。

SLI・SLO の考え方は SRE の解説で

正解が遅れて分かる場合：「30日以内に解約するか」「この取引は不正か（チャージバックが来るのは数週間後）」のように、正解がすぐには分かりません。そのため、次のように組み合わせます。

• すぐ分かる代わりの指標を見る：入力のドリフト・予測の分布・クリックなどの早く分かる行動。
• 正解が届いたら、予測した日ごとにさかのぼって精度を計算する（予測のログに ID と時刻を残しておき、後で正解と結合する）。
• 一部を人がすぐ確認して、早めに精度を見積もる。

アラートの設計：すぐ人が動くべきもの（エラー率・レイテンシ・推論が止まった・入力が全部 NULL）は呼び出し（ページ）にします。ドリフトや精度の緩やかな低下は、すぐには対応できないので、チケットや日次のレポートに回します。しきい値は、普段の変動の幅（曜日や時間帯の差）を見てから決め、鳴ったときに何をするかの手順（再学習・前のモデルに戻す・上流のデータを確認）を一緒に書いておきます。

アラートには、鳴ったときに見る手順（ダッシュボードの場所・切り分けの順・戻し方）を必ず付けます。鳴っても何もしないアラートは消すか、レポートに移します。

SLI・SLO の考え方は SRE の解説で

個人情報は、ID に置き換える・保存期間を決める、を守ります。件数が多い場合は、全件ではなく一部を抜き出して保存しても、分布や精度の監視には十分なことが多いです。

モデルの予測が利用者の行動を変え、その行動が次の学習データになるため、モデルが自分の見たい世界を強めてしまうことがあります。これをフィードバックループといいます。

モデルを当てない比較用のグループ（ホールドアウト）を少し残しておくと、モデルの効果とループの影響を測れます。

影響が大きいときは、原因が分かる前でも前の版に戻す・代わりの答えに切り替えるなどで先に影響を止め、落ち着いてから原因を調べます。終わったら、見つけるまでの時間を短くするアラートを足します。