Baseline before model

The rule#

Before training anything, build the trivial predictor and score it on the same split with the same metric.

Problem	Baseline
Classification	Majority class, then the base rate
Regression	The mean, then the median
Time series	The last value, then the same period last week
Ranking	Popularity, or the single most obvious feature
Recommendations	Most popular items to everyone

Why seasonal-naive is a hard opponent#

For anything with weekly seasonality, "the same hour last week" is a genuinely strong forecaster. Plenty of deployed models do not beat it.

python

baseline = y.shift(24 * 7)                       # same hour, last week
mae_baseline = (y - baseline).abs().mean()
print(f"seasonal-naive MAE: {mae_baseline:.1f}")

Run that on grid-energy-load before building anything, and be prepared to be humbled.

The baseline is also your communication#

"The model reduces error by 34% versus predicting last week's value" is meaningful to a stakeholder. "MAE is 412" is not. The baseline converts an absolute number nobody can interpret into a relative one everybody can.

The rule that is often enough#

python

high_risk = (df["days_since_login"] > 21) & (df["tenure_days"] > 60)

Measure its precision and recall properly. If it captures 70% of what a gradient-boosted model captures, ship the rule. It needs no serving infrastructure, no monitoring, no retraining, and no explanation — and you can change it in an afternoon when the business changes, which a model cannot do.

The order of work#

Frame the decision, the unit, the horizon and the costs.
Assemble the data with strict as-of discipline.
Build the baseline. Measure it on the real split.
Build the simplest thing that could beat it — regularised regression, or one gradient-boosted model with defaults.
Stop.

Most projects should stop at step four. The gap between step 3 and an extensively tuned ensemble is typically one to three points of AUC, and it costs weeks plus a permanent maintenance burden.