MLOps: from notebook to production

Why MLOps?

Many ML projects never reach users, and many that do quietly get worse over time. The causes are rarely the algorithm: nobody can reproduce last month's model, the live data differs from training data, or nobody notices that accuracy dropped after a festival season. MLOps borrows ideas from DevOps (automation, testing, monitoring) and adds the parts that are special to ML: data and models change too.

The ML lifecycle

1. Data: collect, validate and version the training data.
2. Experiment: train models and record every run's code version, data version, settings and scores.
3. Package: save the model with its preprocessing (one pipeline) and its exact library versions.
4. Deploy: serve predictions as an API (real time) or as scheduled jobs (batch).
5. Monitor: watch service health, input data and, when labels arrive, real accuracy.
6. Retrain: on a schedule or when monitoring says so, then evaluate and redeploy safely.

Versioning and experiment tracking

Code goes in Git. Data and model files are too large for Git, so tools such as DVC store versions of them elsewhere while Git keeps small pointers. Experiment trackers such as MLflow record parameters, metrics and the model file for every run, and a model registry marks which version is in staging and which is in production. The goal: anyone can answer "exactly which data and code produced the model that made this prediction?"

Serving: batch and real time

Batch prediction scores many rows on a schedule, such as every night computing churn risk for all customers. Real-time serving answers each request in milliseconds, such as a fraud score during a UPI payment. Real-time models are often wrapped in a small web API.

from fastapi import FastAPI
from pydantic import BaseModel
import joblib

app = FastAPI()
model = joblib.load("churn_pipeline.joblib")      # preprocessing + model, saved together

class Customer(BaseModel):
    tenure_months: int
    monthly_bill: float
    complaints_90d: int

@app.post("/predict")
def predict(c: Customer):
    p = model.predict_proba([[c.tenure_months, c.monthly_bill, c.complaints_90d]])[0][1]
    return {"churn_probability": round(float(p), 3)}

Monitoring: drift

Data drift means the inputs change: a new city launches, prices rise, a festival changes shopping. Concept drift means the relationship between inputs and the target changes: what used to signal fraud no longer does because fraudsters adapted. Monitor input distributions (for example, compare the mean of a feature with its training mean, or use the population stability index, PSI), prediction distributions, and real accuracy when labels arrive. Alert when they move beyond agreed thresholds.

PSI compares the share of values in each bin between training (expected) and live (actual) data: PSI = Σ (actual − expected) × ln(actual ÷ expected). A common rule of thumb reads below 0.1 as little change, 0.1–0.25 as moderate and above 0.25 as a big shift, but agree thresholds for your own use case.

CI/CD for ML

Automate: tests for data (no missing ids, values in range), tests for code, an evaluation gate (the new model must beat the current one on the test set), and safe rollout such as shadow mode (the new model predicts silently alongside the old one) or a canary (a small share of traffic first). Keep the old model ready for a quick rollback.

Common mistakes

• Different preprocessing in training and serving ("training-serving skew"). Fix: ship one pipeline.
• No monitoring, so a broken input feed goes unnoticed for weeks.
• Retraining automatically on bad data without an evaluation gate.
• Not recording which model version made which prediction.