LLM evaluation
LLM Evaluation Metrics
A decision guide for selecting, calibrating, and interpreting LLM metrics across models, RAG applications, and production workflows.
Direct answer
Which LLM evaluation metrics should a production team use?
A production team should use a portfolio of LLM evaluation metrics tied to the application’s actual requirements. Objective outcomes such as valid schemas, calculations, citations, tool arguments, and forbidden disclosures should use deterministic checks where possible. Generated answers may also need task-specific measures for correctness, groundedness, relevance, completeness, safety, consistency, latency, and cost. RAG applications should separate retrieval quality from response quality so teams can locate the failure. Contextual qualities require explicit rubrics and calibrated human or model-assisted review rather than a generic similarity score. Metrics should be segmented by user, task, language, risk, or workflow because an average can hide severe failures in a small cohort. Every metric needs a definition, data source, threshold, owner, and known limitation. The right set is the smallest group that provides actionable evidence for a named product or release decision.
Metric selection
Start with requirements, not a fashionable score.
Write each requirement as an observable claim before choosing a metric. If the application must return valid JSON, test the schema directly. If it must answer from approved documents, measure retrieval and grounding. If it must be useful to a specialist, define a rubric with concrete examples of acceptable and unacceptable responses. This sequence prevents teams from optimising a metric that is easy to calculate but weakly connected to user value. For every metric, document what it measures, what it does not measure, how it is calculated, the population it covers, and how a failure will change the product or release decision.
- Requirement and affected user outcome
- Scoring method and data source
- Threshold or review rule
- Owner, limitation, and expected action
Objective checks
Use deterministic metrics where the outcome is verifiable.
Many important LLM application requirements are ordinary software assertions. A structured response can be validated against a schema. A calculation can be recomputed. A citation can be checked against retrieved sources. A tool call can be compared with permitted functions, argument types, and resulting system state. Deterministic checks are transparent, repeatable, and easier to debug than a subjective score. They should be preferred whenever they capture the actual requirement. Their limitation is coverage: passing an exact check does not prove that the answer is complete, helpful, or safe in every relevant context.
- Schema validity and required fields
- Calculation and transformation correctness
- Citation presence and source correspondence
- Tool selection, parameters, permissions, and side effects
Quality metrics
Define correctness, relevance, and completeness for the task.
Correctness is not always the same as matching one reference answer. Some tasks have several valid responses, while others require a specific fact, procedure, or decision. Relevance asks whether the response addresses the user’s request without unnecessary diversion. Completeness asks whether required elements are present. Fluency and tone may matter, but they should not outweigh factual or operational failures. Build rubrics from real product expectations, include examples at different score levels, and test whether reviewers interpret them consistently. When several dimensions matter, report them separately before considering a combined score.
- Task correctness or factual consistency
- Answer relevance and instruction fulfilment
- Completeness against required elements
- Clarity, tone, and format for the intended audience
RAG metrics
Separate retrieval quality from grounded generation.
A RAG application can fail because it retrieves the wrong passages, because the model ignores good evidence, or because the response makes claims that the evidence does not support. Evaluate these stages separately. Retrieval metrics can measure whether relevant documents or passages appear within the selected context and whether irrelevant material crowds them out. Response metrics can assess groundedness, citation accuracy, answer relevance, and coverage of required facts. Maintain examples where the correct response is to state that evidence is insufficient. This prevents the system from being rewarded for confidently filling gaps with unsupported content.
- Retrieval relevance, recall, and rank
- Context precision and distracting evidence
- Groundedness and citation correctness
- Appropriate abstention when evidence is insufficient
Safety and reliability
Treat critical failures as gates, not small penalties.
Privacy violations, disallowed content, unsafe actions, prompt-injection success, or cross-user disclosure may be rare but consequential. If those failures are averaged with ordinary quality metrics, strong performance elsewhere can hide them. Define critical checks and escalation rules separately from the overall quality score. Reliability also includes consistency across repeated trials, stability across model or prompt updates, graceful handling of unavailable tools, and recovery from invalid input. Segment results by risk level and preserve the evidence needed to reproduce a failure. Where requirements depend on policy or regulation, involve the responsible domain expert rather than inferring compliance from a generic evaluator.
- Policy and prohibited-content checks
- Privacy, leakage, and trust-boundary failures
- Consistency and variance across repeated trials
- Error handling, recovery, and safe failure behaviour
Operational metrics
Measure latency and cost alongside quality.
A response that is accurate but too slow or too expensive may still fail the product requirement. Record end-to-end latency as well as relevant model, retrieval, and tool stages. Track token use, external service cost, retries, error rates, and throughput under realistic conditions. Avoid declaring one model superior from a quality score without showing the operational trade-off. Establish service-level targets by workflow and user need; an interactive assistant and a background document-analysis job may justify different limits. When comparing configurations, hold the dataset and scoring rules constant and report uncertainty rather than treating small differences as decisive.
- End-to-end and component latency
- Token and external-service cost per task
- Error, timeout, and retry rates
- Quality-cost-latency trade-offs by workflow
Calibration
Validate the metric before trusting the dashboard.
A metric is useful only when it agrees often enough with the people and outcomes the organisation cares about. Create a reviewed calibration set with clear labels and difficult disagreements. Compare automated scores with human judgement, inspect false positives and false negatives, and revise rubrics that reward superficial patterns. For model-based judges, test sensitivity to response order, verbosity, phrasing, and the identity of the system being scored. Recalibrate after major task, language, or model changes. Keep raw examples and reviewer notes available so a team can understand why a number moved instead of accepting the metric as an unquestionable fact.
- Human-labelled calibration examples
- Agreement and disagreement analysis
- Bias and sensitivity checks for automated judges
- Scheduled review after meaningful product change
Reference table
LLM metric families and appropriate use
Use the table as a decision aid, then adapt the detail to the application, users, and consequences being evaluated.
| Metric family | Best used for | Important limitation |
|---|---|---|
| Deterministic checks | Schemas, calculations, required fields, tools, prohibited outputs | Only covers conditions explicitly encoded |
| Reference-based | Tasks with a stable target or accepted answer set | Can penalise valid alternative answers |
| Rubric-based | Relevance, completeness, tone, domain quality | Needs clear criteria and reviewer calibration |
| Model-assisted judge | Scaling rubric scoring across many cases | Can be biased, inconsistent, or share blind spots |
| Human review | Ambiguous, high-impact, or domain-specific judgement | Slower, costlier, and subject to reviewer disagreement |
| Operational | Latency, cost, failures, throughput, stability | Does not establish content quality by itself |
Apply the framework
LLM Evaluation Services
Replace demo confidence with repeatable evidence for the models, prompts, retrieval pipelines, and application workflows your users actually depend on.
Evidence base
Primary sources and further reading
Technical claims are bounded to the cited material and the stated QA-CS methodology. Sources were reviewed on 15 August 2026.
- Microsoft: Evaluation metrics for LLM-generated content
Primary platform guidance on metric categories and evaluation methods.
- NIST AI RMF: Generative AI Profile
Official guidance for measuring and managing generative AI risk.
- Anthropic: Demystifying evals for AI agents
Primary guidance on combining code-based, model-based, and human graders.
Questions teams ask
Clarify the evaluation decision.
Is accuracy enough for LLM evaluation?
No. Accuracy may be central for factual tasks, but production applications can also require relevance, completeness, grounding, safety, privacy, structured output, latency, cost, and appropriate failure behaviour.
Can an LLM judge another LLM?
A model can assist with rubric scoring at scale, but its judgement should be calibrated against labelled examples and monitored for bias, inconsistency, and shared blind spots. Consequential or ambiguous failures still need qualified human review.
How should metrics be combined?
Keep important dimensions visible. Use weighted summaries only when weights have a defensible product rationale, and define non-negotiable safety or policy checks as separate gates so strong average performance cannot hide a critical failure.
How do we choose a pass threshold?
Use baseline performance, user and business risk, reviewer agreement, and the consequence of error. Record who approved the threshold, validate it on held-out cases, and revisit it as the product and evaluation set change.
Continue the topic
Related services and guides
Follow the evidence from framework design to metrics, system-level evaluation, security, and delivery.
LLM Evaluation Framework
Build an LLM evaluation framework with representative datasets, suitable scorers, release thresholds, human review, and production feedback.
Read guideAI Agent Evaluation Framework
Evaluate AI agents across tasks, tools, retrieval, memory, safety, latency, cost, and downstream outcomes with a repeatable release framework.
Read guideLLM Evaluation Services
Evaluate LLM applications for quality, groundedness, safety, reliability, latency, and cost with human-reviewed production evidence.
Explore service