Monitoring, Drift & Continual Improvement

"Nobody told me the cameras would be replaced with a sharper model, that the store would repaint its walls beige, or that winter would arrive. I kept answering with the same confidence I had in summer. Confidence, I have learned, is the last thing to notice it is wrong."

A Deployed Classifier the World Quietly Moved On From

Every previous section in this chapter assumed a fixed model meeting a fixed world. The world is not fixed. The training distribution you so carefully assembled in Chapter 21 was a snapshot, and the production distribution slides away from it continuously: hardware gets upgraded, environments change, user behavior evolves, and rare conditions you never trained on eventually arrive. The model does not know any of this. It keeps mapping inputs to outputs with the same machinery, and because no ground truth arrives in production to score against, accuracy can collapse with no alarm, as the illustration below captures. This section is about replacing that silence with signal, and then closing the loop so the model improves rather than merely degrades.

1. Why Accuracy Decays Silently Beginner

The core difficulty is the absence of labels. In training you knew the right answer for every image, so accuracy was a number you could compute. In production the right answer almost never arrives, or arrives much later (a fraud is confirmed weeks on, a diagnosis is verified at follow-up), so the one metric you actually care about is the one you cannot measure in real time. Meanwhile the input distribution shifts. We distinguish two kinds of shift, because they call for different responses.

Data drift (covariate shift) is a change in the distribution of inputs $p(x)$: new camera sensors, a redesigned store, a different season, a population the model rarely saw. The relationship between input and label is unchanged, but the model now sees inputs unlike its training data and extrapolates poorly. Concept drift is a change in the relationship $p(y \mid x)$ itself: the same input should now get a different label, perhaps because a product category was redefined or fashions changed what counts as the target class. Data drift you can detect from the inputs alone; concept drift is harder because the inputs may look unchanged while their correct labels have moved. Figure 28.5.1 contrasts them.

2. Detecting Drift Without Labels Intermediate

Since labels are unavailable, drift detection works from two label-free signals. The first is the input distribution: compare the statistics of recent production inputs against a reference window from training or launch. Comparing raw pixels is hopeless (too high-dimensional), so the effective recipe, established by the "Failing Loudly" study, is to reduce dimensionality first, usually by running inputs through the model's own feature extractor (the penultimate-layer embeddings, the learned representations of Chapter 25), then run a statistical two-sample test on those low-dimensional features. The second signal is the model's output confidence: a model meeting unfamiliar inputs tends to become either over-confident in wrong predictions or diffusely uncertain, so the distribution of maximum softmax probabilities or prediction entropy shifts measurably even when accuracy itself cannot be measured. The histograms-and-statistics tools of Chapter 2 return here as drift detectors.

A standard univariate test is the two-sample Kolmogorov-Smirnov (KS) test, which compares two empirical distributions and reports the probability they came from the same source. Applied to a confidence score or to each feature dimension, it gives a principled drift alarm. When you run it across hundreds of feature dimensions at once, add a multiple-comparison correction, which tightens the per-test threshold so that the handful of false alarms you expect by chance do not trigger the alert. The code below builds a minimal drift monitor on the model's confidence scores.

import numpy as np
from scipy import stats

class ConfidenceDriftMonitor:
    """Alarm when production confidence drifts from a reference window (label-free)."""
    def __init__(self, reference_confidences, alpha=0.01):
        self.reference = np.asarray(reference_confidences)   # e.g. launch-day max-softmax
        self.alpha = alpha                                    # significance threshold

    def check(self, recent_confidences):
        recent = np.asarray(recent_confidences)
        # Two-sample KS test: is the recent confidence distribution the same as reference?
        ks_stat, p_value = stats.ks_2samp(self.reference, recent)
        drifted = p_value < self.alpha
        return {
            "ks_statistic": float(ks_stat),
            "p_value": float(p_value),
            "drifted": bool(drifted),
            "mean_shift": float(recent.mean() - self.reference.mean()),
        }

# Reference: confidences observed at launch (model is healthy and well-calibrated).
ref = np.random.beta(8, 2, size=5000)            # skewed high: confident, mostly correct
monitor = ConfidenceDriftMonitor(ref)

# Production batch after the environment shifted: confidence sags toward uncertainty.
drifted_batch = np.random.beta(4, 3, size=1000)  # flatter, less confident
print(monitor.check(drifted_batch))
# {'ks_statistic': 0.34, 'p_value': 1.2e-58, 'drifted': True, 'mean_shift': -0.21}

3. The Continual-Improvement Loop Intermediate

A drift alarm is the entry point to a loop, not an end in itself. The mature production loop, sometimes called the data flywheel, turns the model's own uncertainty into the next training set. It runs continuously: the deployed model serves predictions; a monitor watches inputs and confidence for drift; when drift or low confidence flags interesting inputs, those inputs are sampled for human labeling (prioritizing the uncertain and drifted, which is exactly the active-learning principle of spending labels where they teach most); the new labels are added to the training set; the model is retrained or fine-tuned; and the candidate is validated and rolled out, after which the loop repeats. Figure 28.5.2 lays out the cycle.

Two pieces of this loop have appeared elsewhere in the book. The "sample the uncertain inputs for labeling" step is active learning, and the human-labeling pipeline (codebooks, multiple raters, agreement) is its own discipline. The retraining step is the training recipe of Chapter 21 run again on an enlarged dataset, often as a fine-tune from the current weights rather than from scratch. The new piece is doing the rollout safely.

4. Rolling Out Safely Advanced

A retrained model is a hypothesis, not an improvement, until proven on real traffic. Deploying it straight to all users risks a regression worse than the drift you were fixing, so production rollout uses two guardrails. In a shadow deployment the new model runs alongside the current one on the same live requests, but its predictions are logged and not served; this measures the new model on real production traffic without exposing users to it, and lets you compare the two before committing. In a canary rollout the new model serves a small fraction of traffic (say 1 to 5 percent) while monitored closely; if its metrics hold, the fraction is ramped up gradually, and if anything regresses it is rolled back instantly with most users never affected. The two compose: shadow first to validate offline-style on live data, then canary to validate while serving. The sketch below shows the routing logic.

import random

class CanaryRouter:
    """Route a fraction of traffic to a candidate model; shadow-run it on the rest."""
    def __init__(self, stable_model, candidate_model, canary_fraction=0.05):
        self.stable = stable_model
        self.candidate = candidate_model
        self.canary_fraction = canary_fraction
        self.log = []                       # for comparing the two models offline

    def predict(self, x):
        stable_out = self.stable(x)         # always run the trusted model

        if random.random() < self.canary_fraction:
            served = self.candidate(x)      # canary: candidate actually serves this request
            source = "candidate"
        else:
            served = stable_out             # stable serves; candidate runs in shadow
            shadow_out = self.candidate(x)  # logged, NOT served, for comparison
            self.log.append((stable_out, shadow_out))
            source = "stable"

        return served, source

# Operating discipline: ramp canary_fraction 1% -> 5% -> 25% -> 100% only while
# the candidate's monitored metrics (confidence, agreement, downstream signals)
# hold; roll back instantly to 0% on any regression.

from evidently import Report
from evidently.presets import DataDriftPreset

# current_df and reference_df hold model features / confidences as columns.
report = Report([DataDriftPreset()])
# run() takes current data first, then reference, and returns a result object.
result = report.run(current_df, reference_df)
result.save_html("drift_report.html")     # per-feature drift, tests, and visuals
# Flags which feature columns drifted, with the test and p-value for each.

5. Summary: Deployment Is a Loop, Not a Line

A deployed vision model decays because the world drifts away from its training distribution, and the decay is silent because production has no labels to score against. Data drift changes the inputs $p(x)$; concept drift changes the input-to-label relationship $p(y \mid x)$. Both are detectable without labels by monitoring the input feature distribution and the model's confidence with two-sample tests, but a drift alarm is a prompt to look, not a verdict on accuracy. The continual-improvement loop turns that signal into action: sample the uncertain and drifted inputs for human labeling, retrain on the enlarged set, and roll the candidate out safely behind shadow deployment and canary releases. This closes Chapter 28 and Part III's journey from a trained network to a living production system. The same compression, export, and serving discipline becomes essential again for the far larger generative models of Part IV, and the monitoring-and-governance loop built here is the operational foundation that Chapter 37 extends to the harder evaluation problems of generated content.