The machine learning lifecycle is the sequence of stages between a business question and a model answering requests in production, and it describes everything around the model, which is a small part of the system. The framing dates from 1999, when a consortium published the first standard process for data mining projects with six phases running from business understanding to deployment, and it was sharpened in 2015 by a widely cited paper from Google engineers whose diagram showed the model as a small box surrounded by much larger boxes for data collection, verification, serving and monitoring. Both vendor examinations name the stages, and the Practitioner course cares because most of the effort and most of the failures live in the stages before and after training.
The sections below take the stages before the model, the building of the model, the delivery of it to users, the work after deployment, where each vendor's tooling sits along the line, and end with a fifteen minute ownership grid.
The stages before the model
Four stages precede training, and the ceiling on everything that follows is set in the first of them.
Data collection gathers what the model will learn from. A model cannot know something absent from its training data.
Exploratory data analysis is the look before the work. Distributions, missing values, obvious errors, and whether the data actually contains the signal the team assumed. This is where most projects should stop and many do not.
Preprocessing cleans and shapes. Handling missing values, removing duplicates, normalising scales, encoding categories as numbers, and splitting into training, validation and test sets.
Feature engineering turns raw fields into things a model can use. A timestamp becomes day of week and hour. Two columns become a ratio. Domain knowledge enters the system here, and on classical machine learning problems it usually beats a cleverer algorithm.
Building the model
Once the features exist, three stages produce and check the model.
Training runs the algorithm over the training set to produce a model.
Hyperparameter tuning adjusts the settings the team chose, and leaves the weights the model learned alone. Learning rate, network depth, number of trees. Tuning means training several times and comparing, which is why it costs what it does.
Evaluation measures performance on data the model has not seen. Judging a model on its training data says only how well it memorised.
Getting the model to users
Deployment is the stage at which the team makes the evaluated model available to the application that will call it, and it happens in one of two ways. With a managed API service the cloud provider hosts the model and charges per call or per hour. With self hosting the team runs the model on its own servers, which takes more engineering time and gives the team more control over latency, over where the data is processed and over cost at high volume.
The second decision is when the model runs. Real time inference answers each request while a person waits, so the constraint is latency. Batch inference scores a large set of records on a schedule, so the constraint is throughput. A fraud check at checkout is real time. Churn scores for tomorrow's mailing are batch, and paying for a low latency endpoint to produce them wastes money.
After deployment
Deployment is the point at which the model starts to decay, and monitoring watches two different things. Operational health covers latency, errors and cost. Model health covers accuracy against outcomes as they arrive, and drift, which is the world moving away from the data the model learned on. Drift is silent. Nothing breaks, the predictions simply get worse, and a retraining trigger and an eventual retirement belong in the plan from the start.
Where AWS puts the stages
Amazon SageMaker covers the pipeline end to end, and the AWS exam expects a few components by name. SageMaker Data Wrangler for preparation, SageMaker Feature Store for reusable features, SageMaker Model Monitor for drift and quality after deployment, SageMaker Clarify for bias and explanations, and SageMaker JumpStart for pre trained models to start from.
The instinct worth having is to look for an existing model first. Sources of models run from a managed service that needs no training, through an open source pre trained model the team adapts, to a custom model trained from scratch, and the cost rises steeply along that line.
Where Google Cloud puts the stages
The Google exam uses a shorter list of five stages and asks for the tool at each. Data ingestion into Cloud Storage or BigQuery. Data preparation with BigQuery and Dataflow. Model training and tuning on Agent Platform, the current name for the Vertex AI tooling, with AutoML where a custom predictive model is wanted without writing training code. Deployment to an Agent Platform endpoint. And model management, covering versioning, monitoring for drift and the Feature Store for reusable features.
The same instinct applies. Model Garden holds Google's models, open models and third party ones, and a prebuilt API frequently answers the problem before any of this is needed.
Practise this
The exercise needs one feature of the team's own that already runs on a model, and the discipline to write a person's name in every row, with no team names allowed.
Fill in the grid for that feature. An owner is one named person who would be called if the row went wrong, so a squad, a rota or "the platform team" counts as blank. Add the date the row was last done and the date it is next due, and where no date exists, leave it empty.
Feature ..........................................
Stage Named owner Last done Next due
Data collection ___________ _________ ________
Exploratory analysis ___________ _________ ________
Preprocessing ___________ _________ ________
Feature engineering ___________ _________ ________
Training ___________ _________ ________
Hyperparameter tuning ___________ _________ ________
Evaluation ___________ _________ ________
Deployment ___________ _________ ________
Monitoring, operational ___________ _________ ________
Monitoring, model health ___________ _________ ________
Retraining trigger ___________ _________ ________
Retirement ___________ _________ ________
Read the blanks from the bottom up. Nearly every team fills the rows down to deployment and thins out below it, and the ones reliably empty are model health monitoring, the retraining trigger and retirement, which is to say nobody is watching the model get worse, nobody has agreed what triggers a retrain, and nobody has thought about switching it off. A missing next due date is worth as much as a missing name, because a row owned in principle and never scheduled behaves exactly like an unowned one.
The grid turns a diagram everybody nods at into a short list of specific gaps with the team's own names against them.