"A model in a notebook helps no one. MLOps is how models get into the real world — and stay reliable once they're there."
Learning Objectives
By the end of this module, you will be able to:
- Explain what MLOps is
- Understand deployment and monitoring
- Know why models need ongoing care
1. From Notebook to Product
MLOps (Machine Learning Operations) is the practice of putting models into production and keeping them healthy — the bridge from experiment to real, running service.
Key idea: Training a model is only half the job. MLOps handles the other half: deploying it so apps can use it, and watching it so it keeps working as the world changes.
Explain like I'm new: Building a great model in a notebook is like cooking a delicious meal in your test kitchen. MLOps is everything it takes to open a restaurant: getting the dish onto real customers' plates reliably, every night, and noticing quickly when the quality slips. A recipe nobody can order is just a nice idea.
Why does this deserve its own discipline? Because production is a harsh environment. Real data arrives messier than your training data, at higher volume, and never stops. The app calling your model expects an answer in milliseconds, every time, without crashing. And the moment your model starts affecting real decisions — prices shown, loans approved, posts recommended — mistakes have real consequences. MLOps borrows hard-won practices from software engineering (automation, testing, monitoring, version control) and adapts them to the fact that models depend on data, which drifts, not just on code, which sits still.
Concept: A model in production is a living system, not a finished document. Code you write once tends to keep working; a model quietly gets worse as the world it learned from moves on. That single difference — that models decay — is the reason MLOps exists.
2. The MLOps Loop
| Step | What it means |
|---|---|
| Deploy | Turn the model into a live service (an API) |
| Monitor | Track its accuracy and health in production |
| Detect drift | Notice when data changes and accuracy slips |
| Retrain | Update the model on fresh data |
| Version | Track models and data so you can roll back |
Notice it's a loop, not a straight line. You deploy, watch how the model behaves on live data, catch problems, retrain on newer data, and deploy again — around and around. Versioning is the safety net that makes this possible: by tracking exactly which model and which data produced which results, you can roll back to yesterday's working version the moment a new one misbehaves — just like undo in a document.
3. Why Models Decay: Drift
The world changes, so a model trained on last year's data slowly goes stale — this is drift. Shopping habits shift, new words appear, trends move. Without monitoring, accuracy quietly erodes.
Simple example: A demand-forecasting model trained before a big trend shift keeps predicting the old pattern — quietly wrong for months until someone notices. Monitoring catches this early.
Real-world use case: A bank's fraud model was trained before fraudsters adopted a new scam. The model keeps waving those transactions through because it never saw the pattern — drift in action. A monitoring dashboard flags a slow drop in caught-fraud rate, the team retrains on recent cases, and detection recovers. Without monitoring, the loss would have grown silently.
The dangerous thing about drift is that nothing breaks. The model keeps running, returning confident answers — they're just increasingly wrong. That's why MLOps treats monitoring as essential infrastructure, not an afterthought: it's the smoke detector that catches a problem you'd otherwise never see.
Drift comes in two everyday flavors. Data drift is when the incoming data itself shifts — a new customer age group, a new product line, a holiday season. Concept drift is when the relationship you learned changes — what counted as fraud last year is done differently this year. Both erode accuracy, and both are caught the same way: by comparing recent live performance against what you saw at launch, and retraining when the gap grows too wide.
Common mistake: "Deploy and forget." A launched model isn't finished — it needs monitoring and occasional retraining, or it silently degrades. The most dangerous model is one everyone assumes still works.
Data scientist tip: Set up monitoring before you deploy, not after something goes wrong. Decide upfront which metric you'll watch and what number should trigger a retrain — a plan beats scrambling once accuracy has already slipped.
Key Takeaway: MLOps takes models from notebook to production and keeps them reliable: deploy (as a live service), monitor, detect drift, retrain on fresh data, and version for rollbacks. It's a continuous loop, not a one-time launch. Models decay as the world changes, so "deploy and monitor" — never "deploy and forget."
Further Learning
Part of the "Data Science and Data Scientist" course.