Read this post on Infere
LLM-as-a-judge is an evaluation method where one large language model scores or compares the text that another LLM produces. You give the judge model a short prompt that states the criteria you care about, the question, and the answer to grade, and the judge returns a number, a label, or a preference between two answers, usually with a written reason for its verdict. It exists because human review does not scale and because classic text metrics miss meaning, and it has become the default way teams evaluate open-ended model output, chatbot conversations, and agent behavior at production volume.
The honest part comes next. An LLM judge is not a metric you switch on and trust. It is an automated stand-in for a human annotator, and it carries real, measurable biases. In the right setup, a strong judge agrees with human reviewers about as often as two humans agree with each other, then quickly grades thousands of responses. Set up carelessly, it rewards length over accuracy, favors whichever answer appears first, and prefers text that looks like its own training data. The difference between those two outcomes is not luck. It is a well-built evaluation prompt, a measured baseline, and a calibration step.
This guide explains what an LLM judge does, how judges are prompted and scored, the single-output and pairwise modes you can use, the four documented bias types, how to calibrate a judge against human labels, and the cases where an LLM judge either beats or loses to a heuristic and to a human evaluator. For the full picture of how judging fits into a quality workflow, start with the LLM evaluation guide, then read our practical walkthrough on how to implement an LLM-as-a-judge.
What LLM-as-a-judge actually is
The core idea is that the model acts as an evaluator instead of a generator. It receives an evaluation prompt that specifies the target text, the criteria, and the required output format, and it returns a judgment such as a numeric score, a categorical label, or a preference between two candidates. Because the criteria are written in natural language, you reuse the same judge for a new task by editing the prompt, with no retraining.
Teams use judges in three places. During development they compare models or prompt versions to confirm an improvement. Once an app is live they monitor user interactions for quality and safety. On every change they run regression checks to make sure nothing broke. LLM-as-a-judge supports all three workflows, which is why it spread so fast.
To apply the method you take the text an LLM application produced and feed it back into a different prompt. That prompt, not the model's default behavior, defines "good." A helpfulness judge might state that helpful responses are clear, relevant, and actionable, while unhelpful ones are vague or off-topic. A faithfulness judge might state that a response must only include information present in the provided context. The judge reads the output against that definition and returns a verdict you can aggregate across a whole dataset to get a distribution: the share of responses labeled helpful, the share flagged as hallucinated, the trend over time.
It helps to be precise about what this is not. LLM-as-a-judge is not a fixed metric like accuracy, precision, or NDCG, which quantify how well a prediction matches ground truth. It is a general technique that approximates human labeling for your specific application. When you ask a judge to assess faithfulness, correctness, or helpfulness, you define those terms in the prompt and rely on the semantic relationships the model learned in training. The result is a use-case-specific proxy, not a deterministic measure. Its success depends on the prompt, the model, and the complexity of the task, all of which you control.
Why an LLM can judge LLM output
The obvious objection is that asking an LLM to grade another LLM looks like allowing the fox to run the henhouse. The reason it works is that evaluating is a more focused job than generating. Critiquing takes less effort than creating. Classifying content is a narrower task than producing it, and detecting a mistake usually takes less work than avoiding the mistake in the first place.
When a model generates a response it juggles many variables at once. It integrates context, follows product prompts that can bundle several instructions, and manages its own style and constraints, so errors are common. When it evaluates, it is not asked to fix or correct anything. A relevance judge only checks whether the response is semantically related to the question. That is a focused classification task, often a single instruction, and a model is well suited to it.
There is also a separation-of-tasks benefit. You use a different prompt, and often a different model, dedicated to evaluation. This activates distinct capabilities and reduces the job to something like a text classifier. Because LLMs are trained on vast amounts of text, they are good at detecting patterns such as bias, tone, and whether an answer stays grounded in context. None of this makes the judge "better" than the original model. It is simply doing a different and more limited job.
A useful way to think about the trade-off is this. If you asked the judge to redo the task, you would inherit all the same failure modes. You are not asking that. You are asking a separate pass over already-produced text, which is why a dedicated judge can catch problems the generator missed.
How judges are prompted and scored
A typical judge prompt contains four moving parts. The first is the criteria, a rubric that defines what good looks like, for example "score 1 if the answer is factually incorrect, 5 if it is fully accurate and well-sourced." The second is the input context, the original user query or prompt. The third is the output to evaluate, the application's response. The fourth is the optional reference, a ground-truth or expected output to compare against.
The verdict comes back in one of three shapes. Numeric scores are the common default: a continuous value from 0 to 1 for something like helpfulness, or a 1 to 5 scale. Categorical labels give you explicit buckets such as correct, partially correct, or incorrect. Boolean verdicts return yes or no for binary decisions, for example whether an answer violates policy or whether it stays within scope. Which shape you pick depends on the granularity you need, and it matters more than most teams realize. Binary labels tend to be more consistent for both LLMs and human reviewers. Deciding whether a response is polite or impolite is reliable; deciding whether politeness is a 73 or an 82 out of 100 is not.
Prompt quality produces most of the difference between a good judge and a noisy one. Research-backed techniques that work here are the same ones that work in generation. Chain-of-thought prompting asks the judge to step through its reasoning before giving a score, which improves agreement with human expectations and leaves a reason trail you can audit. Few-shot examples anchor the rubric, and one frequently cited result shows few-shot prompting lifting a model's consistency from 65.0 percent to 77.5 percent. Reference-based scoring supplies an expected answer so the judge can compare. And managers often treat the evaluation as a binary classification problem even when the underlying quality is graded, because binary labels hold up better.
Other reliable moves matter at the margins but add up. Define the meaning of every score in the prompt rather than labeling without explanation. Split a complex criterion into separate evaluators so the judge handles one quality at a time. Set a low temperature so the same input returns the same verdict. Request structured output such as JSON for parsing. Start with a more capable model as the judge, then test whether a smaller one meets your baseline.
A framework worth knowing about is G-Eval. It first asks the model to generate a series of evaluation steps from the criteria, then uses those steps to fill in a scoring form and produce a score from 1 to 5. The chain-of-thought structure is what stabilizes the judge. Some later work found that simply asking the model to explain or analyze can outperform an auto-generated chain-of-thought, so treat G-Eval as one good option, not a rule.
Single-output versus pairwise judging
There are two main judging modes, and each answers a different question.
Single-output scoring evaluates one response at a time and returns an absolute score. It comes in a reference-free and a reference-based form. Reference-free judging scores an output only against the rubric, with no ideal answer shown. This suits open-ended and creative work where no single correct answer exists, such as the helpfulness of a support reply or the fluency of generated copy. Reference-based judging adds an expected output, which anchors the evaluation and produces more consistent scores on tasks with a verifiable answer such as mathematical correctness, code correctness, and Q&A responses matched to a golden answer. Because it returns an absolute number, single-output scoring is the mode you use for monitoring and regression testing, where you need a quality signal on a stream of live traffic.
Pairwise comparison shows the judge two outputs for the same input and asks which one better meets the criteria, with ties allowed. This mirrors the format of Chatbot Arena, an automated version of that human-voted leaderboard. It relies on relative judgment rather than absolute scoring, which is easier for the model to produce and works well even when a scoring rubric is subjective. Pairwise judging is the right tool for A/B tests, for choosing between two prompt versions, two models, or two fine-tunes on the same task, and for deciding whether a new configuration beats the current one on real examples. Its weakness is position bias: the judge may prefer whichever answer happens to appear first, so the safest practice shows every pair in both orders and counts a win only when the same answer wins both times.
The evident point to retain is that the two modes answer different questions. Use single-output scoring when you need an absolute quality number for monitoring or gating. Use pairwise when you are comparing candidates and only relative order matters.
The documented bias types
Judges are not neutral. The literature reports a repeatable set of systematic biases that distort verdicts, and knowing them by name is the first step to controlling them. Four keep coming up.
Position bias. The judge favors a response based on where it sits in the prompt, most often the first answer. In the widely cited 2023 MT-Bench study, even the strongest model tested reached the same verdict both ways in only about two-thirds of cases, and swapping the order of the two answers often reversed the outcome. Later large-scale work found the effect is systematic rather than chance. The counter is to present candidates in both orders and count a verdict only when the response is preferred twice.
Verbosity bias. The judge prefers longer answers even when the extra length adds no information or quality. In the same 2023 study, when answers were rephrased to be longer without new content, judges such as Claude and GPT-3.5 still preferred the longer version more than 90 percent of the time. This creates a real incentive for a model team to game the evaluation by padding output rather than improving it. Benchmarks such as AlpacaEval 2.0 respond with a length-controlled win rate, and you can add an instruction that disfavors padding, though the effect does not fully disappear from prompt guidance alone.
Self-preference bias, sometimes called model narcissism. The judge rates its own outputs, or output from its own model family, more highly. Early work found GPT-4 favored its own answers with a roughly 10 percent higher win rate and Claude-v1 with about 25 percent, while GPT-3.5 showed no such effect. The proposed mechanism is perplexity: a model assigns higher probability, lower perplexity, to text that resembles its own distribution, so its own output reads as more natural and scores higher. Because this bias is baked into the model's representations, prompt-level instructions alone do not remove it. You can only expose it by comparing several judges from different model families on the same examples.
Sycophancy bias. The judge agrees with a position that appears endorsed in the prompt, rather than weighing the evidence. This shows up in a few ways. Probe a judge with a statement such as "the user found the first response more helpful," and many models shift their verdict toward that answer even when instructed to ignore user-preference signals. An authority-injection variant adds a fake expert endorsement to one response, and a well-calibrated judge should be immune while many models are not. The same tendency appears as a preference for confident, authoritative phrasing over appropriately hedged but more accurate ones.
These biases compound rather than cancel. A judge that gives one answer a positional advantage and a length advantage and a self-preference advantage does not deliver three separate penalties. It may hand a materially better win rate to the weaker answer. Measuring one bias also requires controlling for the others, because a pair where one response is longer and matches the judge's style will produce a confounded estimate.
The mitigations are real but partial. Swapping order handles position. Length-controlled metrics and rubric guidance temper verbosity. Multi-judge panels drawn from different model families, aggregated by majority vote, offset any single model's skew, and pairwise comparison tends to be more reliable than pointwise scoring. Pairing these practices does not make the judge unbiased; it makes the bias visible and bounded.
Calibration against human labels
The headline number for judge accuracy is reassuring and runs the risk of being misused. A strong judge such as GPT-4 aligns with human judgment around 85 percent of the time, which is higher than the roughly 81 percent agreement two human annotators have with each other on the same task. That is the basis of the claim that a judge is a reasonable substitute for human review at scale.
Calibration is the part that tempers the headline. Agreement with humans varies widely across datasets, tasks, and evaluated properties. A large-scale study across 20 NLP tasks found exactly this and recommended that teams validate and calibrate judges against task-specific human judgments before deploying them. On tasks with a verifiable answer the gap can be dramatic: on JudgeBench, where one response in each pair is objectively correct, strong judges including GPT-4o performed only slightly above chance. High apparent agreement at the level of overall rankings can also hide substantial disagreement on individual judgments.
Two more cautions come from the reproducibility side. Judges are poorly calibrated in the confidence sense, expressing more certainty in a verdict than their accuracy justifies. And scoring is not deterministic. Because language-model generation is inherently random, the same judge can return different scores for the same input on repeated runs, and minor changes in prompt wording shift judgments. A judge accessed through a frequently updated API can also change behavior when the underlying model version changes.
The discipline that follows is concrete. Build a small labeled evaluation set where a human marks each example exactly as you want the judge to later. Measure agreement with metrics such as precision and recall, not just a single headline number. Keep a held-out portion to test your final prompt. And re-check periodically, because both the judge and your expectations drift over time. The judge does not need to be perfect. It needs to agree with your labels well enough for your goal, and staying aware of the residual gap is exactly how you keep that true.
When an LLM judge beats heuristic evaluation
Heuristics and rule-based metrics were the standard before judges, and they still win in specific places. But for open-ended text they lose to an LLM judge on almost every axis that matters.
The decisive advantage is that an LLM judge handles semantics. Classic metrics such as BLEU and ROUGE measure token or phrase overlap with a reference text. That captures superficial similarity and misses meaning: a response that answers the question in different words scores poorly, and a response that overuses reference phrasing scores well regardless of whether it makes sense. Judges read for meaning, so they catch the many ways a response can be right without matching an example word for word.
Judges also handle output with no reference at all. Semantic-similarity metrics and n-gram overlap both require a gold text to compare against. A judge scores a brand-new response against a rubric in natural language, which is what makes live production monitoring possible when no ground truth exists. This is the difference between trying to detect quality on a stream of fresh traffic and having nothing to compare against.
Subjective qualities are where heuristics break down entirely. Tone, helpfulness, politeness, coherence, adherence to a brand voice, and whether a conversation resolved the user's issue are properties with many valid expressions. No fixed rule captures them. A judge evaluates them consistently at scale, and it generalizes across languages the way a keyword list does not. It also returns a written reason with each verdict, giving you an audit trail that a score and a regex cannot.
For large volumes the arithmetic turns decisive. Human review of tens of thousands of outputs costs weeks and money. A judge grades the same volume in minutes with a per-evaluation cost in fractions of a cent, and it does so around the clock. That is the entire blunt reason LLM-as-a-judge became the default evaluation method.
When an LLM judge loses to heuristic evaluation
The same properties that make judges powerful also make them the wrong tool for certain checks, and knowing the boundary keeps you from overpaying for a verdict a regex can produce instantly.
Deterministic checks belong to heuristics. If the criterion is a yes or no that depends on structure rather than meaning, such as whether the response contains a required field, follows an output format, matches a policy list, or stays under a length limit, a rule is exact where a judge is approximate. A judge may waffle on a canonical question, while a rule answers it identically every time. Guardrails are the sharpest case. Validating an answer in real time as it is generated demands milliseconds, and a rule completes in that time where a model call adds latency and cost. Judges are also slower and more expensive than rule-based checks for the same reason they are more capable.
Heuristics also win when the signal is unambiguous and inexpensive to find, such as flagging specific product names or competitor mentions with a regular expression, or detecting a formatting violation. Many production setups use a hybrid: a regex catches the terms it can certify, and a judge handles the semantic quality the regex cannot see. This keeps cost down while still catching the hard cases.
The deciding question is whether a wrong answer is tolerable. A heuristic that returns an exact, repeatable answer on a narrow rule is the right call. Where the criterion shades into meaning, the judge earns its cost. Use each for what it is good at rather than forcing one to do both.
When human evaluation still wins
Humans remain the gold standard for a specific set of cases, and no amount of automated convenience replaces them there.
The first is small, high-stakes evaluation. When the dataset is a few hundred examples and the cost of a wrong verdict is high, human review is affordable and more trustworthy than any proxy. The second is novel or highly specialized domains where a judge has no reliable training signal. A subject-matter expert who internalizes the nuances of a niche field still catches things a general-purpose model scores as normal. The third is tasks where there is no objective answer and no stable rubric, the kind of judgment where two expert humans legitimately disagree and consensus must be negotiated rather than voted.
There is also the question of what the judge was calibrated against. Human labels are the source of a judge's agreement in the first place. If no human has ever labeled your type of output, a measured agreement figure does not exist, and deploying a judge there is an unvalidated bet. In those cases you cannot trust a judge score about quality you have never defined.
The practical pattern is not either-or. Run the judge on everything to get scale, then have humans review a sample, especially the disagreements and the borderline tiers. The judge handles the volume; the humans keep the judge honest and generate the labels you verify against. That pairing is how teams get the speed of automation without surrendering the accountability that only people provide.
Bottom line
LLM-as-a-judge is the evaluation technique in which one model grades or compares another model's output against criteria you write, returning a score, a label, or a preference plus a reason. It replaced metrics that missed meaning and human review that could not scale, and it now powers model comparisons, regression checks, and live quality monitoring at production volume.
The technique is not automatic. Its value lives in the details: a precise evaluation prompt, the right judging mode, active control of position, length, self-preference, and sycophancy bias, and measured agreement with human labels. Handle those and an LLM judge comes close to human judgment at a fraction of the cost. Skip them and it quietly grades its own quirks. To place judges in the wider workflow, see the LLM evaluation guide, and for a step-by-step build, follow how to implement LLM-as-a-judge.
Top comments (0)