LLM evaluation metrics help teams compare models, prompts, and retrieval pipelines using evidence rather than impressions. This guide explains how to estimate accuracy, relevance, faithfulness, safety, latency, cost, and user satisfaction with repeatable inputs, worked examples, and a review schedule that remains useful as models, traffic, and pricing change.
Overview
There is no single score that describes whether an LLM application is good. A support assistant can produce fluent answers while citing the wrong source. A classification model can achieve high overall accuracy while failing on a small but important category. A RAG system can retrieve relevant documents yet still generate an answer that is not supported by them.
Effective LLM evaluation therefore uses a set of metrics tied to the product's intended behavior. The most useful scorecard usually covers five areas:
- Quality: Is the answer correct, relevant, complete, and well structured?
- Grounding: Is the response supported by the supplied context or retrieved sources?
- Safety: Does the system avoid prohibited, unsafe, private, or otherwise unacceptable outputs?
- Operations: How much latency, token usage, and infrastructure cost does each request create?
- Experience: Do users accept, correct, retry, or abandon the result?
Metrics should be reported with the evaluation set, model version, prompt version, retrieval configuration, and decision threshold. A score without that context is difficult to interpret and even harder to reproduce. For a broader test-case workflow, see the LLM evaluation framework.
How to estimate
Start by defining the decision the metric will support. If the team is choosing between two prompts, compare them on the same test cases. If the team is deciding whether a feature is ready for release, define minimum acceptable thresholds and review failures individually. If the goal is model routing, estimate quality and cost together rather than optimizing either one in isolation.
1. Build a representative evaluation set
Collect examples from the real task: common requests, difficult requests, ambiguous inputs, long inputs, multilingual cases where relevant, and known failure modes. Include expected answers, required facts, source documents, labels, or grading criteria when available. Keep a stable set for trend comparisons and a separate set for newly observed cases.
For each case, record the input, expected behavior, risk category, and importance. A simple weighted average is often more informative than treating every example as equally important:
Weighted score = sum of (case weight × case score) ÷ sum of case weights
Weights can reflect business importance, severity, or frequency. Document the weighting rule so it does not become an invisible way to improve a result.
2. Select metrics that match the task
For factual question answering, measure correctness and support from evidence. For RAG, separate retrieval quality from generation quality. For classification, use accuracy alongside precision, recall, and F1 when class balance or error costs make accuracy misleading. For summarization, assess whether the summary preserves important information, avoids unsupported claims, and follows the requested length or format. The guide to evaluating AI summarization quality provides a useful task-specific perspective.
3. Calculate rates, not only averages
An average quality score can hide unacceptable failures. Track pass rate, critical-failure rate, and the distribution of scores. For example:
- Pass rate: passed cases ÷ total cases.
- Critical-failure rate: critical failures ÷ total cases.
- Deflection or acceptance rate: accepted outputs ÷ eligible outputs, using a clearly defined event.
- p95 latency: the response time below which approximately 95% of recorded requests fall, calculated from the chosen measurement window.
Use the same sampling method and time window when comparing versions. A model tested on easy examples is not comparable with one tested on a difficult or recently expanded set.
Inputs and assumptions
Quality and accuracy
Choose a grading method appropriate to the output. Exact-match accuracy works for tightly defined labels or strings. For open-ended answers, use a rubric with criteria such as factual correctness, completeness, instruction following, and clarity. Human review is valuable for calibration and for ambiguous cases. An automated evaluator can make repeated comparisons efficient, but its rubric, model, and disagreement rate should be documented.
Do not treat an evaluator's score as ground truth by default. Review a sample of high, low, and borderline results, and record common evaluator errors. For classification-specific measures, see best practices for evaluating AI classification outputs.
Relevance and faithfulness
Relevance asks whether the response addresses the user's request. Faithfulness asks whether the response is supported by the supplied context. These are different: an answer may be relevant but invent a detail, or faithful to a document while failing to answer the question.
For a RAG pipeline, measure retrieval separately. Useful inputs include whether the expected document appears in the retrieved results, the rank at which it appears, and whether the retrieved context contains enough information to answer. Then evaluate the generated answer against that context. This separation helps identify whether a failure came from search, context construction, or generation.
Safety and policy adherence
Define the behaviors that are unacceptable for the application, such as revealing confidential data, following malicious instructions in retrieved content, or producing disallowed output. Measure both the rate of prohibited outputs and the rate of unnecessary refusals. A guardrail that blocks nearly everything may reduce one risk while damaging usefulness.
Latency and cost
Record time to first token, total response time, timeout rate, input tokens, output tokens, retries, and tool calls. Estimate request cost using the pricing inputs supplied by your provider or internal accounting system:
Estimated cost = (input tokens ÷ 1,000,000 × input rate) + (output tokens ÷ 1,000,000 × output rate) + tool or infrastructure costs
Keep rates as editable inputs. Prices, model limits, caching behavior, and traffic patterns can change, so a cost estimate should never be embedded as a permanent fact in the evaluation report.
Worked examples
Example 1: Comparing two answer-generation prompts
Suppose a team evaluates two prompt versions on 100 support questions. Each response receives a rubric score from 0 to 2 for correctness, relevance, and instruction following. The team also marks any critical factual error separately.
Prompt A averages 1.72 out of 2, with 8 critical errors. Prompt B averages 1.68, with 3 critical errors. If critical errors have a higher release cost than small style differences, Prompt B may be the safer choice despite the lower average. The decision should be recorded as a trade-off rather than summarized as “B scored better.”
Next, inspect the failures by category. If Prompt B reduces errors only because it refuses more requests, add unnecessary-refusal rate and successful-answer rate before making a decision. For structured output, include schema validity and field-level accuracy; the structured output reliability guide covers this distinction.
Example 2: Estimating request cost
Assume an illustrative workload of 1,000 requests. Each request uses 1,200 input tokens and 300 output tokens. Using hypothetical rates of $0.50 per million input tokens and $1.50 per million output tokens:
- Input volume: 1,200 × 1,000 = 1,200,000 tokens, or 1.2 million.
- Output volume: 300 × 1,000 = 300,000 tokens, or 0.3 million.
- Input cost: 1.2 × $0.50 = $0.60.
- Output cost: 0.3 × $1.50 = $0.45.
- Estimated model cost: $1.05, before tools, retries, storage, or other infrastructure.
These numbers are examples, not current pricing. Replace them with the rates and token counts from your own environment. If 5% of requests retry once, the effective volume is higher than the nominal request count, so retry rate belongs in the calculation.
Example 3: Combining quality and operational metrics
Imagine two models with similar grounded-answer pass rates. Model X has lower latency but uses longer prompts. Model Y is slower but uses fewer output tokens. Compare them using a table that includes pass rate, critical-failure rate, p95 latency, average input and output tokens, retry rate, and estimated cost per successful answer. “Per successful answer” is often more actionable than cost per request because failed or retried requests still consume resources.
When to recalculate
Recalculate LLM evaluation metrics whenever an input to the system changes. At minimum, review the scorecard after a model change, prompt or system-instruction change, retrieval-index update, embedding change, guardrail change, tool integration, or meaningful shift in user traffic. Revisit cost estimates when provider pricing, model context limits, caching, token usage, or retry behavior changes.
Set a regular review cadence for production data, but do not rely on cadence alone. Add event-based checks for incidents, unusual output drift, a spike in user corrections, or a drop in acceptance. The AI output drift guide can help structure that monitoring.
To keep the process practical, maintain one versioned evaluation record containing the dataset snapshot, prompt and model identifiers, metric definitions, sampling rules, thresholds, cost inputs, and known limitations. Re-run the stable test set for comparability, then add recent production examples to detect new failure modes. Use the results to decide one concrete next action: revise the prompt, improve retrieval, change the model, add a guardrail, adjust routing, or collect better labels. For team-level reporting, see the AI evaluation dashboard metrics guide.
