LLM as a judge

LLM as a judge is the practice of using a language model to evaluate the outputs of another AI system — grading responses, comparing pairs, scoring quality against a rubric, or classifying whether an output meets criteria. It has become one of the most widely-used evaluation techniques in production AI because it scales cheaply to large datasets while producing scores that correlate well with human judgment on many tasks.

LLM-as-a-judge sits inside the broader discipline of AI evals. Where programmatic scoring works only for outputs with unambiguous correct answers, and human evaluation is expensive and slow, LLM judges fill the gap: they can score subjective qualities like helpfulness, tone, and factual accuracy across thousands of examples in minutes.

How LLM-as-a-judge works

The basic pattern is straightforward. A judge prompt is written that specifies the evaluation criteria, the scoring scale, and the format the judge should output. For each example being evaluated, the judge model is called with the input, the model's output, and — for reference-based evaluation — a reference answer. The judge returns a score, a classification, or a natural-language explanation.

Common judge patterns include pointwise scoring (rate this output from 1 to 5 on helpfulness), pairwise comparison (which of these two outputs is better, A or B?), classification (does this output violate any policies from the following list?), and rubric-based scoring (evaluate this output against these five criteria, giving each a score and a justification).

Pairwise comparison tends to be the most reliable pattern because it turns a subjective absolute judgment ("is this a 4 or a 5?") into a comparative one ("is A better than B?"), which is easier for both humans and LLMs to do consistently.

Why LLM-as-a-judge works

Judge models often score more consistently than the average human annotator on rubric-following tasks. They apply the same criteria to every example without fatigue, don't get distracted, and generate scores at hundreds of examples per minute for pennies each.

For many evaluation tasks — especially assessments of tone, format compliance, and instruction adherence — modern LLMs correlate 0.7 to 0.9 with human raters. That's not perfect but it's comparable to inter-annotator agreement between humans, and it comes at a small fraction of the cost.

Where LLM judges fail

Several well-documented biases undermine LLM judges when applied naively.

Position bias. In pairwise comparisons, judges often prefer whichever output appears first (or, in some models, whichever appears second). This is easy to counter by evaluating each pair twice with positions swapped and taking a majority vote.

Verbosity bias. Judges often prefer longer responses even when the shorter response is objectively better. Rubrics that call out conciseness explicitly help but don't fully eliminate the bias.

Self-preference. A judge model tends to prefer outputs from itself or from the same model family over outputs from other model families. This matters especially when using an LLM judge to compare models from different providers.

Rubric drift. A judge that is not carefully anchored to specific criteria will slowly drift toward evaluating on the "vibes" of the output — style, confidence, fluency — rather than the intended dimensions.

Sensitivity to prompt wording. Small changes to the judge prompt can shift scores meaningfully. This makes prompt engineering the judge as important as prompt engineering the system under test.

Best practices for LLM-as-a-judge

Five practices reliably improve judge quality.

First, calibrate against human judgment. Before trusting a judge in production, score a couple hundred examples with both the judge and with humans, and confirm the correlation is high enough for your use case. If it isn't, iterate on the judge prompt or use a stronger judge model.

Second, use a stronger model as judge than the system being evaluated. A GPT-4 or Claude 3.5 Sonnet judge can reliably evaluate a smaller or older model's output; using the same model to judge itself introduces circularity and reduces reliability.

Third, ask for reasoning before the score. Prompting the judge to explain its reasoning before producing the numeric score often produces more consistent scores — the reasoning acts as a scaffolding step. This is a specific case of chain-of-thought prompting.

Fourth, use structured output. Have the judge produce a JSON object with named fields for each scoring dimension rather than a free-form response. This eliminates parsing errors and forces the judge to address each dimension explicitly.

Fifth, evaluate the judge itself over time. As you update prompts, models, or the system under test, the judge's calibration may drift. Periodic re-validation against a held-out human-scored set catches this before it corrupts your metrics.

When to use LLM-as-a-judge and when not to

LLM-as-a-judge is the right tool when the output is natural language, the criteria are subjective but describable in a rubric, and you need to score more examples than human evaluation can economically cover. This describes most production AI eval workloads.

It is the wrong tool when the correct output has an unambiguous programmatic check — is the JSON valid, does the tool call use the right arguments, does the numeric answer match the ground truth — because programmatic scoring is faster, cheaper, and less noisy. It is also the wrong tool for high-stakes evaluations (safety, medical, legal) where the cost of a wrong score is much higher than the cost of human review; those cases still warrant human evaluation, potentially with LLM judges as a first-pass filter.

For the vast middle where evaluation is subjective, scoring at scale is necessary, and the cost of an occasional miscalibrated score is acceptable, LLM-as-a-judge is now the default. See AI agent testing for how it fits into a broader testing discipline for agents.