Evaluation metrics are the numerical or categorical measures used to judge AI system behavior. Task success rate, correctness, faithfulness, relevance, toxicity, latency, cost, tool-call accuracy, Recall@K, and human preference are all evaluation metrics, and they measure genuinely different things.
The best metric depends on the job the system is supposed to do. A retrieval metric will not tell you whether an answer is safe. A correctness score will not tell you whether the agent took an expensive or risky path to get there. This is why production eval suites carry several metrics at once, and why the first real decision in an evaluation project is which handful to track rather than how to compute any one of them.
Key takeaways
- Metrics fall into a few recognizable families: task outcome, retrieval quality, generation quality, safety and policy, trajectory and tool use, and operational cost.
- Pick metrics from the failure modes you have observed, not from a list. A metric nobody would act on is overhead.
- Every metric needs a slice view. A single average across all traffic is the most common way a real failure stays hidden.
- Some metrics are computed by code and some by a model. Model-computed metrics have their own error rate and need to be validated against human labels.
- Latency and cost belong in the same suite as quality. A system that is correct and unaffordable has still failed.
The families of evaluation metrics
Task outcome. Did the system do the thing. Task success rate, resolution rate, and exact match on structured outputs live here. These are the metrics a product owner recognizes, and the hardest to define precisely for an open-ended task.
Retrieval quality. For any system that fetches context, the retrieval step gets its own metrics: Recall@K for whether the right document appeared in the top K results, precision for how much of what came back was relevant, and ranking metrics such as NDCG and MRR for whether it appeared near the top. A generation metric cannot distinguish a model that reasoned badly from one that was handed nothing useful.
Generation quality. Faithfulness or groundedness, relevance, coherence, completeness, and tone. These are properties of the text itself. Most are scored by a model applying a rubric, because no formula computes whether an answer is supported by its context.
Safety and policy. Toxicity, PII leakage, jailbreak susceptibility, refusal correctness, and compliance with whatever rules your domain imposes. These behave differently from quality metrics: you care about the worst case rather than the average, and one violation can matter more than a thousand clean responses.
Trajectory and tool use. For agents, the path is part of the product. Tool-call accuracy, argument validity, number of steps, loop detection, and whether the agent recovered after a failed call. A correct answer produced by fourteen redundant tool calls is a cost and reliability problem that answer-level metrics never see.
Operational. Latency, token spend per request, and cache hit rate. They are not quality metrics, but they set the envelope you have to stay inside, and they change when you change the prompt or the model.
Choosing metrics
Work backward from failures, not forward from a catalog. Read a few hundred real production outputs, group the bad ones, and name the categories. Those categories become your metrics, and a suite built this way stays small because every entry corresponds to something you have seen go wrong.
Two filters help. First, would you act differently if this number moved five points? If not, it is a dashboard decoration. Second, can you tell what to fix when it drops? A generic “quality” score fails this test, which is why splitting quality into groundedness, relevance, and completeness is usually worth the extra scoring cost.
Metrics also have to be comparable over time. That means fixing the dataset, the scorer version, and the sampling rule, then changing one at a time. Comparing the same agent metrics across different models under one harness only works because the harness is held constant.
Why one number hides the failure
An average is a summary, and every summary discards the thing you most need to see. A mean faithfulness score of 0.91 is consistent with a system that is uniformly good and also with one that is near perfect on 90% of traffic and broken on the 10% coming from a single integration, language, or document type.
The fix is slicing. Compute every metric by customer segment, input category, retrieval source, conversation length, and model version. Failures in AI systems are almost never uniform, because the inputs are not uniform. Look at the low end of the score distribution rather than its center.
Metrics also need to point somewhere. A score attached to a span is diagnostic, since you can open the trace behind the failing evaluation and see which step produced the input that broke the next one. A score sitting in a spreadsheet is a report card.
Metrics that quietly mislead
Proxy metrics that drift from the thing they proxy. Response length correlates with helpfulness until someone optimizes for it. Any metric that becomes a target stops being a good measurement of what it originally tracked.
Model-scored metrics nobody validated. If a judge computes your relevance score, the error rate of that judge is part of your metric. Measure its agreement with human labels before you put it on a dashboard, and re-measure after any change to the judge model or its prompt.
Metrics whose denominator moves. Success rate over “requests we were able to parse” climbs nicely when parsing failures increase. Define the denominator explicitly and count failures as failures.
Scoring cost treated as free. Running several model-based metrics on every span multiplies inference volume, and the cost of the evaluation pipeline itself can quietly exceed the cost of serving the application.
FAQ
What are the most common evaluation metrics for LLM applications?
Groundedness or faithfulness, relevance, correctness against a known answer where one exists, toxicity or policy compliance, and task success rate. For retrieval-augmented systems, add Recall@K and a ranking metric. For agents, add tool-call accuracy and step count. Most production suites run somewhere between three and eight.
What is the difference between an evaluation metric and an eval?
The metric is what you measure. The eval is the whole test: the examples, the criteria, the scoring mechanism, and the run. One eval can produce several metrics, and one metric can appear in several evals.
How many metrics should a suite have?
Few enough that someone reads all of them. Three to six well-chosen metrics that map to observed failures beat twenty that nobody looks at. Every extra model-scored metric also adds inference cost and latency to your pipeline.
Can traditional ML metrics still be used?
Yes, wherever the task actually has a label. Classification, extraction, routing, and intent detection steps inside an LLM application are ordinary supervised problems, and precision, recall, F1, and confusion matrices apply directly to them. The open-ended generation step is where they stop working.
Should latency and cost be tracked as evaluation metrics?
Treat them as part of the same suite. A change that improves faithfulness by two points while tripling p99 latency is a tradeoff someone needs to see and approve.
