Machine Learning for Data Science
What you'll learn
- How ML fits into the data science workflow
- scikit-learn — the 5-line model
- Measuring a model: accuracy and why it can lie
- You'll compute a model's accuracy yourself
From "what happened" to "what will happen" 🔮
So far data science has been about understanding the past: stats, pandas, SQL, charts. Machine learning adds predicting the future — the same ideas from the AI track, but here it's a tool in the analysis pipeline, not the whole job.
The data science workflow:
- Get data (SQL) → 2. Clean & explore (pandas) → 3. Visualize (charts) → 4. Model (ML) → 5. Communicate results.
In Python, scikit-learn makes modeling astonishingly short:
from sklearn.linear_model import LogisticRegression
model = LogisticRegression()
model.fit(X_train, y_train) # learn from training data
predictions = model.predict(X_test) # predict on unseen data
Three lines: create, fit (train), predict. scikit-learn has dozens of models behind one consistent interface.
But: how good is your model? The first metric is accuracy = (correct predictions) ÷ (total predictions). 90 right out of 100 = 90% accuracy.
The trap — accuracy can lie. Imagine a disease that affects 1% of people. A lazy model that always predicts "healthy" is 99% accurate… and completely useless — it never catches a single sick person! When classes are imbalanced, accuracy alone is dangerous. That's why data scientists also use precision (of those you flagged positive, how many really were?) and recall (of all the real positives, how many did you catch?). For the disease test, recall is what matters.
The lesson: always ask what a metric is hiding.
Measure a model. Write accuracy(predictions, actuals) — two equal-length lists — returning the fraction that match (correct ÷ total).
Example: predictions ["spam","ok","spam"], actuals ["spam","ok","ok"] → 2 of 3 correct → 0.666...
The student who memorized the answer key 📖
Here's a trap that catches every beginner at least once: you train a model, test it on the same data you trained it on, and get 99% accuracy. Exciting — until it fails miserably on real, new data. What happened?
The model memorized instead of learning. This is called overfitting — like a student who memorizes last year's exact exam questions and answers instead of understanding the subject. Ask that student the same questions and they look brilliant. Ask slightly different questions, and they're lost — because they never learned the underlying pattern, just the specific answers.
The fix data scientists always use: the train/test split.
- Split your data before training: commonly 80% for training (the model learns from this), 20% held back as a test set the model never sees during training.
- Train only on the 80%. Then measure accuracy only on the 20% test set — data the model has genuinely never encountered.
- If training accuracy is 99% but test accuracy is 60%, that gap is overfitting, caught red-handed.
Why this matters more than almost anything else in ML: a model's only job is to work on data it hasn't seen yet (tomorrow's customers, next month's transactions). A model that only performs well on data it already memorized is worthless in production — no matter how impressive its training-set number looks. This is why every serious project, every scikit-learn tutorial, and every job interview question about ML circles back to one habit: never trust a score computed on training data.
Simulate a train/test split without any library. Write split(data, train_fraction) that returns a tuple (train, test): the first train_fraction portion of the list goes to train, the rest to test. Assume the split size (len(data) * train_fraction) is always a whole number in the tests below.
Example: split([1,2,3,4,5,6,7,8,9,10], 0.8) → ([1,2,3,4,5,6,7,8], [9,10]) — 8 training rows, 2 test rows, and critically, no overlap between them.
Real-world case study: the flu-prediction model that vanished 🔍
In 2008, Google launched Google Flu Trends, a widely celebrated project that predicted flu outbreaks by analyzing which health-related search terms ("fever," "flu symptoms") were trending in different regions — often faster than official government health reports. It looked like a triumph of big data.
By 2013, it had badly failed: it predicted more than double the actual flu cases that the U.S. Centers for Disease Control (CDC) reported that season. Researchers who studied the collapse pointed to a version of overfitting at the system level: the model had been tuned to match historical search patterns so closely that it drifted out of sync as real-world behavior changed — media coverage of flu season itself drove extra searches unrelated to actual illness, and Google's own search algorithm kept changing underneath the model, feeding it a shifting target it had implicitly "memorized" rather than truly modeled.
Google quietly retired the public Flu Trends project a couple of years later. The lesson generalizes far beyond flu: a model that fits its training conditions perfectly can still fail once the world shifts even slightly underneath it — which is exactly why data scientists don't just check train/test accuracy once, but keep monitoring live models after deployment, watching for the moment their real-world accuracy starts drifting away from what the lab numbers promised.
Question 1 of 6
What do the 3 scikit-learn lines do?
Question 2 of 6
A disease affects 1% of people. A model always says 'healthy'. Its accuracy is…
Question 3 of 6
Where does ML sit in the data science workflow?
Question 4 of 6
A model gets 99% accuracy on training data but only 60% on new data. What's happening?
Question 5 of 6
Why is a train/test split necessary?
Question 6 of 6
Why did Google Flu Trends eventually fail?
Summary
- ML is the "predict" step in the data workflow (get→clean→visualize→model→communicate)
- scikit-learn: create → fit → predict in ~3 lines
- Accuracy can lie on imbalanced data — use precision and recall too
- You computed accuracy from scratch
- Overfitting is memorizing instead of learning — always evaluate on a held-out test set, never on training data
- You coded a train/test split from scratch
- Google Flu Trends shows how even a well-tuned model can silently drift and fail once the real world shifts
Next: Data Engineering Basics — building the pipelines that feed clean data to everything you've learned.
Practice
Reading is not learning until you run something. Pick one.