LLM-as-a-Judge

Judging is easier than generating. A judge does not have to compose an answer; it compares one with a rubric and a context. That asymmetry is why a modest model can grade a stronger one on narrow questions, and why a judge is cheaper than a human. It fails in predictable ways:

The first rule follows: where a deterministic check exists, use it. A citation either points at a retrieved chunk or it does not; a JSON answer either parses or it does not; a code answer either compiles or it does not. Spend judge calls on the remainder.

A reliable judge prompt has six parts. The order is not decoration: criteria and scale come before the material to grade, so the model reads the rubric first, and the verdict format comes last.

There are two shapes of judgement, and they answer different questions.

Use pointwise judges for gates on a single candidate (is groundedness above the threshold?) and for monitoring live traffic, where there is no second candidate. Use pairwise judges to choose between two versions on the same inputs, and turn the outcomes into ratings with the methods on Comparative Evaluation and Arenas. A third shape, reference-guided grading, is pointwise with a reference answer in the prompt; it is the most reliable of the three when a trustworthy reference exists, because the judge compares two texts rather than recalling facts.

The MT-Bench paper by Zheng and colleagues names these modes (single-answer grading, pairwise comparison and reference-guided grading) and quantifies how strongly a strong judge model agrees with human preferences on its benchmark; read it for the numbers instead of trusting a rule of thumb copied from a blog.

The same paper catalogues the systematic errors of LLM judges, and later work confirms and extends them. Treat each as a hypothesis to test on your own judge, not a constant of nature.

The position-swap protocol is easy to implement and worth making a default. For a pair and a judge that returns the preferred answer, the swapped verdict is . The pair has a consistent winner only when both orders pick the same underlying answer, and the flip rate over pairs is

where the superscript means the verdict is mapped back to the original labels before comparing. A flip rate near zero means the judge’s preference is driven by content; a high one means the judge cannot discriminate between the candidates, or has a strong position bias, and its verdicts on those pairs are noise.

openevals is the LangChain team’s package of prebuilt evaluators. Its create_llm_as_judge function builds a judge from a prompt, a model, and a feedback key, and returns a callable that takes inputs, outputs, reference_outputs and any further variables your prompt names. The documented parameters include prompt, feedback_key, model (a string of the form provider:model_name) or judge (a LangChain chat model or an OpenAI client), continuous (a float score between 0 and 1 instead of a boolean), choices (a list of allowed numeric scores, exclusive with continuous), use_reasoning and few_shot_examples. The result is a dictionary with key, score and comment. Prebuilt prompts such as CORRECTNESS_PROMPT live in openevals.prompts. How these evaluators plug into LangSmith datasets, evaluate and the pytest plugin is on LangChain evaluation; this section only shows the judge itself.

The DocsAssistant correctness judge, with the rubric from the table above as a custom prompt and a discrete 1 to 4 scale:

Source: openevals README (LLM-as-judge). The model string ollama:llama3.1:8b assumes the provider integration for Ollama is installed; the README documents the provider:model form and its OpenAI example, and a LangChain chat model can be passed through judge instead if you prefer to construct it yourself.

A pairwise judge is the same function with a prompt that has two answers and a categorical outcome. The README documents that extra prompt variables are supplied at call time, and that choices restricts the numeric score; encoding "A wins" and "B wins" as two scores keeps the verdict machine-readable. Running the pair in both orders implements the position-swap protocol:

Source: openevals README (LLM-as-judge, custom prompts and extra variables). Passing custom variables such as answer_a follows the README’s statement that additional prompt variables are provided when the evaluator is called; the repository’s other prompt helpers (for example prebuilt correctness or hallucination prompts) are single-answer prompts, so the pairwise prompt above is ours, not a prebuilt one.

MLflow 3 treats a judge as a scorer: an object that mlflow.genai.evaluate runs over a dataset, recording the verdicts and the judge’s rationale next to traces and runs, so judge scores sit in the same experiment as the rest of the evaluation. The make_judge function builds a judge from natural-language instructions. Its signature in the 3.x source takes name, instructions, model (a URI of the form openai:/gpt-4), feedback_value_type, and optional description, inference_params, base_url, extra_headers and generate_rationale_first. The instructions must contain at least one of the template variables {{ inputs }}, {{ outputs }}, {{ expectations }}, {{ conversation }} or {{ trace }}, and feedback_value_type accepts primitive types, Literal enums and some containers (Pydantic models are not supported). MLflow also ships built-in scorers such as Correctness.

Source: MLflow GenAI documentation; the signatures of make_judge and mlflow.genai.evaluate (data, scorers, predict_fn, model_id) were read from the mlflow source on GitHub because the documentation site answered automated fetches with HTTP 403 on 2026-10-01. The ollama:/ model URI is an assumption by analogy with the documented openai:/gpt-4 form; confirm the provider prefix for your version before relying on it. With predict_fn set, mlflow.genai.evaluate calls your application on each input and traces it, and the dataset then needs no outputs column.

MLflow documents a workflow for aligning a judge with human feedback: Judge.align(traces, optimizer) takes traces that carry human assessments and returns a new judge whose instructions have been adjusted, defaulting to an optimizer named MemAlign in the source. I did not find a reachable official page that states the full workflow, so this page does not show code for it; treat alignment as an automated version of the prompt revision loop in the calibration section below, and validate any aligned judge on held-out labelled data before trusting it.

Spring AI ships two model-based evaluators in org.springframework.ai.chat.evaluation that implement the Evaluator interface (one method, evaluate(EvaluationRequest), returning an EvaluationResponse with isPass(), a score and feedback). RelevancyEvaluator asks whether the answer is in line with the context for the query, and FactCheckingEvaluator asks whether a document supports a claim, which makes it a groundedness check for the DocsAssistant. Both are pointwise, binary judges whose prompts you can replace; the full API, the strictness of the yes parsing and the custom evaluators are on Spring AI evaluation, so only the judge-specific parts are shown here.

Source: Spring AI: Model Evaluation. The builder form of FactCheckingEvaluator (builder(clientBuilder).build()) follows the 2.0.1 API as exercised on the sibling page, where the constructor shown in the reference page is not accessible.

Spring AI’s own LLM-as-a-judge guide describes the same two patterns as this page, direct assessment (point-wise) and pairwise comparison, and recommends a separate evaluation model to avoid self-evaluation (narcissistic) bias; its worked example is a recursive advisor that rates a response on a 1 to 4 scale and retries with the judge’s feedback, which is the runtime self-refinement use of a judge and is covered on the sibling page. For fact checking, the evaluator has a forBespokeMinicheck mode, which leads to the next topic.

A general chat model can judge, but a model trained for the job is often cheaper and more consistent on that job. Two families exist:

Three considerations decide between a specialised judge and a large general model. A small local judge keeps documentation text and user questions inside your network (see Running LLMs Locally for hosting it), costs little per call, and can be run on every pull request. A large model reads long contexts and subtle rubrics better. And any fine-tuned judge inherits the biases of its training data, so it needs the same bias tests and kappa measurement as a general model. A practical pattern is a two-tier setup: a cheap judge scores everything, and a stronger judge re-scores the items where the cheap judge is uncertain or where two cheap judges disagree.

G-Eval (Liu et al.) is the related idea of asking the judge to first generate evaluation steps from the criterion and then score, optionally weighting the score by token probabilities; libraries such as DeepEval implement it, and it improves granularity at the cost of extra calls.

A judge score is a claim about quality; calibration is how you earn the right to use it. The procedure:

Raw accuracy misleads whenever one label dominates: a judge that always says "grounded" scores 90% accurate if nine answers in ten are grounded. Cohen’s kappa corrects for the agreement expected by chance. With two raters (the judge and a human) labelling the same items into categories, let be the observed fraction of items on which they agree, and , the fraction of items each rater assigned to category . Then

where is the agreement expected if both raters labelled independently with their own base rates. is perfect agreement, is no better than chance, and negative values are worse than chance. A worked case: 100 answers, judge and human both say "grounded" on 80, both say "ungrounded" on 8, and disagree on 12 (judge says grounded 6 times when the human says not, and the reverse 6 times). Then , the judge says grounded on 86% and the human on 86%, so and . An 88% raw accuracy hides a kappa of about one half, because the prevalence of one class inflates chance agreement.

Common verbal scales (Landis and Koch’s) call 0.41 to 0.60 moderate and 0.61 to 0.80 substantial agreement, but the threshold that matters is the one your decision needs. A judge that gates releases should be near the kappa between two trained humans on the same rubric; a judge that only triages items for human review can be lower.

For ordered scales such as 1 to 4, a disagreement of one level is less serious than three. Weighted kappa replaces exact matching with disagreement weights (linear or quadratic in the distance between levels):

where is the observed count of items the judge put in level and the human in , and is the count expected by chance from the marginals. In Python, scikit-learn implements both:

Source: scikit-learn: cohen_kappa_score. Eight items are far too few for a real estimate; the sample-size reasoning is on Building Eval Sets, and a kappa computed on 100 items has a wide confidence interval that you should report.

A validated judge becomes part of the suite described on the neighbouring pages:

Judge prompts are versioned artefacts like any other (see Prompt and Model Management). Security testing of judges themselves, for example attempts to embed instructions in an answer that tell the judge to pass it, belongs to AI Red Teaming in the AI Security & Responsible AI sub-section; a minimal defence is to delimit the graded text with tags, tell the judge that the content inside them is data to be graded and not instructions, and include injection attempts in the validation set.