Shipping It: MLOps Without the Buzzwords
A model in a notebook is an opinion. A model in production is a promise — that it will keep being roughly this good, for these users, while the world changes underneath it. MLOps is just the reliability engineering that keeps the promise, and 90% of it is ordinary software discipline applied to two unusual artifacts: data and models.
Reproducibility is the foundation
Any prediction in production must be traceable to: the code version (git), the data version, the model artifact, and the training configuration. Assemble it from parts you already know: git for code, immutable versioned data (Part 3's data/raw/ discipline, scaled up), an experiment tracker (MLflow or W&B — a spreadsheet beats nothing) recording every run's config and metrics, and model artifacts stored with checksums, never "final_model_v2_REAL.pkl" on someone's laptop.
Deployment shapes, simplest first
- Batch scoring — a scheduled job writes predictions to a table. Boring, debuggable, and sufficient for most business problems. Start here unless latency forbids it.
- Online service — the model behind an API (FastAPI + a container). Now it's a service like any other: health checks, timeouts, load tests, and a rollback path.
- Streaming/edge — only when the problem genuinely demands millisecond decisions where the data lives.
Ship the pipeline, not the pickle: the same feature code must run in training and serving, or you've built training-serving skew — the production twin of leakage.
Models rot: monitor for drift
Software breaks loudly; models degrade politely, still returning confident numbers as the world walks away from their training data. Watch three layers:
- Data drift: input distributions shifting (new device type, new customer segment, schema change upstream). Cheap statistical checks per feature, alerted like any SLO.
- Prediction drift: the output distribution moving — often the earliest smoke.
- Performance drift: actual accuracy against ground truth, measured as fast as labels arrive (chargebacks in weeks, churn in months — design the feedback loop before launch).
Retraining is the response, on a schedule or a trigger — but always through the same gate: new model beats current champion on the golden evaluation, or it doesn't ship. Automate the pipeline, keep a human on the promote button until trust is earned.
The go-live checklist
- One-command retrain from versioned data; artifact checksummed and registered.
- Same featurization code in train and serve; a skew test proving it.
- Golden-set gate wired into CI; champion/challenger comparison logged.
- Drift dashboards with owners and thresholds, not just charts.
- Rollback rehearsed: previous model restorable in minutes.
- An owner on the rota — a model without an owner is an outage with a lead time.
Checkpoint — and the series, closed
Take the Part 6 model and give it the full treatment: tracked training run, containerized batch scorer, drift check on a held-out "future" month, and a written rollback plan. Do that once and you'll never again wonder what separates a data scientist from a data science engineer — it's this part, done unglamorously, every time.