MLOps = DevOps for machine learning
MLOps applies software-engineering discipline (automation, testing, CI/CD, monitoring) to the ML lifecycle. The difference from plain DevOps: an ML system has three things that change — code, data, and the model — not just code. All three must be versioned, tested, and reproducible.
The lifecycle
- Data — collect, clean, label, split, validate. Garbage in, garbage out; most ML failures are data failures.
- Train / experiment — build features, train, tune, track experiments.
- Evaluate — offline metrics against a held-out set; decide if it's good enough to ship.
- Deploy / serve — package the model, expose it (batch or real-time), scale it.
- Monitor — watch performance, latency, cost, and drift in production.
- Retrain / iterate — new data and drift trigger a loop back to training.
The point of MLOps is to make this loop automated, repeatable, and fast — not a one-off notebook that no one can reproduce.
Why it's hard
- Reproducibility — the same code + a different data snapshot = a different model. You must version data and configs, not just code.
- Training/serving skew — features computed differently at train time vs serve time silently break the model. A top real-world bug.
- Silent failure — a model doesn't crash when it's wrong; it just degrades. Monitoring is not optional.
LLMOps
For LLM apps the shape shifts: you often don't train a model — you engineer prompts, retrieval, and tools, and "the model" is a versioned API. So LLMOps centers on prompt/version management, evals (the Evaluation course), cost/token tracking, and feedback loops rather than training pipelines. The lifecycle discipline is the same; the artifacts differ.