MLOps: meaning and definition
MLOps in plain language
A model file is only one part of the deployed system. Changes to input preparation or data can alter predictions even if the model itself is unchanged.
Whether a service is up and whether its predictions are good are separate questions. A fast, available endpoint can still give poor predictions once the people or data it sees change.
How it works
A model release needs a feedback path
Operate the whole ML system
- Version + evaluate
Record data, code, model and acceptance tests.
- Release
Deploy the approved combination with a recovery plan.
- Monitor
Inspect service health, input changes and outcome quality.
Investigate a change before deciding whether to retrain, repair data or revert a release.
Make a reproducible candidate
Record data selection, preprocessing, dependencies and training configuration.
Compare before release
Evaluate against the current model and relevant baselines using the same test conditions.
Monitor and respond
Define who investigates alerts and how a prior working version can be restored.
Illustrative example · Fictional data
A fictional routing model encounters a new product
- Input
- A support classifier begins receiving messages about a newly launched product that was absent from its evaluation set.
- Process
- Look at wrong routings, new words and label quality. Build realistic test cases before you update the model.
- Expected output
- A reviewed change with evidence that new-product routing improves without unacceptable regressions elsewhere.
- How to check it
- Do not retrain on the model’s own guesses as if they were verified labels. Keep a reliable evaluation set separate.
Where it helps
- Maintaining deployed prediction services.
- Tracing a result to the model and processing version.
- Managing model updates and recovery.
DevOps, MLOps and LLMOps
- DevOps
- Connects software delivery with operation.
- MLOps
- Adds model, data and predictive-evaluation concerns.
- LLMOps
- Applies operational practices to language-model applications, including prompts, retrieval and generated-output evaluation.
Experiments, versions and registries
Experiment tracking records the data used, code version, settings, results and files for each run. Data versioning identifies the exact inputs. A model registry records model versions and whether they are approved. Together they link a live prediction back to the work that produced it.
MLflow offers tracking and a model registry; DVC is one way to version data and pipelines. Cloud ML platforms can combine managed training, deployment and workflow features. Choose tools for traceability and how you run things, not because you feel you must install every platform.
A minimum useful setup for a small team
Keep code and its dependencies reproducible, know which data trained the model, save the model, test it on data held back from training and deploy it in a repeatable way. Name an owner, keep the previous working version and decide how problems will be spotted and handled. Add automation as the number of models and changes grows.
Watch for changes in the input, speed, failures and results once reliable labels come in. A drift alert is a reason to investigate, not proof that accuracy has dropped. A retrained model should pass testing and release checks before it replaces one that works; retraining automatically on new data can repeat bad labels or a one-off incident.
Related reading and learning pathways
Common pitfalls
- Input drift and accuracy loss are related but not identical.
- Outcome labels may arrive long after predictions.
- An unversioned preprocessing change can break reproducibility.
Put the idea to work
Try it yourself
Write an incident note that names a prediction’s input version, data-preparation version, model and actual result. Mark anything you cannot rebuild today.
Common questions
Does MLOps require automatic retraining?
No. Retraining should follow justified triggers and evaluation, not merely an alert. Retraining can introduce new errors, so compare the new model against the current one on held-out data before release, and keep the ability to roll back.
Is an available endpoint enough?
No. Measure whether the service is running and whether its predictions are good, separately. An endpoint can respond quickly while its predictions get worse because the incoming data has changed. Watch speed and errors alongside accuracy, data drift and business results, and alert on quality, not just on uptime.
Your next step
Continue learning
Connected concepts
Sources and further reading
Examples on this page are teaching exercises using fictional information. They are not client case studies or measured outcomes.