Ask five teams how they evaluate their AI system and you'll often get five different metrics, chosen less because someone reasoned about the failure mode they're guarding against and more because the metric sounded credible in a planning meeting. That's a real problem, because every metric on this list is genuinely useful for some failure mode and genuinely blind to others. A model with excellent precision can still be dangerously unreliable if recall is what your use case needs. A RAG system with a low hallucination rate on easy questions can still be unsafe if its faithfulness collapses on the hard 10%. This is a plain-language guide to what each metric actually measures, with a worked example for each, and a table mapping use case to the metric that should actually be driving your ship/no-ship decision.
Precision and recall: the tradeoff underneath almost every classifier
Precision and recall are the two most fundamental metrics for any system that makes a yes/no call, flagging spam, detecting fraud, classifying support tickets, routing documents. Precision asks: of everything the system labeled positive, what fraction was actually positive? Recall asks: of everything that was actually positive, what fraction did the system catch? A worked example makes the difference concrete: imagine an AI system reviewing 100 support tickets, 20 of which are genuinely urgent. If the system flags 15 tickets as urgent and 12 of those really are urgent, precision is 12/15 (80%), the flags you got were mostly trustworthy. But recall is 12/20 (60%), the system missed 8 of the 20 truly urgent tickets entirely. These two numbers pull in different directions: a system tuned to flag everything remotely urgent-looking will catch nearly all real urgent tickets (high recall) but bury the queue in false alarms (low precision). A system tuned to only flag the certain cases will have high precision but miss real ones (low recall). F1 score is the harmonic mean of the two, useful as a single number when you genuinely don't have a reason to weight one over the other, but it can mask a bad asymmetry, an F1 of 0.75 could be 90% precision and 63% recall, or the reverse, and those describe very different systems.
| Use case | Costlier failure | What to optimize for |
|---|---|---|
| Fraud detection | Missing real fraud (false negative) | Recall, tolerate more false positives for manual review |
| Spam filtering | Blocking a real email (false positive) | Precision, tolerate a little spam getting through |
| Medical/safety-critical flagging | Missing a real positive case | Recall, near-zero tolerance for false negatives |
| Content auto-publishing decisions | Publishing something wrong (false positive) | Precision, err toward holding for review |
Hallucination rate vs. faithfulness/groundedness
Hallucination rate is the broadest metric: across a sample of outputs, what fraction contain a claim that's factually wrong or fabricated, regardless of whether the system had access to source material at all. It's typically measured by having a human or a strong secondary model check claims in the output against known ground truth. Faithfulness (also called groundedness) is a narrower, more useful metric specifically for retrieval-augmented systems: it measures whether the answer is actually supported by the documents the system retrieved, independent of whether those documents themselves are correct. A RAG system can have perfect faithfulness (every claim traces back to a retrieved passage) while still giving a wrong answer, because the retrieved passage itself was outdated or wrong; that's a retrieval problem, not a faithfulness problem, and the two metrics together tell you which stage of the pipeline to fix. Conversely, a RAG system can retrieve perfectly correct documents and still produce an unfaithful answer, because the model added an unsupported inference on top of what the documents actually said, that's a generation problem, not a retrieval problem. Measuring only overall hallucination rate collapses this useful distinction; measuring faithfulness separately from retrieval accuracy tells you which half of the pipeline to fix.
Exact match vs. semantic similarity
For tasks with one clearly correct answer, extracting a specific field from a document, classifying a ticket into a fixed category, answering a factual question with a single correct value, exact match (does the output literally match the expected answer, sometimes with light normalization) is the right metric, and using semantic similarity instead tends to inflate scores by giving credit for 'close but wrong' answers that shouldn't count. For open-ended generation tasks, summarization, drafting, open-ended Q&A, there often isn't one correct phrasing, and exact match against a single reference answer will score a genuinely good output as a failure just because it used different words. Semantic similarity (comparing meaning via embeddings, or using a model-based judge to rate whether the output captures the same content as a reference) is the appropriate metric there. Using the wrong tool for the task in either direction produces a misleading score: exact match on a summarization task looks artificially terrible; semantic similarity on a data-extraction task looks artificially fine even when the extracted value is subtly, importantly wrong.
Latency percentiles: why the average lies
Average (mean) latency is one of the most commonly reported and least useful numbers in AI system monitoring, because it's dominated by the common case and hides the tail. A system with a 500ms average latency can still be delivering a multi-second stall to 5% of users, and that 5% is often disproportionately the users hitting the hardest, longest, most context-heavy requests, exactly the interactions where a slow response is most noticeable and most damaging to trust. Percentile metrics fix this: p50 (median) tells you the typical experience, p95 tells you what the slower-than-typical fraction of users see, p99 tells you the near-worst case. A team that only tracks average latency can ship a change that doubles p99 while barely moving the average, and have no idea it happened until support tickets about 'the AI is slow sometimes' start piling up.
Which metric actually matters, by use case
| Use case | Primary metric | Why |
|---|---|---|
| Fraud/anomaly detection | Recall (with acceptable precision floor) | Missed positives are far more costly than false alarms needing manual review |
| Document data extraction | Exact match (field-level) | There's one correct value; near-misses are still wrong |
| RAG customer-facing Q&A | Faithfulness/groundedness + retrieval accuracy separately | Distinguishes a retrieval problem from a generation problem |
| Summarization/drafting | Semantic similarity or model-judged quality | Many valid phrasings exist; exact match unfairly penalizes good output |
| Real-time conversational agent | p95/p99 latency, not average | Tail latency is what users actually notice and complain about |
| Content moderation/auto-publish | Precision | A wrong auto-published action costs more than a held-for-review item |
How to actually pick the right metric for your system
Start from the failure mode that would actually hurt, not from the metric that sounds most rigorous. Ask what a false positive costs versus what a false negative costs, that answer alone tells you whether to weight precision or recall. Ask whether your task has one correct answer or many valid phrasings, that tells you exact match versus semantic similarity. Ask whether your system retrieves source material at all, if it does, faithfulness deserves to be tracked separately from overall accuracy, because it tells you which half of the pipeline broke. And track percentiles, not averages, for anything with a latency requirement, because the tail is where users actually notice. A single project usually needs two or three of these metrics tracked together, not one; picking just one, however rigorous it sounds, guarantees a blind spot somewhere the metric wasn't designed to see.