LLM Evaluation & Testing — Core

Why

A deterministic function returns one output per input, so an exact-equality assertion is a valid test. A generative model samples tokens from a probability distribution and can produce many different but equally correct phrasings for the same prompt. So an exact-match assertion would reject valid paraphrases and is the wrong tool. The same-string-every-time option is backwards; the whole issue is that outputs vary. The needs-fine-tuning option is wrong; models produce outputs without being trained on your eval set, and you should not train on it anyway. The always-numeric option is false; outputs are typically free text. The consequence is that evaluation must operate at the semantic level, tolerating surface variation while still catching real errors. Even at greedy decoding, outputs can vary slightly across API versions and hardware. This is the foundational reason LLM evaluation needs specialized methods rather than simple equality checks.

Why

Evaluation methods trade cost against flexibility. Exact match and regex are free but brittle, working only for constrained outputs. Token-overlap metrics like BLEU and ROUGE are cheap but correlate weakly with human judgment on open-ended text. Embedding similarity captures meaning at a small per-comparison cost. LLM-as-judge is more expensive but flexible enough to score nuanced criteria. Human review is the most expensive and most flexible, but it does not scale. The first option reverses the cost ordering. The third option wrongly claims cost is unrelated to method, when cost rises steadily along the spectrum. The fourth option orders by name, which is arbitrary and wrong. The engineering skill is picking the cheapest method that correlates well enough with human judgment for your task. A constrained extraction task can use regex, while a creative task may need a judge or humans. Matching method to task is the core decision.

Why

BLEU and ROUGE compare a candidate against reference strings by measuring n-gram or subsequence overlap. For open-ended tasks there is no single correct reference, so a valid answer worded differently from the reference is penalized, while a fluent answer that overlaps the reference words but is factually wrong can still score high. That mismatch is why their correlation with human ratings is weak on open-ended generation. The thousand-runs option is wrong; these metrics are computed once per candidate and are cheap. The only-numeric option is wrong; they are designed for text, not numbers. The measure-latency option is nonsense; they score textual overlap, not speed. These metrics remain useful for narrow tasks with tight references, like machine translation, and for regression testing where you compare against a fixed reference. But for judging faithfulness or open-ended quality, they miss factual errors. Embedding-based or model-based metrics correlate better, though even they can miss hallucinations.

Why

A reference-based metric scores an output by comparing it against a provided gold or reference answer, as BLEU and ROUGE do. A reference-free metric instead judges intrinsic properties of the output, often relative to the input or provided context, without needing a gold answer, as faithfulness and answer-relevance metrics do. The first option swaps the two definitions. The humans-versus-machines option is wrong; both kinds can be computed automatically, and reference-free metrics are often model-based. The always-exact-match option is wrong because reference-free metrics are not exact match, and reference-based ones are not limited to embedding similarity. Reference-free metrics are valuable precisely when open-ended tasks have no single correct answer to compare against. They let you ask whether an answer is grounded in its source or actually addresses the question. Choosing between the two depends on whether you have trustworthy references. Many production evaluations rely heavily on reference-free metrics for exactly this reason.

Why

Faithfulness, also called groundedness, measures whether the claims an answer makes are actually supported by the provided context. It is often computed by decomposing the answer into atomic claims and checking each against the source, so a faithfulness of 0.9 means about a tenth of claims are unsupported. This directly targets hallucination in retrieval-augmented systems. The fluent-prose option describes coherence, a different quality; an answer can be fluent yet ungrounded. The shorter-than-context option is unrelated; length says nothing about factual support. The fetched-quickly option describes latency, not faithfulness. Faithfulness is usually the primary metric for question-answering over documents, because an unsupported answer is dangerous even if it reads well. It pairs naturally with answer relevance, since an answer can be faithful yet off-topic. Tracking faithfulness in production is how teams catch silent grounding regressions. It is central to trustworthy retrieval-augmented generation.