Model performance is how well a model does the job it was built for, measured with a metric that suits the task and computed on data that resembles what the model sees in production. Those last two clauses carry most of the weight. A metric that does not match the task, or a test set that does not match production, reports a number that is technically correct and practically useless.
There is no single performance metric, because “doing the job” means different things for a fraud classifier, a demand forecast, a search ranker, and an agent that books travel. The shape of the question stays constant: compare output against correct outcome, aggregate in a way the business would recognize, then look at how it varies across slices.
Key takeaways
- Performance is always metric-relative. Pick the metric from the task and the cost of each error type, not from convention.
- A single aggregate hides slice failures. A model at 94% accuracy overall can be at 60% for the segment that generates most of your revenue.
- Ground truth usually arrives late or never, so production monitoring leans on proxies: prediction distribution, input drift, and data quality.
- For LLM and agent systems there is often no single correct answer, so performance is measured with evaluations and task outcomes rather than label comparison.
- Latency and cost are performance dimensions too, and for agents they often decide whether a system is shippable.
Metrics by task type
Classification. Accuracy collapses under class imbalance. Precision and recall pull the tradeoff apart; F1 blends them, and PR-AUC is more honest when positives are rare.
Regression. MAE reports average absolute error in target units. RMSE squares errors first, so large misses weigh more. R-squared reports variance explained.
Ranking. NDCG, MRR, and precision at k matter because position matters. Pick k from what the product shows.
Unsupervised models. Silhouette and adjusted Rand index score structure, not usefulness.
Why one number is never enough
Aggregate performance is an average over populations that behave differently. The useful work starts when you break it down: by cohort, geography, device, customer tier, model version, time of day. You are hunting for a slice that is materially worse than the aggregate and large enough to matter. Fairness questions get answered here too, since disparate performance across groups shows up as a slice gap first.
A concrete version: a support classifier reports 0.94 accuracy overall while a Spanish slice at 0.71 drives most escalations. No aggregate threshold would fire on that gap.
The second habit is watching performance over time, not just at release, so you can tell monitoring from observability when a slice moves.
Measuring performance when labels are late
A loan default is known in months, a churn label needs a churn window, and some outcomes are never labeled at all. When labels lag, teams watch proxies available now:
- Prediction distribution. The share of predictions in each class or score band. A shift here with no matching shift in inputs is worth chasing.
- Input drift. Distance between current features and the training reference, using measures explained in statistical distance metrics for machine learning observability.
- Data quality. Missingness, out-of-range values, and type mismatches, which degrade performance long before a label confirms it.
None of these prove degradation. They tell you where to look while you wait.
Performance for LLM and agent systems
The classical framing assumes one correct answer per input. Generative systems break that assumption, so performance moves from label comparison to evaluation. You define what good means for your task, encode it as an evaluator, and run it over real traffic. Some evaluators are code, checking format validity or whether a required tool fired. Others use a model as the grader, an approach and its calibration pitfalls covered in the LLM as a judge guide.
Three things change. The unit moves up to the session. The score needs the trace to be actionable, as in tracing and evaluating AI agents. Latency and token cost become part of the definition.
FAQ
How do you set a performance threshold that triggers a retrain?
Work backwards from the normal variation rather than picking a round number. Measure how much the metric moves window to window over a period you know was healthy, then set the trigger outside that band so ordinary noise does not fire it. Attach a minimum sample size per window, or a low-traffic route pages you every week on three observations. Set it per slice, because the same drop on 2% of traffic and on half of it are not the same incident.
How do you compare two model versions when the traffic mix changed?
Not by the headline numbers, since part of the gap is the mix rather than the models. Compute the metric per slice for both versions, then reweight both to the same slice distribution before comparing. If version B only looks better because it got more of the easy traffic, the per-slice view shows a tie. And when the mix shifted enough that a slice has almost no volume under one version, report that rather than a difference the data cannot support.
What is the difference between model performance and model evaluation?
Performance is the measured result. Evaluation is the process that produces it: the dataset, the metric, and for generative systems the evaluator itself. In LLM work the evaluation design is usually the harder half, since a poorly specified evaluator produces stable numbers that mean nothing.
How is LLM performance different from traditional model performance?
There is usually no single correct output, so measurement relies on evaluators scoring qualities such as groundedness, relevance, or task completion, at the session level rather than per request, with latency and cost included.
