Baselines & Benchmarks
Start every project with a deliberately dumb model — dummy baselines, the class-imbalance accuracy trap, and fair benchmarking with cross-validation.
"My model gets 92% accuracy." Is that good? You genuinely cannot know without something to compare against. If guessing the majority class already scores 91%, that model has learned almost nothing. This lesson gives you the habit that separates rigorous practitioners from hopeful ones: establish a dumb baseline first, benchmark everything against it, and only trust improvements you can measure fairly.
Why every project starts with a dumb model
A baseline is the score of the simplest strategy imaginable — random guessing, always predicting the most common class, or one hand-written rule ("predict survived for every female passenger"). A benchmark is a stronger reference to beat: a simple standard model, a previous production system, or a public leaderboard.
Starting simple pays off repeatedly:
- It calibrates every number that follows. 92% only means something relative to the baseline's 91% — or 55%.
- It catches bugs and leaks. If your first fancy model scores below a dummy, something is broken. If it scores suspiciously near 100%, suspect leakage.
- It delivers value early. A working end-to-end pipeline with a simple model beats a half-finished sophisticated one, and effort is often not proportional to payoff — a huge grid search frequently buys a fraction of a percent.
DummyClassifier: the honest zero point
scikit-learn ships baseline models that deliberately ignore the features:
DummyClassifier and DummyRegressor. Let's pit one against a real model
on the breast cancer dataset:
The dummy scores about 63% without ever looking at a single feature —
because 63% of patients in this dataset have benign tumors. So the honest
reading of the KNN result is not "97% accurate" but "34 points above chance."
(DummyRegressor plays the same role for regression, predicting the training
mean or median; its R² is essentially zero by construction.)
The accuracy trap: imbalanced classes
Now the trap this protects you from. When one class dominates, accuracy becomes nearly meaningless:
The dummy hits about 97% accuracy while catching zero fraud cases — its recall (the fraction of true positives it finds) is 0. Anyone who reports "97% accurate" on this problem is reporting the class ratio, not model skill. On imbalanced problems, lead with metrics like recall, precision, F1, or balanced accuracy — the classification module covers them in depth — and always publish the dummy's score next to yours.
Benchmarking models fairly
Once the baseline is planted, compare candidate models under identical conditions: same data, same preprocessing, same cross-validation splits. A loop over a dictionary of pipelines does it cleanly:
Reading the table properly:
- Cross-validation, not a single split, so no model wins by luck of the draw. Report the mean and the standard deviation.
- Overlapping error bars mean "roughly tied." If two models are within a standard deviation of each other, prefer the simpler, faster one.
- Each model gets the preprocessing it needs (scaling for KNN and logistic regression; trees don't care), bundled in a pipeline so nothing leaks.
Beating the benchmark is a loop, not a step
When your best model must improve, there are only two levers: better data (feature engineering, cleaning, more samples) and better modeling (tuning, different algorithms). Change one thing at a time, re-run the same benchmark, and keep what helps. Public competitions like Kaggle work exactly this way — a shared leaderboard is just a benchmark thousands of people iterate against.
Keep an experiments log
Within a day of iterating you will forget which combination produced which score. Professionals keep a log — a spreadsheet or a plain text file is enough. For every run record:
- the data version and features used (e.g., "added is_alone, binned age"),
- the model and hyperparameters (or the grid searched),
- the validation scheme (5-fold CV, seed 42) — it must stay constant, or scores aren't comparable,
- the score with its spread, and one line of notes ("helped, keep" / "no change, revert").
Two related habits multiply your speed: build yourself reusable templates for the boilerplate (imports, split, preprocessor, grid search) so each new experiment costs minutes, and resist tinkering past the point of diminishing returns — when three experiments in a row move the score by less than its standard deviation, the remaining gains probably live in the data, not the model.
Check your understanding
Q1.Your classifier reports 94% accuracy on a dataset where 94% of samples belong to one class. What have you learned about the model?
Q2.What does DummyClassifier(strategy="most_frequent") do?
Q3.Why benchmark models with cross-validation instead of one train/test split?
Q4.Model A scores 0.951 ± 0.020 and model B scores 0.958 ± 0.025 in the same 5-fold CV. B is much slower. What's the reasonable call?
Q5.Which item is LEAST important to record in an experiments log?
Exercise: Benchmark on an imbalanced problem with the right metric
Rebuild the fraud-style imbalanced dataset from this lesson and benchmark
three candidates — a majority-class dummy, scaled KNN, and scaled logistic
regression — with 5-fold cross-validation, reporting both accuracy and
F1 (scoring="f1") for each. Which metric actually distinguishes the real
models from the dummy, and which model would you pick?
That wraps the foundations — next module: regression, where you'll fit your first line with gradient descent and meet the loss functions behind almost every model.