LLM Evaluation Metrics Explained: Perplexity, BLEU, ROUGE, and Beyond

Contents

What each number computes, where each lies, and what to use instead

Your model scored 0.76 BLEU on a sentence that states the wrong capital of France. A correct paraphrase scored 0.00. Is the metric broken, or are you using it wrong?

Mostly the second. Each classic metric measures one narrow thing, and trouble starts when you ask it to measure something else. This article explains what perplexity, BLEU, and ROUGE actually compute, where each fails, and what to add on top — the metric-level companion to the full LLM evaluation guide.

The numbers below come from implementations written from scratch and tested by hand: no metric library (nltk, sacrebleu, rouge_score) was installable in the sandbox, so the code is checked against the papers' worked examples and hand calculations rather than against those libraries.

Perplexity: How Surprised Is the Model?

Hugging Face's docs define perplexity as "the exponentiated average negative log-likelihood of a sequence." In plain terms, it asks how well the model predicts each next token. Lower is better.

Two facts help build intuition:

• A model that spreads probability evenly over 1,000 tokens has perplexity exactly 1,000. The demo below confirms it:

import math

uniform_p = 1 / 1000                      # one guess, 1,000 options, all equal
perplexity = math.exp(-math.log(uniform_p))
print(perplexity)                          # 1000.0 — exactly one unit of surprise per token

• Perplexity can't go below the data's true entropy. On a synthetic 50-word source, the best possible perplexity was 20.71. The true model scored 20.98 on a sample, and a model estimated from only 200 words scored 23.31.

The docs add two caveats worth remembering. Perplexity applies to autoregressive models and "is not well defined for masked language models like BERT." And context matters: for fixed-length models, the docs show GPT-2 on WikiText-2 scoring 19.44 with non-overlapping chunks and 16.44 with a stride of 512, because overlap gives the model more context.

The Tokenizer Trap

This one catches people. The docs say it directly: "the tokenization procedure has a direct impact on a model's perplexity which should always be taken into consideration when comparing different models."

The demo made it concrete. The same text, the same model, and the same total information (15,134 nats) gave a perplexity of 20.63 per word but 1.89 per character. Nothing about the model changed, only the unit of counting. A fair comparison across tokenizers uses total loss per character or byte — here, 0.922 bits per character.

Use perplexity for comparing models with the same tokenizer on the same text. Don't use it to judge whether answers are correct or helpful. It says nothing about either.

BLEU: Precision Against a Reference

BLEU comes from machine translation. The original paper defines it with three pieces:

• Modified n-gram precision. Count each candidate n-gram, but cap its count at the most times it appears in any reference. The paper's example is the candidate "the the the the the the the," which scores 2/7 — reproduced exactly.
• A brevity penalty. Equal to 1 if the candidate is at least as long as the reference, otherwise e^(1 − r/c). A 3-word answer against a 6-word reference gets e^(−1) = 0.368, even if every word matches.
• A geometric mean of precisions for 1- to 4-grams with equal weights.

That last part has a nasty side effect. If no 4-gram matches, the geometric mean is zero — at the sentence level, BLEU often returns exactly 0.000 for answers that are perfectly fine:

import math

def brevity_penalty(c, r):
    return 1.0 if c >= r else math.exp(1 - r / c)

print(brevity_penalty(3, 6))              # 0.368 — short-but-correct answer, penalized
precisions = [1.0, 1.0, 1.0, 0.0]         # words match, no 4-gram does
print(math.prod(precisions) ** 0.25)      # 0.0 — sentence BLEU reported as exactly zero

BLEU Isn't One Number

Matt Post's 2018 paper says BLEU "is in fact a parameterized metric whose values can vary wildly," reports "differences as high as 1.8 between commonly used configurations," and blames "different tokenization and normalization schemes applied to the reference." His fix is SacreBLEU, a tool that standardizes the scheme.

The toy version agrees on direction. On five sentence pairs, splitting on spaces gave a mean BLEU of 0.471, and splitting punctuation off gave 0.701. Same text, different number. (Punctuation tokens match easily, so the gap here is exaggerated; Post's 1.8 is on real data.) Always report your tokenization.

ROUGE: Recall Against a Reference

ROUGE, from Chin-Yew Lin's 2004 paper, was built for summarization. The paper describes four variants. The two you'll see most:

• ROUGE-N: n-gram overlap divided by the n-grams in the reference, so it's recall-oriented.
• ROUGE-L: based on the longest common subsequence, with recall, precision, and an F-measure.

Two more — ROUGE-W (weighting consecutive matches) and ROUGE-S (skip-bigrams) — exist but weren't implemented here.

Recall-oriented has a consequence: in testing, a correct answer padded with extra text kept ROUGE-1 recall at 1.00, even though its F-score fell to 0.63. If you track only recall, you reward rambling.

Watching Them Fail

Here's the reference sentence from the test: "The capital of France is Paris and it is on the Seine."

Candidate	BLEU-4	ROUGE-1 F	ROUGE-L F
Exact copy	1.000	1.00	1.00
True paraphrase	0.000	0.57	0.36
Wrong fact, same words ("Berlin")	0.761	0.92	0.92
Words shuffled	0.000	1.00	0.46
Short but correct	0.000	0.56	0.44

Three lessons in one table:

• Overlap isn't truth. The wrong-fact sentence beat the correct paraphrase on every column.
• Order matters unevenly. The shuffled sentence kept ROUGE-1 at 1.00, which ignores order, while BLEU-4 and ROUGE-L dropped.
• Paraphrases get punished. Correct wording that differs from the reference scores low.

The second row is the one to remember. If your answers can be phrased many ways, these metrics measure how much your model sounds like one particular reference — which isn't the same as being right.

Figure 1: Five candidates, three metrics — the wrong fact wins every column while the correct paraphrase loses

Where These Metrics Still Earn Their Keep

Don't throw them out. They're cheap, fast, and reproducible, which makes them good at three jobs:

• Regression checks. Did a change move the numbers a lot? — the gate shape the regression testing guide builds.
• Constrained tasks. Translation, extractive summaries, and templated output, where references are close to unique.
• Sanity floors. A score near zero usually means something is broken.

Just don't treat a small difference as a verdict.

Beyond N-Grams

Embedding-based metrics. BERTScore compares tokens with "contextual embeddings" instead of exact matches. Its abstract claims it "correlates better with human judgments and provides stronger model selection performance than existing metrics." That's the authors' claim and it wasn't tested here — expect it to help with paraphrases and still struggle with a swapped fact, but that's an expectation, not a measurement.

LLM-as-judge. A strong model grades outputs. The MT-Bench paper reports that strong judges reach "over 80% agreement" with human preferences, matching human-to-human agreement. It also lists biases to watch: "position, verbosity, and self-enhancement," plus "limited reasoning ability." The full bias catalog and the calibration routine live in the evaluation guide's judge section.

A simulation makes one bias tangible. Model X truly wins 60% of the time. A judge that favors the first-shown answer 10% of the time reports 0.64 when X is shown first, 0.54 when second, and 0.59 when order is randomized. Randomization removes the swing but still pulls the number toward 50%. (The 10% is invented for the demo — the paper names the bias, but the figure isn't from it.)

Human review and task checks. For anything high-stakes, sample outputs and have people grade them — the capture loop is the feedback signals playbook. For tasks with checkable answers — code that runs, JSON that parses, math with a known result — test the property directly. That beats any similarity score, and it's the first rule of the agent metrics guide.

How to Choose

• Can you check the answer directly? Do that. Unit tests and exact match beat similarity.
• Is there one right phrasing? BLEU or ROUGE can work as a quick signal.
• Are many phrasings valid? Use an embedding metric or a judge, and calibrate against human labels.
• Comparing language models? Use perplexity only with matching tokenizers, or use loss per character.
• Shipping to users? Add human review on a sample.

Whatever you pick, report the exact settings: tokenizer, smoothing, judge prompt, and model version. A number without its settings can't be compared with anything.

Common Pitfalls

• Comparing perplexity across tokenizers — the same text scored 20.63 per word and 1.89 per character.
• Reporting BLEU without the tokenization scheme — configurations differ by up to 1.8.
• Trusting recall alone and rewarding long outputs — ROUGE-1 stayed 1.00 on padded text.
• Using one reference for open-ended tasks — you're measuring resemblance to one phrasing.
• Accepting a judge model's score unaudited — position and verbosity bias are documented, not hypothetical.
• Skipping a human spot-check on anything a user will read twice.
• Treating sentence-level BLEU as pass/fail — the geometric mean hits zero without a 4-gram match.
• Chasing a metric gain users never feel — pair every swing with regression tests and real feedback.

Unlock AI That Actually Works

Get lifetime access to GPT-6 Astra, Claude Fable 5.1, Gemini 3.5, Grok 4.5, and more — all in one platform. Build websites, apps, videos, content, and digital products from a single command. No monthly fees. No tool-hopping.

Click here to get GPTAstra Max now — one-time payment, lifetime access.

Frequently Asked Questions

What does perplexity actually measure?

Perplexity is the exponentiated average negative log-likelihood of a sequence — how well the model predicts each next token, where lower is better. Two facts build intuition: a model spreading probability evenly over 1,000 tokens has perplexity exactly 1,000, and perplexity cannot drop below the data's true entropy (a synthetic 50-word source had a floor of 20.71, the true model scored 20.98 on a sample, and a model estimated from 200 words scored 23.31). It applies to autoregressive models only — Hugging Face's docs say it is not well defined for masked models like BERT — and context changes the number: GPT-2 on WikiText-2 scores 19.44 with non-overlapping chunks and 16.44 with a stride of 512. The tokenizer trap is decisive: the same text, model, and total information (15,134 nats) gave perplexity 20.63 per word but 1.89 per character. Compare perplexity only across models with the same tokenizer on the same text, prefer loss per character across tokenizers, and never use it to judge whether answers are correct or helpful.

Why does BLEU score 0.000 on correct answers?

BLEU multiplies three pieces: modified n-gram precision (candidate counts capped at reference counts — the paper's "the the the the the the the" example scores 2/7), a brevity penalty (1 if the candidate is at least as long as the reference, otherwise e^(1 − r/c), so a 3-word answer against a 6-word reference gets 0.368 even with perfect words), and a geometric mean of precisions for 1- through 4-grams. That last piece is the trap: if no 4-gram matches, the geometric mean is zero, so sentence-level BLEU returns exactly 0.000 for answers that are perfectly fine — and paraphrases almost never share 4-grams. BLEU also isn't one number: Matt Post's 2018 paper reports configurations differing by as much as 1.8 BLEU from tokenization and normalization choices, which is why SacreBLEU exists. A toy implementation split two ways gave 0.471 versus 0.701 on the same five sentence pairs. Always report your tokenization.

What is the difference between BLEU and ROUGE?

BLEU is precision-oriented and was built for machine translation: it measures how much of the candidate is supported by the reference, with a brevity penalty against short answers. ROUGE is recall-oriented and was built for summarization (Chin-Yew Lin's 2004 paper): ROUGE-N divides n-gram overlap by the n-grams in the reference, ROUGE-L scores the longest common subsequence with recall, precision, and an F-measure, and the less common ROUGE-W and ROUGE-S weight consecutive matches and skip-bigrams. The recall orientation has teeth: in testing, a correct answer padded with extra text kept ROUGE-1 recall at 1.00 while its F-score fell to 0.63 — track recall alone and you reward rambling. On a five-row failure table, a wrong-fact sentence ('Berlin' instead of Paris) beat a correct paraphrase on every column (BLEU-4 0.761 vs 0.000), and word shuffling kept ROUGE-1 at 1.00 while BLEU-4 and ROUGE-L collapsed.

Which metric should you use for LLM outputs?

Work down the decision list: if you can check the answer directly, do that — unit tests and exact match beat any similarity score. If there is one right phrasing (translation, extractive summaries, templated output), BLEU or ROUGE work as a quick regression signal. If many phrasings are valid, use an embedding metric like BERTScore or an LLM judge and calibrate against human labels — MT-Bench reports strong judges reach over 80% agreement with human preferences, while listing position, verbosity, and self-enhancement biases. When comparing language models, use perplexity only with matching tokenizers, or loss per character. When shipping to users, add human review on a sample. Whatever you pick, report the exact settings — tokenizer, smoothing, judge prompt, model version — because a number without its settings cannot be compared with anything.

Wrapping This Up

Perplexity tells you how well a model predicts text. BLEU and ROUGE tell you how much a candidate overlaps with a reference. None of them tells you whether an answer is true, helpful, or safe. A wrong-fact sentence outscored a correct paraphrase in the test above, and a tokenizer change alone moved the numbers.

Use the cheap metrics for regressions and constrained tasks, add embeddings or judges for open-ended output, and keep humans in the loop. Pick your metric from the question you're really asking, then write down the settings.

If you're standing at the start of an eval program rather than a metric choice, begin with the first principles guide: define good, build 50 real cases, and only then decide which of these numbers gets to speak.

Related Articles

• LLM Evaluation: Complete Guide to Testing and Measuring LLM Outputs
• Evaluating AI Agents: Metrics, Benchmarks, and Test Strategies
• LLM Regression Testing: Catch Broken Outputs After Prompt Changes
• Feedback Loops for LLM Apps: Turn User Signals into Better Outputs