LLM-as-Judge: When One Model Evaluates Another, and When Not to Trust the Verdict
The cheapest evaluator you will ever deploy is another language model, and the cheap thing is also the one that lies to you in the most flattering way. I have watched teams spin up an LLM-as-judge pipeline in an afternoon, point it at a thousand outputs by Monday, and by Friday be making roadmap decisions on a number that looked rigorous and was structurally biased. The scaffolding produces a verdict; the verdict feels precise; precision is not accuracy. That gap is where this pattern earns its reputation as both the most useful evaluation lever of the last two years and the most quietly misleading.
I want to walk through where LLM-as-judge actually works, where the wheels come off, and the discipline that separates the two. The pattern is a real one and it belongs in a mature stack. It just has to be used for what it can do, not for what it superficially looks like it can do.
The pattern, named properly
LLM-as-judge means using one language model to score, rank, or gate the output of another. The canonical formulation is Zheng et al.’s 2023 MT-Bench paper, which showed that a strong judge model (GPT-4 at the time) correlated with human pairwise preferences over 80% of the time on open-ended chatbot answers. That number is the reason the pattern took off. Eighty percent agreement with humans, at a fraction of the cost and a hundred times the throughput, sounds like an unambiguous win.
The honest reading of the paper is more careful. The 80% agreement holds in a specific regime: rubric-bounded pairwise comparison of similar-quality outputs, scored by a judge meaningfully stronger than the candidates, on tasks where humans themselves agreed at roughly the same rate. Move outside that regime and the agreement falls quickly. The pattern is not a universal evaluator; it is a tool with a working envelope, and the working envelope is narrower than the press coverage suggested.
Where the pattern earns its keep
Three workloads use LLM-as-judge well.
Rubric-bounded scoring. Give the judge a checklist (“does this output cite a source”, “does this output refuse appropriately”, “does this output stay on topic”) and ask for a yes/no per item. This is the closest the pattern comes to symbolic checking. The rubric reduces the judge’s freedom of interpretation, which is exactly the source of variance. Rubric scoring is what production gate-keepers look like in mature stacks: ten yes/no items, a deterministic aggregation rule, a documented threshold for pass/fail.
Large-N comparative judgment. Pairwise comparison (“which of these two answers is better, A or B”) is more reliable than absolute scoring (“score this answer 1-10”) because humans and LLMs both struggle with absolute scales but handle relative ones well. Run a tournament over hundreds of candidate outputs, the noise averages out, and the resulting ranking is usable for model selection or for A/B-style regression testing across releases. This is the workload Zheng et al. measured. The ranking is the deliverable, not any single verdict.
Cheap pre-screening. A judge model that filters a 10,000-output dataset down to the 500 most likely to need human review is doing a real job even if its precision per item is mediocre. The cost of a false positive is one wasted human minute; the cost of a false negative is captured by the human pass on the surviving 9,500 (if you can afford that pass). Pre-screening trades judge precision for human throughput, which is a trade worth making when human time is the binding constraint.
For the symbolic complement to this semantic pattern, the deep dive on Wikidata and external knowledge graphs as ground truth covers the cases where a deterministic lookup makes the judge unnecessary.
Where the verdict lies to you
The pattern fails in four families. Naming them is the first step to designing around them.
Four ways an LLM judge is biased (and the fix)
Length bias. Judges systematically prefer longer answers, even when the longer answer is verbose, repetitive, or wrong. The bias is large enough that Wang et al. (2023) documented swings of more than 20 points purely from padding. A team optimising for a judge score will, given a few iterations of prompt-tuning, ship a model that writes more words and earns more praise. That is selection pressure for verbosity, applied silently, in the name of quality. The fix is a length-normalised rubric (explicitly score conciseness as its own item) or a hard word cap baked into the evaluation prompt.
Position bias. In pairwise comparisons, the answer shown first wins more often than 50% on ties. Wang et al. measured the effect at 5 to 15 points depending on judge and task. The fix is mechanical: run every pair both ways (A vs B, then B vs A), average the two scores, throw out pairs where the verdicts disagree. The cost is double the judge calls; the benefit is a verdict that does not depend on the order your batch loader happened to emit.
Family bias. A judge model prefers outputs that come from the same model family as itself. Panickssery et al. (2024) showed GPT-4 favouring GPT-4 generations, Claude favouring Claude generations, and similar within open-weights families. The likely cause is shared RLHF lineage and overlapping training data, which produce shared stylistic preferences the judge mistakes for quality. The fix is a multi-judge ensemble drawn from different families (one GPT, one Claude, one open-weights, take the majority or the average). Family bias is the hardest of the four to spot because it does not break agreement with humans on most tasks; it just tilts the ranking on the margin, which is exactly where model-selection decisions get made.
Capability cap. A judge cannot validate what it does not know. Ask GPT-4 to grade a clinical-trial summary against the actual trial and it will produce a verdict, but the verdict caps at GPT-4’s clinical knowledge. If the candidate model is a domain-specialist trained on the trial corpus and the judge is a generalist, the generalist will mark the specialist wrong on facts the specialist had right. The pattern is the same as a non-musician reviewing a jazz solo: the verdict reflects the reviewer’s ear, not the performance. The fix is to recognise the capability ceiling exists and to route capability-bounded judgments to symbolic ground truth or human experts, not to another generalist LLM.
The mitigation discipline
Three habits separate teams who use this pattern well from teams who do not.
Calibrate against a human-labelled gold set. Before trusting a judge’s verdicts at scale, score 50 to 200 outputs both with the judge and with humans, and measure agreement. If agreement is below the threshold the workload requires, the judge is not ready, no matter how clean its rubric looks. Re-calibrate every model upgrade, because a new judge release can shift the bias profile without warning. This is the audit trail a regulator will ask for.
Frame the output as a score, not as ground truth. A judge produces a probabilistic signal, never a verdict in the legal sense. Reports, dashboards, and downstream automation should reflect this in their language (“89% rubric pass rate per judge model X, calibrated against a 100-item human gold set with 0.84 agreement”), not collapse it to a single confident number. The framing constrains how the score gets used, which is the only way to prevent the verdict-creep that turns an evaluator into an oracle.
Combine with symbolic checks wherever ground truth exists. Use the judge for what only a judge can do (tone, helpfulness, refusal correctness, comparative ranking) and use symbolic mitigation for everything else. Entity claims go to a knowledge-graph lookup. Numeric claims go to a deterministic checker. Citation existence goes to a URL resolver. Reserve the judge for the genuinely interpretive surface, which is smaller than most teams assume. The deep dive on Wikidata-grounded output checks is the symbolic complement; the discipline is knowing which half of the work each pattern owns.
A short note on what this article does not cover
The judge-versus-symbolic distinction is one axis of the mitigation stack. The other axis (prevent before the output leaves the model, versus catch after it leaves) is covered in the parent on hallucination taxonomies and mitigations. The broader question of evaluation as a discipline (benchmarks, gold sets, regression-testing pipelines, the difference between offline and online evaluation) is covered in evaluation and benchmarking. Judge models are one component of that larger evaluation surface; they are not the surface.
Resources
- Hallucination taxonomies and mitigations (parent)
- Wikidata-grounded output checks (symbolic complement)
- Evaluation and benchmarking (broader frame)
- Hallucinations, Guardrails, and the LLM Harness (pillar)
- Primary source: Zheng et al., “Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena” (2023)
- Critique: Wang et al., “Large Language Models are not Fair Evaluators” (2023) (position and length bias)
- Critique: Panickssery et al., “LLM Evaluators Recognize and Favor Their Own Generations” (2024) (family bias / self-preference)


