LLM evaluation tests a defined system, task, population, and operating context against explicit requirements. No single metric proves that a model is safe or useful. Evaluate the complete application: model, prompt, retrieval, tools, permissions, interface, human review, dependencies, and fallback.
Conventional software tests remain essential for schemas, permissions, tool contracts, deterministic components, regression cases, and safety invariants. Generative behavior adds probabilistic and open-ended measurement; it does not replace unit, integration, security, or property-based testing.
Start with contamination controls
Benchmark items or close variants may appear in training, tuning, prompt examples, or development feedback. Record provenance, use time- or source-separated holdouts where feasible, detect near duplicates, and avoid optimizing repeatedly against the final set. Keep a protected holdout and version every operational set.
Perplexity
For an autoregressive language model, token-level perplexity is commonly the exponential of average negative log-likelihood:
PPL = exp(-1/N × Σ log p(x_i | x_<i))
Perplexity is not calibrated answer confidence or evidence of understanding. Compare it only when evaluation text, tokenization, vocabulary, context handling, and likelihood calculation are compatible. Lower can reflect domain fit, memorization, or contamination and can coexist with worse factuality or safety. There is no valid architecture-wide “typical range.” Read about tokenization.
BLEU and ROUGE
BLEU was proposed as a corpus-level machine-translation metric. It uses a brevity-penalized geometric mean of modified n-gram precisions. Scores depend on tokenization, case, references, language pair, domain, corpus size, smoothing, and implementation; no universal score band means “good.”
ROUGE is a family. ROUGE-N compares n-gram overlap and is commonly recall-oriented; ROUGE-L uses longest common subsequences. Implementations may report precision and F-measure. High overlap does not establish factuality, completeness, concision, or usefulness.
Learned similarity metrics
Embedding and contextual-token metrics can recognize paraphrases missed by exact overlap, but they do not prove semantic equivalence. They can reward fluent contradictions, miss changed numbers or negation, inherit bias, and vary by language and domain. BERTScore aligns contextual token representations; report its model, layer, baseline rescaling, tokenizer, version, and references, then validate it against task-specific judgments.
Human evaluation is measurement
Human judgments vary with rubric, expertise, language, culture, presentation order, incentives, and ambiguity. Define observable criteria and severity levels; train and calibrate raters; use blinded duplicates or anchors; measure agreement where meaningful; adjudicate critical disagreements; and report sampling and uncertainty.
A 1–5 score is ordinal unless stronger assumptions are justified. A mean can hide severe failures and subgroup differences. Protect raters from harmful content and sensitive data.
LLM judges require validation
An LLM judge can apply a rubric at scale, but its explanation is generated text—not proof of correct reasoning. Judges can show position, verbosity, style, self-preference, prompt, language, and reference biases and may follow instructions embedded in candidate output.
Validate each judge configuration against blinded qualified humans and adversarial cases. Randomize order, isolate candidate content from instructions, version prompts and models, measure subgroup errors, and audit disagreements. Never treat the same model family as an unquestioned authority.
Match measures to the task
- Support: task completion, source support, escalation, policy compliance, user effort, latency, cost, safety, and security.
- Summarization: coverage, faithfulness, quantities, negation, entities, attribution, concision, and decision impact.
- RAG and QA: retrieval recall at a stated cutoff, source authority and freshness, answer correctness, claim-level citation support, abstention, permissions, and injection resistance.
- Code: compilation, types, tests, task completion, security, dependency and license risk, maintainability, and review burden.
- Creative assistance: brief adherence, revision burden, diversity, rights risk, harmful content, and qualified preference under a defined rubric.
See NLP applications, NLP and LLM relationships, and explainability limits.
Versioned sets and release gates
Specify users, unsupported cases, risks, baselines, and release criteria. Build representative and challenge sets with provenance, rights, privacy controls, expected behavior, and severity labels. Synthetic prompts can supplement coverage but may reproduce generator bias or miss real behavior; label, review, and deduplicate them.
Predefine blocking thresholds and severity rules. Record model, prompts, tools, retrieval index, evaluator versions, dataset hashes, sampling parameters, environment, and date. After controlled release, monitor errors, complaints, overrides, incidents, drift, latency, cost, and delayed outcomes. Re-evaluate after changes to any system component.
Reviewed and substantially updated September 4, 2026. Original publication date preserved.

Historical comments from Datanizant
No public comments on this article
No approved public comments were included in the WordPress export for this article.