Evaluating models

A model with 99% accuracy can be worthless, and a model with a modest AUC can still make money. Evaluation means measuring the thing that matches the decision you framed in ML framing, not the metric that looks best in a notebook. For LLM products, see AI evals. For live experiments, see A/B testing.

Concepts in this topic

Read in this order.

Start from the decision

Before computing anything, write the operating constraint in one line. For example: "We can review 200 accounts a day," or "A missed fraud costs about 40 times a false decline," or "The page shows 10 results, and users rarely scroll."

That line picks the metric family. Defaults such as accuracy or ROC-AUC on imbalanced data are how teams ship the wrong model with a green dashboard.

Regression metrics

MAPE breaks when y is near zero, and it over-weights cheap items. Prefer MAE or RMSE, or a weighted variant that matches the business cost.

Validation and cross-validation

k-fold cross-validation splits the training data into k folds, trains k times and averages the scores. Use stratified folds for classification. Use GroupKFold or TimeSeriesSplit when rows are not independent, such as repeated measures from one user.

If you tune hyperparameters and report the score on the same folds, the estimate is optimistic. Nested cross-validation uses an inner loop for tuning and an outer loop for the estimate.

Offline metrics are a filter

Offline you optimize PR-AUC or log loss. Online you care about revenue, retention, latency and abuse rate. They diverge: the model changes behavior, the label is a proxy, and serving features can differ from training features.

Treat offline metrics as a filter. Promote only candidates that beat the baseline, then confirm with an A/B test.

Slices and hidden failures

A model can look fine in aggregate and fail a segment that matters. Report the main metric per slice, such as new versus returning users. A churn model with overall PR-AUC of 0.45 that scores 0.15 on enterprise accounts is not shippable if enterprise is the business.

Common mistakes

• Reporting accuracy alone on rare events. Predicting "never fraud" gets 99.9% accuracy on a 0.1% fraud rate.
• Choosing a threshold of 0.5 by default. Set it from costs or capacity, and store it next to the model, so serving cannot quietly use 0.5.
• Trusting one aggregate number. A good overall score can hide a segment where the model fails.

Key takeaways

• Match the metric to the decision and to the class balance.
• Set thresholds from costs or review capacity, not from 0.5.
• Use PR-AUC for rare positives, and ROC-AUC for balanced ranking quality.
• Calibrate before you use scores as probabilities, and check for leakage before you celebrate.
• Confirm offline wins with experiments, and report slice metrics as well as the aggregate.

Further learning

An Introduction to Statistical Learning covers classification and resampling, with labs:

An Introduction to Statistical LearningAn Introduction to Statistical Learning

The scikit-learn model evaluation guide lists the functions you will call most often:

scikit-learn: Model evaluationWhich scoring function should I use?: Before we take a closer look into the details of the many scores and evaluation metrics, we want to give some guidance, inspired by statistical decision theory...scikit-learn

StatQuest's short intuition for why hold-out sets and cross-validation exist:

Josh Starmer's ROC and AUC visual is the fastest way to see the geometry:

Precision and recall in six minutes, with an optional sing-along: