LLM as a Judge
Suppose you change a prompt, swap a model, or tweak a RAG pipeline. Did the outputs get better? Human review is the gold standard, but it is slow, expensive, and impossible to run on every commit. The pragmatic alternative is to have another language model do the grading. This is "LLM as a judge," and it has quietly become the default way teams evaluate generative systems.
The three common setups
Almost every judge pipeline is one of three shapes:
- Pairwise comparison. Show the judge two candidate answers to the same input and ask which is better. This is the most reliable setup because relative judgments are easier than absolute ones — for models and for people.
- Rubric scoring. Ask the judge to score a single answer against explicit criteria: faithfulness, completeness, tone, formatting. Scores let you track a metric over time, but they are noisier than pairwise picks.
- Reference-guided grading. Give the judge a known-good answer and ask whether the candidate matches it. This works well for tasks with verifiable answers — extraction, math, closed-book QA — and poorly for open-ended writing.
Where judges fail
Judges inherit the biases of the models they run on, and the failure modes are consistent enough to have names:
- Position bias. In pairwise setups, judges favor whichever answer appears first. Always evaluate both orderings and count only consistent verdicts.
- Verbosity bias. Longer, more confident-sounding answers score higher even when they say less. Rubrics that explicitly reward concision help, but only somewhat.
- Self-preference. Models rate outputs from their own family higher. Use a judge from a different provider than the system under test when you can.
- Rubric drift. Vague criteria like "is this answer good?" get interpreted differently across runs. The judge is a program; underspecified programs are bugs.
Keeping the judge honest
The fix for all of these is the same discipline you would apply to any measurement instrument: calibrate it. Hand-label a small set of examples — fifty is enough to start — and measure how often the judge agrees with you. If agreement is below roughly 80%, tighten the rubric or switch judges before trusting any downstream number. Re-check the calibration set whenever you change the judge's prompt or model, because judge upgrades silently move your baseline.
A few practical rules that pay for themselves quickly: force the judge to explain its reasoning before emitting a verdict, since verdict-first outputs are measurably less accurate; constrain the output to a schema you can parse; pin the judge model version; and log every judgment so you can audit disagreements later.
The bottom line
An LLM judge is not a replacement for human evaluation — it is a cheap, fast proxy that you periodically anchor to human judgment. Treat its scores as relative signals rather than absolute truth: good for catching regressions and comparing variants, unreliable for claims like "our system is 94% accurate." Used with calibration and a healthy distrust of its biases, it turns evaluation from a quarterly event into something you run on every change.