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.
Discussion
💡 Discussion rules
- Ask and answer about this concept. Off-topic gets removed.
- No homework dumps. Show what you tried first.
- Corrections are welcome. Cite a source when you claim an error.
Loading discussion…
Further reading
- Google Cloud, MLOps: Continuous delivery and automation pipelines in machine learning