Drift, Feedback Loops, and Retraining
In one line: a model is trained on a snapshot of a world that keeps moving, and the interesting part is that the model itself is one of the things moving it.
Three distinct drifts
These get used interchangeably and they have different causes, different detection methods and different fixes. Separating them is a level signal on its own.
| Data drift | Concept drift | Prediction drift | |
|---|---|---|---|
| What moved | The input distribution | The relationship between input and target | The output distribution |
| Example | A marketing push brings a new user demographic | Fraud tactics change, so the same features now mean something else | The model suddenly flags twice as much |
| Needs labels to detect | |||
| Model still valid? | Possibly — it may generalise | No — what it learned is now wrong | It is a symptom, not a cause |
The row that matters operationally is needs labels to detect. Concept drift is the one that actually invalidates your model, and it is the one you cannot see until labels arrive — which, as the labels lesson established, can be 90 days.
So you monitor what you can see immediately, as a leading indicator for what you care about but cannot yet measure.
Prediction drift is the cheapest and most under-used signal here. It needs no labels, no feature-level instrumentation, and it catches a wide range of upstream breakage — a feature pipeline that silently started returning nulls shows up as a shifted score histogram long before anyone notices the accuracy.
Data drift is not automatically a problem
Worth saying, because over-alerting on it is the standard first mistake. An input distribution can move a long way while model quality is untouched — a new locale whose users behave like an existing one is drift the model handles fine.
Alert on data drift as a prompt to investigate, not as an incident. If every distribution shift pages someone, the alert gets muted within a month and you lose the signal you built.
The feedback loop is the one with no classical analogue
Data drift and concept drift both happen to the system. The feedback loop is caused by it, and it is where the genuinely hard reasoning lives.
Whatever the system ranks highly gets shown; whatever gets shown gets clicked; clicks become labels; labels train the next model to rank those things higher still.
Three named failures come out of this loop, and being able to name them is worth more than describing the loop generically.
Popularity collapse. Diversity narrows over successive retrains. The catalogue effectively shrinks to whatever was popular when the loop started.
Filter bubbles. The same dynamic per user. Each retrain makes the system more confident about a narrower model of what someone wants, and less able to discover it was wrong.
Degenerate feedback in moderation and fraud. You block a class of behaviour, so it stops generating outcomes, so it disappears from training data, so the next model forgets it was ever a problem — and the block quietly weakens.
Breaking the loop
The countermeasures are all versions of deliberately spending something now to keep information flowing.
| Countermeasure | What it costs |
|---|---|
| Position-debiased training weights | Nothing to serve; requires logging propensities |
| An exploration budget — show uncertain items | Short-term metric, deliberately |
| A randomised holdout slice with no personalisation | A small population's experience |
| Let a budgeted share of blocked cases through | Real risk, capped and accounted for |
| Inject fresh or cold-start items into candidates | Some precision, by design |
Every row is a cost paid today for information tomorrow, and framing them that way is what makes the answer sound like operating experience rather than a list.
What should trigger a retrain
Candidates usually answer "we retrain weekly". That is a schedule, not a policy, and the follow-up question is always why weekly.
There are three trigger types and mature systems use more than one.
Scheduled. Simple, predictable, easy to operate, and either too often or too late — it is unrelated to whether anything actually changed.
Performance-triggered. Retrain when a quality metric crosses a threshold. Correct in principle, and it needs labels, so it is slow exactly where labels are delayed.
Drift-triggered. Retrain when input or prediction distributions move beyond a bound. Fast and label-free, and it fires on drift that would not have hurt you.
That closing point is the one worth making. A retrained model is a new model. It goes through the same evaluation ladder, the same regression suite and the same guardrails as any other change. Teams that treat retraining as routine maintenance rather than as a deployment ship regressions automatically, on a schedule, which is a considerably worse failure than shipping one by hand.
Key takeaway
Separate the three drifts: data drift moves the inputs, concept drift invalidates what you learned, and prediction drift is a symptom you can measure without labels — which makes it the leading indicator when the true labels are months away. The feedback loop is the one with no classical analogue, because the system's own output becomes its successor's training data, and every countermeasure is a cost paid today to keep that data honest. Trigger retraining on drift or performance rather than only the calendar, and treat every retrain as a deployment that must clear the same gate.
Next: how to see any of this, in a system that never raises an error.