Data Drift

Data Driftとは、モデルが本番で受け取る入力データの統計的分布が、学習時や過去のreference dataと比べて変化することです。

Data Driftとは何か

Data Drift（データドリフト）は、機械学習モデルが本番で受け取る入力データの統計的な分布が、学習時のデータや過去のreference dataと比べて変化することです。Model Monitoringで最もよく使われるsignalの一つです。

Google CloudのModel Monitoring関連APIは、Data Driftを「current datasetとbaseline datasetのdistribution distance」として扱い、最近のproduction dataとtraining data、または最近のproductionと過去期間を比較する用途を示しています。Azure Machine Learningも、model inputのdistribution変化をtraining dataやrecent production dataと比較するsignalとしてData Driftを定義しています。

何が「分布の変化」なのか

たとえばloan審査modelが年齢、収入、借入額をinputに使うとします。Training時は30代利用者が多かったのに、productionでは50代以上が増えたなら年齢distributionが変わっています。

数値featureなら平均、分散、quantile、distribution shapeが変わることがあります。Category featureならcategoryの比率が変わる、新しいcategoryが出現する、といった変化があります。

Data Driftは一つのfeatureだけで起きることも、複数featureの組み合わせで起きることもあります。単変量monitoringだけでは、多変量関係の変化を見逃す場合があります。

なぜ起きるのか

原因はさまざまです。季節変動、利用者層の変化、新商品、経済状況、地域展開など現実世界が変化した結果かもしれません。

一方で、data pipelineの変更が原因のこともあります。単位が円からドルへ変わった、temperatureが摂氏から華氏へ変わった、missing valueの埋め方が変わった、category codeが変更された、といったupstream changeです。

この二つは対処が違います。現実世界が変わったならmodelの再評価・再学習が必要かもしれません。Pipeline bugならmodelを再学習する前にdata処理を直すべきです。Data Drift alertは原因まで教えてくれるわけではありません。

Concept Driftとの違い

Data Driftは主にinput Xのdistribution、つまりP(X)の変化を見ます。Concept Driftは、input Xとtarget yの関係、P(y|X)が変わることを指すのが典型です。

Spam filterを例にします。Spam mailの文章styleが変わり、使用単語distributionが変わったならData Driftです。さらに、以前は安全だった表現が今はspamに多用されるようになり、同じfeatureとlabelの関係が変わったならConcept Driftです。

両者は同時に起きることも、片方だけ起きることもあります。ここを分けないと、monitoringのalertを誤解します。

Data DriftがあればModel性能は落ちたのか

必ずしも落ちたとは言えません。これは最も重要な注意点です。

たとえば画像分類modelで、撮影背景の色が季節により変わっても、対象物を認識するfeatureには影響しないかもしれません。Data distributionが変わっても、modelのdecision boundaryに関係しない領域なら性能は維持される可能性があります。

逆に大きなData DriftがなくてもConcept Driftで性能が落ちることがあります。したがってData Driftは「production環境がtraining時と変わっている」という警告であり、「modelが間違っている」という直接証拠ではありません。

Ground truthが得られるなら、AccuracyやRecall等のperformance metricと合わせて判断します。

どうやって検出するか

Data Drift detectionでは、reference distributionとcurrent distributionの距離や統計検定を使います。数値featureではJensen-Shannon distance、Wasserstein distance、Kolmogorov-Smirnov testなど、category featureではChi-squared系のtestやL-infinity distanceなどが使われます。

AWS SageMaker Model Monitorのdata quality監視はbaseline statisticsとconstraintsを作り、current dataを比較してdistribution drift等を検出します。Azureも複数のdistance/testを用意しています。

ただしmetricの値だけ見ても意味は決まりません。同じ0.1でもfeature、sample size、business riskによって重要度が違います。

WindowとSample Size

Production dataを何時間・何日まとめて比較するかで、検出結果は変わります。Windowが短すぎるとsample不足でnoiseが増え、長すぎると急激な変化の検出が遅れます。

曜日や季節性も考慮が必要です。EC serviceで日曜と月曜を直接比較すると、正常なweekly patternをdriftと判定するかもしれません。前年同月、過去4週同曜日など、業務に合うreference設計が必要です。

Sample sizeが少ないsegmentで大きなdistanceが出ても、偶然の可能性があります。Alert thresholdとminimum sampleを組み合わせることがあります。

Featureごとの重要度

全featureを同じ強さでmonitorすると、重要でないfeatureのalertが大量に出ることがあります。Model predictionへ大きく寄与するfeatureや、business上criticalなfeatureを優先する方法があります。

ただし「model importanceが低いからmonitorしなくてよい」とも限りません。Upstream data breakageのsignalとして重要なfeatureもあります。Feature importanceとdata quality riskは別に考えます。

実務の例

Fraud modelで、training時の平均取引額が8,000円、productionでは30,000円へ急増したとします。Data Drift monitorがalertを出しました。

ここで「modelが壊れたから再学習」と即断してはいけません。まず通貨単位や集計logicが変わっていないか、キャンペーンや大型商品で実際に取引額が増えたのか、特定merchantだけの変化かを調べます。

そのうえでfraud detectionのRecallやFalse Positive Rateが悪化しているか確認します。Performanceが維持されているなら、alert thresholdやbaselineの見直しだけでよいかもしれません。

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

Data Drift scoreを見たら、第一にreferenceを確認します。Training dataとの比較なのか、先週との比較なのかで意味が違います。

第二にfeatureとmetricです。どのfeatureが、どのdistance/testで、どのthresholdを超えたのか。第三にwindowとsample sizeです。第四にpipeline changeとschemaです。第五に同じ期間のmodel performanceです。

Data Driftは、modelが現実世界から離れ始めている可能性を早く知らせる重要なsignalです。しかし、入力分布が変わったことと、予測性能が落ちたことは同じではありません。この境界を守って読むことが、Monitoring結果を正しく解釈する鍵です。

関連AI用語

• G257 — Model Monitoring
• G259 — Concept Drift
• G260 — Model Drift

注・出典

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

1. Google Vertex AI SDK Docs — Data driftはcurrent datasetとbaseline datasetのdistribution distanceを測るものと定義され、productionとtrainingまたは過去productionの比較に使われる。 ↩
2. AWS SageMaker Data Quality — production dataのstatistical natureがtraining baselineからdriftした場合を監視し、distribution comparison等で検出する。 ↩
3. Azure ML Model Monitoring — Data driftはmodel input distributionの変化をtraining dataまたはrecent productionと比較して追跡するsignal。 ↩
4. IBM Model Drift — Data drift/covariate shiftはinput dataのunderlying distributionが変わることとしてConcept Driftと区別される。 ↩

AI協働制作について