MLOps

MLOps (machine learning operations) is the work of keeping an AI model reliable after it goes live: knowing which version runs, checking whether its predictions still hold as customers, prices and seasons change, and updating it without breaking anything. Think of product recommendations in a webshop or a sales forecast for a garden centre. Without that upkeep, a model can slowly get worse without anyone noticing.

Where does MLOps come from?

The name borrows from DevOps, the practice of automating how software is tested and released so that changes reach users faster and more reliably. In 2015, Google engineers (Sculley et al.) warned that machine learning systems carry large hidden maintenance costs: in a real system the model code is only a small part, surrounded by data collection, configuration, serving and monitoring. Google Cloud describes MLOps as an engineering culture and practice that unites the development and the operation of machine learning systems, with automation and monitoring at every step. Based on the literature, the tools and eight expert interviews, Kreuzberger et al. (2022) place MLOps where machine learning, software engineering (especially DevOps) and data engineering meet.

Why does a model need upkeep?

A model learns from data, and the world that produced the data keeps changing. Google writes that models can decay in more ways than conventional software because data profiles keep evolving. It advises tracking summary statistics of the incoming data and the model's performance in production, with an alert or a rollback when values deviate. Google's triggers for retraining include a fixed schedule, the arrival of new data, a drop in performance and a noticeable shift in the input data.

How does it work?

Google describes three levels of maturity:

1. Level 0, manual. Every step, from preparing data to training and deploying, is done by hand in scripts and notebooks. According to Google this is the most common level, and a new model version goes live only a couple of times per year.
2. Level 1, an automated training pipeline. The model is retrained on new data automatically, with automated checks on the data and the model (continuous training).
3. Level 2, CI/CD for the pipeline itself. Changes to the pipeline code are built, tested and deployed automatically, so a team can try new ideas quickly.

Kreuzberger et al. name the principles behind it, among them versioning of data, model and code, tracking of experiments and metadata, continuous training and evaluation, monitoring and feedback loops. Open-source tools such as MLflow (experiment tracking and a model registry) and Kubeflow (tools for data and AI workloads on Kubernetes) cover parts of this, and the large cloud providers offer managed platforms.

What changes with language models?

Google calls LLMOps a subset of MLOps that focuses on managing large language models. Applications built on these models add their own tasks: MLflow, for example, advertises tracing, evaluation and prompt management for LLM applications and agents next to its model lifecycle features (September 2026). The advice in the entry on prompt engineering applies here as well: pin the model version and test prompts before changing them.

Example

Suppose a garden centre uses a model that forecasts weekly sales per product group, so it can order the right stock. At level 0, an analyst retrains it by hand now and then. With MLOps, the shop keeps each model version with the data it was trained on, compares the forecast with actual sales every week, and gets an alert when the error grows, for example after a heatwave shifts demand. The model is then retrained on recent data, and if the new version forecasts worse, the shop switches back to the previous one.