TL;DR

  • When an AI grades another AI’s answers, it needs instructions on what a good answer looks like and how many points each part earns. LLM-as-a-judge is the name for this setup (one AI doing the grading instead of a person), and it’s the only realistic way to check thousands of answers instead of a few dozen.
  • This only works if three things are true: the grading instructions actually catch the specific mistake they’re meant to catch, the AI grader isn’t quietly favouring one answer over another for reasons that have nothing to do with quality, and someone tested the grader on answers with a known correct score before trusting it on real ones.
  • There are two ways to use an AI grader: score one answer on its own, or show it two answers and ask which is better. These answer different questions, and using the wrong one for the job is a common mistake.

Key Takeaways

  • Scoring one answer and comparing two answers are different jobs. Scoring an answer on its own tells you how good it is; showing an AI two answers and asking which is better only tells you which one wins, not by how much; a “which one wins” verdict can’t turn into an overall score by itself.
  • The instructions you give the AI grader decide what mistakes it can catch. Vague instructions let a confident, wordy answer score well even when it never actually answers the question. The fix is one specific, unmissable requirement that zeroes the whole score if it’s not met, no matter how good the rest of the answer is.
  • AI graders have real, well-documented blind spots. They tend to favour whichever answer they see first, favour answers that read like something they themselves would have written, and favour longer answers regardless of whether they’re actually better.
  • Test the grader before you trust it. Feed it a handful of fake answers whose correct score you already know, and see if it agrees. This catches problems that a perfectly normal-looking response from the AI grader would otherwise hide completely.

Grading a model’s answer used to mean a person reading it. That works for a few dozen answers. It doesn’t work for the thousands a benchmark or an evaluation pipeline produces, and it doesn’t scale at the speed teams now ship model updates. LLM-as-a-judge is the answer most of the field has converged on: have one model score another’s output, at a fraction of the cost and time of a human panel.

What is LLM-as-a-judge?

LLM-as-a-judge is the practice of using a language model to score or compare another model’s output against a rubric or reference answer, standing in for a human reviewer. It trades a slower, more expensive human panel for a faster, cheaper one, at the cost of failure modes a careful human reviewer doesn’t have, from position bias to inventing a score when the rubric doesn’t cleanly apply.

The appeal is straightforward: a benchmark of even a few hundred questions, re-run against every model release, is not something a team can put in front of human graders every time. A judge model can. The rest of this guide is about what has to be true of that judge before its score is worth trusting.

We run one ourselves. Groundtruth, our dynamic benchmark for geological reasoning, grades every answer with openai/gpt-5.5 as judge, and most of what follows is drawn from what broke, and what we built to catch it, while running that judge in production.

LLM-as-a-judge rubric design and calibration

The rubric a judge grades against decides what the judge can find, before the judge ever runs. A rubric that rewards a fluent, comprehensive-sounding answer will pass one, regardless of whether it commits to the actual claim being tested. The fix that does the most work is a gate: one component that tests the single claim or mechanism the question exists to check, worth its own points, that zeroes the entire answer if missed, independent of how good the rest of the answer is. Without a gate, a long answer that covers everything adjacent to the question collects partial credit everywhere and lands at a respectable score while missing the point entirely. The full rubric structure behind that gate design is in Dynamic Benchmarking: How We Did It.

A rubric that looks correct on a read-through can still double-count credit, and that specific defect doesn’t show up by reading it again. It shows up when you run fabricated answers, one per point on the scale with a predicted score attached (a calibration fixture) through the actual judge and see what comes back. Across two 50-question benchmarks we built this way, 14 and 16 fixtures out of 200 scored higher than their author predicted, a full account of which is in How to Benchmark AI Models: A Practical Framework for Reliable Results. The dominant cause was the same both times: a component awarded credit for something the gate already required, so every answer that passed the gate collected that component automatically, whether it demonstrated the thing being scored or not.

Calibration doesn’t run itself, either. In our own harness, fixture checking is a deliberate manual pass, not something the scoring run performs on its own, which means it’s a step that has to be built into the process on purpose, not one you can assume happens by default. AI evaluation rubric design that skips this step is passing a rubric no one has actually tested.

Single vs. pairwise judging

A judge can answer two different questions, and they require different setups: the same split documented in Google’s agent evaluation metrics templates, which we used as a reference when designing our own.

Single (absolute) scoring

Pointwise scoring shows the judge one answer, the rubric, and usually a reference answer, and asks for a score against fixed components, one call per answer graded. This is the mode that produces a number you can track over time, compare across a leaderboard, or set a pass/fail bar against. It’s also the mode a gate structure applies to directly: the judge either finds the core claim in this one answer or it doesn’t.

Pairwise comparison

Pairwise puts two answers in front of the judge and asks which is better, returning a verdict like “A is better” or “A is much better,” rather than a 0 to 10 score. Done properly, it costs two judge calls per question, not one: the same pair graded once in each order, so the answer that happened to be shown first isn’t quietly favoured. That second call exists purely to catch position bias, one of the best-documented failure modes in LLM as a judge evaluation.

Pairwise comparison is the right tool when the question is “which of these two is better,” and the wrong one when the question is “how good is this, on its own.” A pairwise verdict alone can’t become a leaderboard column, because it never produces an absolute score to aggregate. The specific mechanics of that failure mode, and how to correct for it without doubling every grading run, are covered in a companion piece, “pairwise LLM evaluation.”

LLM-as-a-judge bias: position, self-preference, and verbosity

The foundational LLM-as-a-judge paper, Zheng et al.’s “Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena”, found that a strong judge model like GPT-4 can reach over 80% agreement with human preferences, matching the agreement rate between two human graders. The same paper is also where position bias, verbosity bias and self-enhancement bias were named and measured as the recurring failure modes behind the gap that remains.

Position bias is the tendency to favour whichever answer appears first, independent of its content. Judging the same pair twice, once in each order, and treating a flipped verdict as no preference rather than picking one, is the direct defence: the reason pairwise comparison costs two calls, not one.

Self-preference bias shows up when a judge favours output from its own model family. This is a real, not theoretical, conflict of interest whenever a judge and a leaderboard candidate share a lineage (GPT-family judges scoring GPT-family candidates, for instance), and the honest response is disclosing it in the methodology rather than leaving a reader to notice it themselves.

Verbosity bias rewards length and confidence over correctness. A gate structure closes off most of this on its own: components score specific, named things a rubric committee decided on in advance, not an overall impression of thoroughness, so a longer answer that never commits to the tested claim gets nothing extra for its length.

LLM-as-a-judge best practices: validating a judge before deployment

None of the structural fixes above catch every way a judge can go wrong, because some failures aren’t about the judge’s reasoning at all. They’re about what it was actually asked to grade. In one benchmark we ran, the question text sent to the judge was pulled from the answer file rather than from the rubric. When an answer file carried an empty or mismatched question field (the kind of thing an external format conversion can introduce quietly), the judge graded against the wrong question, or an empty one, and the harness’s own logging only printed a warning and kept running. Nothing about that failure was a malformed JSON response; the output looked perfectly valid, because the judge answered the question it was actually given. A contract validator that only checks output shape has no way to catch it.

That’s the practical case for two separate checks, not one. A structured output contract (the judge must return machine-checkable JSON, including a gate decision, each component’s award and reasoning, and a flag for anything it can’t confidently resolve) catches malformed or self-contradictory responses; ours rejects and re-grades up to three times before recording a question as unscored rather than accepting a guess. The full contract, and the eleven rules a response has to pass, is covered in AI Agent Evaluation: Frameworks, Metrics, Benchmarks, and Best Practices. Fixture calibration, run before any real grading, catches a rubric that’s structurally wrong. Neither one catches a judge given the wrong input entirely, which is why spot-checking real transcripts, not just the judge’s output, stays a manual step even after both automated checks pass.

FAQs

What is LLM-as-a-judge?

LLM-as-a-judge is the use of a language model to score or compare AI-generated outputs against a rubric or reference answer, replacing a human reviewer for evaluation at a scale humans can’t sustain: thousands of answers, re-run every time a model changes.

Is LLM-as-a-judge reliable?

It can be, conditionally. The founding research found strong judges reaching over 80% agreement with human graders, matching human-to-human agreement, but that number holds only when position bias, self-preference bias and verbosity are controlled for, and the rubric has been calibrated against known answers first.

What is the difference between single and pairwise judging?

Single (pointwise) scoring grades one answer against a rubric and produces a number you can track or rank. Pairwise comparison grades two answers against each other and only says which is better, not by how much: useful for head-to-head questions, useless as a leaderboard score on its own.

How do you reduce bias in an LLM judge?

Run every pairwise comparison in both answer orders to cancel out position bias. Disclose any shared lineage between judge and candidate models rather than ignoring the conflict, the way we do for our own judge in AI Agent Evaluation: Frameworks, Metrics, Benchmarks, and Best Practices. Use a gate-based rubric so length and confidence can’t substitute for the specific claim being tested.

LLM-as-a-judge vs. human evaluation

On agreement rate alone, a strong LLM judge can match human-to-human agreement on the same task. It doesn’t match a human’s ability to notice that a judge was handed the wrong question entirely: that class of error still needs a human spot-checking real transcripts, not just judge output.

Where to go next

The judge output contract, the eleven checks it has to pass, and the case for disclosing a judge’s own conflicts of interest are covered in full in AI Agent Evaluation: Frameworks, Metrics, Benchmarks, and Best Practices. Rubric calibration and the exact fixture defect numbers cited above are part of the wider construction process in How to Benchmark AI Models: A Practical Framework for Reliable Results, and the full rubric structure behind the gate design is in Dynamic Benchmarking: How We Did It.

Two companion pieces go deeper on specific pieces of this guide and aren’t live yet: “Position Bias in Pairwise LLM Evaluation” on the swapped-order mechanics in full, and “An LLM Judge That Can’t Invent a Score” on the output contract that keeps a judge from guessing. Current Groundtruth results, judged the way this piece describes, are live on the Groundtruth leaderboard.