LLM-as-a-judge: using one model to score another, and when to trust it.

What is LLM-as-a-judge?

LLM-as-a-judge is a method of evaluation where one language model scores another model's outputs against criteria written in natural language, returning a score, label, or preference. It is used for open-ended tasks that have no single correct answer, where word-overlap metrics fail, and it scales human-style judgment far more cheaply than human raters, at the cost of biases that must be managed.

LLM-as-a-judge is one technique inside the broader discipline of language-model evaluation; for the full picture of metrics, methods, and where judges fit, see our guide to LLM evaluation. This page goes deep on the judge itself: how to build one, the biases that break it, and how to know whether to trust it.

How does an LLM judge actually work?

An LLM judge works by taking an evaluation prompt, the output to score, the criteria to judge it against, and the required output format, and returning a verdict: a numeric score, a pass or fail label, or a preference between two outputs. Because the criteria are natural language, one judge retargets to a new task by rewriting the prompt, not by retraining.

That flexibility is the whole appeal. A word-overlap metric like BLEU cannot tell you whether a support reply is on-brand or a summary is faithful, but a judge with a clear rubric can approximate how a human would rate it, on millions of outputs, for cents each.

What are the types of LLM judge?

There are three main types: pairwise comparison (which of two outputs is better), single-answer or pointwise grading (score one output against a rubric), and reference-guided grading (score against a known-good answer). They differ in whether they need a reference and in what they are best at, from preference data to production scoring.

How do you write a judge prompt and rubric?

You write a good judge prompt by giving an explicit rubric, asking the model to reason before it scores (critique-then-score), requiring structured output, anchoring with a few labeled examples, and using a low temperature for consistency. The most consequential choice is the scale: prefer binary pass/fail or a short ordinal scale over a 1-to-5 Likert, which judges apply inconsistently.

The case for binary is practical. As practitioners like Hamel Husain argue, nobody knows what to do with a 3 versus a 4, so a Likert score is rarely actionable, while a pass/fail with a written reason forces the rubric to be explicit and makes disagreements debuggable. Start binary, add gradations only when you can define what each one means.

What are G-Eval and DAG judges?

G-Eval and DAG are two structured approaches to LLM judging. G-Eval, from Liu et al. (2023), has the model generate chain-of-thought evaluation steps from your criteria and then score in a form-filling pass, which correlates better with humans than earlier metrics. DAG, from DeepEval, runs a deterministic decision tree where each node is an LLM judgment, giving objective tasks reproducible, auditable branching.

The contrast is the useful part: G-Eval suits subjective, natural-language criteria where you want the model's holistic judgment; a decision-graph like DAG suits objective or mixed criteria where you want to check things in a fixed order (format first, then grounding, then tone) and get the same answer every time.

What biases do LLM judges have, and how do you fix them?

LLM judges have well-documented biases: position bias (favoring the answer shown first), verbosity bias (favoring longer answers), and self-preference or self-enhancement bias (favoring their own family's outputs), among others. Each has a standard mitigation, and the biggest one is simply not to trust a single unvalidated judge.

These biases are documented in the foundational work by Zheng et al. (2023), which introduced MT-Bench and Chatbot Arena and documented the position, verbosity, and self-enhancement effects. The self-preference mechanism was later tied to self-recognition: models rate their own generations higher partly because they can recognize them, per Panickssery et al. (2024).

How do you validate an LLM judge against humans?

You validate an LLM judge by building a set of examples labeled by humans, running the judge on the same examples, and measuring agreement, using Cohen's kappa or Krippendorff's alpha rather than raw percent agreement, since those correct for chance. Aim for the human-to-human agreement ceiling, often around 80 percent raw agreement; a chance-corrected kappa runs lower, so treat the two as separate scales. Re-validate whenever a model changes.

Which agreement metric matters. Raw percent agreement is misleading because two raters agree by chance on skewed data; Cohen's kappa corrects for chance for two raters, quadratic-weighted kappa suits ordinal or Likert scores, and Krippendorff's alpha handles any number of raters and missing data. Track precision and recall separately on rare classes, and know that kappa deflates on skewed label distributions. Zheng et al. found a strong judge could reach over 80 percent agreement with humans, about the level humans reach with each other, which is the realistic ceiling to aim for.

When should you not use an LLM judge?

You should not use an LLM judge for verifiable tasks where a code check is cheaper and exact (math, schema validity, exact match), for high-stakes decisions without human oversight, when you cannot validate the judge against human labels, or when you need precise fine-grained numeric scores, which judges are unreliable at. In those cases, deterministic checks or humans are the right tool.

The rule of thumb: if a task has a verifiable answer, check it with code, which is cheaper, faster, and exact. Reserve the judge for the genuinely open-ended cases where no deterministic check exists, and even there, keep a human in the loop on a sample and never let one model both generate an output and be the sole judge of the number that decides money.

What does an LLM judge cost, and how slow is it?

An LLM judge adds a model call for every output you score, so at scale it has real cost and latency. The usual mitigations are to use a smaller, cheaper judge model calibrated against a stronger one, batch requests, cache repeated evaluations, and sample production traffic rather than judging every request. The judge does not have to be the biggest model; it has to be a validated one.

What tools implement LLM-as-a-judge?

Most evaluation frameworks implement LLM-as-a-judge: OpenAI's evals, DeepEval (home of G-Eval and DAG), Arize Phoenix, LangSmith, MLflow, and Promptfoo, among others. They handle the plumbing; the hard parts, the rubric, the bias controls, and the validation, are yours. The question that matters for an enterprise is who runs the judge, on whose data, and whether your vendor can see the criteria. We compare the categories in AI evaluation tools, compared.

How do you run LLM-as-a-judge privately, on your own data?

You run LLM-as-a-judge privately by hosting the judge inside your own perimeter, scoring on your own data against a rubric you keep to yourself, and never routing the criteria or results through the vendor whose model you are evaluating. Your rubric encodes what good means in your business, which makes it intellectual property, and a target your vendor can see is a target your vendor will optimize for.

This is where the judge meets the strategic point of owned evaluation. The rubric is the most concentrated form of your evaluation criteria, so exposing it both corrupts the score and hands over your standard. We make the full argument in what private AI evaluation is, why your eval criteria are IP, and Goodhart's Law for AI. We do not judge your AI for you; we give you the private machinery to judge it yourself.

Common questions about LLM-as-a-judge