Model Monitoring

Model Monitoringとは、本番稼働中の機械学習モデルについて、入力データ、出力、品質指標、運用状態などを継続的に測定し、劣化や異常を検知・調査する活動です。

Model Monitoringとは何か

Model Monitoring（モデル監視）は、本番環境で動いている機械学習モデルが、時間が経っても期待した状態を保っているかを継続的に確認する活動です。学習時やvalidation時に高いAccuracyを出したモデルでも、実世界の入力、利用者、業務ルール、データpipelineが変われば性能は落ちる可能性があります。

Monitoringでは、モデルのinput、prediction、ground truth、data quality、latency、error、resource利用などを継続して集め、referenceとなるdataや過去の状態と比較します。異常がthresholdを超えたらalertを出し、原因調査や再学習、rollbackにつなげます。

なぜ「学習時に良かった」だけでは足りないのか

機械学習モデルは、学習dataのpatternを使って未知dataを予測します。しかし本番世界は固定ではありません。利用者層が変わる、季節が変わる、sensorが交換される、価格体系が変わる、spam手法が変わる、といった変化が起きます。

Software bugがなくても、model outputの品質が悪化する点が通常softwareとの大きな違いです。Azure Machine Learningのdocumentationも、data distribution、training-serving skew、data quality、environment、consumer behaviorの変化がmodelをstaleにし得ると説明しています。

だからMLOpsでは、deploymentを終点ではなく、monitoringと改善を含む継続cycleとして扱います。

何をMonitoringするのか

Model Monitoringは一つのmetricだけを見るものではありません。代表的なsignalには次があります。

Data Driftは、model inputのdistributionがreferenceと比べて変化したかを見ます。Training dataとproduction data、または過去productionと現在productionを比較します。

Prediction Driftは、model outputのdistributionが変化したかを見ます。たとえばloan審査modelで「承認」predictionの割合が急増した、といった変化です。

Data Qualityは、missing value、range違反、schema change、未知categoryなどを監視します。Distribution以前にpipelineが壊れている場合を検出する役割があります。

Model Performanceは、predictionとground truthを比較し、Accuracy、Precision、Recall、RMSEなどtaskに応じた品質を直接測ります。これは最も分かりやすいsignalですが、ground truthがすぐ手に入らない問題があります。

そのほか、Feature Attribution Drift、Fairness、calibration、latency、throughput、error rate、costなどを対象にする場合もあります。

BaselineとReferenceが必要

「変化した」と言うには比較対象が必要です。Training datasetをbaselineにする場合、production inputが学習時のdistributionからどれだけ変わったかを測れます。

一方、直近30日をreferenceにして今週と比較する設計もあります。こちらはtraining時との差ではなく、production環境内での時間変化を見ます。

どのbaselineを選ぶかでalertの意味が変わります。Training dataから大きく離れていても、すでに長期間その状態で性能が安定している場合があります。逆に過去1週間との比較だけでは、training時からゆっくり蓄積したdriftを見逃すことがあります。

Monitoring画面の数値を読むときは、「何と何を比較しているのか」を最初に確認してください。

Data Driftは性能劣化そのものではない

ここは非常に重要です。Data Driftが検出されても、model performanceが必ず低下したとは限りません。

たとえば画像分類modelで、背景色のdistributionが季節で変わっても、対象物の認識には影響しないかもしれません。逆に入力featureのmarginal distributionがほとんど変わらなくても、inputとtargetの関係が変わるConcept Driftによって性能が落ちる場合があります。

Google Cloudのfeature attribution monitoringに関する解説も、feature distributionやattribution driftにはfalse positiveとfalse negativeがあり得るため、複数手法を組み合わせる必要があると述べています。

したがってData Driftは「調査すべき変化のsignal」であって、「modelが壊れた」という最終判定ではありません。

Ground Truthが遅れる問題

Model Performanceを直接測るには正解labelが必要です。しかし本番ではすぐに得られないことがあります。

不正取引は数週間後に判明するかもしれません。解約予測は実際に顧客が解約するまで正解が分かりません。医療predictionでは確定診断まで時間がかかることがあります。

この間、Data Drift、Prediction Drift、Data Quality、latencyなどをproxyとして早期監視します。ただしproxyはあくまでproxyです。「driftがないから性能も正常」と断定してはいけません。

Ground truthが届いた時点で、predictionとjoinしてperformance metricを計算する仕組みが必要です。AWSのModel Quality monitoringもpredictionとground truthを結合してquality metricを評価する構成を取ります。

Thresholdは真理ではない

Monitoringでは、distanceやmetricが一定thresholdを超えるとalertを出します。しかしthresholdは自然界に唯一正しい値があるわけではありません。

低すぎるthresholdはfalse alertを増やし、運用teamがalert疲れを起こします。高すぎると重要な変化を見逃します。Featureごとにbusiness impactが違うなら同じthresholdを使うべきとも限りません。

さらにsample sizeが小さいwindowではstatistical metricが不安定になることがあります。曜日や季節性が強いsystemでは、単純な前日比較が毎週alertを出すかもしれません。

Threshold、window size、minimum sample、segmentを実dataで調整することが必要です。

Segment単位で見る重要性

全体Accuracyが安定していても、特定地域、端末、年齢層、商品categoryだけ悪化する場合があります。Aggregate metricだけでは問題が相殺されることがあります。

たとえば全体Recallが90%のままでも、新規顧客segmentで95%→70%に落ち、既存顧客で改善して全体が同じということが起こり得ます。

Monitoring設計では、business上重要なsegmentを事前に決め、必要ならslice別metricを持ちます。ただしsegmentを増やしすぎるとmultiple testingやcostの問題もあるため、riskに応じて選びます。

Alertの後が本番

良いMonitoringはalertを出すだけでは不十分です。誰が確認し、何を調べ、どの条件でrollback/retrainするかを決めておく必要があります。

Data Drift alertなら、まずpipeline change、schema、missing、upstream service、segment構成を確認します。Model Performance低下なら、label品質、business rule変更、Concept Drift、model bugを調べます。

原因がdriftだからといって、即座に自動再学習すればよいとは限りません。新dataにlabel leakageやattack dataが混ざっていれば、再学習が問題を悪化させる可能性があります。Human approvalやvalidation gateを挟む設計が必要なsystemもあります。

LLMや生成AIではどうなるか

生成AIではground truthが一意でないため、Monitoringはさらに難しくなります。Latency、token、error、safety violation、retrieval quality、user feedback、evaluation scoreなど複数signalを組み合わせます。

Prompt templateやmodel versionが変わればoutput distributionも変わります。A/B testやcontinuous evaluationとMonitoringを組み合わせ、version変更によるregressionを追います。

ただしLLM-as-a-Judgeのscoreだけで完全な品質を表せるわけではありません。Evaluation method自体のbiasやvarianceも監視対象になり得ます。

元の文脈で何を確認するか

「Model Monitoringを導入した」と書かれていたら、まず何のsignalを見ているかを確認します。Data Driftだけなのか、ground truthを使ったperformanceまで含むのかで強さが違います。

次にbaseline/reference、window、metric、threshold、monitoring frequencyを確認します。さらにalert後のaction、rollback/retrain policy、Human Gateも重要です。

Model Monitoringは、modelが永遠に正しいことを保証する仕組みではありません。本番世界の変化を継続的に測り、品質劣化の兆候を早く見つけ、原因調査と改善へつなげる運用processです。Monitoringの数字を見るときは、「何を、何と比較し、何を意味するalertなのか」を必ず確認してください。

関連AI用語

• G258 — Data Drift
• G259 — Concept Drift
• G260 — Model Drift

注・出典

主要参照資料：^[1][2][3][4]

1. Azure ML Model Monitoring — production inference dataとreference dataからsignalを計算し、data drift、prediction drift、data quality、model performance等を監視する。ground truthがある場合はmodel performance signalを推奨。 ↩
2. Azure Model Performance — 定期monitoringでdata drift、prediction drift、data qualityを追跡し、ground truthがあればmodel performanceを直接評価できる。 ↩
3. Google Vertex AI Model Monitoring — baselineとtarget datasetを比較し、input feature、prediction、feature attributionのdistribution driftをthresholdで検出し、定期jobとして実行できる。 ↩
4. AWS Model Quality — predictionとground truthを結合し、problem typeに応じたmodel quality metricsをbaseline thresholdと比較できる。 ↩

AI協働制作について