Continuous Training Triggers
The rules that decide when a production model gets automatically retrained — on a fixed schedule, on new data volume, or when monitored performance degrades.
A model that's deployed once and never updated will degrade as the world it was trained on drifts away from the world it's now scoring — a well-run production system instead retrains automatically under some trigger condition, rather than waiting for a person to notice performance has slipped. There are three common trigger types. A schedule-based trigger just retrains on a fixed cadence, weekly or monthly, regardless of whether anything has actually changed — simple to reason about but wasteful if nothing has moved, and too slow if something breaks between cycles. A volume-based trigger fires once a set amount of new labeled data has accumulated, useful when data arrives in irregular bursts. A performance-based trigger watches a live metric — accuracy against realized outcomes, a drift statistic on the input distribution — and retrains only when it crosses a threshold, catching real degradation faster but requiring reliable ground truth to arrive quickly enough to compute that metric.
Most production systems in practice combine two of these: a scheduled retrain as a baseline safety net, plus a performance-based trigger that can fire early if monitored drift or error crosses a threshold before the next scheduled run.
Retraining triggers come in three flavors — fixed schedule, new-data volume, and live performance degradation — and most reliable systems combine a scheduled baseline with a performance-based trigger that can retrain early if monitored drift crosses a threshold.
Further reading
- Google Cloud, MLOps: Continuous delivery and automation pipelines in machine learning