Your team has a model that worked in testing, and now you ask: what is MLOps? It is the set of practices for deploying, monitoring and retraining models so they keep working after launch.
This page is part of the machine learning basics section.
| Item | Value |
|---|---|
| Definition | A set of practices for managing machine learning models throughout their lifecycle |
| Lifecycle cycles | 4 cycles: data, model, development and operations |
| Retraining triggers | A set schedule, or an event such as a performance metric falling below a threshold |
| Gradual release patterns | Shadow, canary and blue-green deployments |
| Monitoring areas | Service health, data quality, model behavior and outcome-based performance |
These figures come from a TechTarget MLOps definition published Sept. 5, 2024 and a Lenovo knowledge-base entry on MLOps. Definitions and practices can change, so check the source before you rely on them.
MLOps in plain terms
The word is short for machine learning operations. According to an MLOps introduction from Arrikto, it brings together practices from machine learning and DevOps alongside data engineering, with the aim of deploying models in production and maintaining them.
It is a set of processes rather than a single framework or product. Developers use those processes to build, deploy, monitor and train their models again and again.
MLOps is modeled on DevOps, which began as a way to unite software developers and IT operations teams. MLOps shares those aims but adds data scientists and ML engineers to the team.
You may also meet the term ModelOps. Because MLOps focuses on operationalizing ML models, it is treated as a subset of ModelOps, which spans AI models of all kinds.
The machine learning lifecycle MLOps manages
MLOps puts the machine learning lifecycle into practice. That lifecycle is the set of stages a model must go through to become production-ready, and one published definition splits it into four cycles.
- Data cycle: gathering and preparing data for training.
- Model cycle: training the model on that data and tracking its versions as it moves through the lifecycle.
- Development cycle: developing, testing and validating the model so it can be deployed to a production environment.
- Operations cycle: end-to-end monitoring that keeps the production model working and retrains it to improve performance over time.
In the data cycle, raw data is pulled from suitable sources and then reshaped with techniques such as feature engineering into labeled data ready for model training. If the term is new to you, a short explainer on what is feature engineering covers the idea.
Version tracking is easier with tooling, and the open source tool MLflow is one example named in that definition. Deployment can then be automated with CI/CD pipelines, which reduce the number of manual tasks.
A model only enters this lifecycle once it exists. If you want the groundwork on how models learn, the explainer on how does machine learning work is a good place to start.
Core building blocks of an MLOps setup
An MLOps system is made of several linked capabilities. According to Lenovo’s MLOps knowledge base, the exact architecture varies by organization size, risk profile and whether workloads are batch or real-time.
Most setups include a handful of common parts:
- Pipelines: repeatable steps for data preparation, training, evaluation and deployment.
- Versioning: tracking changes to the data, code and models used throughout development and deployment.
- Experiment tracking: recording what changed between training runs, which supports reproducibility and makes experiments easier to compare without informal notes.
- Model registry: a catalog of model versions and their metadata.
- Testing: checks that cover the software, data, model performance and prediction service.
Data deserves special care. MLOps commonly adds automated data checks that detect missing values, schema changes, unexpected ranges or shifts in category distributions, so upstream surprises are caught early.
Data tests also look for data leakage, where training uses information that would be unavailable when making real predictions. A model that leaks looks excellent in testing and then disappoints in live use.
How releases, monitoring and retraining work after launch
Shipping a model is not the end of the job. MLOps typically introduces controlled release patterns so a new model can prove itself before it takes over.
- Shadow deployments: send copies of live requests to a new model for evaluation while the current model keeps answering the application.
- Canary releases: route a small portion of traffic to the new model and expand gradually.
- Blue-green deployments: switch traffic between two environments to reduce downtime.
A model can also be deployed to the production environment for testing before it is activated for live use. That lets a team check its performance before its predictions influence decisions.
Once a model is live, monitoring becomes continuous. It usually covers:
- Service health, such as availability, error rates, latency and throughput.
- Data quality, such as schema consistency, missing values and distribution shifts.
- Model behavior, such as prediction distributions, confidence scores and drift indicators.
- Outcome-based performance, using metrics computed when ground truth becomes available.
The main risk monitoring watches for is data drift, in which the accuracy of a model deteriorates over time because the data it was trained on has changed. The TechTarget definition adds that MLOps can retrain a model on a set schedule or when an event, such as a performance metric falling below a threshold, triggers it.
Why teams adopt MLOps, and where it gets hard
The core reason is that production machine learning is never finished. A model that performs well during development can degrade after deployment because of changing data, shifting user behavior or upstream system changes.
The benefits that published definitions describe fall into a few groups:
- Speed and efficiency: automation of repetitive tasks in development and in the ML pipeline.
- Scalability: handling increased workloads, larger data sets and new features.
- Reliability: testing and validation that fix problems in the development phase.
- Governance: traceability, access control and audit trails that support regulatory compliance.
There are costs. Staffing is hard because the data scientists who develop algorithms may not be the most effective at deploying them. Expense is the other issue, since MLOps can be costly given the need to build infrastructure that uses many new tools.
Interest in the field is growing. One vendor glossary cites a market forecast that expects the global MLOps market to exceed USD 39 billion by 2034, though forecasts like this are estimates and methods differ.
Frequently asked questions
Is MLOps the same as DevOps?
Show answer
No. MLOps is modeled on DevOps and shares its aims, but it adds data scientists and ML engineers to the team and manages data, models and retraining as well as code.
Does MLOps replace data scientists?
Show answer
No. The work of data scientists is not changing; operations practices remove data silos and broaden the team so that models already in production can be managed by dedicated engineers.
What is data drift?
Show answer
Data drift is when the accuracy of a model deteriorates over time because the data it was trained on has changed. Monitoring is how teams spot it, and retraining is a common response.
When does a model get retrained?
Show answer
Retraining can run on a set schedule or be triggered by an event, such as a performance metric falling below a threshold. Many teams combine both.
