Skip to Content

YOUR LLM-AS-JUDGE IS AN UNTESTED TEST ORACLE

November 10, 2026
Chandrika B R

LLM-as-judge has quickly become a practical way to evaluate AI systems. It helps when there is no simple answer key for qualities such asfaithfulness, helpfulness, tone, completeness, or whether important caveats were preserved.

But there is a problem: Teams often validate the AI system carefully and then trust the judge without validating the judge itself.

That turns the judge into an untested test oracle.

A judge is a measurement instrument

An LLM judge is not “just another prompt.” It is part of your evaluation system. If the judge is inconsistent, biased, or drifting, every score it produces becomes questionable.

A polished dashboard can still be built on unreliable measurements.

Common judge failures are already well known. A model may prefer the first answer it sees in a pairwise comparison. It may reward longer answers even when they are less correct. It may favour outputs that resemble its own style. It can also be impressed by confident formatting while missing factual errors.

These are not rare edge cases. They are predictable failure modes and they should be tested.

Calibrate before you trust

Before using an LLM judge for release decisions, build a small human-labelled evaluation set. The examples should reflect real production cases and include near-misses, not only obviously good and obviously bad outputs.

Then compare the judge with trusted human or domain-expert decisions.

Start simple. Binary pass/fail judgments are often easier to interpret than vague 1–5 scores. Ask the expert to explain why an example passed or failed, then use those critiques to improve the rubric.

The goal is not to prove that the judge is perfect. The goal is to understand when it is reliable enough for the decisions you want it to make.

When the judge disagrees with humans, study the disagreement. It usually points to one of three things: a judge defect, an unclear rubric, or a genuinely difficult case.

That analysis is often more valuable than the overall score.

Treat judge changes as breaking changes

An LLM judge has several moving parts: the model, model version, prompt, rubric, decoding settings and scoring anchors.

Any of them can change the measurement.

If a provider updates the model or someone edits the rubric, the new score may not be comparable with last month’s score. Judge configuration should therefore be versioned just like application code.

A useful pattern is to keep two judges:

  • A frozen judge for regression testing and release gating.
  • A current judge for experiments and improvements.

When the current judge is promoted, re-score a fixed anchor set and document the difference. Do not silently change the measurement instrument and pretend the historical numbers still mean the same thing.

Use deterministic checks first

Not every quality check needs an LLM.

Schema validation, valid JSON, required fields, citation presence, pattern-based secret detection and many policy checks can often be handled with deterministic rules or classifiers.

Use the LLM judge where interpretation is genuinely required: faithfulness to retrieved context, tone, preservation of caveats, nuanced completeness or semantic quality.

A simple evaluation cascade can therefore be:

Deterministic checks → Lightweight classifier → LLM judge

This reduces cost, latency and unnecessary variance.

Decompose the rubric

“Rate this answer from 1 to 5 for quality” is difficult to defend and even harder to debug.

Instead, break quality into smaller questions:

  • Did the answer address every part of the request?
  • Are factual claims supported by the available context?
  • Are limitations and caveats clearly stated?
  • Does the answer introduce unsupported information?

These smaller judgments are easier to test, explain and improve.

The takeaway

LLM-as-judge is powerful, but it should not be trusted by default.

Validate it against human judgment. Test known biases. Version the complete judge configuration. Run deterministic checks before expensive judge calls. Use clear, decomposed rubrics. Revalidate whenever the judge changes.

If you cannot explain how well your judge agrees with trusted human decisions, you do not yet have a reliable evaluation system.

You have a number.

About the author

Senior Manager | India
Chandrika is a Senior Manager and AI Automation Innovation Lead at Sogeti – QET Practice. She specializes in Quality Engineering for AI systems, with a strong focus on embedding governance, risk, and reliability into Generative and Agentic AI solutions.

Leave a Reply

Your email address will not be published. Required fields are marked *

Slide to submit