Why Models Break in Production
Tunebox, a music streaming service, wants to know which subscribers are about to cancel so it can send them an offer first. A data scientist trains a churn model in a notebook and gets an excellent score. Three months after launch, the retention team says the predictions "feel random". Nobody changed the model. So what broke?
The rule
The model is the small part; the system around it breaks.
A trained model is one file. To be useful it needs a whole system around it:
- Data pipelines that collect and clean fresh subscriber data every day.
- Feature code that turns raw events into inputs such as
days_since_last_loginandskips_per_week. - Training infrastructure that can rebuild the model when data changes.
- Serving that answers "will this user churn?" fast enough for the app.
- Monitoring that notices when answers stop being good.
MLOps (machine learning operations) is the set of practices for building, shipping and running that whole system reliably. It borrows from DevOps — version control, automated tests, continuous delivery, monitoring — and adds what is special about ML: the behaviour of the product depends on data, not only on code.
That difference matters. A normal program with the same code gives the same result forever. A model with the same code can quietly get worse, because the world it learned from has moved on.
The shortcut
When a model misbehaves, check the four places outside the algorithm before touching the algorithm: data, code, environment, world.
Data
Is the input pipeline healthy? A broken join might be filling
days_since_last_loginwith zeros, making everyone look active.
The trap is to retrain or tune the model first. If the real cause is a broken pipeline, a fresh model trained on broken data only hides the problem for a while.
Drills
Answer fast — trust the rule.
What does MLOps add on top of ordinary DevOps practice?
The churn service computes skips_per_week differently from the training notebook. Which of the four places is the cause?
The code, data pipeline and libraries are unchanged, yet accuracy slowly falls after a competitor launches. What is the likeliest cause?
Why is "retrain the model" a risky first reaction to bad predictions?
Remember
- The model is the small part; the system around it is where most failures happen.
- Diagnose in four places before blaming the algorithm: data, code, environment, world.
- Trap: retraining first can bake a pipeline bug into a brand-new model.