# Symptom-based Alerting for Machine Learning ## 概要 [[Lina Weichbrodt]]（ML フリーランス・コンサルタント、元 [[Zalando]] シニアリサーチエンジニア、元 DKB リード ML エンジニア）による SREcon23 EMEA（Dublin, 2023-10-10）の発表。30 以上の ML ユースケースを本番運用した経験から、SRE の症状ベースアラーティングの原則を ML サービス監視に転用する実践的ガイドを提示する。 ## 主要メッセージ - **バックエンド監視は ML サービスには不十分**: 従来の 4 ゴールデンシグナル（レイテンシ・トラフィック・エラー・飽和度）ではサービスは「稼働中」に見えるが、ML 固有のサイレント障害（入力単位変更、データ欠損、フィルタドリフト、劣化モデルの自動リリース等）を検知できない(p.10-12)。 - **サイレント障害の商業的影響は大きい**: 高給の ML チームが 5 か月かけて 4% 改善した成果を、検知されないフィルタ破損等が 15% 品質低下で帳消しにしうる。「恒久的でサイレントな損失であり、大半のモデル改善より金銭的影響が大きい」(p.12)。 - **症状ベースアラーティングの ML 転用**: SRE の「原因でなくエンドユーザーの痛みに着目する」原則（Prometheus ベストプラクティス、*Distributed Systems Observability* Ch.2 を引用）を ML リクエストシーケンスに適用し、出力側から逆順に監視を優先する(p.14-17)。 ## 視覚的に重要な図表 **p.10 ML テストの追加的複雑さ** ![[_attachments/srecon23emea-weichbrodt/page-010.png]] Google "ML Test Score" 論文に基づき、従来システム（左）に対して ML ベースシステム（右）はデータテスト・スキューテスト・データ監視・予測監視が追加される。 **p.17 症状ベース監視の優先順位フレームワーク** ![[_attachments/srecon23emea-weichbrodt/page-017.png]] ML リクエストシーケンスを右（ユーザー影響）から左（入力データ）へ逆順に 3 段階の優先度を割り当てる。Priority 1 = 本番評価メトリクス＋ステークホルダー懸念、Priority 2 = サービス応答（後処理後）、Priority 3 = 入力/特徴量データ。 **p.24 評価メトリクスと検知メトリクスの区別** ![[_attachments/srecon23emea-weichbrodt/page-024.png]] ML の「メトリクス」は品質評価（適合率・再現率等）と問題検知の 2 種類がある。検知メトリクスは品質の客観測定を目指す必要はなく、品質低下時に変動するヒューリスティクスで十分である。 **p.27 D1 距離メトリクス** ![[_attachments/srecon23emea-weichbrodt/page-027.png]] 応答分布の変化検知に用いる D1 距離（$d_1(p,q) = \sum_{i=1}^{n} |p_i - q_i|$）。Google "Data Validation for Machine Learning" (2019) に基づく。 ## 3 段階の ML 監視優先順位 ### Priority 1: ユーザー影響 **本番評価メトリクス**: 訓練で使うメトリクス（適合率・再現率・NDCG 等）を本番データでも算出する。正解ラベルが近い時間で得られるケース（配送時間予測 ≈ 1 時間後）では有効。課題は (a) 正解が不明（不正検知でブロックした場合）、(b) 正解の遅延（配送で 2-4 日）、(c) フィルタバブル効果（推薦で未表示アイテムの評価不能）(p.18-21)。 **ステークホルダー懸念シグナル**: ステークホルダーに最悪シナリオを聞き、その恐怖をメトリクス化する。ローン審査の例では「不当な拒否」→ 適合率 <95% アラート、「処理遅延」→ p95 レイテンシアラート(p.22)。 ### Priority 2: サービス応答分布 後処理ルール適用後の出力（分類スコア、回帰予測値、推薦スコア、LLM テキスト）の分布を監視する(p.25-28)。 - **ルールベース距離**: 中央値、分位点、空/不十分出力の割合。 - **統計的距離**: Kolmogorov-Smirnov 統計量、D1 距離、Population Stability Index。 - **ヒューリスティック品質指標**: パーソナライズ応答の割合、空/フォールバック応答の割合、最頻利用カルーセルの順位（Spotify の例）(p.28)。 利点: 全応答を対象にできる「キャッチオール」手法で、正解ラベル不要。ユーザーのクリック率（ノイジー）より応答分布の方が小さな変化を検知しやすい(p.26)。 ### Priority 3: 入力/特徴量データ分布 Priority 2 と同じ距離メトリクスを入力側に適用する。出力アラートの根本原因分析に有用。例外: 訓練-サービング間スキューの監視は Priority 1（Google Rules of ML, Rule #29）(p.29-30)。 ## ツーリングの推奨 MLOps プラットフォームの導入は組織的準備が整ってからにすべきである。ある金融会社のデータサイエンティストは ML オブザーバビリティツール導入後「入力フィールドの分布変化アラートが週に複数届くが、上流のビジネス変更か自然変動か分からず一切対処しなかった」と報告している(p.32)。 既存スタック（Prometheus・Grafana・ジョブスケジューラ）で始める利点: (1) 新ツール不要で即時開始、(2) 他メトリクスと同一ダッシュボードで統合、(3) どのメトリクスが重要か学ぶ時間を確保、(4) チームと組織が ML 運用責任に成長する猶予(p.33-34)。 実装例として Prometheus クライアントの `Histogram` で ML 出力スコアを計測するコードを提示(p.35)。 ## 口頭説明・補足 口頭では以下のスライドに載らない補足があった(YouTube 自動字幕由来): - データサイエンティストにバックエンド監視の基礎（4 ゴールデンシグナル）を導入として説明する価値があり、両分野の橋渡しになる。 - 評価メトリクスの本番算出はデータサイエンティストにとって「未知の概念」であることが多い。訓練時にしか計測しない前提が染みついている。 - 出力監視の有効性は、入力の 70 フィールドのうち 1 つの中央値が変わっても出力への影響が不明であるのに対し、出力分布の変化は直接的にユーザー影響と相関する点にある。 - Spotify のホームページランキングでは「最も利用するカルーセルの順位」をリアルタイム品質指標として使っている。パーソナライズ推薦が正常なら最頻利用カルーセルは上位にあるはずという常識的ヒューリスティクス。 - MLOps ツール導入前に「誰がアラートに対処するか」「データサイエンティストはオンコールか」「データ品質の問題を検知しても修正の優先順位をどう決めるか」を解決すべき。データは多くのチームにとって副産物であり、修正を依頼しても優先度が低い。 ## 概念・実体への接続 - [[アラート管理]] — 症状ベースアラーティングの ML ドメインへの拡張。 - [[アクショナブルアラート]] — ML 固有のサイレント障害は従来のアクショナブルアラートの範囲外であり、出力品質メトリクスの追加が必要。 - [[アラート疲労]] — MLOps ツールの入力分布アラートが疲労を引き起こす事例を報告。 - [[MLモデル監視]] — 本発表が提示する 3 段階優先順位フレームワーク。 ## 限界・不確実点 - p.21 のダッシュボードスクリーンショットは「Hidden」ラベルで一部グラフの軸・凡例が隠されており、具体的な閾値は読み取れない。 - p.22 のローン審査の適合率 95% は例示であり、実際に DKB で使用した値かは不明。 - p.28 の Spotify の例は口頭説明に基づき、公式な出典は示されていない。 - Whisper による文字起こしが失敗し、YouTube 自動字幕（英語）をフォールバックとして使用。自動字幕の精度は機械精度であり、固有名詞等に誤認識がありうる。