The Machine Learning Workflow
Building a machine learning system is rarely just 'train a model' — it is an iterative pipeline with distinct stages, each of which can make or break the final result. A typical workflow moves through problem framing, data collection, data preparation, feature engineering, model selection and training, evaluation, and finally deployment and monitoring. Teams that skip stages, especially data preparation and evaluation, tend to ship models that look good in a notebook but fail in production.
Cricket analogy: Building a winning cricket team isn't just 'pick good players' — it's a pipeline from scouting to trials to contract to match-day execution to post-match review, and teams that skip scouting or post-match review tend to look great in practice nets but flop under real match pressure.
Problem Framing and Data Collection
Before touching any algorithm, you must translate a business or research question into a well-posed ML problem: what exactly is being predicted, what counts as success, and what data is realistically available. Data collection follows — gathering raw data from databases, logs, sensors, APIs, or manual labeling. The quality and representativeness of this data ceiling everything downstream; no algorithm can compensate for data that does not reflect the real-world distribution the model will face.
Cricket analogy: Before recruiting a single player, a franchise must define exactly what 'success' means (title win? highest win percentage?) and what data is realistically available (domestic stats, fitness records); scouting follows, and no amount of coaching can fix a roster built on incomplete or biased scouting data.
Preparation, Training, and Evaluation
Raw data is almost never ready for modeling. Preparation involves cleaning (handling missing values, fixing inconsistent formats), splitting into train/validation/test sets, and feature engineering (transforming raw fields into informative model inputs). Model training fits candidate algorithms to the training set, while the validation set is used to tune hyperparameters and select among competing models. Only after that selection is finalized does the test set get used once, to produce an honest estimate of how the model will perform on genuinely new data.
Cricket analogy: Raw player performance data is rarely ready for team selection — it needs cleaning (handling injury gaps, inconsistent formats across leagues), a split into trial squad, provisional XI, and a held-out 'big match' test, and only after the provisional XI is locked in does the team face the real, unseen pressure of a final, once, for an honest read of readiness.
Deployment and Monitoring
A model that performs well offline still has to be integrated into a live system — wrapped in an API, embedded in an application, or run as a batch job — and this deployment step introduces its own engineering challenges around latency, scale, and versioning. Once live, monitoring is essential: input data distributions drift over time (a phenomenon called data drift), and a model's real-world accuracy can silently degrade. Production ML is a loop, not a one-time event — monitoring feeds back into retraining and re-evaluation.
Cricket analogy: A team that trains well in the nets still has to perform live under crowd noise, tricky lighting, and real opposition scouting — and once the season starts, form must be monitored continuously, since a batsman's technique can silently break down (analogous to data drift) and selectors must feed that back into training adjustments.
from sklearn.model_selection import train_test_split
from sklearn.preprocessing import StandardScaler
from sklearn.ensemble import RandomForestClassifier
from sklearn.metrics import classification_report
import pandas as pd
# 1. Data preparation: split before any preprocessing to avoid leakage
df = pd.read_csv('customers.csv')
X, y = df.drop(columns=['churned']), df['churned']
X_train, X_test, y_train, y_test = train_test_split(
X, y, test_size=0.2, stratify=y, random_state=42
)
# 2. Feature scaling fit ONLY on training data
scaler = StandardScaler().fit(X_train)
X_train_scaled = scaler.transform(X_train)
X_test_scaled = scaler.transform(X_test)
# 3. Model training
model = RandomForestClassifier(n_estimators=200, random_state=42)
model.fit(X_train_scaled, y_train)
# 4. Evaluation on held-out test data (used exactly once)
preds = model.predict(X_test_scaled)
print(classification_report(y_test, preds))A useful rule of thumb: in most real projects, 60-80% of the time goes into data collection, cleaning, and feature engineering, while model training and tuning — the part beginners focus on most — is often a comparatively small fraction of the total effort.
- The ML workflow moves through problem framing, data collection, preparation, feature engineering, training, evaluation, and deployment.
- Problem framing defines what is being predicted and what success looks like before any modeling begins.
- Preprocessing steps like scaling must be fit only on training data to avoid data leakage into the test set.
- The validation set tunes model choices; the test set is reserved for a single, honest final performance estimate.
- Deployment introduces engineering concerns like latency, scaling, and API integration beyond raw model accuracy.
- Monitoring for data drift and performance decay is essential, since production ML is a continuous loop, not a one-off task.
Practice what you learned
1. Which workflow stage typically consumes the largest share of project time in practice?
2. Why should a StandardScaler be fit only on the training set, not the full dataset?
3. What is the purpose of the validation set in the workflow?
4. What is 'data drift' in the context of production monitoring?
5. Why is problem framing considered the first and one of the most important workflow stages?
Was this page helpful?
You May Also Like
What Is Machine Learning?
An introduction to machine learning as the practice of building systems that improve their performance on a task by learning patterns from data rather than following hand-coded rules.
Train/Test Split and Cross-Validation
Understand how holding out data and using k-fold cross-validation give an honest estimate of how a model will perform on unseen data.
Data Cleaning Basics
Covers the core techniques for detecting and fixing messy real-world data — duplicates, inconsistent formatting, outliers, and type errors — before it reaches a model.
Hyperparameter Tuning
Explore systematic strategies — grid search, random search, and cross-validation-based tuning — for choosing model settings that are not learned directly from data.