ML Lifecycle
Beginner 12 min read ML Lifecycle

The ML Lifecycle

A model is never 'done' the day it ships

Operating ML in production is a continuous loop — scope, data, experiment, evaluate, deploy, monitor, retrain — not a one-shot 'build a model' project. This module is the map for everything else in the ML Ops track.

ML lifecycleMLOpsmachine learning operationsmodel lifecyclecontinuous training
Before we start

What you will learn

  • Describe the phases every ML product passes through
  • Contrast a research prototype with a production system
  • Locate where each tool in the MLOps stack fits in the loop
Introduction

What is this?

The ML lifecycle is the end-to-end loop that starts with a business problem, produces a validated model, deploys it, watches how it behaves on live data, and eventually retrains or retires it. Unlike traditional software, ML adds data as a first-class input: your system can degrade silently even when no code changed, because the world the model learned from has changed.

Motivation

Why do you need it?

  • Most ML failures are lifecycle failures — stale data, silent drift, unmonitored retrains — not model-building failures.
  • A research prototype proves feasibility; a lifecycle makes that result repeatable, governable and recoverable.
  • Knowing which phase you're in tells you which tools and tasks matter: tracking here, serving there, monitoring next.
  • Teams that treat ML as a pipeline (not a project) ship trustworthy models and can roll back safely.
Think about it

Mental model

Imagine

Farming: plant → grow → harvest → market → re-seed

Think of

The ML lifecycle

You don't plant once and walk away forever. Soil changes, seasons change, and the harvest has to reach customers on time. An ML product is a crop you tend continuously, not a one-time harvest.

Mechanics

How it works

  • Scope defines the business problem, success metric and the decision the model will influence.
  • Data work gathers, validates and versions the inputs — the most important and most underestimated phase.
  • Experimentation trains and evaluates candidate models, recording every parameter and artifact.
  • The registry stores the winning model with metadata, so it can be served and reproduced later.
  • Deployment serves predictions through batch or real-time paths, integrated with the product.
  • Monitoring watches inputs, outputs, performance proxies and business impact; drift or decay triggers retraining.

The ML lifecycle loop — every stage feeds the next and closes back on itself.

Scope
Data
Experiment
Register
Deploy
Monitor
Retrain
Real world

In production

  • A credit-risk platform scopes 'approval precision', validates applicants CSV daily, retrains monthly, and alerts engineers the moment approval trends drift.
  • An ad-bidding system retrains on a weekly cadence and auto-promotes the new model only after a shadow period shows no revenue regression.
  • A computer-vision plant inspector treats every deployment as one radian of the loop: new imagery versions the dataset and schedules a monitoring review.
Guidelines

Best practices

  • Define the success metric before writing any training code — 'accuracy' only matters if it moves the business metric.
  • Involve data/platform engineers in the lifecycle from the first week, not at deployment time.
  • Make every stage re-runnable from a versioned artifact so you can replay any point in time.
  • Design monitoring from day one, even if the first alerts are coarse.
Watch out

Common mistakes

  • Celebrating model accuracy and ignoring the pipeline that must feed it forever.
  • Treating retraining as an occasional manual chore instead of a scheduled, automated operation.
  • Optimizing a phase in isolation (e.g. hyperparameters) while the data pipeline is silently corrupting inputs.
  • Shipping a model nobody hooked into a decision — model built, value zero.
Root cause analysis

Common issues

Error
Model was accurate in offline eval but fails in production
Root cause

A lifecycle handoff broke the assumptions — training-serving skew, different schema, stale features

Fix

Compare feature distributions train vs live, verify schema at every boundary, and add a shadow deployment.

Error
Product depends on the model but retraining was forgotten for 3 months
Root cause

No automated retrain trigger; monitoring wasn't in the loop

Fix

Schedule retrains and tie them to drift alerts rather than calendar luck.

When things break

Debugging tips

  • When the product fails, walk the loop in order: was data fresh? did training run? did deployment succeed? did monitoring fire?
  • Check the boundaries between phases; most ML incidents are handoff failures (format, schema, timezone).
  • Keep one raw artifact per phase so you can diff what happened versus what should have happened.
Interviews

Interview checkpoint

Test yourself

Quick quiz

0/2
1

A model's accuracy drops six months after deployment although no code changed. What is the most likely cause?

2

An ML model is finished once it passes offline evaluation.

Go deeper

Official documentation

Google MLOps whitepaper — lifecycle & automation
docs
Microsoft — What is MLOps?
docs