ML Fundamentals
The Machine Learning Workflow: From Data to Deployment
Real machine learning is a circuit: frame the problem, get data, clean and split it, train, evaluate, deploy, then go round again. This lesson walks the whole pipeline end to end.
beginner · 12 min read
Lesson content
Choosing an algorithm is a small part of a real machine learning project. On most projects it is an afternoon.
Far more of the work goes into framing a question worth answering, wrangling messy records into a usable table, checking honestly whether the result is any good, and keeping it working once real traffic hits it.
This lesson is the map of that whole journey: the stages every project moves through, and back through.
The six stages
Frame the problem
Decide what you are predicting and how you will know whether it is good enough. Write the success number down before you start. A vague goal produces a useless model no matter how well it is built.
Get the data
Gather examples, then actually look at them. Plot distributions, count missing values, check that the labels mean what somebody told you they mean.
Clean and split
Handle missing values, fix errors, encode categories, scale features. Then hold out a test set and seal it away before you do anything else. Splitting late is how leakage gets in.
Train
Fit one or more algorithms on the training data. Usually the quickest stage of all, and often a single line of code.
Evaluate
Measure performance on data the model has never seen, using a metric that matches the goal you wrote down in stage one. Compare candidates honestly.
Deploy and monitor
Put the chosen model where it can make real predictions, then keep watching it. The world drifts away from the data it learned on, and nothing tells you except monitoring.
Written as a list, those six look like a checklist you complete once. They are not.
Stages three to five form a tight loop that you will run many times: clean, train, evaluate, discover the result is mediocre, go back and change the features, run it again.
Most of a project's calendar time is spent inside that loop, and almost none of it is spent on stage four.
| Stage | Share of effort | Why |
|---|---|---|
| Framing the problem | Small but decisive | Cheap to do, ruinous to get wrong |
| Getting the data | Large | Access, permissions, joins, and finding out the data is not what you were told |
| Cleaning and feature work | Largest | Every column needs deciding about, and this is where accuracy is actually won |
| Training | Small | Often one line, repeated |
| Evaluation | Moderate | Choosing the right metric is harder than computing it |
| Deployment and monitoring | Ongoing | Never finishes while the model is live |
Exact percentages vary with the project and are widely argued over. The shape does not: preparation dominates and training does not.
Why does data preparation take so much more time than training?
Because real data is never clean. Values are missing, formats clash, categories are misspelled three different ways, units are inconsistent and outliers hide data-entry errors rather than genuine surprises.
On top of that sits feature work, which is the part that actually moves the numbers. Turning a raw timestamp into "hour of day" and "is it a weekend" can help more than swapping your model for a fancier one.
A model can only be as good as what it is fed. Training is a library call. Deciding what to feed it is the job.
The workflow is a loop, and the return leg lands on the data
When evaluation disappoints, the instinct is to try a different algorithm. That is the least productive move available.
Almost always the better return is to the data: gather more examples, fix a leaky column, build a feature that encodes something the model cannot infer, or admit the problem was framed wrongly.
Expect to go round several times. Treating the six stages as a one-way checklist is the classic beginner mistake, and it is why so many first projects stall at a mediocre score.
Example
One project, three laps
A team wants to predict which customers will cancel next month.
Lap one. They pull a year of account records, clean the obvious mess, train a model and score 71%. Not good enough.
Lap two. Looking at the errors, they notice the model does badly on new customers. They add tenure and time-since-last-login as features. Back through cleaning, training, evaluation: 79%.
Lap three. Someone spots that the data includes a "cancellation reason" column, which only exists after a customer has already cancelled. It was leaking the answer. They drop it, score honestly, and get 76%.
That third lap lowered the number and improved the model. This is the part that surprises people.
| Stage | What goes in | What comes out |
|---|---|---|
| Frame | A business question | A prediction target and a success threshold |
| Get data | Systems, logs, surveys | Raw examples, and a list of their problems |
| Clean and split | Raw examples | A tidy feature table, plus a sealed test set |
| Train | The training split | A fitted model: a set of parameters |
| Evaluate | The model and held-out data | A number you can defend, or a reason to go back |
| Deploy | The chosen model | Live predictions, and a monitoring problem |
Frame
- What goes in
- A business question
- What comes out
- A prediction target and a success threshold
Get data
- What goes in
- Systems, logs, surveys
- What comes out
- Raw examples, and a list of their problems
Clean and split
- What goes in
- Raw examples
- What comes out
- A tidy feature table, plus a sealed test set
Train
- What goes in
- The training split
- What comes out
- A fitted model: a set of parameters
Evaluate
- What goes in
- The model and held-out data
- What comes out
- A number you can defend, or a reason to go back
Deploy
- What goes in
- The chosen model
- What comes out
- Live predictions, and a monitoring problem
Cooking, not assembling
Training a model is the twenty minutes the dish spends in the oven. Everyone who has cooked knows that is not where the evening goes.
The evening goes on deciding what to make, shopping, finding out the shop had no fennel, chopping, and tasting as you go.
And tasting is the part beginners skip. You taste, you adjust, you taste again. A cook who put the dish in the oven once and served whatever came out would be doing what a first machine learning project usually does.
Splitting the data after cleaning it.
Anything you compute from the full dataset, a mean for filling gaps, a scaler, a category list, has already seen the test set. Split first, then fit every transformation on the training split alone.
Skipping stage one and going straight to the data.
Without a written success threshold you have no way to decide when to stop, so you stop when you run out of time. Decide what good enough means while it is still cheap to decide.
Treating deployment as the finish line.
A deployed model starts degrading the day it ships, because the world moves. Monitoring is a stage, not an afterthought.
Reaching for a bigger model when results disappoint.
Look at the errors first. The cases the model gets wrong will usually point at a missing feature or a broken column, and both are cheaper to fix than a new architecture.
Each later path on this site fills in one stage of this map.
Data and Preprocessing is stage three. Supervised Learning, Unsupervised Learning and Neural Networks are stage four. The rest of this Fundamentals path is stage five.
ML Projects walks the whole loop end to end on real datasets, which is the only way the stages stop feeling like a list and start feeling like a job.
Key takeaway
- A project runs from framing the problem through getting data, cleaning, training, evaluation and deployment.
- Preparation dominates the effort and training is often the quickest stage.
- Split the data and seal the test set before you fit anything at all.
- Stages three to five are a loop you will run many times.
- When results disappoint, the productive return is to the data rather than to a different algorithm.
- Deployment is a stage, not the end, because a live model drifts away from what it learned.
Finished this lesson?
Guest progress is saved on this device.