AI / ML · Guide

Evaluating Generative Systems

Judging output that has no single right answer, without shipping on vibes.

— min read AI / ML

No Answer Key

Classification has a label to compare against. A summary, an answer or a piece of code has many acceptable forms and many subtly wrong ones, so accuracy is not available and something has to replace it.

What replaces it is a layered approach: a fixed evaluation set you can rerun, automated judgement for scale, human review for the questions that matter, and online metrics for what users actually do. Skipping straight to "it looks good in the playground" is how teams ship a regression they cannot see.

Generative systems are non-deterministic and version-sensitive. The same prompt gives different output run to run, and a provider model update changes behaviour with no change on your side — which is precisely why a rerunnable evaluation set is not optional.

Offline Evaluation Sets

Build a fixed set of inputs with expectations attached, and run it on every prompt change, model change and retrieval change. It is the regression suite for a system that has no unit tests.

IncludeBecause
Typical requestsThe common path must not regress
Known failuresEvery bug found becomes a permanent case
Adversarial promptsInjection attempts and jailbreaks
Out-of-scope questionsRefusing correctly is a requirement too
Edge casesEmpty input, enormous input, another language
Check typeExample
Deterministic assertionValid JSON, required fields, no PII, under a length
Reference comparisonContains the expected figure or citation
Graded judgementFaithful to the source, helpful, appropriate tone

Get as much as possible into the first category. A deterministic check — schema valid, forbidden phrase absent, citation present — is fast, free and never disagrees with itself.

LLM-as-Judge

Using a strong model to grade output scales far past human review, and it works — with known biases you have to control for.

BiasMitigation
Position bias — prefers the first optionRandomise order, run both ways
Verbosity bias — prefers longer answersScore criteria separately from length
Self-preference — favours its own familyJudge with a different model than you generate with
Vague criteria produce vague scoresAsk for specific yes/no judgements, not "rate 1–10"

Pairwise comparison — "which of these two is better, and why" — is markedly more reliable than absolute scoring. And the judge itself needs validating: grade a sample by hand, measure agreement, and treat a judge that disagrees with humans as a broken instrument.

A judge is a model with the same failure modes as the one under test. It is a fast approximation of human preference, not a source of truth — calibrate it before trusting it.

Human Review & Online Metrics

Offline sets catch regressions on cases you thought of. Production tells you about the ones you did not.

SignalReveals
Thumbs up/downCheap, sparse, biased toward the annoyed
Edit distance on accepted outputHow much users had to fix — a strong quality proxy
Task completionWhether the feature actually helped
Retry and rephrase rateThe answer failed without anyone reporting it
Escalation to a humanThe clearest failure signal in support contexts
Cost and latency per requestQuality is not free; both belong on the dashboard
Sample and read real outputs every week. Every team that skips this discovers a failure mode months later that a half-hour of reading would have caught immediately.

Treat prompts, models and retrieval settings as versioned artefacts: pin the model version, keep prompts in git, log which combination produced each response, and run the evaluation set before shipping a change to any of them.

Interview Questions

Why is evaluating generative output hard?

There is no single correct answer to compare against, output is non-deterministic, and provider model updates change behaviour without any change on your side.

What goes into an offline evaluation set?

Typical requests, every known failure, adversarial prompts, out-of-scope questions and edge cases — rerun on every prompt, model or retrieval change.

What are the biases of LLM-as-judge?

Position bias toward the first option, verbosity bias toward longer answers, and self-preference for its own model family. Randomise order, score criteria separately, and judge with a different model.

Why prefer pairwise comparison to absolute scoring?

Models are much more consistent at saying which of two outputs is better than at assigning a stable number, where scores drift between runs.

Which online signal is most useful?

Edit distance on accepted output — how much the user had to change it — plus retry and escalation rates, which capture failures nobody bothers to report.

Why version prompts and pin model versions?

Both change behaviour. Without pinning and logging which combination produced a response, a quality change cannot be attributed to anything.

Quick Quiz

1. The best evaluation checks are…
2. LLM judges tend to prefer…
3. Pairwise comparison is preferred because it is…
4. A strong online quality proxy is…
5. A provider model update can…