LLM-as-a-judge is the practice of using a strong language model to grade another model’s outputs against a written rubric, and it works best when you calibrate it against human labels. If you ship a chatbot, RAG assistant or AI agent, it is one of the fastest ways to turn “it seems fine” into numbers you can track.
What is LLM-as-a-judge?
An LLM judge receives the user input, the system’s answer and a criterion, then returns a score, a label or a preference. The idea was popularised by the 2023 paper “Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena” (Zheng et al.), which reported that strong judges such as GPT-4 reached over 80% agreement with human preferences, roughly the level at which humans agree with each other.
That makes judges a scalable, explainable stand-in for expensive human review. It does not make them ground truth, a point we return to below.
Model evals vs product evals
Evidently’s beginner guide separates two things that are often mixed up. Model evals test raw ability with public benchmarks. Product evals test your whole system, including prompts, retrieval and tools, on data that looks like your real traffic. For most teams, product evals are what decide whether a release is safe.
Evaluation methods compared
| Method | Best for | Main weakness |
|---|---|---|
| Code checks (JSON schema, regex, latency) | Format, tool arguments, hard rules | Cannot judge quality or tone |
| Reference-based metrics (exact match, BLEU, ROUGE, embeddings) | Tasks with one right answer | Poor fit for open-ended text |
| LLM-as-a-judge | Open-ended quality at scale | Bias and drift; needs calibration |
| Human review | Calibration and high-risk cases | Slow and costly |
Pointwise vs pairwise LLM judges
Pointwise scoring
A pointwise judge looks at one output and returns a score or pass/fail label. It needs no reference answer if you only use the input and output, which makes it practical for monitoring live traffic and gating releases in CI.
Pairwise comparison
A pairwise judge sees two answers and picks the better one. It suits A/B choices between prompts or models. Swap the order of the answers across runs, because judges can favour whichever answer appears first.
Known biases of LLM judges
The MT-Bench paper names three to watch, and says some can be mitigated:
- Position bias: preferring an answer because of where it appears.
- Verbosity bias: rewarding longer answers regardless of quality.
- Self-enhancement bias: favouring text produced by the same model family.
Only that paper quantifies these effects, while the vendor guides focus on calibration. Treat any specific bias percentage you see elsewhere with caution unless it cites a method.
How to build a reliable LLM judge, step by step
- Write one criterion per failure type. Separate evaluators for correctness, safety, tone and format are easier to debug than one vague “quality” score.
- Add explicit evaluation steps. DeepEval recommends spelling out steps, not only a criterion, for judges used in CI or production.
- Build a golden dataset. Use real logs, synthetic cases, edge cases and past failures. Feed low-scoring production traces back in.
- Calibrate against humans. Label a sample by hand and compare. Arize notes that judge output shifts with the model, prompt, label definitions and input order, so version your evaluators.
- Gate releases on noisy scores. Use repeated runs or confidence intervals rather than a single number.
- Re-run after every change. Run a small smoke suite on each pull request and a full suite nightly or weekly.
Evaluating RAG applications with an LLM judge
For retrieval-augmented systems, score retrieval and generation separately. On the retrieval side, check whether the retrieved context is relevant and covers the question. On the generation side, check faithfulness (also called groundedness): is the answer supported by the retrieved context? Arize uses “groundedness” and DeepEval uses “faithfulness” for the same idea. If you are weighing RAG against other approaches, see our related reading on AI hallucination.
Evaluating agents and tool use
Agents add tool calls and multi-step trajectories, so combine code checks on tool arguments with a judge that reviews the whole trajectory. Our explainer on the Model Context Protocol shows how tools get exposed to models, and RLVR covers the opposite approach of rewards that are checked automatically instead of judged. If your agents touch personal data in India, read AI agents and the DPDP Act too.
Common mistakes
- Trusting a judge you never compared with human labels.
- Using the same model to generate and judge, which invites self-enhancement bias.
- Changing the judge prompt without re-running the baseline.
- Optimising for the judge score until real user quality drops.
Cost, latency and when not to use a judge
Every judged answer is another model call, so a judge adds cost and latency. A common pattern is to run cheap code checks on everything, run the judge on a sample of live traffic or on every item in your offline test set, and send only borderline or high-risk cases to human reviewers. If a rule can be checked with a regular expression or a schema, do not ask a model to do it. Judges earn their place on subjective qualities such as helpfulness, tone, completeness and groundedness.
A simple starter checklist
- Pick the three failure modes that would hurt users most and write one evaluator for each.
- Collect 30 to 50 cases from real logs, including past failures and awkward edge cases.
- Hand-label a subset and measure how often the judge agrees with you.
- Randomise answer order whenever you compare two outputs.
- Store the judge prompt, model name and version next to every score so results stay comparable over time.
- Review the lowest-scoring traces each week and turn them into new test cases.
Teams that follow a loop like this tend to find regressions before users do, and they can change models or prompts with evidence instead of guesswork. The numbers matter less than the habit of measuring the same things the same way each time.
Frequently asked questions
What is LLM-as-a-judge?
LLM-as-a-judge means using a strong language model to score, classify or compare the outputs of another model or application against written criteria, instead of relying only on human reviewers.
Can an LLM judge replace human reviewers?
Not entirely. Research on MT-Bench and Chatbot Arena found that a strong judge can match human preferences more than 80% of the time, but guides from Arize and DeepEval stress that you must validate a judge against human labels for your own task and keep humans in the loop for high-risk cases.
What are the main biases of LLM judges?
The original MT-Bench paper names position bias, verbosity bias and self-enhancement bias, plus limited reasoning ability on hard problems.
Should I use pairwise or pointwise judging?
Pointwise scoring suits production monitoring and CI gates on a single output, while pairwise comparison suits choosing between two prompts or models. Randomise answer order in pairwise tests to reduce position bias.
How many test cases do I need to start?
Start small: a few dozen real or realistic cases, including edge cases and past failures, then grow the set from production traces that scored poorly.
Conclusion
Start with a small golden dataset, one narrow judge per failure type and a handful of human-labelled examples to check the judge. Then wire the suite into CI so every prompt or model change is measured, not guessed.