Applied ML systems
The ML system lifecycle
A deployed model is a loop of data, features, training, evaluation, serving and monitoring. Each stage produces an artifact you can record, check and roll back.
A deployed model is one part of a loop. Data arrives, features are computed, a model trains, gets evaluated, is registered, is served, and is watched. Then the loop runs again. Knowing the stages, and the artifact each one produces, is the map for everything else in production ML.
The loop
- Data. Logs, databases, labels and human feedback.
- Features. Transforms that must match between training and serving.
- Training. Batch jobs or continual training, tracked as experiments.
- Evaluation. Offline metrics and slices, with a gate before promotion.
- Deployment. Batch scores, an online service, or on-device.
- Monitoring. Inputs, predictions, latency and business numbers, plus delayed labels.
- Retraining. Scheduled, or triggered when quality drops.
The model weights are one artifact among many. A training run also produces code, configuration, a data snapshot and an evaluation report. All of them matter when something breaks.
Walking through a registry
Here is a realistic sequence. A fraud model, version 3, is in production. Version 4 trains on Monday. Its offline checks pass, so the pipeline pushes it to a Staging state. A person reviews it and moves the Production alias to version 4.
Serving reads the alias, not a file path. If version 4 misbehaves, moving the alias back to version 3 takes minutes. Nobody rebuilds the service.
Record these for every production model:
- The training job ID and the git commit SHA.
- The data snapshot ID and the evaluation report.
- The thresholds and feature list, versioned with the model.
Common mistakes
- Shipping a file from a laptop. A
model.pklwith no code, data or evaluation record cannot be audited or reproduced. - Treating the model as the whole system. Feature pipelines, configuration and monitoring usually contain more code than the model itself.
- Retraining with no fixed evaluation set. Each retrain then automates a new mistake, and nobody can tell which version is better.
Check yourself
- What makes a rollback fast in a registry setup? Answer: Serving reads a
Productionalias, so rollback moves the alias to the previous version. - Name three things to record next to every production model. Answer: The training job ID, the git commit SHA and the data snapshot ID. The evaluation report and feature list also count.
Key takeaways
- Production ML is a loop, not a single training run.
- Every stage produces an artifact that should be recorded.
- A registry with aliases makes promotion and rollback explicit.
- Most long-term cost sits in pipelines and glue code, not the choice of classifier.
Further learning
Sculley et al. describe why the model code is only a small part of a real system:
Hidden Technical Debt in Machine Learning Systemspapers.nips.ccNext, decide how fresh each prediction needs to be: batch vs online inference.
Related
ML in production
Feature stores, training-serving skew, monitoring for drift and the lifecycle of a deployed model.
Batch vs online inference
Batch scoring writes predictions ahead of time. Online scoring answers while a user waits. Choose by how fresh the features must be and how much latency the product can afford.
LLMOps and observability
Tracing, prompt management, feedback loops and online monitoring for LLM applications.