LLM-as-judge 負責任使用指南：信任 AI 評分前的檢查清單

"LLM-as-judge" has quietly become infrastructure. We use one model to grade another's answers, to decide if a test really passed, to score RAG relevance, to moderate, to rank. It's cheap, fast, and scales to volumes no human can touch.

It's also a measurement instrument — and most teams deploy it without ever checking whether the instrument is accurate. Here's a practical checklist before you let an LLM grade anything that matters. (Context: I built a small harness that runs a local LLM as a test judge and scores it against ground truth; some numbers below come from that.)

1. Measure it against ground truth at least once

You cannot manage what you haven't measured. Assemble a set of cases where you know the right verdict (labelled correct/wrong) and run the judge over them. You're looking for:

• False-pass rate — of everything it approved, how much was actually wrong? (The dangerous direction.)
• Miss rate — of the genuinely wrong items, how many did it wave through?
• False-alarm rate — how often does it reject good work? (The annoying direction.)

In my run, a capable open model missed 26% of wrong outputs — a quarter of real failures, passed. You want your number, on your task, before you rely on it.

2. Check calibration, not just accuracy

Ask the judge for a confidence, then check whether that confidence means anything. A well-calibrated judge that says "90% sure" should be right about 90% of the time. Measure Expected Calibration Error (ECE).

The common failure: models are massively overconfident. Mine answered with ~100% confidence on nearly every call — including the wrong ones (ECE ≈ 0.31). If the confidence is always "very sure," it carries no signal and you can't use it to route hard cases to a human.

3. Pin everything and version it

An LLM judge whose model, prompt, or temperature drifts is a ruler that changes length. Pin:

• the exact model (and version),
• the prompt template,
• temperature (use 0 for grading — you want determinism, not creativity).

Open-weight models help here: you can pin a local model and know it won't change under you. A hosted endpoint can be swapped silently.

4. Watch for the known biases

LLM judges have documented, reproducible biases:

• Position bias — prefers the first (or last) option in a pairwise comparison. Mitigate by running both orders and averaging.
• Verbosity bias — rates longer answers higher regardless of correctness.
• Self-preference — a model tends to favour outputs that look like its own.
• Leniency — many judges default to "PASS" when unsure.

If your eval drives a leaderboard or a release decision, these biases become your biases.

5. Never let it be the only gate

The safe pattern isn't "judge decides, ship." It's:

• Use the judge as a cheap first-pass filter, not the final word.
• Keep a ground-truth backstop on a sample — spot-check the judge continuously, not once.
• Route low-confidence or high-stakes cases to a human or a stronger check.
• Treat a PASS as "probably fine," not "verified."

The one-line version

An LLM judge is a fast, cheap, biased, overconfident grader that is right often enough to be useful and wrong often enough to be dangerous. Measure it, pin it, debias it, and keep a human backstop — then it's a great tool. Trust it blindly and it will quietly approve your worst bug with total confidence.

Are you using LLM-as-judge in production? What did you find when you checked it against ground truth — or have you checked yet?

I'm Krishnasai Rollamadugu — a test automation architect researching trust and measurement in AI-driven software testing. Related: an open experiment measuring a local LLM judge — trust-judge.