ML problem framing — supervised, unsupervised, RL

📅 Day 36. Week six begins. We've built the foundation; now we go into actual machine learning.

🧠 Before any code, frame the problem. Every ML problem fits into one of three boxes — and naming the box determines what algorithms apply, what data you need, and what 'success' even means.

📦 Box 1 — Supervised learning. You have inputs AND labels. Predict the label for new inputs. Two flavours — classification (label is a category, like 'spam' or 'not spam') and regression (label is a number, like 'house price'). 95% of real ML jobs are supervised. Most ML APIs you'll ship live here.

📦 Box 2 — Unsupervised learning. You have inputs but NO labels. Find hidden structure. Clustering (group similar items), dimensionality reduction (compress to fewer features while keeping structure), anomaly detection (flag the weird ones). Useful for exploratory analysis and as preprocessing.

📦 Box 3 — Reinforcement learning. An agent acts in an environment, gets rewards, learns a policy that maximises long-term reward. Game playing, robotics, recommendation systems with feedback loops. Most exciting; least common in practical jobs.

💡 Most ML jobs are supervised. Most real impact comes from getting the labels right — clean labels, sufficient labels, labels that actually represent what you want to predict. Don't underestimate the labelling step. I've seen models fail because the 'positive' label was applied inconsistently across training data, and the model dutifully learned the inconsistency.

🎯 Frame first. Pick the box. Then pick the algorithm. The other order leads to forced fits and wasted effort.

🔄 Every supervised ML project follows the same six-step loop. Knowing the loop is half the discipline of shipping ML that actually works.

1️⃣ Frame the problem. What's the input? What's the output? What metric makes a good model? If you can't answer these three questions in one sentence each, you're not ready to start. I've seen multi-quarter projects fail because step 1 was rushed.

2️⃣ Get and clean data. The 60% from week 5. Real data is messy — handle that before modelling. The cleaner your data, the easier everything downstream.

3️⃣ Split. Train / validation / test. Train on train. Tune on validation. Final score on test (touched ONCE at the end, never to tune). If you tune on test, you've leaked — your reported number is optimistic by 2-5%, sometimes more.

4️⃣ Train a baseline. Linear regression for regression, logistic regression for classification. ALWAYS start with a baseline. The baseline tells you what 'better than nothing' looks like and gives you a number to beat.

5️⃣ Iterate. Better features, different model classes, hyperparameter tuning. The art is here — informed by EDA, guided by validation metric, bounded by time.

6️⃣ Evaluate on test. Once. Deploy. Monitor. The test number is your honest estimate of production performance. The monitoring catches drift.

⚠️ Most teams skip steps 1 and 6. They frame loosely (the project drifts) and deploy without monitoring (the model degrades silently). The good news — if you do all six, you're already top quartile by execution.

🚀 Discipline beats cleverness in ML. Most of the time.

💻 Three-way split. Train ~64%, validation ~16%, test 20%. The most-skipped step in ML, and the most-expensive one to skip.

🎯 Why three sets, not two? Because the validation set is your hyperparameter-tuning sandbox. You train on train, evaluate on val, adjust hyperparameters (learning rate, regularisation, model architecture), repeat. The validation set sees your tuning decisions; it's no longer an unbiased estimate of generalisation.

🔒 Test is sacred. Touched exactly once, at the end, after you've committed to a final model. The test score is your honest estimate of production performance.

⚠️ If you tune hyperparameters on the test set, you've leaked. The model is optimised against the test data; reported test score is optimistic by 2-5% (sometimes more for small datasets). Looks great in your report; disappoints in production.

📊 For small datasets, use cross-validation on the train+val portion. K-fold (typically k=5 or k=10) gives you K different train/val splits; train K models, average their validation scores. More robust estimate than a single split. Keep test held out separately.

Look at the snippet. We use stratify=y to preserve class proportions in each split. Critical for imbalanced classification — without stratify, you might end up with all positive cases in test by accident, and your training set won't have any to learn from.

🔢 random_state=42 makes the split reproducible. Pin it. Different splits give different scores; without a fixed seed, you can't compare experiments.

💡 Three-way split takes 30 seconds to write. Saves entire categories of bug. Always.

💡 Pro tip that I learned the hard way — pick your evaluation metric BEFORE you start training. If you decide it after results come in, you'll cherry-pick.

🎯 Why this matters. After training, you'll see a bunch of numbers — accuracy, F1, precision, recall, AUC, log-loss. They tell different stories. The temptation is to report whichever number looks best. That's confirmation bias dressed as analysis.

📊 For binary classification:

→ Class-balanced + cost-symmetric (false-positive and false-negative cost about the same) → accuracy is fine.

→ Imbalanced + want to minimise false negatives (medical diagnosis, fraud detection) → recall first, then precision.

→ Imbalanced + want a single number → F1 (harmonic mean of precision and recall) or PR-AUC.

→ Probability calibration matters → Brier score or log-loss.

📈 For regression:

→ Symmetric error matters → RMSE.

→ Robust to outliers → MAE.

→ Multiplicative errors (forecast, demand) → MAPE or sMAPE.

→ Hard upper bound on target → quantile loss at the relevant quantile.

📋 My rule — write the metric in the README before you start training. State it explicitly. 'We're optimising for F1 on the positive class because false negatives are 3x worse than false positives.' Now everyone knows the goal.

⚠️ The trap to avoid — silently changing metric mid-project because the original one isn't going well. If you change it, document why, and reset the baseline against the new metric. Otherwise you're just moving the goalpost.

🔒 Pick once. Stick. Report honestly.

📅 End of Day 36. Week six begins. We're now in actual machine learning territory.

✅ What we covered today:

📦 Three boxes — supervised, unsupervised, reinforcement. Most jobs are supervised; most impact comes from clean labels.

🔄 The 6-step ML loop — frame, data+clean, split, baseline, iterate, evaluate+deploy. Most teams skip steps 1 and 6; doing both puts you in the top quartile.

💻 Three-way train/val/test split with stratify=y for classification. The validation set is your hyperparameter sandbox; test is touched once.

🎯 Pick the metric BEFORE training. Document it. Don't cherry-pick after results.

🧠 Reflection — ML is more discipline than cleverness. The teams that ship great ML aren't the ones with the smartest tricks; they're the ones that frame the problem precisely, clean the data ruthlessly, and pick metrics that match their business goal. Cleverness within that frame is great. Cleverness outside the frame is wasted.

🚀 Tomorrow, Day 37 — linear regression. The workhorse you must understand before any neural net makes sense. The closed-form solution. The MSE/RMSE/MAE choice. The 'always compare against a dumb baseline' rule.

💼 We're 40% through the sprint. Five weeks of foundation behind us; we now spend three weeks (6, 7, 8) on the core ML/DL stack, then four weeks on RAG and agents and automation, and one week on career.

👋 See you in the morning.