AIF-C01 does not expect you to code a model yourself. It asks "which stages are there, and what is each stage responsible for?"
Ordinary software development: a relatively linear flow of requirements → design → implementation → deployment.
ML: the output (the model) learns patterns from data, so when the data changes the model goes stale → a loop that keeps turning.
💡 Related theory: The key reason the ML lifecycle is circular is "data drift." The distribution of real-world data changes over time (for example, last year's shopping patterns ≠ this year's shopping patterns). A model built from the data available at training time gradually drifts away from reality, so you need a cycle of collecting data again and retraining.
Clean the data and turn it into a form that can be learned from
"Is the data clean and usable?"
Model Training
The algorithm learns patterns from the data
"Did the model learn the patterns well?"
Model Evaluation
Measure whether the model really predicts well
"Does it do well on data it has never seen?"
Deployment
Release the model so it can be used in a real service
"Can users actually use it?"
Monitoring
Watch whether model performance degrades in production
"Is it still working well?"
This order is worth memorizing. When a question asks "Can we just train right after collecting the data?", you should notice that the 'preparation' stage in the middle is missing.
A model cannot produce something it has never seen. A model that has never seen a single cat photo cannot recognize a cat.
The first stage is collecting data that fits the problem.
Sources: databases, logs, sensors, external APIs, user input, and so on.
To build a model that filters spam, you first need to collect lots of "emails classified as spam" and lots of "normal emails." If you cannot collect enough of both kinds, none of the later stages mean anything.
Real-world data is messy: missing values, duplicates, inconsistent formats, typos.
What happens here: cleaning → filling in missing values → unifying formats → converting to numeric form that the model can understand.
At this stage the data is also split into training, validation, and test sets (covered in detail on Day 2).
They say most of the time in an ML project goes into data preparation. As the maxim "Garbage In, Garbage Out" puts it, even the best algorithm cannot build a good model from bad data.
Doing well on the training data is a given (the model has already seen it).
What matters is whether it does well on data it sees for the first time → measure with test data that was not used for training.
Metrics such as accuracy appear at this stage (the topic of Day 3).
⚠️ Trap: Judging "99% accuracy on the training data, so it's a good model" is dangerous. A model that has simply memorized the training data can be terrible on new data (overfitting). Evaluation is only meaningful when done on data the model has never seen.
┌──────────────────────────────────────────────┐
│ │
▼ │
[Data Collection] → [Data Preparation] → [Model Training] → [Model Evaluation]
│
▼
[Monitoring] ◄──────── [Deployment]
│
└─ On detecting performance degradation, back to data collection
The key point is that this flow does not run in one direction only.
If evaluation shows poor performance → go back to data preparation or training.
If monitoring finds a problem → go back to the beginning.
ML is inherently iterative and cyclical.
🎯 Scenario: "The click-through rate of a recommendation model deployed 6 months ago keeps dropping. What should you do?" → This is a case where monitoring has detected performance degradation. The correct answer is to collect the latest data again and retrain the model, in other words to go around the lifecycle once more.
Tomorrow we take a deep look at "data" itself, the fuel of this lifecycle. We will cover the difference between structured and unstructured data, why data is split into three sets, and why data quality determines everything.