LLM Evaluation roadmap
How to know whether your system is any good, and whether last week's change helped. The discipline every AI role roadmap points at and almost no team invests in properly.
Deep dive14 stages260 topics
A subsystem deep dive, not a job title - though "evaluation engineer" is starting to appear as one. Section 2 is statistics, and it's the part practitioners most often skip; without it you will confidently ship regressions and celebrate noise. Sections 6, 9 and 10 are where the field is least mature and where careful work stands out fastest.
Foundations
The reframe that makes everything else possible. Evaluation is not testing with extra steps; the assertion is statistical and nobody hands you ground truth.
Statistical Foundations
The most skipped section and the most load-bearing. Without this you will ship regressions confidently and celebrate noise.
Building Eval Datasets
The highest-leverage work in the whole discipline. Everything downstream is limited by the quality of this set.
Criteria and Metrics
Choosing what to measure. Most bad evaluation is a metric problem before it is a method problem.
Deterministic Checks
Always exhaust these before reaching for a model. They are free, instant, and never disagree with themselves.
LLM-as-Judge
Powerful, cheap, and quietly unreliable. Use it for what deterministic checks cannot cover, and never trust an uncalibrated judge.
Human Evaluation
The ground truth everything else is calibrated against. Expensive, slow, and irreplaceable.
Task-Specific Evaluation
RAG Evaluation
Two systems, evaluated separately. Conflating retrieval and generation quality is the most common evaluation mistake in AI applications.
Agent Evaluation
The least mature area in the field. Final-answer accuracy tells you almost nothing about an agent.
Safety and Adversarial Evaluation
Regression Testing
Where evaluation stops being a research activity and becomes engineering.
Online Evaluation
Offline evals tell you what changed. Production tells you whether it mattered.
Tooling and Practice
Standing up evaluation from nothing
The order matters. Teams that start at step five build elaborate harnesses that measure the wrong thing.
- Look at a hundred outputs by hand. Before any tooling. You cannot define quality for a system you haven't watched fail.
- Write down the failure modes you saw. Categorised, with rough frequencies. This becomes your criteria, and it is worth more than any published metric list.
- Build the smallest golden set. Thirty to fifty real cases covering those failure modes. Real beats synthetic. Version it like code.
- Write deterministic checks first. Format, schema, required fields, forbidden content. These are free, fast and never disagree with themselves.
- Add a judge only for what's left. Calibrate it against your own labels before trusting a single number from it.
- Put it in CI with a gate. An eval nobody runs automatically is documentation.
- Wire production failures back in. Every real failure becomes a case. This is the loop that compounds.
A team with fifty real cases and honest statistics beats a team with a thousand synthetic ones and a dashboard.
Two numbers with overlapping confidence intervals are the same number. Most reported LLM improvements are within noise, and the discipline of admitting that - rather than shipping the version that scored higher on forty examples - is most of what this skill is.