Drift Detection in Production

"At 02:14 nobody was awake, the labels would not arrive for another nine days, and the error metric still read a serene and entirely fictional 0.91. But I had been watching the inputs, and the inputs had quietly stopped looking like anything I was trained on. I raised my hand before the loss ever noticed."

A Monitoring Dashboard That Noticed Before Anyone Else Did

In Section 21.1 we built the adaptive loop that retrains a model when the world moves, and we left one component as a promise: the trigger, the thing that decides the world has moved enough to act. This section is that trigger. It is also the production counterpart to the conceptual drift taxonomy of Section 20.2, where we classified covariate, label, and concept drift and reasoned about them with the labels in hand. Here the labels are gone, or late, and that single change of circumstance reorganizes everything: the quantities you can measure, the statistics you compute on them, and the inferences you are allowed to draw. We use the unified notation of Appendix A: $\mathbf{x}$ the input features, $y$ the (delayed) label, $\hat{y} = f(\mathbf{x})$ the model's prediction, $P_{\text{ref}}$ the reference distribution the model was validated against, and $P_{\text{live}}$ the distribution of the current production window.

The four competencies this section installs are these: to decide what to monitor when labels are unavailable, and why inputs and predictions come first; to choose and compute the right distance for a given feature type, and to correct for testing many features at once; to estimate a performance metric you cannot directly measure because the labels have not arrived; and to wire a drift signal into thresholds, severity tiers, and the retraining trigger without drowning the on-call engineer in false alarms. These are the load-bearing skills for operating any of the adaptive systems in this chapter, and they connect directly to the deployment and MLOps material of Chapter 34.

1. Where Drift Actually Bites: Production Without Labels Beginner

The cleanest mental model of monitoring is "watch the loss, and when it rises, react". It is also, in production, frequently useless, because the loss is a function of the label and the label is the one thing you do not have in real time. Consider the three running datasets of this book. A credit model's true label (default or repay) materializes over months. A clinical deterioration model's label (did the patient actually deteriorate) is confirmed after a clinician reviews the chart, days later and only for some patients. An industrial anomaly model's label (was that reading a real fault) is settled only when a maintenance engineer inspects the machine, if ever. In every case the prediction is made now and the ground truth, if it comes at all, comes later. This is the defining condition of production drift detection: the label is delayed or absent, so the error is not observable when you need it.

The taxonomy of Section 20.2 tells us why this still leaves us something to watch. Drift decomposes the joint distribution $P(\mathbf{x}, y) = P(\mathbf{x})\,P(y \mid \mathbf{x})$ into two movable parts. Covariate drift moves the input marginal $P(\mathbf{x})$ while the relationship $P(y \mid \mathbf{x})$ holds; concept drift moves the relationship $P(y \mid \mathbf{x})$ itself; label drift moves the target marginal $P(y)$. The crucial observation for a label-free setting is that $P(\mathbf{x})$ is fully observable the instant a request arrives, with no label required, and the model's own output $\hat{y} = f(\mathbf{x})$ is observable too. So even though concept drift, the most dangerous kind, lives in the unobservable $P(y \mid \mathbf{x})$, two of its fingerprints are visible immediately: a shift in the inputs $P(\mathbf{x})$, and a shift in the predictions $P(\hat{y})$ that the inputs induce. Input and prediction monitoring is how you watch for trouble through the keyhole the missing label leaves open.

This forces a layered monitoring strategy, ordered by how early the signal is available. Input drift is the earliest and most plentiful signal: it needs no label and no model output, just the request. Prediction drift is next: it needs the model's output but still no label, and it folds the model's learned response into the signal, so a change in the prediction mix can reveal an input change the raw features hid. Performance drift, the gold standard, is last and rarest, because it needs the label, and in production the label is exactly what is scarce. A mature monitor uses all three in this order: inputs and predictions as the always-on early-warning layer, and performance as the slower, authoritative confirmation that arrives when (and if) labels catch up.

There is a sharp logical limit worth stating up front, because it keeps the rest of the section honest. Input drift is neither necessary nor sufficient for performance to degrade. Not sufficient: $P(\mathbf{x})$ can move into a region where the model still happens to be accurate (a benign covariate shift the model generalizes through). Not necessary: $P(y \mid \mathbf{x})$ can rot underneath a perfectly stationary $P(\mathbf{x})$ (pure concept drift, invisible to any input monitor). Input and prediction drift are therefore leading indicators, not proofs: they buy you early warning at the cost of some false alarms and some missed concept drift. The job of the rest of this section is to make that trade favorable, by measuring change well, by not crying wolf across hundreds of features, and by estimating performance directly when we can.

2. What to Monitor and How to Measure It Intermediate

Having decided to watch inputs and predictions, we need a way to quantify "this distribution has changed". The problem is always the same shape: we have a reference sample drawn from $P_{\text{ref}}$ (typically the training or validation set, or a trusted recent baseline) and a live sample drawn from $P_{\text{live}}$ (the current production window), and we want a scalar that is small when the two look alike and large when they diverge, plus a way to call it significant. Several statistics answer this, each with a different sweet spot.

For a single numeric feature, four distances dominate practice. The Population Stability Index (PSI), ubiquitous in credit risk and finance, bins both samples into the reference's quantile bins and sums a symmetric relative-entropy term over bins:

where $p_b^{\text{ref}}$ and $p_b^{\text{live}}$ are the fractions of the reference and live samples falling in bin $b$. PSI is cheap, interpretable, and carries a folklore threshold scale (below $0.1$ no meaningful shift, $0.1$ to $0.25$ moderate shift worth watching, above $0.25$ a major shift that usually warrants action) that we make precise in the worked example. The closely related Kullback-Leibler divergence $\text{KL}(P_{\text{live}} \,\|\, P_{\text{ref}}) = \sum_b p_b^{\text{live}} \ln(p_b^{\text{live}} / p_b^{\text{ref}})$ is the asymmetric cousin; PSI is essentially the symmetrized, sign-aware version and is preferred operationally for its stability and its threshold lore.

The Kolmogorov-Smirnov (KS) statistic avoids binning entirely: it is the maximum gap between the two empirical cumulative distribution functions, $D = \sup_x |F_{\text{live}}(x) - F_{\text{ref}}(x)|$, and it comes with a classical two-sample significance test, so it returns not just a distance but a $p$-value. The Wasserstein distance (the one-dimensional earth-mover's distance) measures the minimal "work" to morph one distribution into the other, $W_1 = \int_{-\infty}^{\infty} |F_{\text{live}}(x) - F_{\text{ref}}(x)|\,dx$; unlike KS it is sensitive to how far mass moved, not just whether the CDFs separated, which makes it the better choice when the magnitude of a shift matters (a feature drifting by one unit versus ten should not score the same). For categorical features, the chi-squared test on the category-count contingency table is the natural analogue of KS.

All four above are per-feature, univariate: they test each feature's marginal in isolation. They are blind to multivariate drift, a change in the joint structure (the correlations, the dependency) that leaves every marginal unchanged. A classic example: two features whose individual histograms are identical to the reference but whose correlation has flipped sign. No univariate test fires, yet the joint distribution has moved and the model, which learned the old correlation, is now in trouble. The standard label-free detector for this is the Maximum Mean Discrepancy (MMD), a kernel two-sample statistic that compares distributions in a reproducing-kernel Hilbert space and so sees the full joint:

with $k$ a characteristic kernel (the Gaussian RBF is standard). MMD is zero exactly when the two distributions are equal and grows with any difference, marginal or joint, which is why it anchors modern multivariate drift libraries (Alibi Detect, for instance) and the domain-classifier "is this point from reference or live?" approach that is its discriminative cousin.

Now the problem that the per-feature tests force on you the moment you scale: multiple testing. A real production model consumes tens to hundreds of features, and a conscientious team runs a KS test on each one every monitoring window. Each test has a false-positive rate $\alpha$ (say $0.05$) under the null of no drift. Run $m = 200$ independent such tests on genuinely stationary data and the probability that at least one fires by chance is $1 - (1 - \alpha)^m = 1 - 0.95^{200} \approx 0.99997$. You are essentially guaranteed a spurious drift alert every single window, on data that has not drifted at all. Left uncorrected, per-feature monitoring at scale is a false-alarm factory, and false alarms are not free: they are the direct cause of the alert fatigue we warned about in Section 8.5, where an on-call engineer who has been paged by noise fifty times learns to ignore the fifty-first page, which is the real one.

The corrections are standard. Bonferroni tests each feature at $\alpha/m$, controlling the family-wise error rate (the chance of any false positive) but at the cost of sensitivity: with $m = 200$ each feature must clear $p < 0.00025$, and genuine moderate drift in one feature may be missed. The Benjamini-Hochberg procedure controls instead the false discovery rate (the expected fraction of flagged features that are false alarms), is far less conservative, and is usually the better operational default. A third, often superior, path is to aggregate: rather than alert on individual features, summarize drift into a small number of signals (a single multivariate MMD, the count of features exceeding their threshold, the drift of the prediction distribution) and threshold those, which sidesteps the multiplicity by simply not running hundreds of independent tests.

3. Estimating Performance Without Labels Advanced

Input and prediction drift tell you the world moved; they do not tell you whether the model still works, because, as subsection one established, a covariate shift can be benign. The quantity you actually want is the performance metric (accuracy, ROC AUC, RMSE), and that needs labels you do not have yet. A line of methods, crystallized in the NannyML library, estimates that metric before the labels arrive, turning the model's own outputs into a label-free performance estimate.

The first family is confidence-based estimation, of which NannyML's Confidence-Based Performance Estimation (CBPE) is the canonical instance. The idea is disarmingly direct: a well-calibrated classifier's predicted probability is an estimate of its own correctness. If the model outputs $\hat{p} = P(y = 1 \mid \mathbf{x}) = 0.9$ on an instance, then under calibration it is right about that instance with probability $0.9$. Aggregating these self-reported confidences over the live window lets you assemble an expected confusion matrix (expected true positives, false positives, and so on) entirely from predicted probabilities, and from that expected confusion matrix you compute any metric you like, accuracy, precision, recall, F1, ROC AUC, with no labels at all. The decisive assumption is that the calibration learned on reference data still holds on the live data, which is exactly true under pure covariate shift (where $P(y\mid\mathbf{x})$ is unchanged) and exactly the assumption that fails under concept drift, so CBPE estimates degradation from covariate shift well and is blind to performance loss caused by concept drift, a limitation it shares with every label-free method and one worth stating loudly to stakeholders.

The second family is reverse / direct modeling, NannyML's Direct Loss Estimation (DLE) and related reverse-classifier approaches. Here you train a second model, a "nanny", to predict the primary model's loss (or its per-instance error) directly from the inputs, using the reference data where labels are available. At inference time the nanny consumes the live inputs and outputs an estimated loss, again with no live label. This sidesteps the calibration assumption of CBPE and handles regression metrics naturally (CBPE is fundamentally about classification confusion matrices), at the cost of training and maintaining the auxiliary model and inheriting its own generalization error. The two families are complementary: confidence-based when the model is well calibrated and you trust calibration to transfer, direct/reverse modeling when you need regression metrics or distrust calibration transfer.

Layered on top of either estimator is the operational reality of label latency. Labels rarely arrive never; more often they arrive late and partially. The design pattern is a two-speed monitor. The fast loop runs every window on inputs, predictions, and a label-free performance estimate, and is what triggers early action. The slow loop runs whenever a batch of true labels lands (a week later, a month later) and computes the actual performance on that now-labeled past window, which serves two purposes: it confirms or refutes what the fast loop suspected, and it back-tests the estimator itself, telling you whether your CBPE or DLE numbers were trustworthy. A subtle trap is partial-label bias: the instances whose labels arrive first are often not a random sample (a defaulted loan resolves faster than a healthy one; a flagged anomaly gets inspected sooner than an unflagged one), so the early-arriving labels paint an optimistic or pessimistic picture that the full cohort will eventually correct. Account for it or your slow-loop "truth" is itself biased.

4. Operational Design: Windows, Thresholds, Severity, and Routing Intermediate

A drift statistic is only half a monitor; the other half is the operational scaffolding that turns a number into a decision without paging a human for every wiggle. Four design choices carry that weight: the reference window, the live window, the threshold scheme, and the routing.

The reference window defines "normal". Two philosophies compete. A fixed reference (the training or validation set, frozen) measures drift against the world the model was actually fit to, which is what you want when the question is "is the model still operating in-domain?"; its weakness is that slow, legitimate seasonal evolution will eventually read as permanent drift. A sliding reference (a trailing window of recent production data) adapts to gradual change and so suppresses seasonal false alarms, but at the cost of boiling-frog blindness: drift slow enough to stay inside the sliding window's own movement is never detected, because the reference drifts along with the data. The robust pattern is to run both, a fixed reference to catch absolute departure from the trained domain and a sliding reference to catch sudden departure from the recent norm, and to size the live window as a bias-variance knob: short windows react fast but are noisy (small samples make KS and PSI jumpy), long windows are stable but sluggish, so the window length is chosen from how fast you need to react versus how much sampling noise you can tolerate.

The threshold and severity scheme converts the statistic into a tiered response rather than a binary alarm, which is the single most important defense against alert fatigue. A good scheme has at least three bands, illustrated here with PSI's folklore scale but applicable to any statistic once you calibrate its bands on historical stationary data.

The routing closes the loop with Section 21.1. A Red drift alert is precisely the retraining trigger that section's adaptive loop was waiting for: drift detection here is the sensor, and the retraining policy there is the actuator. But the routing must be smart, not reflexive, for two reasons. First, retraining is expensive and not always the cure: if the drift is a transient data-quality glitch (a broken upstream feed, a unit change, a sensor recalibration) the fix is to repair the pipeline, not retrain on corrupted inputs, so a Red alert should route through a triage step that distinguishes genuine distribution shift from data-quality breakage. Second, you must guard against retraining thrash, where a noisy drift signal fires the trigger repeatedly and the model churns; a cooldown period, a requirement of sustained drift across several consecutive windows before acting, and a hysteresis gap between the fire and clear thresholds all damp the oscillation, the same stability logic that governs any feedback controller.

The thread running through all four choices is the war on false alarms, and it is the same lesson Section 8.5 taught for anomaly detection (see Section 8.5 on alert fatigue): a monitor that cries wolf is worse than no monitor, because it trains its operators to ignore it, so the one true alarm arrives to a deaf audience. Every design lever in this subsection, the dual reference, the calibrated multi-tier thresholds, the require-sustained-drift cooldown, the data-quality triage before retraining, exists to keep the precision of the alerts high enough that an engineer still believes the dashboard at 02:14.

5. Worked Example: A Drift Monitor From Scratch, Then By Library Advanced

We now make the whole pipeline executable on the sensor/IoT series of this part. The plan: simulate a reference window and a drifted live window for one feature; compute PSI, the KS statistic with its $p$-value, and the Wasserstein distance from scratch; raise a tiered (Green/Amber/Red) alarm from the PSI bands of subsection four; then reproduce the same drift report in a few lines of Evidently, and estimate label-free performance with NannyML. Code 21.2.1 is the from-scratch monitor.

import numpy as np

rng = np.random.default_rng(0)

# Reference window: the feature's distribution at training time (a trusted baseline).
reference = rng.normal(loc=20.0, scale=3.0, size=5000)   # e.g. a sensor temperature, deg C
# Live window: the same sensor, now shifted up and slightly wider (covariate drift).
live      = rng.normal(loc=22.2, scale=3.6, size=2000)

def psi(ref, live, n_bins=10, eps=1e-6):
    """Population Stability Index using the REFERENCE's quantile bin edges."""
    # Quantile bins from the reference make each reference bin ~equally populated.
    edges = np.quantile(ref, np.linspace(0, 1, n_bins + 1))
    edges[0], edges[-1] = -np.inf, np.inf            # open the tails so live outliers land
    ref_frac  = np.histogram(ref,  bins=edges)[0] / len(ref)
    live_frac = np.histogram(live, bins=edges)[0] / len(live)
    ref_frac  = ref_frac  + eps                       # additive smoothing: no empty bins
    live_frac = live_frac + eps                       # (else ln(.) blows up, see the fun note)
    return float(np.sum((live_frac - ref_frac) * np.log(live_frac / ref_frac)))

def ks_statistic(ref, live):
    """Two-sample Kolmogorov-Smirnov: sup gap between empirical CDFs, plus an asymptotic p."""
    allx = np.sort(np.concatenate([ref, live]))
    cdf_ref  = np.searchsorted(np.sort(ref),  allx, side='right') / len(ref)
    cdf_live = np.searchsorted(np.sort(live), allx, side='right') / len(live)
    d = float(np.max(np.abs(cdf_ref - cdf_live)))     # the KS statistic D
    n, m = len(ref), len(live)
    en = np.sqrt(n * m / (n + m))                     # effective sample size
    # Kolmogorov asymptotic survival function for the p-value.
    lam = (en + 0.12 + 0.11 / en) * d
    p = 2.0 * np.sum([(-1)**(k-1) * np.exp(-2 * k**2 * lam**2) for k in range(1, 101)])
    return d, float(np.clip(p, 0.0, 1.0))

def wasserstein_1d(ref, live):
    """1-D Wasserstein (earth-mover) distance: integral of |F_live - F_ref| dx."""
    allx = np.sort(np.concatenate([ref, live]))
    dx = np.diff(allx)
    cdf_ref  = np.searchsorted(np.sort(ref),  allx[:-1], side='right') / len(ref)
    cdf_live = np.searchsorted(np.sort(live), allx[:-1], side='right') / len(live)
    return float(np.sum(np.abs(cdf_ref - cdf_live) * dx))

def tiered_alarm(psi_value):
    """Map a PSI value to a Green/Amber/Red severity tier (subsection 4 bands)."""
    if psi_value < 0.1:   return "GREEN  (no action)"
    if psi_value < 0.25:  return "AMBER  (watch, notify channel)"
    return "RED    (act: page on-call, fire 21.1 retraining trigger)"

p_index = psi(reference, live)
ks_d, ks_p = ks_statistic(reference, live)
wdist = wasserstein_1d(reference, live)

print("PSI         = %.4f  ->  %s" % (p_index, tiered_alarm(p_index)))
print("KS stat D   = %.4f   (p = %.2e)" % (ks_d, ks_p))
print("Wasserstein = %.4f" % wdist)

PSI         = 0.3127  ->  RED    (act: page on-call, fire 21.1 retraining trigger)
KS stat D   = 0.2486   (p = 1.43e-87)
Wasserstein = 1.9034

The from-scratch monitor above is roughly 50 lines and reimplements binning, the KS survival function, the Wasserstein integral, and the tiering by hand. Production teams reach for a library that bundles all of it, computes per-feature and dataset-level drift, applies multiple-testing corrections, and renders an HTML report. Code 21.2.2 reproduces the entire per-feature drift report in about five lines with Evidently.

import pandas as pd
from evidently import Report
from evidently.presets import DataDriftPreset

# Same reference and live data as Code 21.2.1, now as DataFrames.
ref_df  = pd.DataFrame({"sensor_temp": reference})
live_df = pd.DataFrame({"sensor_temp": live})

report = Report(metrics=[DataDriftPreset()])          # picks per-column tests automatically
result = report.run(reference_data=ref_df, current_data=live_df)
result.save_html("drift_report.html")                 # full interactive drift dashboard
print(result.dict())                                  # per-feature drift flags + scores

Evidently watches the inputs. To estimate the model's performance on that drifted window without labels, the companion tool is NannyML, which implements the CBPE and DLE methods of subsection three. Code 21.2.3 fits CBPE on a labeled reference and estimates ROC AUC on the unlabeled live window.

import nannyml as nml

# reference_df has features, model predictions, predicted probabilities, AND true labels.
# analysis_df  has features, predictions, probabilities, but NO labels (the live window).
estimator = nml.CBPE(
    problem_type="classification_binary",
    y_pred="prediction", y_pred_proba="pred_proba", y_true="target",
    metrics=["roc_auc", "accuracy"],
    chunk_size=1000,
)
estimator.fit(reference_df)                            # learn calibration on labeled reference
estimated = estimator.estimate(analysis_df)            # estimate metrics on UNLABELED live data
print(estimated.to_df()[["chunk", "roc_auc_estimate", "roc_auc_alert"]])

Read the three code blocks as one system. Code 21.2.1 measured input drift from scratch and raised a tiered alarm; Code 21.2.2 reproduced that input-drift report in a tenth of the lines with Evidently; Code 21.2.3 added the label-free performance estimate that input drift alone cannot give, using NannyML. Together they instantiate the full subsection-one strategy: watch inputs and predictions always (Evidently), estimate performance without labels (NannyML CBPE), and route a Red alarm into the Section 21.1 retraining trigger. That is a production drift monitor, end to end.

# The whole input-drift report, library-style:
from evidently import Report
from evidently.presets import DataDriftPreset
Report(metrics=[DataDriftPreset()]).run(reference_data=ref_df, current_data=live_df).save_html("drift.html")

6. Proactive Drift Adaptation: Anticipate Before You Degrade Advanced

Every drift detection method covered so far in this section, ADWIN, DDM, CUSUM, PSI, KS, Wasserstein, shares the same temporal logic: observe the stream, compute a statistic, and alarm when that statistic exceeds a threshold. The alarm always follows the degradation. This is reactive adaptation, and it carries a structural cost called the reaction lag: the interval between the moment performance starts to degrade and the moment the detector's alarm triggers retraining. During that interval the model is already degraded, and the retraining pipeline's own latency (data collection, training, deployment) extends the degradation period further. For abrupt, fast-moving drifts the reaction lag can be a significant fraction of the drift's total duration.

Proactive adaptation inverts this logic. Rather than waiting for performance to degrade and then responding, a proactive system learns to predict drift before it manifests as measurable performance loss, and pre-emptively adjusts the model's parameters so that when the drift arrives the model is already partially or fully adapted. The Proceed framework (KDD 2025, arXiv 2412.08435) is the first production-grade realization of this idea, and it introduces two components absent from every reactive system: a Drift Predictor and an Adaptation Generator.

The Drift Predictor is a meta-model that monitors a set of leading-indicator feature statistics computed from the live stream and outputs a probability and estimated magnitude of upcoming drift. The leading indicators are the quantities that change before the target distribution changes: the mean and variance of input features, autocorrelation structure, cross-feature correlation coefficients, and any domain-specific early warning signals available in the application (weather forecasts for energy demand, macroeconomic indices for financial series, scheduled maintenance calendars for industrial equipment). Formally, the predictor takes a window of these statistics as input,

and outputs $(\hat{p}_t^{\text{drift}},\,\hat{m}_t^{\text{drift}})$: the predicted probability of drift in the next $H$ time steps and the predicted magnitude of that drift. The predictor is an MLP trained on historical data where past drift events have been labeled retrospectively (after labels arrived) so the predictor learns which combinations of leading indicators reliably precede real distribution shifts.

The Adaptation Generator takes the drift signal $(\hat{p}_t^{\text{drift}},\,\hat{m}_t^{\text{drift}})$ and the current model parameters $\theta_t$ as inputs and produces a parameter adjustment $\delta\theta_t$ to apply pre-emptively. The generator is not a full retrain; it is a learned small perturbation to $\theta_t$ in the direction that the historical drift trajectory suggests will be beneficial:

where $g_\psi$ is the adaptation generator network (parameterized by $\psi$) trained end-to-end on historical drift episodes. The generator is trained to minimize the model's forecasting loss after the drift arrives, given only the leading-indicator signal available before the drift arrives, making it a form of meta-learning across drift episodes.

Why proactive adaptation works on real-world drifts. Many operationally important drifts are not instantaneous. They are preceded by a detectable ramp: a hot spell begins as a gradual temperature increase over days before peak demand shifts; an economic regime change shows early signals in leading indices before credit risk distributions move; a mechanical fault develops progressively before vibration statistics cross any threshold. The reactive system, by construction, cannot act until the forecast distribution has already shifted enough to raise a statistic. The proactive system detects the ramp in the leading indicators and adjusts before the shift reaches the forecast target. This is precisely the early-warning advantage the reactive system sacrifices by monitoring the error stream rather than the input structure.

The table below compares reactive and proactive adaptation across the dimensions that matter operationally.

The following code sketches the Proceed architecture: the drift feature extractor, the drift predictor MLP, the adaptation generator, and the pre-emptive update loop that connects them at test time.

import torch
import torch.nn as nn

class DriftFeatureExtractor(nn.Module):
    """Extracts leading-indicator statistics from a recent window of input features."""
    def forward(self, x_window):
        # x_window: (window_len, n_features)
        mu   = x_window.mean(dim=0)                            # per-feature mean
        sigma = x_window.std(dim=0)                            # per-feature std
        # Autocorrelation at lag 1 for each feature (Pearson between x[:-1] and x[1:]).
        diff1 = x_window[:-1] - x_window[:-1].mean(dim=0)
        diff2 = x_window[1:]  - x_window[1:].mean(dim=0)
        autocorr = (diff1 * diff2).mean(dim=0) / (
            diff1.std(dim=0).clamp(min=1e-6) * diff2.std(dim=0).clamp(min=1e-6)
        )
        return torch.cat([mu, sigma, autocorr], dim=-1)        # phi_t in R^{3 * n_features}

class DriftPredictor(nn.Module):
    """MLP: phi_t -> (drift probability, drift magnitude) for the next H steps."""
    def __init__(self, phi_dim, hidden=64):
        super().__init__()
        self.net = nn.Sequential(
            nn.Linear(phi_dim, hidden), nn.ReLU(),
            nn.Linear(hidden, hidden),  nn.ReLU(),
            nn.Linear(hidden, 2),
        )

    def forward(self, phi):
        out = self.net(phi)
        p_drift = torch.sigmoid(out[..., 0])                   # drift probability in [0, 1]
        m_drift = out[..., 1]                                  # drift magnitude (signed)
        return p_drift, m_drift

class AdaptationGenerator(nn.Module):
    """Generates a parameter-space delta-theta from the drift signal and current parameters."""
    def __init__(self, drift_dim, param_dim, hidden=128):
        super().__init__()
        self.net = nn.Sequential(
            nn.Linear(drift_dim + param_dim, hidden), nn.ReLU(),
            nn.Linear(hidden, param_dim),
        )

    def forward(self, drift_signal, theta_flat):
        # drift_signal: (p_drift, m_drift) concatenated; theta_flat: flattened model params.
        inp = torch.cat([drift_signal, theta_flat], dim=-1)
        return self.net(inp)                                    # delta_theta in param space

# --- Pre-emptive update loop at test time ---
def proactive_update(forecast_model, feature_extractor, drift_predictor,
                     adaptation_generator, x_window, drift_threshold=0.5):
    """Apply a pre-emptive parameter adjustment when the drift predictor fires."""
    phi = feature_extractor(x_window)                          # extract leading indicators
    p_drift, m_drift = drift_predictor(phi)                    # predict upcoming drift

    if p_drift.item() >= drift_threshold:
        # Flatten current model parameters into a single vector.
        theta_flat = torch.cat([p.data.view(-1) for p in forecast_model.parameters()])
        drift_signal = torch.stack([p_drift, m_drift], dim=-1)
        delta_theta = adaptation_generator(drift_signal, theta_flat)

        # Write the delta back into the model's parameters.
        offset = 0
        with torch.no_grad():
            for param in forecast_model.parameters():
                numel = param.numel()
                param.data += delta_theta[offset:offset + numel].view(param.shape)
                offset += numel

    return p_drift.item()                                      # return signal for logging

# Example test-time call (no labels needed):
# p = proactive_update(forecast_model, extractor, predictor, generator, recent_window)
# y_hat = forecast_model(current_input)

Proactive and reactive adaptation are not competing alternatives; they are complementary layers in a mature adaptive system. The proactive layer (Proceed, TTA) handles the cases where leading indicators or input structure provide early signal; the reactive layer (ADWIN, the tiered alarm of subsections four and five) handles abrupt, unpredictable drifts and serves as the safety net that catches any drift the proactive layer missed. A production deployment running both layers gains the lag reduction of proactive adaptation without sacrificing the coverage of reactive detection, which is exactly the multi-timescale adaptation hierarchy that the adaptive systems of Chapter 21 are building toward. Section 21.3 extends this hierarchy to the active-learning setting, where the system can also decide which future observations to label, closing the loop between adaptation and data acquisition.

7. Exercises

Three exercises, one of each type. Solutions to selected exercises are in Appendix G.