How to Evaluate a Language Model: From Metric to Decision

As of July 30, 2026, a table declaring one model “better” usually hides the decisive question: better for which decision, on which population, and at what cost of error? Perplexity, BLEU, and human preference measure different objects. No isolated number turns a demonstration into evidence. The durable method is to build a chain connecting a real task, traceable data, a baseline, metrics, uncertainty, and deployment thresholds.

Start with harm, not the benchmark

Before choosing a metric, write down the unit of work: input, output, user, and subsequent action. A summary used to locate documents can tolerate mediocre style if it does not omit the key passage. Text shown to a patient carries a different cost when it invents a dose. A translation tool may require terminological fidelity rather than general naturalness.

Then classify errors and assign severity. What happens after an omission, changed number, inverted negation, fabricated quotation, or needless abstention? That matrix determines whether average accuracy, coverage, calibration, review time, or critical-failure rate matters. A benchmark is useful only when it represents the distribution and consequences of the decision.

The dataset is part of the result

An evaluation should declare provenance, license, period, language, inclusion rules, deduplication, and labelling process. Datasheets for Datasets proposed documenting motivation, composition, collection, preprocessing, uses, and maintenance precisely so a dataset would not appear to be a neutral object.

The split matters too. Examples by the same author, from the same document, or from the same conversation can fall into both training and test sets and inflate apparent generalization. With temporal data, the test should follow the training cutoff when the question is future adaptation. If a model may have seen a benchmark during pretraining, contamination is possible. The GPT-3 paper already included analysis of overlap with test sets: recognizing the issue does not remove it, but omitting it makes a score difficult to interpret.

Perplexity measures prediction, not usefulness

Perplexity is the exponential of average log loss: it expresses how surprised a model is by the test sequence. Lower perplexity means it concentrates more probability on observed tokens. It is useful for comparing variants under compatible data and tokenization and for tracking training.

It does not directly measure truth, instruction quality, or safety. Nor is it cleanly comparable across different tokenizers: splitting one word into one or four tokens changes the averaging unit. Corpus, tokenizer, end-of-sequence handling, and length must be stated. If a product must answer with sources, perplexity can be an internal diagnostic rather than an acceptance criterion.

Overlap metrics count matches

BLEU was designed for translation and aggregates n-gram precision with a brevity penalty at corpus level. It does not apply a “copy penalty”: it rewards matches with references and can score a valid paraphrase poorly. ROUGE developed families for summarization, including n-gram and subsequence overlap. Both require versions and options to be reported.

METEOR introduced more flexible alignments using stems and synonyms, plus a fragmentation penalty. CIDEr originated in image description and weights matches by consensus and specificity across references. Treating it as a general metric for any text ignores its design.

These metrics do not certify factuality, logical coherence, or coverage of every important claim. Two summaries may share vocabulary but disagree on a number. A faithful output may use different words. Overlap belongs as one reproducible signal in a battery, never as a substitute for inspecting content.

Factuality and citations require claim-level work

For sourced answers, the evaluation unit is each verifiable claim. Check whether it is supported, whether the link reaches the original, whether the passage actually entails the conclusion, and whether attribution is correct. Citation coverage—how many important claims have support—is different from citation correctness—how many cited passages support what is said.

An automated evaluator can help classify large samples, but it needs a human reference set and regular audits. Numerical claims support targeted checks: unit, denominator, period, formula, and rounding. One “factuality score” hides the failure type and makes system repair harder.

Human evaluation is an instrument too

“We asked people” is not a method. Report who evaluated, what training they received, whether model identity was visible, the order of responses, the rubric, and how disagreements were handled. Randomization and blinding reduce brand and position effects; anchor examples help interpreters understand the scale.

Analysis should separate agreement from quality. Two annotators may agree because a task is obvious or because they share a poor rule. Publish score distributions, disagreement, and comments rather than only a mean. Human Evaluation of Generated Text reviewed generation practices and documented design and reporting problems that prevent meaningful comparison.

A model judge needs its own evaluation

LLM judges make open-ended comparisons cheaper. Judging LLM-as-a-Judge examined agreement with human preferences and also exposed position, verbosity, and self-enhancement biases that require controls. Changing the prompt, response order, or judge version may change the verdict.

A defensible protocol randomizes positions, repeats with reversed order, preserves prompt and version, permits ties, and calibrates the judge against humans on the actual task. The same model family should not be the sole arbiter when a technical conflict of interest exists. A judge creates a measurement; confident language does not turn it into truth.

Baseline, configuration, and uncertainty

Every result needs a relevant alternative: the previous system, simple search, a template, a smaller model, or human work. Comparing only against a weak version magnifies the advance. Budgets should match: the same document access, examples, tools, temperature, token limit, and number of attempts.

A number without variation may be luck. Repeated runs and confidence intervals or bootstrap estimates show whether a difference is stable. Rare, severe events require a sufficiently large sample, or the report must admit that it cannot estimate the rate. Statistical significance must also be separated from operational value: a tiny improvement may not pay for its latency.

Evaluate more than one property

HELM formalized multidimensional evaluation through scenarios and metrics covering accuracy, calibration, robustness, fairness, bias, toxicity, and efficiency. The transferable idea is to expose trade-offs. A model can become more accurate but less calibrated, or improve in English while degrading in another language.

Fairness is not solved by one tool. IBM maintains AIF360 as a library of metrics and algorithms, but a team must define groups, desirable outcomes, and legal and social context. A numerical disparity is an observation; interpreting it requires understanding the application and how labels were produced.

Cost and operations belong in the evaluation

Measure end-to-end latency, tokens, memory, energy when available, price, retry rate, and human review minutes. A slightly better answer that takes ten times longer may be unusable. A cheap model that increases corrections may shift costs onto professionals and degrade service.

Inputs, users, and vendors change after deployment. Monitor distribution, critical failures, complaints, abstentions, and cost; retain samples and set withdrawal triggers. A pre-deployment evaluation authorizes one version under stated conditions. It does not award a permanent certificate.

The minimum record for believing a table

Demand ten fields: task and user; harm by error type; dataset and provenance; split and contamination; baseline; configuration; metrics and why they fit; uncertainty; cost; and decision threshold. Add who reviewed failures and what changed afterward.

With that record, BLEU, ROUGE, or an automated judge returns to its proper role: a partial instrument inside a decision-oriented test. The question is no longer “which model won?” but “what evidence shows that this version improves this task, for these people, within this budget, with these known failures?”