D4 - monitoring, drift & model performance

• for ordinary software, same code and input yield the same behaviour
• ML systems also depend on the real-world data distribution
• hence, there can be performance degradation

TRAIN
 ↓
DEPLOY
 ↓
MONITOR
 ↓
detect problem
 ↓
investigate
 ↓
RETRAIN / FIX / ROLLBACK

• monitoring is a part of the lifecycle

• it has four layers:

  • service/infrastructure
  • data
  • predictions
  • model performance

• service monitoring overs whether the serving system is technically operating correctly

• monitoring needs sensible window size, frequency and threshold

data monitoring

• data monitoring inspects the inputs

• suppose $P_{\text{train}}(X)$ and $P_{\text{prod}}(X)$ are the training and production distributions, so if $P_{\text{train}}\ne P_{\text{prod}}$, so there is a form of input/data shift, which is data drift

• eg: temperature regime changing from $15-30$ to $30-45$

• drift is often a warning signal prompting investigation, not a sure sign of failure

• a model can degrade even if obvious feature distributions have not changed

• if the input distribution remains broadly similar, but the relationship between input and target changes, ie. change in $P(X\mid Y)$, it is called concept drift

• eg: the same input values give different results later

• if the distribution of predictions has changed, ie. $P(\hat{Y}{)}_{\text{past}}\ne P(\hat{Y}{)}_{\text{current}}$, it is called prediction drift

• it is a symptom, and not a diagnosis

• a reference dataset is needed to detect drift

• this can be the training data, or another approved baseline window

• drift metrics are statistical methods for measuring distribution differences between the reference and current, such as:

  • population stability index;
  • Jensen–Shannon divergence;
  • Wasserstein distance;
  • statistical tests;
  • categorical distribution comparisons

• drift thresholds can be defined to alert/investigate

• alerts should prompt diagnosis of the cause

• drift-triggered retraining should be event/condition-driven

performance monitoring

• if ground-truth is obtained, metrics can directly be calculated

• observing the metrics provides direct evidence of model performance degradation

• label delay is when the ground truth can be received after a long time, eg: if a detector is used to detect failure within 7 days, the true label can take up to 7 days to be known

• proxy/leading signals can be monitored while labels are unavailable

  • for service: latency, errors, CPU
  • for input data: feature distributions, missing-value rates, schema, range violations
  • for predictions: prediction distribution, positive prediction rate, confidence distribution

• when labels arrive, metrics such as precision, recall, F1 can be used

schema monitoring

• monitors the following:
  • missing columns
  • unexpected columns
  • data types
  • ranges
  • null rates
  • categorical values

segment monitoring

• overall metrics might be different to segment metrics

• eg: overall recall = .94, detectors: A recall = .97, B recall = .96, C recall = .51

• monitor relevant segments/cohorts, where appropriate:

  • detector type
  • operating regime
  • site
  • hardware generation
  • temperature band

• aggregate metrics can also hide failures

• eg: $99\mathrm{\%}$ observations normal, but $1\mathrm{\%}$ from high temperature detectors for which model performance is terrible, where the overall F1 might look excellent

• production monitoring should reflect important operating regimes

model version monitoring

• model version should be monitored to know which model handled which traffic
• particularly useful for canary comparison to make evidence-based rollout decisions

alert

• different severity levels may justify different response
• every tiny fluctuation generating an alert would cause alert fatigue
• thresholds should represent actionable deviations, potentially using:
  • persistence requirements
  • windows
  • severity levels
  • statistical confidence
• a useful monitoring system maximizes signal, not alert volume
• diagnosis-first policy is better as alert response

MLOPs loop

                     DATA
                       │
                       ▼
                    TRAIN
                       │
                       ▼
                    MLFLOW
                       │
                       ▼
                   EVALUATE
                       │
                       ▼
                   REGISTER
                       │
                       ▼
                    DEPLOY
                       │
                       ▼
                    SERVE
                       │
                       ▼
                   MONITOR
		 ┌─────────┼─────────┐
		 ▼                           ▼                           ▼
	  service                       data                    model
	   health                       drift                    quality
		 │                           │                           │
		  └─────────┼─────────┘
					   ▼
					ALERT
					   │
					   ▼
				   DIAGNOSE
					│
	   ┌───────────┼───────────┐
	   ▼                                 ▼                                 ▼
   fix service                      fix data                     retrain
									   │
									   ▼
								NEW CANDIDATE
									   │
									   ▼
								  quality gates
									   │
									   ▼
								   deployment

monitoring hierarchy

1. SERVICE: is the endpoint/job working?
2. DATA QUALITY: are inputs valid?
3. DATA/PREDICTION DRIFT: has distribution changed?
4. MODEL PERFORMANCE: when labels arrive, is predictive quality degrading?
5. CONCEPT: has the real X→Y relationship changed?