"They froze my weights on a Tuesday in spring and shipped me to a machine that has not stopped changing since. I was correct once. Correctness, it turns out, has a shelf life."
A Perishable AI Agent
Prerequisites
This section assumes you understand a trained model as a fixed function of its weights, and that sensors are physical devices whose response drifts with age, temperature, and mounting (Chapter 2). It leans on the notion of a data distribution and how a test distribution can diverge from the training one; the formal treatment of that divergence lives in Chapter 66. The retrain-and-ship machinery this section critiques is the subject of Chapter 69. No new mathematics is introduced; the one model here is a simple decay curve you could sketch on a napkin.
The Big Picture
The dominant deployment story in machine learning is: train once on a big dataset, validate, freeze the weights, ship the artifact, and treat it as done. That story is quietly built on an assumption that the world the model will see tomorrow looks like the data it saw in training. For sensory AI that assumption is not merely imperfect; it is structurally false. Sensors age, users change, seasons turn, firmware updates, and the phenomenon being measured evolves. A frozen model does not stay correct: it decays, and it decays on a clock set by the physical world, not by your release calendar. This section makes the case that a static model on a live sensor is a depreciating asset, quantifies how fast it depreciates, and shows why the obvious fix, periodic retraining in the cloud, cannot reach every device fast enough or cheaply enough. That gap is exactly the space this chapter fills.
The static assumption and the moving world
A deployed model is a function \(f_\theta\) with the weights \(\theta\) frozen at the moment you export the artifact. Static deployment bets that the joint distribution \(p(x, y)\) of sensor inputs \(x\) and labels \(y\) at inference time matches the training distribution \(p_{\text{train}}(x, y)\). The bet pays off in a controlled benchmark. It fails in the field because sensor data is non-stationary: the distribution the model faces is a moving target, and it moves for reasons that have nothing to do with your model.
The movement has several distinct sources, and it helps to name them because each demands a different response. Sensor drift is the slow change of the transducer itself: an electrochemical gas sensor loses sensitivity over months, an IMU's bias walks with temperature, a camera's lens hazes. The measured \(x\) changes even when the underlying physical truth does not (Chapter 2). Environmental shift is change in the world being sensed: a factory line runs a new product, a wearer moves from a cold winter to a humid summer, road conditions vary by geography. Behavioral and user shift is the drift of the subject: a person's gait changes after an injury, their resting heart rate falls as they train, their vocabulary of gestures grows. And concept shift is when the mapping \(p(y \mid x)\) itself moves: the same vibration signature that meant "healthy" on a new bearing means "worn" on an aged one. A model frozen against one snapshot of \(p(x, y)\) is wrong about all four the moment they begin to move, which is immediately.
Key Insight
Static deployment implicitly treats a sensor stream as a stationary process, but a sensor sits inside a physical system that is guaranteed to be non-stationary: it ages, its subject changes, and its environment turns over. The question is never whether a frozen model will drift out of calibration, only how fast. "Train once and freeze" is therefore not a neutral default; it is an unstated and usually wrong assumption about stationarity. The professional move is to make the stationarity assumption explicit, measure its half-life, and design for the case where it does not hold.
Quantifying decay: a model has a half-life
It is tempting to treat drift as a vague worry. It is better treated as a measurable decay curve. Suppose accuracy \(a(t)\) starts at \(a_0\) on release day and erodes as the field distribution drifts away from the training snapshot. A useful first-order model is exponential relaxation toward a floor \(a_\infty\) (chance level, or the accuracy of guessing the majority class):
\[ a(t) = a_\infty + (a_0 - a_\infty)\, e^{-t / \tau} \]where \(\tau\) is the drift time constant: small \(\tau\) for a fast-changing wearable on a growing child, large \(\tau\) for a temperature-stabilized lab instrument. The half-life of usefulness, the time to lose half the gap between launch accuracy and the floor, is \(t_{1/2} = \tau \ln 2\). The value of this framing is that it turns an argument into a number you can put next to a maintenance schedule: if \(\tau\) is three weeks, a model refreshed quarterly spends most of its deployed life below its acceptance threshold. The snippet below plots the decay and marks where accuracy crosses a service-level line.
import numpy as np
a0, a_inf, tau = 0.94, 0.50, 21.0 # launch acc, floor, drift constant (days)
threshold = 0.85 # contractual minimum accuracy
t = np.arange(0, 120)
acc = a_inf + (a0 - a_inf) * np.exp(-t / tau)
half_life = tau * np.log(2)
below = t[acc < threshold]
crosses = below[0] if below.size else None
print(f"half-life of usefulness: {half_life:5.1f} days")
print(f"drops below {threshold:.2f} after: {crosses} days")
print(f"accuracy at day 90: {acc[90]:.3f}")As Listing 62.1.1 shows, a model with a modest three-week drift constant breaches an \(85\%\) contract inside two weeks. If your release cadence is measured in months and your decay is measured in weeks, static deployment guarantees that most devices in your fleet are running a stale model most of the time. Measuring \(\tau\) for a real deployment, ideally with time-aware, leakage-safe evaluation so the estimate is not optimistic (Chapter 5), is one of the highest-value diagnostics you can run before deciding how a model should be maintained.
Field Story: a continuous glucose sensor that ages by the hour
A continuous glucose monitor worn under the skin degrades measurably over its ten-day wear period: enzyme activity falls, the tissue reaction around the filament evolves, and the raw current-to-glucose mapping drifts continuously from insertion to removal. A single factory-frozen calibration model is systematically wrong on day one (a fresh, still-settling sensor) and wrong again on day nine (a spent one), in opposite directions. Vendors handle this not by shipping a better static model but by letting the calibration adapt over the wear cycle, nudged by occasional reference measurements. The physical truth is blunt: the sensor the model was trained on no longer exists a week later; it has chemically become a different device on the same wrist. No amount of cloud retraining reaches inside the wear cycle of one specific sensor on one specific person. Only adaptation local to that device does.
Why the cloud retrain loop cannot close the gap
The textbook answer to drift is the MLOps loop: monitor the fleet, collect fresh labeled data, retrain in the cloud, validate, and push a new artifact over the air (Chapter 69). This loop is real, valuable, and necessary, and it is also insufficient on its own for four reasons that recur across every sensor domain.
First, latency. The loop's period is set by human review, data pipelines, and staged rollouts, and it is measured in weeks to months. When \(\tau\) is measured in days, the loop is chasing a target that has already moved by the time the new artifact lands. Second, labels. Retraining needs ground truth, but the field is where labels are scarcest: no one annotates a wearer's activities, and the interesting drift is precisely the novel condition you have no labeled examples of yet. Third, connectivity and privacy. A batteryless soil sensor, an implanted device, or a factory node behind an air gap may rarely or never phone home, and much sensor data is biometric or proprietary and may not be allowed to leave the device at all (Chapter 64). Fourth, and most fundamental, heterogeneity. A single global model shipped to a million devices is a compromise averaged over all of them; it is optimal for none. The best model for this pump, on this foundation, in this climate, differs from the fleet average, and no central retrain can produce a million bespoke models. The optimum is per-device, and per-device optimization has to happen on the device.
Research Frontier
The frontier is moving the adaptation itself onto the sensor. Latent replay for on-device continual learning (Pellegrini et al., 2020) showed rehearsal-based updates running on a Raspberry-Pi-class device; TinyOL (Ren et al., 2021) demonstrated incremental training on a microcontroller with kilobytes of RAM; and test-time adaptation methods such as Tent (Wang et al., ICLR 2021) update a model from unlabeled test data alone, sidestepping the label bottleneck entirely (Chapter 66). The open problem this chapter circles is doing all of this under a real edge budget: adapting fast enough to track \(\tau\), without forgetting what was learned before (Section 62.2), and inside an energy envelope a battery can sustain (Section 62.5).
The Right Tool
You do not have to build the continual-learning bookkeeping, the replay buffers, the per-task accuracy matrices, and the forgetting metrics, from scratch to start measuring drift and adaptation. The Avalanche library packages the standard benchmarks, strategies, and metrics behind a few lines.
from avalanche.benchmarks import nc_benchmark
from avalanche.training import Naive
from avalanche.evaluation.metrics import forgetting_metrics
bench = nc_benchmark(train_ds, test_ds, n_experiences=5, task_labels=False)
strategy = Naive(model, optimizer, criterion, train_mb_size=32)
for experience in bench.train_stream:
strategy.train(experience) # adapt as each new "experience" arrives
strategy.eval(bench.test_stream) # track accuracy and forgetting over timeListing 62.1.2 removes the harness, not the hard part. Whether an adaptation strategy actually holds up under a leakage-safe, time-aware evaluation is a judgment the library cannot make for you.
From maintenance chore to design principle
Put the pieces together and a conclusion emerges that reframes the whole problem. Static deployment is not a stable end state that occasionally needs a patch; it is the beginning of a decay you have chosen not to manage. For a large class of sensor products, the right response is to treat the model less like a shipped artifact and more like an organism that keeps learning in place, adapting to its own drifting sensor, its own user, its own site. This is a spectrum, not a binary: some models can and should stay frozen (a certified safety classifier whose behavior must be auditable and unchanging), and cloud retraining remains the backbone for large architectural updates. The argument here is narrower and firmer: for non-stationary sensor streams, some capacity to adapt on-device is not a luxury feature but a precondition for staying correct. The streaming and online-learning machinery of Chapter 60 is one route in; this chapter takes the harder road of updating the model's learned representation itself, on the device, without a supervisor and without forgetting.
That road has a signature hazard, which is why it needs a whole chapter and not a paragraph. The moment you let a model update itself on a live stream, you invite it to overwrite what it already knew. Naively adapting to today's data can erase yesterday's competence, and doing it on a device with kilobytes of memory and a battery makes every safeguard expensive. Establishing that hazard precisely is where we go next.
Exercise
Take a sensing product you can observe, such as a fitness tracker's step counter or a phone's face-unlock. Sketch its accuracy decay \(a(t)\) qualitatively and estimate its drift time constant \(\tau\): does it drift over hours (a wound-healing biosignal), weeks (a person's fitness), or years (a fixed industrial vibration sensor)? Then classify the dominant driver as sensor drift, environmental shift, behavioral shift, or concept shift, and argue in three sentences whether a monthly cloud retrain could keep it above an \(85\%\) service level, or whether on-device adaptation is required.
Self-Check
1. Name the four sources of non-stationarity in a sensor stream and give a one-line example of each. Which one changes \(p(y \mid x)\) rather than \(p(x)\)?
2. In the decay model \(a(t) = a_\infty + (a_0 - a_\infty)e^{-t/\tau}\), what does \(\tau\) represent physically, and how does the usefulness half-life relate to it?
3. Give two reasons the cloud retrain-and-push loop cannot, by itself, keep a fast-drifting per-device sensor model calibrated. Why does fleet heterogeneity in particular argue for on-device adaptation?
What's Next
In Section 62.2, we confront the price of adaptation. Once a model is allowed to keep learning on a live sensor stream, updating it on new data tends to overwrite the old, a failure mode called catastrophic forgetting. We will see why it is especially vicious on the edge, where you cannot keep the original training set around to rehearse from, and set up the memory and energy constraints that shape every solution in the rest of the chapter.