Home / Blog / Engineering
Engineering

LLM as Judge: How to Use a Model to Evaluate Your Agents Without Fooling Yourself

LLM as judge is the practice of using a language model to assess the quality of another system's output against a stated rubric, so that quality can be measured across thousands of runs instead of a few dozen human reviews. It is the most scalable evaluation method available today and the easiest to misuse, because a judge returns a confident number whether or not it is measuring anything.

What is LLM as judge?

LLM as judge is an evaluation method in which a language model is given a task, an expected output or a rubric, and the output to be assessed, and returns a score, a comparison or a critique against a stated standard.

Three inputs are always present, and understanding what each contributes separates a usable evaluation from a plausible-looking one. The task establishes what was attempted, so the judge assesses against the right goal rather than its own preference. The rubric or reference supplies the standard — written criteria with levels, or a known-good answer. The output is what is scored. Optional but important: the context the output was produced from, because without it the judge cannot distinguish a wrong answer from a correct answer given insufficient information.

What it costs is that the judge is now a measurement instrument, and it must be treated like one. A scale never calibrated against human judgement is not a measurement — it is an opinion, repeated. The entire discipline of LLM as judge is calibration.

Why do enterprises need model-based evaluation at all?

Because agent quality degrades quietly and in ways a user does not report. A change to a chunk size, a new tool implementation, a different model, an upstream data change — each can shift output quality without changing anything obvious in the interface. The customer notices three months later, and by then the cause has been lost.

Human review does not scale to this. In a Singapore or Hong Kong SAR deployment with thousands of agent runs a week, a subject expert can look at perhaps a few dozen — enough to form an impression, not enough to detect a regression, because a few percent regression is invisible in a sample of thirty.

Assessor typeWhat it is good atWhere it is weakTypical use
Deterministic checkFormat, schema validity, required field presence, exact-match facts, latency budgetAnything requiring interpretationRun on every single run; cheap and always on
Ground-truth verificationAnswers where the correct value is known independentlyJudgement, tone, strategyMaths, extraction, lookups, contract clause matching
Human expert reviewAnything consequential or ambiguous; calibration of everything elseVolume, consistency, reproducibilityCalibration sample, escalation cases, new task types
Model-based judgeVolume, consistency, regression detection over long periodsStrategic quality, novel task types, anything it was not calibrated onEvery run in regression plus a share of live traffic

The useful architecture layers the four by cost and severity. Deterministic checks and ground-truth verification run first, on every run, and are cheap. The judge runs on everything that survives them, and on a sampled share of live traffic, to catch drift that no fixed set would reveal. The human expert looks at what the judge flags, and at a fixed calibration sample that never changes, so the two stay comparable over time.

How do you design a rubric a judge can actually apply?

A rubric for model-based judging has to be written differently from a rubric for a human assessor. The human can infer what you meant. The model will not, and the gap between your intent and the model's reading is where silent noise enters your measurement.

Five rules make a rubric usable by a judge.

  1. Make every criterion binary or explicitly banded. "Is the answer correct?" is unjudgeable. "Does the answer state the refund window as stated in the policy document?" is judgeable, because it names the fact that must appear. Reserve graded scales for dimensions where band descriptions are written out.
  2. Write the band descriptions, not just the band names. A one-to-five scale with only the ends defined will produce a distribution clustered at three, because the model has no anchor for four.
  3. Require a reason and a quoted span for every judgement. Make the judge cite the specific text that supports its score. This lets you audit the judge, and it materially improves judge accuracy, because it forces the reasoning to precede the number.
  4. State the negative case explicitly. If a common failure should be scored zero — an unsupported claim, a hallucinated citation, a missing disclosure — say so. Judges otherwise reward fluency, and fluent wrong answers are the dominant failure in enterprise evaluation.
  5. Keep the rubric versioned and separate from the prompt. A rubric change is a change to your measurement instrument and must be dated, reviewed and — critically — never applied retroactively to earlier results.

A worked example. For an insurance claim triage agent, a weak rubric asks whether the response is "helpful and professional". A usable rubric asks five specific things: whether the claim category is correctly assigned from the policy definition; whether the notification window is stated in days as the policy states it; whether the required documents are listed exactly; whether the referral trigger is correctly identified; and whether no claim is covered or denied by the response itself. That rubric is auditable, regression-testable, and one a subject expert can read and agree with.

Four kinds of assessor, and the boundary of each

Every assessor has a domain where it is trustworthy. Declaring that boundary up front is what stops model-as-judge quietly grading its own homework.

AssessorUse it whenBoundary — where it must not judge
Rule-basedThere is a correct answer and it is machine-checkable: format, field presence, arithmeticNever for quality, tone, adequacy, or anything requiring judgement
Model-as-judgeThe question is whether an answer is adequate, relevant, grounded and appropriately refusedNever as the sole assessor on high-stakes decisions, and never on its own outputs without a reference
Human reviewThe decision is material, the population is small enough to read, and being wrong is expensiveNever at full volume — humans degrade into sampling the easy ones
Reference comparisonA known-correct answer exists and near-miss mattersNever where multiple valid answers exist; it rewards one phrasing over a better one

When should you use pairwise comparison instead of absolute scoring?

Use pairwise comparison when you are choosing between two candidate approaches — two prompts, two retrieval configurations, two agent architectures. Use absolute rubric scoring when you need a number you can track over time or gate a release on.

Relative judgement is easier and more consistent than absolute judgement, for both models and humans. Asked to score a response on a one-to-five scale, two reviewers will disagree about whether it is a three or a four. Asked which of two responses is better, they usually agree, and the disagreement concentrates on genuinely close cases. Judges behave the same way.

Pairwise comparison has a specific implementation requirement: you must randomise the position of the candidates and, where the ordering is decided by the model rather than fixed, you must run both orderings and require agreement. A judge that prefers the first candidate will produce a biased result unless you correct for it, and the bias is large enough to reverse a conclusion in close cases.

The second requirement is a reference anchor. Pure pairwise comparison gives you an ordering, not an absolute position, which means it cannot tell you whether the winner is good. In practice you keep a small set of reference examples with known human scores and include them in the comparison, so the ordering is anchored to something external.

The third requirement is consistency across runs. Because pairwise judgements are sensitive to small changes in presentation, the comparison protocol — the instruction, the order, the anchor set — must be frozen and versioned. Changing the protocol invalidates previous comparisons even if the underlying candidates did not change.

What are the failure modes, and how do you mitigate them?

Four biases are strong enough to change conclusions if you do nothing about them, and each has a known mitigation.

Failure modeWhat happensMitigation
Position biasThe candidate shown second wins more often than it should, regardless of qualityRandomise order per comparison; run both orderings and require agreement; discard the pair if they disagree
Verbosity biasLonger, more elaborate answers score higher even when less correctExplicitly instruct the judge to disregard length; add a rubric criterion for absence of unnecessary content; normalise for length in the analysis
Self-preferenceA judge rates output from the same model family as itself more highlyUse a judge from a different model family where you can; never use the candidate model as its own judge; record the judge model identity with every result
Rubric driftThe same rubric is read differently over months, so the trend line is not a trendVersion the rubric; re-run the calibration set after any change; keep a frozen set of anchor cases that must always be included
Confident error on noveltyOn a task type the judge was never calibrated for, it produces a confident, wrong numberMark task types as calibrated or uncalibrated; exclude uncalibrated types from release gates; escalate them to human review instead
Reference contaminationIncluding an ideal answer makes the judge favour text that resembles it over a better answerUse a reference for facts and required content, not for style or structure; or drop the reference and use a criterion-only rubric

Two deserve emphasis because they most often go unnoticed. Self-preference matters if your agent and your judge share a model family, and the fix is a different family for the judge — a deliberate cost worth accepting. Rubric drift is quieter, because scores keep looking plausible while becoming incomparable across time. The defence is a frozen anchor set re-scored every time the rubric is touched, so a shift shows up as a change in anchor scores rather than a mysterious trend in production.

Four failure modes you must measure for

A model-as-judge without calibration is not a measurement — it is an opinion with a number attached. These four are the ones to test for.

Judge says pass too easily

Leniency

Symptom: your live failure rate is far lower than your observed complaint rate. Almost always under-calibration. Fix: calibrate against human labels before you trust any number.

Longer reads as better

Verbosity bias

Symptom: the judge prefers the longest answer regardless of accuracy. Fix: state length as neutral, or normalise it explicitly in the rubric.

Judge favours its own family

Self-preference

Symptom: outputs from the same model family score higher. Fix: use a different model family for the judge, and check for the bias explicitly.

Order changes the score

Position bias

Symptom: the same pair scored differently depending on which was presented first. Fix: randomise order and run it a second time to measure the variance.

How do you calibrate a judge against human labels?

Calibration is defined as the process of measuring the agreement between a model-based judge and independent human labels on a labelled sample, and re-running that measurement whenever the judge, the rubric or the underlying model changes.

The procedure is straightforward and almost nobody does it.

  1. Build a labelled sample. A few hundred cases is enough to start; stratify across task types and across quality levels, including deliberately weak cases, because a judge that only sees good outputs will look better than it is.
  2. Measure agreement, and report it as part of the result. Report per-criterion agreement, not just one aggregate. A judge with strong agreement on factual criteria and weak agreement on tone is a useful judge for the first and not for the second.
  3. Set the scope of what the judge may be used for. Write down the task types it is calibrated on and treat everything else as uncalibrated. This prevents the most damaging misuse: a judge applied to a new task type with no recalibration.
  4. Re-run on a schedule and on change. After any change to the rubric, the judge model, the candidate model or the retrieval configuration.

Report the calibration figure alongside every evaluation result. An evaluation that publishes a score without an agreement rate asks the reader to treat the number as more precise than it is, and in an enterprise setting that number ends up in a board paper.

Calibrating a model-as-judge before you trust it

The most common misuse we see is a single judge scoring 100% of traffic with no reference answers and no human calibration. Five steps to fix that.

01

Build a small human-labelled set

Two hundred cases, labelled by two people who know the domain, with disagreements resolved explicitly.

1
02

Run the judge against it

On the full set, not a sample. You are measuring the judge, not the agent.

2
03

Measure agreement per category

Not one overall number. A judge at 85% overall can be useless on exactly the category you care about.

3
04

Split by assessor type

Judges behave differently on factual, judgement and refusal cases. Calibrate each separately.

4
05

Re-calibrate on every model change

A new judge model is a new assessor and needs its own calibration from scratch.

5

How do you turn judge scores into a regression gate?

A regression gate is a check that runs on a fixed set before a change is allowed through, and that blocks the change when a stated condition is not met. The value of model-based judging is not that it produces a score; it is that it produces a comparable score on a fixed set, which is what a gate requires.

Four design decisions matter.

  • Gate on the failure, not the average. An average across a test set hides the case that matters. Gate on a per-criterion pass rate, and on the specific hard cases you have declared as must-pass. A system can improve its average and still fail the one case that would have caused an incident.
  • Use deterministic checks for hard gates wherever possible. If a required fact must be present, check for its presence directly. Reserve the judge for dimensions that genuinely require interpretation, so your gate depends on the noisy instrument as little as possible.
  • Keep the set fixed and growing. Every production failure becomes a new named case, never removed. A set that is edited rather than accumulated drifts toward what the current system already does, and stops detecting anything.

The observability layer we deploy keeps exactly this association, described on our observability and cost page. A related point appears in our article on context engineering and why prompt tuning cannot repair a broken pipeline: a judge scoring a bad retrieval result will report a bad answer, and the bad answer is not the thing that needs fixing.

Where does model-based judging stop being the right tool?

Four cases.

First, when the task is strategic rather than operational. Whether a negotiation opening is the right one, whether a risk escalation was proportionate — these are judgements where disagreement is a matter of perspective, and a rubric-trained judge systematically favours the mainstream. Those need human review.

Second, when the correct answer is unknown and the stakes are high. If nobody can say what the right answer is, a judge's confidence is not evidence of anything.

Third, when the evaluated model produces text the judge is unusually fluent about. Judges are more reliable on structured, fact-shaped work — extraction, summarisation against a source, compliance checks, classification — and less reliable on long free-form prose.

Fourth, when the volume does not justify it. If you run forty agent tasks a week, a human expert can read all of them, and the judge adds cost, calibration work and a second thing to maintain. The honest recommendation for a low-volume deployment is a good regression set and a person reading it.

Where we draw the same boundary in delivery: we do not sell a judge as a compliance attestation. It is a measurement instrument, and an auditable statement about an agent's behaviour needs deterministic checks, traceable evidence and human sign-off. A model-based score is one input to that statement.

FAQ

Frequently asked

What is LLM as judge?

LLM as judge is an evaluation method in which a language model is given a task, the expected output or a rubric, and the output to assess, and returns a score or a comparison against a stated standard. It is used to scale quality assessment across large volumes of agent runs where human review is too slow or too inconsistent to be the only method.

Is LLM as judge reliable?

Reliable within a narrow scope, and unreliable outside it. A judge is a measurement instrument with a known error profile: it is reasonably consistent on whether an answer contains a required fact, unreliable on whether a response is strategically good, and biased by position and verbosity. Treat its output as a noisy signal that needs calibration, not as ground truth.

How do you make judge scores trustworthy?

Calibrate against human labels. Take a sample, have two subject experts score it independently, and measure the agreement between the judge and the human labels. Publish the agreement rate as part of the evaluation result, and re-run the calibration whenever the judge, the rubric or the model changes.

Should you compare two answers pairwise or score one answer absolutely?

Use pairwise comparison when you are choosing between two candidate approaches, because humans and models are both more consistent in relative judgement than absolute scoring. Use absolute rubric scoring when you need a trend over time or a regression gate, since pairwise comparison gives you a ranking but not a number you can track. Many programmes run both.

What are the main failure modes of model-based judging?

Position bias, where the answer in the second position wins more often than it should; verbosity bias, where longer answers score higher; self-preference, where a judge rates its own output highest; and rubric drift, where the same rubric is interpreted differently across runs. Each has a known mitigation, described in the article.

How often should the evaluation set be re-run?

On every change to a prompt, a retrieval configuration, a tool implementation or a model, and on a fixed schedule against a sample of live traffic. A regression set that only runs before a release tells you about the release; the scheduled run tells you about drift.

Read next

Related

Engineering

AI Agent Platform Evaluation Criteria

The nine criteria we score, and why evaluation tooling decides more vendor selections than model quality does.

Engineering12 min read

Talk to a practitioner about this

WhatsApp +852 5807 1860

Talk to us about your workflow

The fastest route to a practitioner. If this article describes your situation, the useful conversation is about which workflow to start with.

Learn more →
info@cyberwisdom.net

Send a brief

For RFPs, tender documents and anything that needs a paper trail you can forward internally.

Learn more →
Singapore

Group headquarters

34 Floor, 77 Robinson Road, Singapore 068896 — enterprise AI consulting and group strategy.

Learn more →
Hong Kong SAR

Enterprise learning headquarters

LMS, TMS, custom courseware, academy and partner enablement.

Learn more →

Where to go next

Consulting

Agentic Business

The core proposition: what an organisation looks like when a meaningful share of decision and execution is delegated to agents.

Learn more →
Where to start

Agentic Operations

Which workflows to delegate first, in what order, and with what supervision.

Learn more →
Selection

20 Industries

Twenty sectors, each with a named first workflow, a named decision-maker, and where we are the wrong answer.

Learn more →
Platform

Evaluation & Quality

How evaluation becomes a production system rather than a checkpoint before go-live.

Learn more →
Topics we cover

What this page answers

Every topic below is covered in the sections above, and each links to the page that goes deeper on it.

LLM as judgeLLM as judge best practicesAI agent evaluation frameworkLLM evaluation without ground truthAI agent testing frameworkAI agent platformenterprise AI agent platformAI agent platform evaluation criteriaAI agent runtimeagent orchestration platformmulti-agent orchestration patternsmulti-agent system architectureAI agent architecture comparisonReAct vs ReWoo vs plan-and-executewhat is ReAct agentplan-and-execute agent designdeep research agentAI agent development platformAI agent DevOpsagentic workflow design patternsAI workflow automation enterpriseAI agent tool callingMCP vs API integrationModel Context Protocol enterpriseMCP server enterprise deploymentA2A protocol enterprise AIagent-to-agent interoperabilityAI agent memory architecturecontext window management for agentsLLM as judge evaluationregression testing for AI agentsAI agent observability tracingLLM tracing and debuggingLLM token cost controlAI agent cost optimisationAI cost governance financehallucination reduction enterprisehallucination detection LLMprompt injection defence enterpriseAI firewall enterprisehuman in the loop AI designhuman in the loop vs fully autonomous AIAI agent sandboxingprivate deployment AI agentshybrid AI deployment enterprisemulti-model routing enterprisemodel gateway enterpriseAI agent observability best practicesbad case analysis LLMAI data flywheelAI agent performance monitoringAI agent SLA designenterprise agent identity and accessagent RBAC designenterprise AI governanceenterprise AI governance frameworkAI governance framework templateenterprise AI governance consultingAI governance SingaporeAI governance Hong Kong SARAI governance in Asia PacificISO 42001 implementation guideISO 42001 consultingISO 42001 vs ISO 27001ISO 42001 vs NIST AI RMFISO/IEC 42001 AI management systemISO 42001 certification supportISO 42001 readiness assessmentNIST AI Risk Management FrameworkEU AI Act compliance for enterprisesEU AI Act readiness assessmentAI risk classification methodologyAI impact assessment enterpriseAI audit trail requirementsAI audit readinessAI compliance SingaporeAI compliance Hong Kong SARgenerative AI regulatory requirements AsiaAI policy framework enterprise templateenterprise AI responsible AI policymodel risk management enterpriseAI ethics governance frameworkAI third party risk managementAI vendor due diligence checklistresponsible AI governance trainingAI compliance evidence automationAI controls testing enterpriseenterprise AI security architectureAI data security enterpriseAI agent security best practicesLLM security enterpriseAI governance roles and responsibilitiesAI steering committee enterprisewhat is AI agent platformhow to implement AI agent platformhow to choose a AI agent platform providerhow to evaluate AI agent platform vendorshow to build an AI agent platform roadmapAI agent platform best practicesAI agent platform implementation guideAI agent platform for mid-market companiesAI agent platform cost and pricingAI agent platform ROI and business caseAI agent platform governance and controlsAI agent platform implementation roadmapAI agent platform vs traditional approachesAI agent platform vs manual processbenefits of AI agent platform for bankingchallenges of AI agent platform for bankingAI agent platform readiness checklistAI agent platform maturity modelAI agent platform KPI frameworkAI agent platform team and skills neededAI agent platform integration with existing systemsAI agent platform pilot to productionwho needs AI agent platformwhen to adopt AI agent platformAI agent platform for bankingAI agent platform for banking companieshow to use AI agent platform in banking
Next step

Bring one task type and we will build you the rubric.

A working session on a real agent output: we draft the rubric, score a small sample, and show you what the judge agrees and disagrees with a human on. You leave with a versioned rubric and a calibration baseline.

Talk to us about this topic

If this raises a specific question in your organisation — a workflow, a learning gap, or a governance obligation — message us on WhatsApp and a practitioner will pick it up. Usually the same working day.