LLM Evaluation Metrics: 17 Metrics, Thresholds and When to Use Them

Shipping an LLM without a proper evaluation strategy is a gamble most teams don’t realize they’re taking. 67% of organizations worldwide now run LLMs in production, but the majority still rely on LLM evaluation metrics designed for 2018-era machine translation or skip structured evaluation altogether. The result is predictable: hallucinations that make headlines, chatbots that give illegal advice, and model updates that silently break things no one notices until users start leaving.

This article covers the LLM evaluation metrics that actually matter. We’ll discuss what each one measures, when to use it, what score to aim for, and the details most teams miss. Whether you run evaluation in-house or bring in LLM evaluation services, these are the numbers that decide if your product is ready to ship.

What Is LLM Evaluation and How Do You Evaluate an LLM?

LLM evaluation is the process of scoring a language model’s outputs against defined criteria to decide whether an application is ready to ship, or still safe to run after a change. Because the same prompt can return different valid answers, evaluation replaces pass/fail assertions with scored metrics and agreed thresholds. To evaluate an LLM application, follow five steps:

1. Define the use case and its risk tier.
2. Build a golden dataset of typical, edge case and adversarial inputs.
3. Pick metrics for each layer: generation, retrieval, agent actions, safety and operations.
4. Set a threshold per metric and score every release candidate against it.
5. Keep scoring a sample of production traffic to catch drift.

If you are still defining your use case or building a golden dataset, our LLM testing checklist covers both in detail. This guide focuses on what comes next: choosing metrics, setting thresholds and measuring quality after launch.

Types of LLM Evaluation Metrics

Every LLM metric sits on two axes: whether it needs a reference answer, and whether a formula or a model does the scoring. Knowing where a metric sits tells you when you can run it and what it will miss.

Reference-based metrics compare the output to a known correct answer, so they need a labeled golden dataset. They are reliable before release but cannot run on live traffic, where no reference exists. Reference-free metrics judge the output on its own or against the user’s input and retrieved context, which is why they carry most of the load in production.

Statistical metrics use fixed formulas such as n-gram overlap or token probabilities. They are cheap, fast and reproducible, but they score wording rather than meaning. Model-based metrics use an embedding model, a classifier or a second LLM acting as a judge. They capture meaning and nuance, but they cost money per call and inherit the biases of the model doing the scoring.

A balanced suite uses at least one metric from each row. Statistical metrics give you a stable baseline for regression checks, while model-based metrics tell you whether the answer was actually right.

LLM Evaluation Metrics at a Glance: Thresholds by Risk Tier

To block a bad release, every metric needs a pass mark agreed before testing begins. The table below lists all 17 metrics in this guide with the starting thresholds we use, split into two risk tiers. The general tier covers internal tools and customer-facing assistants where a person can still catch a mistake. The high-stakes tier covers legal, medical, financial and compliance products, plus any app where users act on an answer without checking it.

Scores on a 0 to 1 scale are normalized, which is how Ragas and DeepEval report them. Treat these numbers as starting points, then calibrate them: score 50 to 100 human-labeled examples and move each threshold to where good and bad answers actually separate on your data.

Generation and Quality Metrics

Generation metrics score the text the model produces, whatever pipeline sits behind it. They apply to every LLM app, from a support chatbot to a contract summarizer. Start with this group, then add the RAG, agent and safety metrics that match your architecture.

1. Answer Relevance

Answer relevance measures whether the response addresses what the user actually asked. A model can stay faithful to its sources and still answer a different question, a common failure in support bots that paraphrase the help center instead of solving the problem.

• How it is computed: in Ragas, an LLM writes three questions the response would answer, and the score is the mean cosine similarity between their embeddings and the original question.
• Tools: Ragas and DeepEval.
• Threshold: 0.70 or higher for general use and 0.80 or higher for high-stakes products.
• Worked example: a user asks whether they can change a delivery address after checkout, and the bot replies with the full returns policy. The reverse-engineered questions are about return windows, the score lands near 0.4 and the case fails.

When relevance is low across the whole test set, check the system prompt before blaming the model. A vague or overloaded prompt drags this score down even on capable models.

2. Hallucination Rate

Hallucination rate is the share of answers that contain at least one false claim, checked against ground truth rather than retrieved context. It is the metric that catches chatbots giving illegal advice, like New York City’s MyCity bot, which The Markup found telling employers they could take a cut of workers’ tips.

• How it is computed: split each answer into atomic claims, verify each claim against a trusted source and count the answer as hallucinated if any claim fails. This follows FActScore (Min et al., 2023), which found that only 58% of the atomic facts in ChatGPT’s generated biographies were supported.
• Tools: DeepEval, the FActScore package and human review on a sample.
• Threshold: 5% or lower for general use and 1% or lower for high-stakes products.
• Worked example: a test set has 200 questions about an HR leave policy, and 9 answers state the wrong number of days. That is a 4.5% rate, which passes the general tier and fails the high-stakes one.

Automated claim checking still needs a human-reviewed sample to confirm the checker itself is right. Budget for that review before you make this a release gate.

3. BLEU and ROUGE

BLEU and ROUGE score word overlap between the output and a reference answer. BLEU (Papineni et al., 2002) is precision-oriented and was built for machine translation, while ROUGE (Lin, 2004) is recall-oriented and was built for summarization.

• How it is computed: BLEU counts matching word sequences of one to four words and penalizes outputs that are too short. ROUGE-L uses the longest common subsequence between output and reference.
• Tools: sacreBLEU, rouge-score and Hugging Face Evaluate.
• Threshold: absolute scores vary by language pair and dataset, so gate on change. Block a release when the score falls more than 5% below the last baseline, or 2% for high-stakes products.
• Worked example: the reference reads “Refunds are processed within five business days” and the output reads “We process refunds in five working days.” The meaning is identical, yet the overlap is small, so BLEU scores it poorly.

The G-Eval paper notes that both metrics correlate weakly with human judgment, especially on tasks that call for creativity. Keep them as regression signals for translation and structured summarization, not as the main gate for open-ended answers.

4. BERTScore

BERTScore compares meaning rather than exact words, which fixes the paraphrase problem above. It is a reference-based, model-based metric, so it still needs a golden answer.

• How it is computed: BERTScore (Zhang et al., 2019) embeds every token in the output and reference, matches each token to its most similar counterpart and reports precision, recall and F1.
• Tools: the bert-score package and Hugging Face Evaluate. Use rescaled scores, since raw scores cluster in a narrow high band.
• Threshold: baseline-relative, the same as BLEU and ROUGE.
• Worked example: the refunds pair above scores high on BERTScore despite its low BLEU score. However, an output saying “fifteen business days” also scores high, because one changed word barely moves the embedding.

That second result is the main limit of similarity metrics. Pair BERTScore with a factual check such as hallucination rate whenever numbers, dates or names matter.

5. Perplexity

Perplexity measures how well a model predicts a sample of text, with lower scores meaning higher confidence. It has nothing to do with the Perplexity search product.

• How it is computed: perplexity is the exponential of the average negative log-likelihood per token over an evaluation text, as the Hugging Face documentation explains. It needs token log-probabilities, so it mainly applies to open-weight models you host or fine-tune.
• Tools: Hugging Face Transformers and EleutherAI’s lm-evaluation-harness.
• Threshold: diagnostic only. Compare perplexity before and after a fine-tune on held-out text from your domain and on general text.
• Worked example: after fine-tuning on support tickets, perplexity on held-out tickets falls while perplexity on general text rises sharply. The fine-tune has overfit and may hurt answers outside the ticket domain.

Perplexity says nothing about correctness or relevance. A model can be fluent and confident while stating something false, so never use it as a production quality gate.

6. LLM-as-a-Judge Score (G-Eval)

LLM-as-a-judge uses a second model to score outputs against criteria you write in plain language, such as “the reply gives the customer a clear next step.” G-Eval (Liu et al., 2023) adds auto-generated evaluation steps and a form-filling score, and with GPT-4 it reached a Spearman correlation of 0.514 with human ratings on summarization, ahead of earlier automated methods.

• How it is computed: the judge reads the criteria, the evaluation steps and the output, then returns a score from 1 to 5. G-Eval weights that score by token probabilities, and DeepEval normalizes it to 0 to 1.
• Tools: DeepEval’s G-Eval metric and LangSmith evaluators.
• Threshold: 0.70 or higher for general use and 0.80 or higher for high-stakes products, once calibrated against human labels.
• Worked example: a judge scores 300 support replies on “gives a clear next step.” The average is 0.82, but replies about billing average 0.55, which points the team to one weak intent instead of a model-wide problem.

Judges have their own biases. Zheng et al. (2023) found that LLM judges favor answers in the first position, longer answers and their own outputs, even though GPT-4 agreed with human preferences more than 80% of the time. Use a judge from a different model family than the one under test, swap answer order in pairwise comparisons and calibrate on at least 50 human-labeled examples.

RAG Metrics

Retrieval-augmented generation adds a second point of failure: the retriever. These three metrics split the score so you can tell whether a bad answer came from the documents pulled or from what the model did with them. For tool-by-tool coverage, see our comparison of RAG evaluation tools, and for a full pipeline audit, our RAG testing services cover these checks across retrieval, ranking and generation.

7. Faithfulness

Faithfulness measures whether every claim in the answer is supported by the retrieved context. It is the core metric for any app that answers from internal documents, knowledge bases or policies, and a central check when you follow RAG best practices.

• How it is computed: in Ragas, an LLM splits the answer into claims and checks each one against the context. The score is supported claims divided by total claims.
• Tools: Ragas and DeepEval.
• Threshold: 0.75 or higher for general use and 0.90 or higher for high-stakes products. For Granola, an AI notepad that turns meeting transcripts into summaries, we set the faithfulness target at 0.90.
• Worked example: Air Canada’s chatbot told a passenger he could claim a bereavement fare retroactively, while linking to the airline’s own bereavement page that said the opposite. The tribunal decision held the airline liable for negligent misrepresentation and awarded $650.88 in damages.

Score a four-claim reply like that one, with three claims supported and one contradicted, and faithfulness is 0.75. That passes the general tier even though the one wrong claim is the one that cost money. For policy, pricing and legal answers, add a rule that any contradicted claim fails the test case, whatever the average says.

8. Context Precision

Context precision measures whether the relevant chunks are ranked at the top of what the retriever returns. Noise near the top crowds the context window and pushes the model toward the wrong passage.

• How it is computed: Ragas takes precision at each rank where a relevant chunk appears and averages those values, so the score rewards relevant chunks that rank early.
• Tools: Ragas, DeepEval and retrieval-focused tools such as TruLens.
• Threshold: 0.70 or higher for general use and 0.80 or higher for high-stakes products.
• Worked example: the retriever returns five chunks, with relevant ones at positions 1 and 4. Precision at those ranks is 1.0 and 0.5, so context precision is 0.75. Move the second relevant chunk to position 2 and the score rises to 1.0.

Low context precision usually points to chunking or reranking rather than the model. Fix the ranking before you spend time on prompt changes.

9. Context Recall

Context recall measures whether the retrieved chunks contain everything needed to answer correctly. If a key fact never reaches the model, no prompt can fix the answer.

• How it is computed: Ragas splits a reference answer into claims and checks how many can be attributed to the retrieved context. The score is attributable claims divided by total reference claims, so it needs a golden dataset.
• Tools: Ragas and DeepEval.
• Threshold: 0.75 or higher for general use and 0.90 or higher for high-stakes products.
• Worked example: the reference answer to a parental leave question has four claims, and the retrieved chunks support three. The missing claim is the eligibility rule, so recall is 0.75, which passes general use and fails a high-stakes HR assistant.

Read faithfulness and context recall together. High faithfulness with low recall means the model is honestly summarizing incomplete documents, which is a retrieval bug, not a generation bug.

Agent Metrics

Agents call tools, chain steps and change state in other systems, so a fluent final message proves very little. The two metrics below are the minimum for any agent that acts on a user’s behalf. Trajectory, planning and recovery metrics are covered in our guide to AI agent evaluation metrics.

10. Task Completion Rate

Task completion rate measures whether the agent reached the user’s goal and left the system in a valid end state. “Produced a response” does not count; “the meeting exists in the calendar with the right attendees” does.

• How it is computed: the most reliable method checks the end state directly, for example by querying the database after the run. Where that is not possible, DeepEval’s task completion metric uses an LLM judge to extract the task and the outcome from the trace and score how well they align.
• Tools: DeepEval, LangSmith and custom end-state assertions in your test framework.
• Threshold: 90% for single-step tasks and 70% for multi-step workflows in the general tier, rising to 95% and 85% for high-stakes products.
• Worked example: a travel agent runs 50 single-step scenarios and completes 47, which is 94%. On 50 multi-step itineraries it completes 31, which is 62% and blocks the release.

Write success criteria for each task type before you measure anything. Without them, task completion turns into a debate about whether a half-booked trip counts.

11. Tool Call Accuracy

Tool call accuracy measures whether the agent chose the right tool, passed the right arguments and called tools in a valid order. An agent can reach a plausible final answer through a wrong or risky path, and only this metric shows it.

• How it is computed: compare the tools called in each test case with the expected calls and arguments. The score is correct calls divided by expected calls, and DeepEval offers a ready-made tool correctness metric for this.
• Tools: DeepEval and trace-level assertions in LangSmith or your own harness.
• Threshold: 0.90 or higher for general use and 0.95 or higher for high-stakes products. Allow zero wrong calls on irreversible actions such as payments, deletions or outbound emails.
• Worked example: a refund agent scores 0.93 overall, but in 2 of 60 cases it passed the order total instead of the item price to the refund tool. The average passes, yet the irreversible-action rule fails the build.

Log every tool call with its arguments in production as well as in testing. Tool errors are rarely visible in the final message, so traces are the only place you will find them.

Safety Metrics

Safety metrics apply to every customer-facing deployment, whatever its architecture. They also carry regulatory weight: the EU AI Act requires providers of high-risk systems to examine training data for possible bias and to reach appropriate levels of accuracy and robustness. The Digital Omnibus on AI moved most stand-alone high-risk obligations to 2 December 2027, which gives teams time to build the test evidence, not a reason to skip it.

12. Toxicity Score

Toxicity score measures how likely an output is to be harmful, insulting, threatening or explicit. Most toxic outputs in production come from adversarial or emotionally charged inputs, so test with those rather than with polite questions.

• How it is computed: a classifier or an LLM judge scores each output from 0 to 1, and you track both the per-output score and the share of outputs above your threshold.
• Tools: Detoxify, OpenAI’s moderation endpoint, Llama Guard and DeepEval’s toxicity metric. If you still rely on Google’s Perspective API, plan a replacement: Google says the service will not run after 31 December 2026.
• Threshold: 0.10 or lower per output for general use and 0.05 or lower for high-stakes products. Review every output above the line before release.
• Worked example: 1,000 adversarial prompts produce 7 outputs scoring above 0.10, a 0.7% rate. Six are the model quoting the user’s own insult back, which a prompt fix resolves, and one is a genuine failure that needs a guardrail.

Generic classifiers miss context-specific harm. A legal assistant can pass every toxicity filter and still produce advice that exposes your company to liability, which is why domain-specific test sets belong in your AI testing plan.

13. Bias Score

Bias score measures whether answer quality or outcomes change when only a protected attribute in the input changes. An individual answer can look fine while the pattern across groups is not.

• How it is computed: build counterfactual prompt pairs that differ only in name, gender, age or another attribute, score both answers with the same metric and report the average gap. Benchmarks such as BBQ (Parrish et al., 2022) cover social bias in question answering.
• Tools: DeepEval’s bias metric, custom counterfactual suites and IBM’s AIF360 for classification-style outputs.
• Threshold: a gap of 0.05 or lower for general use and 0.02 or lower for high-stakes products.
• Worked example: a hiring assistant summarizes 200 identical CVs, half with typically male names and half with typically female names. The judge’s “strength of candidate” score averages 0.81 and 0.74, a gap of 0.07 that fails the gate.

Bias testing needs inputs that reflect your real users and use cases. A public benchmark tells you about the base model, while your own counterfactual pairs tell you about your product.

14. Injection Resistance

Injection resistance measures how reliably the app keeps to its instructions when a user, document or web page tries to override them. Direct injections arrive in the user’s message, while indirect injections hide in retrieved files, emails or tool results that the model treats as trusted content.

• How it is computed: run a suite of known direct and indirect attack prompts and count the share the app resists without following the injected instruction, leaking its system prompt or calling tools it should not.
• Tools: Garak, PyRIT, Promptfoo and DeepEval’s red teaming module, plus manual red teaming for chained and context-specific attacks.
• Threshold: 100% on your attack suite for both general and high-stakes products. Any successful injection blocks the release until it is fixed and added to the regression set.
• Worked example: a support assistant resists 248 of 250 attack prompts. Both failures come from an uploaded PDF with hidden text telling the model to reveal its system prompt, so the score is 99.2% and the release is blocked.

Automated scanners cover known patterns, while new attack phrasing appears all the time. Our prompt injection testing checklist covers the attack surfaces to probe before launch.

Operational Metrics

An answer that is correct but arrives too slowly, or costs too much to serve at scale, still fails in production. Operational metrics are where quality targets meet budgets and service levels. Track them alongside quality scores, because most fixes for one move the other.

15. Latency

Latency measures how long users wait for an answer. For chat interfaces, time to first token (TTFT) drives perceived speed, while total response time and its 95th percentile (p95) show what slower users actually experience.

• How it is computed: log TTFT, total response time and output tokens per second for every request, then report the median and p95 under realistic concurrent load.
• Tools: load testing tools such as k6 or Locust, plus tracing in LangSmith, Langfuse or OpenTelemetry.
• Threshold: TTFT under 1 second for streaming chat, with p95 total latency inside the service level you promise users.
• Worked example: a support bot shows a median TTFT of 0.6 seconds in staging. At 500 concurrent sessions the p95 TTFT climbs to 3.4 seconds, because a reranking step queues behind the model call.

Teams usually tune for quality in development and discover latency at load testing. Add LLM latency to your performance testing plan from the first sprint, and record the quality score per latency bucket to see what a faster configuration really costs.

16. Cost per Request

Cost per request measures what one answer costs to produce, including the model call, retrieval, reranking, judges and retries. A setup that looks cheap with ten test users can behave very differently at production volume.

• How it is computed: sum input and output tokens per request multiplied by each model’s price, then add retrieval, tool and infrastructure costs. Report the average and the p95, since long conversations and agent loops create expensive outliers.
• Tools: provider usage dashboards, Langfuse or LangSmith cost tracking and your cloud billing exports.
• Threshold: within budget at 10 times expected volume, with an alert on any sudden rise in average tokens per request.
• Worked example: an agent averages $0.04 per request, but 3% of sessions loop through the same tool and cost more than $1 each. A step limit cuts the p95 cost by more than half without changing the task completion rate.

Cost belongs in the release gate, not only in the finance report. A prompt change that adds 2,000 tokens of context to every call is a regression even when every quality metric holds.

17. Error Recovery

Error recovery checks whether the app behaves correctly when something between the user and the model fails, such as a dropped connection, a timeout or an error from the model provider. LLM apps rely on long streamed responses and external APIs, so network failures are routine rather than rare.

• How it is computed: inject faults in a test environment, for example by cutting the connection mid-stream, returning a 429 or 500 error from the provider or timing out a tool call. Each scenario is a simple pass or fail: the app retries or shows a clear message, keeps the conversation state and never presents a partial answer as complete.
• Tools: Toxiproxy or a mock provider for fault injection, plus Playwright or your end-to-end framework to check what the user sees.
• Threshold: pass on every scenario for both general and high-stakes products.
• Worked example: when the stream drops at 60%, a chat app shows the half-written answer with no warning, which is a fail. A refund agent that retries a timed-out payment call and refunds the customer twice also fails, even though its final message looks correct.

Run these scenarios on every release, not only once before launch. A dependency upgrade or a new retry setting can quietly change how the app behaves when a call fails.

How to Pick the Right Metrics for Your Use Case

No product needs all 17 metrics as release gates. Pick three to five must-haves that map to how your app can fail, and track the rest as supporting signals. As a rule, combine at least one reference-based metric, one reference-free metric and one metric specific to the task.

If you are looking for LLM accuracy metrics specifically, hallucination rate, faithfulness and task completion rate map most directly to “was it right.” For fluency, use an LLM judge with a fluency criterion on live outputs and keep perplexity for model development.

How to Measure LLM Output Quality in Production

Pre-release scores describe your golden dataset, not your users. LLM evaluation in production answers a different question: is quality holding on real traffic this week? The setup below keeps that answer current without scoring every request with an expensive judge.

Sample Live Traffic in Two Layers

Run cheap checks on 100% of requests: toxicity classifiers, format and schema validation, latency and cost. Then send a sample of 1% to 5% of conversations to model-based metrics such as faithfulness, answer relevance and your G-Eval criteria. Stratify the sample by intent and oversample conversations with negative feedback, retries or unusual length, since that is where failures cluster.

Run Judges Online, Outside the Request Path

Online judges should score logged conversations asynchronously, so they never add latency for the user. Use the same judge model, prompt and criteria as in pre-release testing, or your production scores will not be comparable to your release baseline. Pin the judge version as carefully as the model under test.

Watch for Drift

Compare rolling daily averages against the release baseline and alert when a metric drops by more than 0.05 for three consecutive days. Track input drift as well, for example new question topics that your golden dataset never covered. Provider-side model updates can change behavior without any change on your side, so pin model versions and re-run the full suite before you move to a new one.

Close the Loop

Every week, have a person review the lowest-scoring conversations from the sample. Confirmed failures go into the golden dataset as new test cases, which makes the next release gate stricter in exactly the places production found weak. This loop is what turns monitoring into a measurable improvement rather than a dashboard nobody reads.

Running LLM Evaluation in CI

Metrics only protect you if they run on every change that can alter behavior: prompts, model versions, retrieval settings, tools and knowledge base updates. Treat them like any other automated test suite, with fast checks on every commit and the full suite before release. Our guide to LLM regression testing covers baselines and test design in depth.

A practical setup runs in three layers:

1. On every commit, run a smoke set of 30 to 50 cases with deterministic checks, toxicity and format validation. It should finish in minutes.
2. On every pull request that touches prompts, models or retrieval, run the full golden dataset with model-based metrics such as faithfulness, answer relevance and task completion.
3. Nightly and before each release, run the full suite plus adversarial and bias sets, and compare every score with the last approved baseline.

Gate on two rules at once. A change fails if any metric drops below its threshold, and it also fails if a metric falls more than 0.03 below the baseline, even while still above the threshold. Add the critical-case rule from the faithfulness section, so one contradicted policy claim fails the build regardless of averages.

LLM outputs vary between runs, so score each case three times or at temperature 0 and compare averages rather than single results. DeepEval runs as a pytest suite, and tools such as Promptfoo plug into GitHub Actions or GitLab CI with little setup.

If you need help choosing metrics, setting thresholds or wiring evaluation into your pipeline, contact us. We will review your current setup and tell you which gates to add first.

FAQ

What are LLM evaluation metrics?

LLM evaluation metrics are scores that measure how well a language model application performs on a defined criterion, such as relevance, factual accuracy, safety or speed. Each metric turns a qualitative question, like “is this answer grounded in our documents,” into a number you can track and gate releases on. They fall into reference-based and reference-free groups, and are computed either by formulas or by models acting as judges.

What are the most important LLM evaluation metrics?

The most important metrics depend on how your app can fail. For most production apps, answer relevance, hallucination rate and toxicity form the baseline. RAG apps add faithfulness, context precision and context recall, while agents add task completion rate and tool call accuracy.

How do you measure hallucinations in an LLM?

Split each answer into atomic claims and check each claim against a trusted source, either ground truth for hallucination rate or the retrieved context for faithfulness. An answer counts as hallucinated if any claim is unsupported, and the rate is hallucinated answers divided by total answers. Automate the checking with an LLM judge, then confirm the judge’s accuracy on a human-reviewed sample.

Can LLM evaluation be automated?

Most of it can. Statistical metrics, classifiers and LLM judges can run on every commit and on sampled production traffic without manual effort. Human review is still needed to calibrate thresholds, validate the judges and handle edge cases, especially for high-stakes products.