Evaluating a machine learning model answers two questions that are easy to run together. Whether the model is right often enough, and whether being right this often was worth what it cost. The metrics come from statistics and from signal detection work in the 1940s, when radar operators needed a way to describe how well a receiver separated aircraft from noise, and the business measures come from the plain observation that a model is a cost with an expected return. The AWS syllabus names accuracy, AUC and F1 alongside cost per user and return on investment, and the Practitioner course cares because the metric a team chooses decides which mistakes it will make.
The sections below start from the four counts every metric is built on, take the metrics and what each one hides, explain why the threshold is a product decision, cover fit and calibration, give the business metrics and the tooling, and end with a ten minute subgroup check.
The four counts underneath every classification metric
Every classification metric comes from four counts, arranged in what is called a confusion matrix. True positives and true negatives are the cases the model got right. False positives are things it flagged that were fine. False negatives are things it missed.
Which of those two errors hurts more is a product question, and it decides every metric choice that follows. A fraud model that misses fraud loses money. A fraud model that flags honest customers loses customers. The same four counts, weighted differently, give two different models.
The metrics worth knowing and what each one hides
The counts combine into a handful of metrics, and each one hides something.
Accuracy is the share of predictions that were correct. It is intuitive and it misleads badly on imbalanced data. If fraud is one transaction in a thousand, a model answering no every time is 99.9 per cent accurate and worthless.
Precision asks, of the cases the model flagged, how many were real. Low precision means people wasting time on false alarms.
Recall asks, of the real cases, how many the model found. Low recall means the thing the team was trying to catch getting through.
The two cannot both be maximised. Loosening the threshold to catch more cases pulls in more false alarms. The F1 score combines them into one number, the harmonic mean, which stays low unless both are decent. It is the metric to reach for on imbalanced problems where the rare class is the one that matters.
AUC, the area under the ROC curve, measures how well the model separates the two classes across every possible threshold. The curve itself, the receiver operating characteristic, is the radar operators' invention, plotting the rate of true alarms against the rate of false ones as the sensitivity is turned up. Its value is that it is threshold independent, so it says whether the model has signal before anybody decides how aggressively to act on it. Half is a coin toss and one is perfect separation. Its weakness is that on heavily imbalanced data it can look excellent while precision is poor, and a 2015 study made the case that the precision recall curve is the more honest picture there.
For regression the errors are distances, with no counting involved. Mean absolute error averages how far off the predictions were. Root mean squared error does the same while punishing large misses harder, which matters when one big error is worse than several small ones.
The threshold as a product decision
Most of those metrics move together with one number the model does not choose. A classifier produces a score, and somebody decides the score above which a case counts as positive. Move the threshold down and recall rises while precision falls. Move it up and the reverse happens.
The threshold therefore belongs to the product and the owner has to be somebody who can put a cost on each of the four counts. The expected value framing does this directly. Each cell of the confusion matrix is given a value, the cost of a false alarm and the cost of a miss and the benefit of each correct call, and the threshold is set where the total is best. A team that has never written those four values down has left the decision to whatever default the library shipped with.
Overfitting, underfitting and holding data back
The threshold assumes the scores mean something, and whether they do depends on fit.
Overfitting is a model that learned the noise in its training data as though it were signal. It performs beautifully on data it has seen and badly on anything new. Underfitting is a model too simple to capture the pattern, performing poorly everywhere.
Either is seen by keeping data back. A validation set guides choices during development and a test set is touched once, at the end. Reusing the test set to tune anything quietly turns it into training data, and a team that has tuned against its test set for a month is reporting a number it has no way to trust. Where data is scarce, cross validation rotates which slice is held out and averages the result.
Calibration
A separate question from fit is whether the scores are honest. A calibrated model that says seventy per cent is right about seventy per cent of the time when it says so, and many models are far from that, being confidently wrong or timidly right. Calibration matters most where the score is shown to a person or used to route work, because an uncalibrated score dressed as a probability tells the reader something the model does not know.
The business metrics that decide whether it was worth doing
The syllabus is explicit that model metrics are only half the evaluation, and the other half is the part product people are best placed to answer.
Cost per user or per inference decides whether the thing survives contact with scale. A model that costs more per call than the decision is worth cannot be fixed by improving its F1 score.
Development cost includes the labelling, the compute and the months, and it is what the alternative gets compared against.
Customer feedback catches what offline metrics cannot, which is whether people trust the output enough to act on it.
Return on investment is the honest question. A model two points more accurate than a simple rule, costing a hundred times more to run, is a worse answer.
Where the tooling sits
Managed tooling exists for both halves of this. Watching the numbers after deployment is SageMaker Model Monitor on AWS, Vertex AI Model Monitoring on Google Cloud and data drift monitoring in Azure Machine Learning. Breaking performance down by subgroup, which is where an aggregate score hiding a bad result for one group becomes visible, is SageMaker Clarify, Vertex Explainable AI and the Azure responsible AI dashboard.
Practise this
The exercise needs one headline accuracy figure and the rows behind it, exported with a column for a subgroup that matters.
Choose the subgroup before looking at anything, and choose one where a poor result would cost somebody something, such as new accounts against long established ones, one language against another, or the smallest region the product serves. Then split the same predictions by that column and recompute. Fifty rows counted by hand in a spreadsheet teaches the same lesson as fifty thousand.
import csv
from collections import defaultdict
# predictions.csv columns: id,group,actual,predicted
rows = list(csv.DictReader(open("predictions.csv")))
def accuracy(subset):
hits = sum(1 for r in subset if r["actual"] == r["predicted"])
return hits / len(subset), len(subset)
score, n = accuracy(rows)
print(f"{'overall':20s} {score:.3f} n={n}")
groups = defaultdict(list)
for row in rows:
groups[row["group"]].append(row)
for name, subset in sorted(groups.items()):
score, n = accuracy(subset)
print(f"{name:20s} {score:.3f} n={n}")
Look at the smallest group first, because it has the least influence on the aggregate and therefore the most room to be bad without disturbing it. A group holding two per cent of the rows can score thirty per cent while the headline stays at ninety two, and nothing in the headline hints that it is there.
Ten minutes of this is the difference between reporting a number and knowing what the number is an average of.