00If you only remember five things
Cheat sheet · 背这五条就够撑一轮
- One judge, one question.
Never ask a single judge for helpfulness and accuracy and tone.
- Binary, not 1–10.
Ask for true/false. Ten-point scales collapse into 7s and 8s.
- Say what is NOT a failure.
The line everyone forgets. Without it the judge becomes a style critic.
- Validate the judge against humans.
A judge that does not agree with people is a bug, not a metric.
- Decide the fail direction.
Judge times out — do you let it through or block it? Cost of failure decides.
01“What is LLM-as-a-judge?”
Opening definition
“It is using one LLM to check or score the output of another, instead of using a human or a string-matching metric.
You give the judge three things: the input, the output, and one clear question — something like ‘is this answer supported by the source text?’ It gives back a verdict and a short reason.
So it is basically an automated reviewer — one you can run ten thousand times for the price of one human hour.”
“Do you want me to go into how I would actually set one up?”
→ 一句定义 + 一个反问。别自己往下倒细节。
02“Why not just use exact match, or just use humans?”
The motivation question
“For open-ended text there is no single correct string. Two answers can be worded completely differently and both be right — so exact match and BLEU end up measuring wording, not correctness.
Humans are still the gold standard. But you cannot put a human in front of every deploy.
So the pattern is: humans label a small set once, and the judge scales that judgement to everything else. The humans define what good means; the judge just applies it at volume.”
03“Where do you use it — evaluation, or in production?”
Two very different jobs
“Both, but they are different jobs.
Offline it is an evaluator. You run it over a test set, get a number, and compare version A with version B. It costs nothing at runtime and being a bit wrong is survivable, because you only care about the trend.
Online it is a gate. It sits in the request path and can block a bad answer before the user sees it. That is much harder — now it costs latency and money on every call, and when it is wrong the user feels it directly.
My rule: only put a judge online when the cost of being wrong is high, and when it is online, ask it one narrow question only.”
| Offline evaluator | Online gate | |
|---|---|---|
| Purpose | Compare versions | Block a bad answer |
| Cost of a mistake | A slightly wrong number | User sees it, or loses a good answer |
| Output | A score you track | A yes/no decision |
| Scale | Can be pairwise, can be rich | Must be binary and fast |
If they ask: do you have one in production?
“Yes, two. One sits right before we return a stored, human-approved answer and labels it ‘verified’ to the user — the judge only has to decide whether that stored answer is about the thing the user actually asked. The other one checks the execution plan against the user’s question before anything runs. Both are one narrow question, both return a verdict plus a reason, and both are logged.”
04“What are the known problems with LLM judges?”
They want to hear you know the failure modes
“Four I always watch for.”
- Position bias
In an A-vs-B comparison it favours whichever one came first. Fix: randomise the order, or run it both ways and only trust it when both agree.
- Verbosity bias
It prefers the longer answer, even when both say the same thing. Fix: say explicitly in the prompt that length is not a criterion.
- Self-preference
A model tends to prefer text written by itself or its own family. Fix: use a different model family as the judge when the stakes are high.
- Scale clustering
Ask for 1–10 and you get 7s and 8s forever — no signal. Fix: binary, or at most three levels.
“So I never treat the judge’s score as the truth. I treat it as a number I track over time — it is good at telling me ‘this got worse’, not at telling me ‘this is 8.2 out of 10’.”
05“How do you know the judge itself is correct?”
The question that separates people who have shipped one
“You validate it like any other model.
I hand-label maybe 50 to 100 examples — and I deliberately load it with the hard near-misses, not the easy ones, because that is where a judge actually fails.
Then I measure how often the judge agrees with the human label, tune the prompt against that set, and keep a held-out slice I never tuned on — otherwise I am just overfitting the prompt.
And the point I would make is: if the judge does not agree with humans, the judge is a bug, not a metric.”
If they push for detail
Which number? Plain agreement rate is fine to say out loud. If the classes are unbalanced — most answers are fine, few are bad — agreement looks great even for a useless judge, so use Cohen’s kappa instead.
Report the two errors separately. “Let a bad answer through” and “kill a good answer” cost different amounts. One number hides that.
Re-validate when anything changes — new judge model, new prompt, new domain. The labelled set is an asset; it is the thing you keep.
06“Which model do you use as the judge? Isn’t it expensive?”
Cost and latency
“Usually a smaller, cheaper model than the one generating — because judging is a much narrower task than writing. You are not asking it to be creative, you are asking it one closed question.
And I only call it when it matters. In my system the check runs only when we are about to return an answer as verified. If we already know it is a miss, we never pay for the judge at all.
So in practice it is about one extra call per request, on a cheap model.”
07“Walk me through setting one up.”
The worked example · 这一段最重要
“Say we have a RAG chatbot. We retrieved three chunks and the model wrote an answer. The thing I am most afraid of is hallucination — an answer that sounds right but is not actually in the sources.
So I would build one judge with one job: is every claim in this answer supported by the retrieved text? Not ‘is it a good answer’. Just supported, yes or no.”
What has to be in the prompt
- One job
One question per judge call. If I also want tone and completeness, that is two more judges, not three lines in one prompt. Multi-axis judges go vague, and then all the scores move together.
- A decision, not a grade
true/false. At most three levels: supported / partly / unsupported. Never 1–10. - Say what failure looks like
Be concrete, and use near-misses: a number that is not in the source, a different product model, a date that changed. Those are the cases it gets wrong — the obvious ones it already handles.
- Say what is NOT a failure
The line everyone forgets. “Do not fail it for being short, cautious, or for leaving out detail the user did not ask for.” Without this, the judge turns into a style critic and starts killing perfectly good answers.
- Close the world
“Judge only from the text I give you. You may not use anything you happen to know.” Otherwise it marks a correct-but-unsourced claim as supported — because it knows it is true — and that is exactly the hallucination you were trying to catch.
- Fixed output shape
A schema:
{"reason": "...", "supported": true}. Reason first, verdict second — it makes the model think before it commits. And keep the reason to one short clause, because you will be reading thousands of them.
The prompt itself
You are checking one thing only: is every factual claim in the
ANSWER supported by the SOURCES below?
Answer false when the answer states a number, name, date, model or
entity that does not appear in the sources, or when it is about a
neighbouring but different thing than the sources describe.
Do NOT answer false because the answer is short, cautious, or leaves
out detail the user did not ask for. Do NOT use knowledge of your
own — if it is not in the sources, it is not supported.
Return JSON: {"reason": "<one short clause>", "supported": true|false}
Two decisions that live outside the prompt
- Fail direction
If the judge errors or times out — do you let the answer through, or block it? Decide it by cost of failure. For labelling something ‘verified’ in a demo, fail open. In a bank, or for anything that is about to execute — fail closed, always.
- Log every verdict and reason
That log is the only way you will ever tune the thing. A judge with no log cannot be improved — you would be guessing.
“Then I would hand-label around 60 cases — half of them near-misses — check how often the judge agrees with me, fix the prompt, and keep 20 of them held out so I know I have not just overfitted the wording.”
→ 场景 → 六条 prompt 要点 → prompt 原文 → 失败方向 + 日志 → 怎么验证。五步讲完。
08“Pointwise or pairwise?”
A quick one — have the answer ready
“Pairwise — ‘which of these two is better’ — is more reliable, because a relative judgement is much easier than an absolute one. I use it offline when I am comparing two versions of a system.
But pointwise — ‘is this one OK, yes or no’ — is the only thing that works in production, because at runtime you only have one answer. There is nothing to compare it to.
So: pairwise offline for A/B, pointwise online as a gate.”
09“How do you monitor it once it is live?”
Closing question — end on the strong line
“Three things.
How often it blocks. If the block rate suddenly doubles, either the generator broke or the judge drifted — and I need to know which.
False-refusal rate. Good answers it wrongly killed. That is the expensive one, because that is the one users notice and stop trusting.
Re-sampling. I pull thirty verdicts a week and read them myself, to check the judge still agrees with me.
Because a judge you never re-check is just a random number generator with good manners.”