LLM eval metrics: exact match, similarity scores, rubrics and pairwise comparison

Take a support assistant for an invented furniture shop. A person has written the reference answer to one test question: "The refund takes five days." On two runs the assistant produces two outputs. The first is "The refund takes ten days." The second is "You get your money back within five days." A score that counts shared words, called ROUGE-1 recall, gives the first output 0.8, because four of the five reference words appear in it. It gives the second output 0.4, because only "five" and "days" appear. The wrong answer scores twice as high as the right one.

That is an invented illustration, computed by hand from the definition in the ROUGE paper [3]. A metric is the rule that turns an output into a score, and each metric counts one specific thing. This page describes five families of metric used in evals, the repeatable tests of an AI product's output. It is one step of the method in the guide to LLM evals, where LLM stands for large language model.

Five families of LLM eval metric in one table

Metric	What it counts	Good for	Fails when
Exact match and code assertions	Whether the output equals a known answer or obeys a rule written in code	Labels, amounts, formats, required links	A correct answer can be worded many ways
BLEU	Runs of words the output shares with reference translations	Comparing translation systems over a whole test set	Used on single texts or outside translation [2]
ROUGE	Words from a reference summary that appear in the output	Summaries with reference summaries written by people	The output is right in new words, or wrong in familiar ones
BERTScore	Similarity of meaning between the output and a reference	Outputs that reword the reference	No reference exists, or nobody has tested the score on your cases
Rubric score	A judgement against written criteria, by a person or a model	Tone, completeness, following instructions	The grader was never compared with human labels
Pairwise comparison	Which of two outputs a grader prefers	Choosing between two versions	You need to know whether either one is good enough

Exact match, BLEU, ROUGE and BERTScore need a reference: a correct answer written or confirmed by a person. Google Cloud's documentation says its computed metrics, "like ROUGE or BLEU", apply "when a ground truth is available" [10]. Ground truth means an answer accepted as correct. OpenAI's documentation names exact match and ROUGE or BLEU scoring among its examples of metric-based evals, and lists human evals and model graders as the other two types [8]. A grader is the person or model that gives the score.

Exact match and code assertions

Anthropic's documentation defines the first: "Exact match evals measure whether the model's output matches a predefined correct answer, typically after normalizing whitespace and case." [7] Normalizing here means ignoring differences in spacing and capital letters. A code assertion is a rule written in code that the output must satisfy. The answer contains the returns link. The answer stays under 120 words. The answer states a return period of 30 days.

The same documentation compares three ways to grade. It calls code-based grading the fastest and most reliable, human grading the most flexible but "slow and expensive", and grading by a model fast and flexible once its reliability has been tested [7]. Its rule is to "choose the fastest, most reliable, most scalable method" that can decide the question [7].

Use a code check for every failure type that has one right form. The page on the three kinds of LLM eval compares it with the other two.

BLEU and ROUGE count shared words

BLEU was published in 2002 by four researchers at IBM for machine translation [1]. BLEU counts the runs of one to four words in the output that also appear in reference translations, combines the four shares into one figure, and applies a penalty to outputs that are too short. The result lies between 0 and 1 [1].

The BLEU paper states two limits. Scores "on individual sentences will often vary from human judgments", because BLEU was built to be averaged over a whole test set [1]. And the score depends on how many references exist: on a test set the paper describes as 500 sentences, a human translator scored 0.3468 against four references and 0.2571 against two [1].

Ehud Reiter reviewed the later evidence in 2018, covering "284 correlations reported in 34 papers". The abstract of that review says the evidence supports BLEU for diagnostic evaluation of machine translation (MT) systems and "does not support using BLEU outside of MT, for evaluation of individual texts, or for scientific hypothesis testing" [2].

ROUGE was published by Chin-Yew Lin in 2004 for summaries: "ROUGE stands for Recall-Oriented Understudy for Gisting Evaluation." [3] Its measures count the units that a computer-written summary shares with "ideal summaries created by humans" [3]. ROUGE-N is the share of the reference's word runs that appear in the output. ROUGE-L uses the longest sequence of words that both texts contain in the same order [3]. The opening illustration is ROUGE-N with runs of one word.

A product answer is a single text, usually outside translation. OpenAI's guide lists "Overly generic metrics" among common mistakes and names BLEU as an example [8].

BERTScore compares meaning instead of exact words

BERTScore was published in 2019 by Tianyi Zhang and four co-authors, who set out to credit an output that keeps the meaning in different words [4]. Their own example uses the reference "people like foreign cars". BLEU, and a second word-overlap score called METEOR, give a higher score to "people like visiting places abroad" than to "consumers prefer imported cars" [4].

BERTScore changes what counts as a match. A language model named BERT turns each token, meaning a word or a piece of a word, into a list of numbers called an embedding. Tokens used with similar meaning get similar numbers. In the authors' words: "instead of exact matches, we compute token similarity using contextual embeddings" [4].

The authors tested it on "the outputs of 363 machine translation and image captioning systems" [4]. They state two limits. First, "there is no one configuration of BERTScore that clearly outperforms all others" [4]. Second, raw scores are in a narrow range, which "makes the actual score less readable", so the authors rescale them against a baseline [4].

The published tests cover translation and image captions. Before a similarity score decides anything in your product, run it on cases a person has already labelled and count how often it agrees.

Rubric scores from a person or a model

A rubric is a written list of criteria with a description of what each score means. Google Cloud's documentation for its own evaluation service describes two kinds. It describes static rubrics in these words: "Apply a fixed set of scoring criteria across all prompts." They return one number for each prompt, such as a score from 1 to 5. Adaptive rubrics, which Google recommends, generate "a unique set of pass or fail rubrics for each individual prompt" [10]. A prompt here is one test input.

The G-Eval paper of 2023 tested a model as the grader. Its grader prompt holds the criteria, evaluation steps that the model writes for itself, and a form to fill in [5]. On SummEval, a public test set of summaries, G-Eval with GPT-4 reached an average Spearman correlation of 0.514 with human ratings, the best figure in the paper's table [5]. A Spearman correlation measures how closely two rankings agree: 1 means the same order and 0 means no relation.

The same paper reports two problems. "LLMs usually only output integer scores, even when the prompt explicitly requests decimal values." [5] And the GPT-4 grader gave GPT-3.5 summaries higher scores than summaries written by people, "even when human judges prefer human-written summaries" [5]. Both models were the 2023 versions.

A model's rubric score therefore has to be compared with human labels before it decides a release. The method is on the page about human review and reviewer agreement. The sample code in Anthropic's documentation carries a second precaution in a comment: "Generally best practice to use a different model to evaluate than the model used to generate the evaluated output" [7]. The post on never letting the model grade its own work argues the same for code.

Pass or fail is easier to keep consistent than a 1 to 5 scale

Hamel Husain and Shreya Shankar take a clear position: "Binary evaluations force clearer thinking and more consistent labeling." [9] Binary means two outcomes, pass or fail. They name three problems with a 1 to 5 scale: "the difference between adjacent points (like 3 vs 4) is subjective and inconsistent across annotators, detecting statistical differences requires larger sample sizes, and annotators often default to middle values to avoid making hard decisions" [9]. An annotator is a person who labels outputs.

OpenAI's guide gives similar advice. For human review it says: "Include a pass/fail threshold in addition to the numerical score". For model graders it says: "Use pairwise comparison or pass/fail for more reliability" [8]. These are positions held by two practitioners and one vendor. The sources read for this guide contain no controlled study that compares the two scales.

We take the same position. Write each criterion as its own pass or fail question. A 1 to 5 score for "quality" becomes several questions. Is every figure in the answer present in the order record? Does the answer give the returns link? Each result names the thing to fix. A pass or fail result also produces a rate with a range around it, which the page on how many test cases an eval needs computes.

Pairwise comparison asks which of two outputs is better

Lianmin Zheng and co-authors describe the method in a 2023 paper: "An LLM judge is presented with a question and two answers, and tasked to determine which one is better or declare a tie." [6]

The paper measured two biases in the graders of 2023.

• Position bias is favouring an answer because of where it appears. When the two answers swapped places, GPT-4 kept its verdict in 65.0 percent of cases, GPT-3.5 in 46.2 percent and Claude-v1 in 23.8 percent [6]. The authors' remedy: "call a judge twice by swapping the order of two answers and only declare a win when an answer is preferred in both orders" [6].
• Verbosity bias is favouring longer answers. The authors lengthened 23 answers with a repeated list and counted how often each grader failed the test: 91.3 percent for Claude-v1, 91.3 percent for GPT-3.5 and 8.7 percent for GPT-4 [6].

Pairwise comparison has two further limits. The paper notes that the number of pairs grows with the square of the number of versions [6]. By our arithmetic, 4 versions make 6 pairs and 10 versions make 45. And a pairwise result names a winner. Whether the winner is good enough to release is a separate pass or fail check.

Choose one metric for each failure type

Error analysis, reading real outputs and grouping the failures, produces a list of failure types. Each type gets the cheapest metric that can decide it. An invented list for the furniture shop:

• Wrong return period stated: a code assertion on the number of days.
• Returns link missing: a code assertion that the link is present.
• Rude tone: a pass or fail rubric question, graded by a model that has been compared with a person's labels.
• Two candidate greetings: a pairwise comparison, judged in both orders.

One overall score hides these types. Suppose two versions each pass 90 of 100 cases. Version A has 2 wrong return periods and 8 tone failures. Version B has 8 wrong return periods and 2 tone failures. The overall score is 90 percent for both, and version B states four times as many wrong facts. Report each failure type as its own pass rate.

The page on error analysis covers how to find the types. Products that search documents before answering need measures for the search step as well, described under RAG evaluation. For the design of a model grader, see LLM as judge vs a decision model.

How Reveneau chooses metrics

At Reveneau we write the expectation for each case before the prompt, and we give every failure type its own check. All of our code is written by AI, and every change must pass a large eval suite, written from the specification before the code, before release. Inside that suite, anything with one right form is a check in code. The checks that need judgement are written as pass or fail questions and graded by Jev, TypeSafe AI's decision model. On our own suite, that run is ten times faster than with our previous language-model grader.

We report each failure type as its own pass rate, so a client sees which type changed. Using AI instead of adding engineers keeps the team small, and that saving goes into the client's price. Reveneau, as a company, takes responsibility for the whole project through production and after release. To choose metrics for your own product, see AI development at Reveneau.