LLM Evals

LLM evals (evaluations) are systematic, repeatable tests of an AI system's output quality: a dataset of representative inputs, defined criteria for what "good" means, and a scoring method — so you measure whether the system works instead of eyeballing a few responses.

Traditional software has unit tests because code either passes or fails. LLM outputs are probabilistic and open-ended — the same prompt can yield different phrasings, and "correct" often has degrees. Evals are the testing discipline rebuilt for that reality, and they are the single clearest divider between teams that demo AI and teams that ship it.

How it works

An eval has three parts.

A dataset: dozens to thousands of real or realistic inputs, ideally harvested from production traffic and failure reports, often with reference answers or labels.

Criteria: what good means for this task — factual accuracy, groundedness in retrieved sources, format compliance, refusal of unsafe requests, tone.

A scorer, chosen by trade-off:

• Code-based checks — exact match, regex, JSON schema validation, does-the-code-run. Cheap, deterministic, but only for verifiable properties.
• Human review — the gold standard for nuance; slow and expensive, so used to calibrate the others.
• LLM-as-judge — a model grades outputs against a rubric. Scales like code, judges like a human, but the judge itself must be validated against human labels and has known biases (position, verbosity, self-preference).

Wire the suite into CI and every prompt edit, model upgrade, or retrieval tweak gets a before/after score instead of a hunch. Mature teams track evals the way they track test coverage.

Why it matters

Without evals, every change is a gamble: a prompt tweak that fixes the example in front of you silently breaks ten cases you did not retest. Model providers deprecate old versions, forcing migrations — evals turn those from cliff-edges into measured swaps. And for hallucination specifically, an eval that checks answers against source documents is the difference between claiming your RAG system is grounded and knowing its groundedness rate.

A worked example

A team ships a RAG support bot and builds a 200-question eval from real tickets, each with a reference answer and source document. Scoring: an LLM judge rates groundedness 1-5 against the retrieved sources; a code check verifies a citation is present; humans audit 20 random judgments monthly to keep the judge honest.

Baseline: groundedness 4.1, citations 86 percent. An engineer switches chunk size from 800 to 300 tokens; the eval reruns in CI: groundedness 4.4, citations 91 percent. Ship it. A later prompt "improvement" drops citations to 71 percent — caught before deploy, reverted in minutes. That is the whole point.

How miatz teaches it

Evals run through the miatz curriculum as the testing effect applied to machines: retrieval practice for humans, eval suites for models — you find out what is actually known by testing, not by reviewing. Learners never tune a prompt without a scored dataset in front of them, and capstone projects are graded partly on the quality of their eval suites, because at miatz "it seems to work" is not an engineering claim.