Regression Metrics — MAE, RMSE, R²
When your output is a number not a class. MAE, RMSE, MAPE, R², and which metric to choose based on how you want to treat large errors.
A classification model is either right or wrong. A regression model is never exactly right — the question is how wrong, and in what direction does wrong hurt more?
DoorDash predicts delivery time as 32 minutes. The actual time is 41 minutes. The model was wrong by 9 minutes. Is that acceptable? That depends on what DoorDash promised the customer. If the app said "arrives in 32 minutes" and it took 41, the customer is angry. The cost of underestimating is higher than the cost of overestimating.
Now imagine one prediction was wrong by 9 minutes and another was wrong by 45 minutes. Are those two errors equally bad? For DoorDash, 45 minutes late might trigger a refund, damage the restaurant's rating, and lose the customer permanently. That one large error is catastrophically worse than five 9-minute errors. The metric you choose determines whether your model optimises to minimise all errors equally or to specifically avoid large ones.
This is the core decision in regression evaluation: how do you want to penalise large errors?MAE treats all errors proportionally. RMSE squares the errors — large errors get penalised much more heavily. MAPE expresses error as a percentage — useful when the scale of the target varies. R² tells you how much better the model is than a naive baseline.
A basketball commentator says "this team needs 12 points a quarter to win." The team scores 10, 11, 13, 9, 12, 8 — never exactly 12. MAE asks: how far off was each quarter on average? Answer: about 1.5 points. RMSE asks the same but doubles down on the 8-point quarter (4 under) — that squared miss from target hurts more than two smaller misses. MAPE asks: what percentage of the target was each miss?
Choose MAE when all errors cost equally — late by 5 minutes is 5× worse than late by 1 minute, nothing more. Choose RMSE when catastrophic errors cost disproportionately — one 45-minute delay is far worse than nine 5-minute delays.
Four metrics — formulas, intuitions, and when each is right
Units: Same units as target
Interpret: "On average the model is off by X minutes."
Penalises: All errors proportionally. A 10-min error is 2× worse than a 5-min error.
Use when: When all error magnitudes cost equally. Easy to explain to stakeholders.
Avoid when: When large errors are disproportionately costly.
Units: Same units as target
Interpret: "Typical error magnitude, with large errors weighted more heavily."
Penalises: Large errors quadratically. A 10-min error is 4× worse than a 5-min error.
Use when: When catastrophic errors must be avoided. Standard in competitions.
Avoid when: When outliers are present and acceptable — RMSE will be dominated by them.
Units: Percentage — scale-independent
Interpret: "On average the model is off by X% of the actual value."
Penalises: Relative errors. Being off by 5 on a target of 10 is worse than off by 5 on a target of 100.
Use when: Comparing models across targets of different scales. Demand forecasting.
Avoid when: When true values are zero or near-zero — MAPE explodes. Not symmetric.
Units: Dimensionless (0 to 1, can be negative)
Interpret: "The model explains X% of the variance in the target."
Penalises: Relative to the baseline of predicting the mean.
Use when: Quick sanity check. Comparing models on same dataset. R²=0.87 = 87% variance explained.
Avoid when: Comparing across datasets with different target variance. Can be misleading.
R² — what it measures, why it can go negative, and when it misleads
R² measures how much better your model is than the simplest possible baseline: always predicting the mean. If someone asked you to predict DoorDash delivery times with no model at all, your best guess would be the historical mean — about 36 minutes for everything. R² = 0 means your model is exactly as good as that naive guess. R² = 0.87 means your model explains 87% of the variance that the mean baseline cannot explain. R² = 1 is a perfect model.
R² can go below zero. This happens when your model is worse than just predicting the mean — its predictions are so bad they increase the total squared error beyond what a constant prediction would give. A negative R² is a signal that something is severely wrong: wrong features, data leakage in reverse, or a completely broken pipeline.
Which metric to use — a decision framework
The right metric is determined by the business cost structure of your errors, not by convention. Before picking a metric, answer two questions: are large errors disproportionately costly? And does the scale of the target vary across predictions?
Residual analysis — where is the model systematically wrong?
A single MAE number hides a lot. A model with MAE = 4.2 minutes might be consistently accurate for short deliveries but systematically wrong for long-distance orders. The aggregate metric looks fine while a whole segment of customers is getting bad predictions. Residual analysis reveals these systematic patterns.
Every common regression metric mistake — explained and fixed
Two production regressors, two different error philosophies
The metric choice for a regression model is written into the design doc before training starts, driven by what a wrong prediction actually costs downstream — not by whichever metric is easiest to compute or looks best in a demo. Two models that both output a plain number, evaluated with completely different philosophies, make this concrete.
The business promise shown to the customer is not "we are off by four minutes on average" — it is "your order arrives within the estimated window most of the time." The team reports MAE as the headline number because it is easy to explain, but the metric that actually gates a launch is a hit-rate against a threshold: the percentage of deliveries within the promised window. RMSE gets tracked alongside MAE specifically because a widening gap between the two signals that a small number of deliveries are going badly wrong — the exact failure mode that triggers refunds and one-star reviews, even while the average error still looks fine.
A pricing model — a marketplace listing price, a real-estate valuation, an ad-auction bid estimate — spans items worth ten dollars and items worth a hundred thousand dollars in the same training set. An absolute error of ten dollars means something completely different depending on which item it lands on, so the team reports MAPE or, more often, a revenue-weighted percentage error rather than plain MAE. Plain MAPE has its own trap here: it treats a ten-dollar error on a fifty-dollar item the same as a ten-dollar error on a five-thousand-dollar item, so teams weight the error by the actual transaction value, because a five percent error on a large transaction costs far more than a five percent error on a small one.
Once a team settles on what "good" means, that definition frequently gets built directly into training, not just left for evaluation afterward. A delivery-time model whose real business metric is a percentile hit-rate is sometimes trained with quantile loss aimed directly at the ninetieth percentile, rather than the mean-squared-error loss that comes with sklearn's default regressor — training the model to be precisely accurate at the percentile that actually gates the SLA, instead of hoping that minimising average error happens to also fix the tail. A pricing model that cares about large errors on high-value items but does not want a handful of outliers to dominate training entirely might use a Huber loss, which behaves like squared error for small residuals and like absolute error for large ones — a training-time compromise that mirrors the same MAE-versus-RMSE tradeoff this module covers for evaluation.
Five things people get wrong about regression metrics
RMSE's quadratic penalty on large errors is a modelling choice, not a universal improvement — it only makes sense when large errors genuinely cost more than proportionally, like DoorDash's 45-minute delay triggering a refund. If your business cost is truly linear in the size of the error — being off by 10 minutes is exactly twice as bad as being off by 5, no more — MAE matches that cost structure honestly, and it is also far more robust to a handful of outliers dominating the reported number. Defaulting to RMSE because it's the convention, without checking whether your error costs are actually quadratic, means optimising and reporting against the wrong objective.
R² is relative to the variance of the target, not to any absolute error tolerance. A model with R²=0.92 on delivery times ranging from 10 to 120 minutes is explaining 92% of a large variance — but the remaining 8% unexplained can still translate into an MAE of 8 minutes, which may be operationally unacceptable even though the R² number looks excellent. This module's own guidance is explicit about this: report MAE or RMSE in the target's real units alongside R², because R² alone tells you nothing about whether the typical error is 30 seconds or 30 minutes.
Being in the same units does not mean being on the same scale. An RMSE of 5 minutes for delivery-time predictions is not comparable to an RMSE of 5 dollars for price predictions, and even within the same problem, an RMSE of 5 minutes on a dataset averaging 30-minute deliveries is a much larger relative error than an RMSE of 5 minutes on a dataset averaging 90-minute deliveries. RMSE and MAE are scale-dependent by construction — comparing them meaningfully across datasets or targets requires normalising first, whether that's dividing by the mean, reporting MAPE instead, or using a normalised RMSE (RMSE / range or RMSE / mean).
An aggregate MAE or RMSE is an average across every prediction, and averages hide systematic bias by construction. A model can post an excellent overall MAE of 4.2 minutes while being consistently 15 minutes late specifically for long-distance orders, or systematically biased for one customer segment — the aggregate number simply blends the good predictions with the bad ones. This is exactly why this module's residual analysis section exists: checking the mean residual, MAE by distance bucket, and MAE by delivery-time bucket separately is the only way to catch a model that looks fine in aggregate but is quietly failing a subgroup that never shows up in the headline metric.
MAPE divides by the actual value, so it breaks down — sometimes to infinity — whenever true values are zero or very close to zero, which is common in demand forecasting for low-volume products. It is also asymmetric in a way that's easy to miss: a prediction of twice the actual value produces a 100% error, but a prediction of half the actual value is capped at a 50% error, so MAPE structurally punishes overestimates more harshly than underestimates of the same relative size. It is genuinely useful for comparing errors across targets of very different scales, but "scale-independent" is not the same as "safe to use everywhere" — it should be avoided whenever the target can be zero or near zero.
Regression metrics — 5 questions interviewers actually ask
The decision should follow the actual cost structure of your errors, not convention. Choose MAE when every unit of error costs proportionally the same — being off by 10 is exactly twice as bad as being off by 5, nothing more — and when you want a metric that isn't dominated by a handful of outliers. Choose RMSE when large errors are disproportionately costly in the real world, because squaring the error before averaging means a 10-minute miss contributes 4× more than a 5-minute miss, not 2×. A good answer also mentions checking the RMSE/MAE ratio in practice: a ratio near 1.0 means errors are fairly uniform and either metric tells a similar story; a ratio above 2.0 signals a few large outliers are inflating RMSE and worth investigating directly.
It depends on three things I'd check before answering. First, compared to what baseline — R²=0.91 sounds strong, but if a naive model (always predict the mean) already gets R²=0.85 on this target because the target itself is easy to predict, the real lift from the model is much smaller than 0.91 suggests. Second, what does that translate to in absolute error — R²=0.91 on a target with huge variance can still leave a large MAE in real units, which matters more operationally than the R² number itself. Third, is it measured on a held-out set with the same distribution as production — R² computed on training data or on a leaked split is not trustworthy at all. I wouldn't call any single R² value "good" without that context.
Negative R² means the model's squared errors are larger than they would be if you'd just predicted the mean of the target for every example — the model is actively worse than the simplest possible baseline. That's a strong signal something is broken, not just underperforming. I'd check, in order: whether train and test come from the same distribution (compare y_train.mean() and y_test.mean() — a big gap points to a bad split); whether the target was transformed during training (e.g. predicting log(y)) but evaluated without un-transforming the predictions back to y's scale; and whether the features used at inference time actually match what the model was trained on. Negative R² is rarely a subtle modelling issue — it's almost always a pipeline bug.
MAPE divides each error by the actual value, so for SKUs with true demand near zero — a product that sells 1 or 2 units a day — a small absolute error like being off by 3 units produces a triple-digit or even undefined percentage error. Those low-volume SKUs then dominate the averaged MAPE even though their absolute business impact is tiny, while high-volume SKUs where the forecast actually matters most get comparatively little weight in the metric. A better choice here is often a weighted MAE (weighted by revenue or volume) or WAPE (weighted absolute percentage error, which divides the sum of absolute errors by the sum of actuals rather than averaging per-item ratios), because both avoid the near-zero-denominator blowup that plain MAPE is vulnerable to.
I'd start with residual analysis rather than trusting the aggregate number. First check whether the mean residual is near zero overall — if it's shifted, the model has a global bias, not just a segment-specific one. Then break MAE down by the segment in question (and a few related cuts — by prediction range, by a key input feature) to see if that segment's error is meaningfully higher than the rest, and check the sign of its mean residual to see whether the model over- or under-predicts for that group specifically. An aggregate metric is a weighted average across every prediction, so a model can look excellent overall while being consistently wrong for a segment that's simply outnumbered by the rest of the data — the fix is always to disaggregate before concluding the model is fine.
The Evaluation section is complete. Section 7 — Deep Learning — begins next.
You have now completed every module in the Model Evaluation section: classification metrics, calibration, ROC curves, cross-validation, hyperparameter tuning, model interpretability, and regression metrics. You can honestly evaluate any model — classifier or regressor — and communicate its performance to any audience.
Section 7 — Deep Learning — begins with Module 41. Everything changes: instead of hand-crafted features, the model learns its own representations from raw data. Module 41 builds a neural network from scratch in NumPy — forward pass, backpropagation, gradient descent — before introducing PyTorch.
Forward pass, backpropagation, and gradient descent built in NumPy before touching PyTorch. The foundation every deep learning framework is built on.
🎯 Key Takeaways
- ✓MAE treats all errors proportionally — a 10-minute error is exactly 2× worse than a 5-minute error. RMSE squares the errors first — a 10-minute error is 4× worse than a 5-minute error. Choose based on whether large errors in your domain are disproportionately costly.
- ✓MAPE expresses error as a percentage of the actual value — scale-independent and useful when targets span different magnitudes. Never use MAPE when true values can be zero — division by zero makes it undefined.
- ✓R² measures how much better the model is than predicting the mean. R²=0.87 means 87% of variance explained. R²=0 means no better than the mean. Negative R² means worse than the mean — a signal of a severely broken pipeline.
- ✓Always compare your model against a naive baseline before reporting any metric. If the baseline (always predict mean) has MAE=12.4 and your model has MAE=11.9, the improvement is marginal despite the metric looking reasonable in isolation.
- ✓The RMSE/MAE ratio reveals the outlier situation. Ratio near 1.0 means errors are uniform. Ratio above 2.0 means a few very large errors are dominating RMSE. Always inspect the error distribution — report percentile errors (50th, 90th, 95th) alongside summary metrics.
- ✓Residual analysis exposes systematic bias that aggregate metrics hide. Always check: is the mean residual near zero (no bias)? Does error vary by prediction range or input feature? Are the largest errors concentrated in a specific segment? A model with good overall MAE can be systematically wrong for a specific customer group.
Discussion
0Have a better approach? Found something outdated? Share it — your knowledge helps everyone learning here.