Predictive ML／Classical MLOps 本番環境 Lifecycle

生成AI以外の予測モデルも、学習時の精度だけでは本番品質を保証できません。classical/predictive MLの本番運用では、予測時点で実際に利用可能だった特徴量だけで学習・評価すること、trainingとservingで同じ特徴定義・前処理を再現すること、正解ラベルが遅れて到着する状況を扱うこと、時間軸に沿ったbacktestを行うこと、再学習後のモデルを再承認し、安全にrollbackできることを一続きのproduction lifecycleとして管理する必要があります。

履歴データから学習行を作るとき、現在のデータベースに存在する値を単純joinしてはいけません。各予測対象について、実際のprediction timestamp時点で利用可能だった情報だけを特徴量として再構成します。未来に確定したchargeback、解約、診断、入金、集計結果などが過去の学習行へ混入すると、offline評価は高くても本番では再現できないtarget leakageになります。

Feastのpoint-in-time joinは、entity dataframeの各timestampを基準に過去のfeature stateを取得する設計を明示しています。Google Cloudもtraining-serving skew対策として、ラベルイベントより後に生成された特徴をtrainingへ入れないpoint-in-time lookupを説明しています。特定feature storeの採用自体を要件にはせず、少なくとも entity_id / prediction_time / feature_event_time / feature_available_time を区別し、履歴再構成が「その時点で知り得た情報」に限定されることをtest可能にします。

遅延到着データがある場合はevent timeだけでは不十分です。出来事が過去に発生していても、当時のserving systemがまだ受信していなかったなら、その値をhistorical trainingへ含めると未来情報になります。backfillや訂正済みmaster dataも同様で、現在から見た正しい値ではなく、予測時点で利用可能だった状態を再現する必要があります。

training-serving skewには複数の原因があります。Google Cloudは、trainingとservingで異なるfeature処理経路を持つこと、学習後にraw dataが変化すること、feedback/data leakageを代表的要因として挙げています。したがってproduction monitoringで入力分布のdriftだけを監視しても、前処理実装の差、category mappingの差、timezone/null処理の差、feature freshnessの差は取り逃がします。

対策は、trainingとservingで同じfeature definitionまたは同じ変換artifactを使うことです。別実装が避けられない場合は、固定fixtureとproduction sampleについてoffline/online parity testを行い、feature name、type、normalization、category mapping、window boundary、timezone、missing-value policyまで比較します。

distribution skewの監視は別controlです。production feature distributionをtraining baselineと比較することは有効ですが、統計的な差が即座にmodel failureを意味するとは限りません。逆にdistributionが大きく変わらなくても、concept driftや実装skewで精度が落ちる場合があります。drift metricを自動再学習の単独根拠にしません。

fraud、credit default、churn、保守故障、医療outcomeなどでは、prediction直後にground truthが確定しません。この場合、production accuracyをリアルタイムに直接測れないため、即時signalと遅延signalを分けます。

即時signalにはschema/type violation、missing rate、feature freshness、input/output distribution、latency、error rate、training-serving parityなどを使います。ground truthが到着した後は、ラベル確定時点を記録してaccuracy、precision/recall、calibration、business loss等をcohort単位でbackfillします。ラベルが到着した母集団だけで評価するとselection biasが入る場合があるため、未確定・欠測・観測不能ラベルの割合も監視対象にします。

proxy metricやdrift alertを「精度低下の証明」と表現しません。正解ラベルが遅れる期間は、品質劣化の早期兆候と確定performanceを区別して運用します。

予測モデルの再学習候補は、単一random holdoutだけでなく、必要に応じてrolling/expanding window等で過去時点を再現します。各foldで、その時点までに利用可能だったfeaturesとlabelsだけを使い、training cutoff、label maturity window、prediction horizonを固定します。

季節性、policy変更、価格改定、景気局面、sensor更新などで分布が変わるtaskでは、複数期間でperformanceを確認します。backtestの目的は未来を完全に予測することではなく、時間依存のleakageを避け、候補モデルが異なる過去局面でどのように失敗したかを把握することです。

drift検出やscheduleを契機に再学習しても、新modelを自動的にproductionへ昇格させる必要はありません。retraining pipelineは、dataset snapshot、feature definitions、code/config、hyperparameters、model artifact、evaluation resultsをversion化し、現行championと同じacceptance criteriaで比較します。

再承認では、offline metricsだけでなく、重要slice、calibration、cost/latency、policy constraints、schema compatibility、必要なfairness/safety条件を確認します。変更が大きい場合はshadow、canary、champion/challenger等でproduction traffic上の挙動を限定的に確認します。自動promotionを使う場合も、承認条件と停止条件をmachine-readableにし、監査記録を残します。

Googleの「Hidden Technical Debt in Machine Learning Systems」は、ML systemがmodel codeだけでなくdata dependencies、feedback loops、configuration、serving infrastructureなど広いsystem-level debtを持つことを指摘しています。再学習を単なる fit() の再実行として扱わず、依存するdata/feature/serving contractまでversioned lifecycleへ含める必要があります。

• prediction timestampとfeature availability timestampを区別し、point-in-time correctなtraining set生成をtestする。
• preprocessing/feature logicをtrainingとservingで共有するか、offline/online parity fixtureで一致を継続検証する。
• train/validation/test分割前後のfit処理を固定し、target leakageとentity/time leakageを検査する。
• delayed labelsについて、即時proxy monitoringとground-truth到着後の確定performanceを分離する。
• dataset、feature definitions、training code/config、model artifact、evaluation、deployment bundleを同じlineageでversion管理する。
• retraining triggerとproduction promotionを分離し、候補modelを現行championと再評価する。
• promotion条件、停止条件、rollback条件を事前に定義し、deployment/rollback後にserving readbackを行う。
• model performanceだけでなくdata quality、feature freshness、schema、latency/error、重要sliceを継続監視する。

feature storeを導入すればtraining-serving skewが自動的に消えるわけではありません。誤ったfeature definitionを一貫して再利用すれば、誤りも一貫して再現されます。point-in-time joinもtimestamp semanticsやlate-arrival条件が誤っていればleakageを防げません。

drift detectionはground-truth performanceの代替ではありません。distribution shiftがあってもperformanceが維持される場合があり、shiftが小さくてもconcept changeでperformanceが低下する場合があります。自動retrainingも常に改善を保証せず、最近のデータが少ない、label biasがある、異常期間を学習する、重要sliceが劣化する等の危険があります。

random split、time split、group splitのどれが正しいかはtaskのdeployment semanticsに依存します。規制・医療・信用等では、model再承認や変更管理に追加の法的・組織的要件があり得ます。

「定期的に再学習すればモデル劣化を防げる」「feature storeを使えばleakageはなくなる」「driftを検知すれば精度低下が分かる」と一般化しません。

安全な表現は、「予測MLの本番品質は、予測時点で利用可能な特徴量の再現、training-serving parity、leakage防止、遅延ラベルを考慮した評価、時間軸backtest、再学習後の再承認、versioned rollbackを組み合わせて維持する。各controlの必要性と閾値はtask・データ・運用環境に依存する」です。

• 各本番modelでfeature event timeとactual availability timeの双方を再現できるか。
• delayed/partially observed labelsによるproduction evaluation biasをどのように補正するか。
• drift/retraining triggerの閾値を、誤警報・見逃し・retraining costを含めてどう最適化するか。
• model/feature/preprocessing/runtimeをどの粒度で一つのrollback bundleとして固定するか。
• 組織固有の再承認authority、regulated change-control、human sign-offの要件。
• feedback loopを持つ推薦・与信・不正検知等で、過去ログがpolicy変更の影響を受ける場合のcounterfactual evaluation方法。

• Google Research, Hidden Technical Debt in Machine Learning Systems, NIPS 2015. https://research.google/pubs/hidden-technical-debt-in-machine-learning-systems/
• Google Cloud, Kickstart your organization’s ML application development flywheel with the Vertex Feature Store, 2021-06-09. https://cloud.google.com/blog/topics/developers-practitioners/kickstart-your-organizations-ml-application-development-flywheel-vertex-feature-store
• Google Cloud, Monitor models for training-serving skew with Vertex AI, 2021. https://cloud.google.com/blog/topics/developers-practitioners/monitor-models-training-serving-skew-vertex-ai
• Feast documentation, Point-in-time joins. https://docs.feast.dev/v0.13-branch/getting-started/concepts/point-in-time-joins
• scikit-learn 1.9.1 documentation, Common pitfalls and recommended practices — Data leakage. https://scikit-learn.org/stable/common_pitfalls