Evals for LLM apps: a practical guide

The short version

Evals are the tests you write for behavior you can't assert with ===. Every LLM app ships with vibes; evals are how you replace vibes with measurements before your users do it for you. Teams that skip evals don't avoid the work — they just outsource it to production incidents.

The three layers

Unit evals test one component in isolation: does the classifier label these 50 examples correctly? Does the extractor return valid JSON? Fast, deterministic, runnable in CI. Write these first — they're the cheapest and they catch regressions.

End-to-end evals run the whole pipeline on realistic inputs: 30–100 representative user queries, graded on final answer quality. Slower and squishier, but they're the only thing that measures what users actually experience.

Online evals watch production: sample real traffic, grade it (with a model judge or human spot-checks), and alert on drift. This is how you catch the slow rot — data changes, user behavior shifts, the world moves on.

Grading without losing your mind

Deterministic checks first: exact match, regex, JSON validity, schema conformance. Use them everywhere they apply — they're free and unambiguous.

For the squishy middle, LLM-as-judge works if you're disciplined about it: a fixed rubric, a strong judge model, a handful of reference examples, and blind grading (the judge shouldn't know which system produced the answer). Validate the judge against human labels on a sample before trusting it — judges have biases, especially favoring their own model family and longer answers.

Reserve human grading for the cases that decide launches: a few dozen examples, clear rubric, more than one grader. Expensive, slow, and still the gold standard.

Making evals stick

• Version your datasets. An eval you can't re-run is a story, not a test.
• Run unit evals in CI. Every prompt or model change gets graded before merge.
• Track a single top-line metric per surface, plus the breakdown. Dashboards with 40 metrics get ignored.
• Eval the retriever separately in RAG systems. Most "model got dumber" incidents are retrieval regressions.

Rule of thumb: if changing a prompt feels scary, you don't have an eval problem — you have no evals. The fear disappears the week the suite goes green in CI.