How to Use LLM-as-a-Judge

Article

This extends our tutorial on evaluating prompts programmatically. Use exact-match metrics where you can, and reach for a judge only where you cannot.

What is LLM-as-a-judge?

LLM-as-a-judge is using a language model to evaluate another model's output against criteria you define. Instead of a string comparison, the judge reads the output and returns a score or a verdict.

The paradigm was formalized by Zheng et al. in 2023, who found that a strong model agreed with human preferences over 80% of the time, roughly the rate at which two humans agree with each other. That is the promise: human-like judgment at machine scale and cost.

The catch is that a judge is a model, so it inherits a model's quirks. Used carelessly, it produces confident scores that measure the wrong thing.

When to use it, and when not

A judge is the right tool for open-ended quality that resists exact scoring. It is the wrong tool when a cheaper, deterministic check would do.

Use a judge for helpfulness, tone, coherence, faithfulness to a source, or "which of these two answers is better." Skip it for anything a programmatic metric already covers: labels, exact values, schema validity, or the presence of a required fact.

The rule of thumb: try to make the check deterministic first. Only when you genuinely cannot should you hand the decision to a judge.

Pointwise vs. pairwise

There are two ways to ask a judge to score, and they suit different jobs.

| Mode | The question | Best for | Weakness | |---|---|---|---| | Pointwise | "Rate this output 1 to 5 against the rubric." | Absolute scores for a dashboard or a CI gate | Calibration drifts; scores are hard to compare across runs | | Pairwise | "Which is better, A or B?" | Comparing two prompts or two models | Gives a winner, not an absolute score; sensitive to order |

Pairwise usually agrees with humans more closely, because relative comparison is easier than absolute calibration. Reach for it when you are A/B testing a change, and use pointwise when you need a standalone number.

Write the judge prompt

A judge is only as good as its rubric. A vague prompt inherits the model's untethered assumptions, so make the criteria explicit and ask the judge to reason before it scores.

```text You are evaluating an answer to a user question. Judge ONLY against the rubric.

Rubric: - Correctness: does the answer match the reference facts? - Completeness: does it cover what the question asked? - Groundedness: are claims supported, with no invented details?

Question: {question} Reference: {reference} Answer: {answer}

First, reason step by step about each rubric criterion in 1-2 sentences. Then output a JSON verdict: {"correctness": 0-1, "completeness": 0-1, "groundedness": 0-1, "pass": true/false}. Do not reward length or style. ```

Two details matter. Asking for step-by-step reasoning before the verdict (a chain-of-thought prompt) improves agreement with humans. And the explicit "do not reward length or style" line directly counters a bias covered next.

The four biases you must handle

A judge is not a neutral oracle. Research has documented consistent biases, and these are properties of the method, not bugs you can prompt away entirely.

| Bias | What happens | Mitigation | |---|---|---| | Position bias | In pairwise, the answer in slot A wins more often than chance | Run both orderings (A/B and B/A) and only trust an agreeing verdict | | Verbosity bias | Longer answers score higher, even at equal quality | Penalize length in the rubric, or use length-controlled win rates | | Self-preference | A judge favors outputs from its own model family | Use a judge from a different family than the model under test | | Format bias | The judge prefers its own preferred format (prose over JSON, etc.) | State the required format in the rubric and score content, not shape |

The most important of these is position bias, because it is easy to catch in code and it silently corrupts every pairwise comparison you run.

Control position bias in code

The fix for position bias is simple: judge each pair twice, swapping which output goes first, and only declare a winner if the verdict holds both ways. If it flips on order alone, the judge is guessing.

```python debias.py

def pairwise_debiased(x: str, y: str, judge) -> str: """Run the judge in both orderings. Trust the result only if it agrees.""" first = judge(x, y) # x in slot A second = judge(y, x) # y in slot A

x_wins = first == "A" and second == "B" y_wins = first == "B" and second == "A" if x_wins: return "x" if y_wins: return "y" return "tie/uncertain (verdict flipped on order)"

A deliberately position-biased judge stub: it always picks slot A. Real judges show a smaller version of this; we exaggerate to prove the control works. def biased_judge(a: str, b: str) -> str: return "A"

A fair judge that decides on a real signal (here, conciseness) regardless of slot. def fair_judge(a: str, b: str) -> str: return "A" if len(a) <= len(b) else "B"

print("biased:", pairwise_debiased("short answer", "a much longer answer", biased_judge)) print("fair: ", pairwise_debiased("short answer", "a much longer answer", fair_judge)) ```

Paste this into debias.py and run python debias.py. You get exactly:

```text biased: tie/uncertain (verdict flipped on order) fair: x ```

The debiasing did its job. It caught the biased judge red-handed and refused to call a winner, while it let the fair judge's stable verdict through. To use a real judge, replace judge with a function that calls an LLM with the rubric prompt above and returns "A" or "B."

Audit your judge

Before you trust a judge in production, measure it. A judge you have not audited is a metric you cannot defend.

Build a small calibration set of cases with known-good verdicts, ideally labeled by humans. Run the judge and check two things: how often it agrees with the human labels, and how often a pairwise verdict flips when you swap the order. A flip rate above about 5% means position bias is still leaking through.

Re-run this audit whenever you change the judge model. A minor version bump can shift the score distribution, so calibration is not a one-time task.

The hybrid pattern

The reliable 2026 setup does not lean on a judge alone. It layers three kinds of check, cheapest first.

Deterministic metrics handle everything they can (labels, schema, required facts). The LLM judge scores only the open-ended qualities left over. And a human spot-checks a sample of the judge's verdicts to keep it honest. This is the same layered discipline behind testing an AI agent safely.

Each layer covers the previous one's blind spot. The judge is a powerful middle tier, not the whole stack.

Common mistakes

Most unreliable judges share a few causes.

Teams use the same model as generator and judge, which bakes in self-preference. They write a vague rubric, so the judge scores on hidden assumptions. They run pairwise in one order only, so position bias goes uncaught. And they never calibrate against humans, so they cannot say whether the judge is right.

Fix these by separating the judge from the model under test, writing an explicit rubric, always swapping order, and auditing against human labels.

Sources

Zheng et al., Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (NeurIPS 2023). The LLM-as-judge paradigm, over 80% agreement with human preferences, and the position, verbosity, and self-enhancement biases.

Methodology: the technique and its biases are asserted in ModelRefs' own voice as the reference layer, cross-checked against the original MT-Bench research on 6 Aug 2026. The debiasing demo is deterministic and reproduces the output shown; real-judge scoring uses an LLM and will vary.