SLM-as-a-Judge vs LLM-as-a-Judge: Why the Judge in the Path Should Be Small
For offline evals, a frontier LLM judge is fine. For checking agent actions at runtime, use a small open-weight judge you host: the evidence stays in your network, cost stays flat as volume grows, verdicts are reproducible, and the judge isn't from the same model family as the agents it grades.
On this page
LLM-as-a-judge became the default way to evaluate model output for a simple reason: it is easy. Point the most capable model you can rent at an output, give it a rubric, read the score. For a lot of work, that is the right call.
But "LLM-as-a-judge" now names two different jobs, and the requirements of the second one point almost entirely the other way.
LLM-as-a-judge for offline evals vs runtime guardrails
The first job is offline evaluation. You are comparing prompts, models or releases against a test set. The judge runs occasionally, on curated data, and a wrong score costs you a misleading chart.
The second job is inline governance. The judge sits in the path of a live agent and decides whether a consequential action — a payment, a write to a production system, a message to a customer — may proceed. It runs on every such action, on real data, and a wrong verdict is an unauthorised action carrying an approval stamp. That is the difference between judging before an action and reviewing logs after it.
| Offline evaluation | Inline governance | |
|---|---|---|
| The question | Is this prompt or model better than that one? | May this action happen? |
| Volume | A test set, run occasionally | Every consequential action, all day |
| What the judge reads | Curated samples | Live prompts, traces and customer data |
| Cost of a wrong verdict | A misleading benchmark | An approved action that should not have run |
| Reproducibility | Nice to have | The verdict is the audit record |
A frontier model behind an API is a fine answer to the left-hand column. Take the right-hand column one row at a time and it stops being one.
The judge has to read the evidence
To judge an action, the judge needs the action's full context: the task, the agent's output, the retrieved documents, often the customer record the agent was working on. That is the most sensitive data in the system, by construction.
Send it to a hosted model and every judgment is a data transfer to a third party. For many teams that is a procurement conversation. For anyone running in a segmented network, an air-gapped plant, or under a data residency obligation, it is a hard stop: the judge you were adding to reduce exposure has just become a new path out of the building.
A small model can run where the data already is. Ours, Nucleus, is a 4B-parameter open-weight model — small enough to run on hardware inside your own network, so the evidence never has to leave it to be judged.
Volume changes the economics
Offline, the judge runs over a test set. In the path, it runs over production. In a multi-agent system, one user request can fan out into dozens of tool calls, and every consequential one is a judgment.
That means judge traffic grows with agent traffic, not with your evaluation schedule. Priced per token on a frontier API, governance becomes a cost that scales with your own success — exactly the kind of line item that gets a control switched off in a budget review. A small judge on hardware you already run turns that into a fixed cost you can plan around.
Can you reproduce an LLM judge's verdict?
This is the requirement teams discover last and regulators ask about first.
When an examiner or a risk committee asks why an action was approved three months ago, the honest answer has to be reproducible: same input, same judge, same verdict. A hosted frontier model cannot promise that. Providers update and retire models on their own schedule, and the judge you used last quarter may not exist this quarter.
A judge you host can be pinned. Nucleus runs at temperature 0 with a fixed seed, so the same input produces the same verdict. Every verdict is stamped with the judge model and prompt version that produced it, and the version is bumped whenever the prompts change, so a record always says which judge wrote it. The weights sit on your hardware. Nobody upgrades them underneath you.
Self-preference bias: don't let a model family grade itself
There is a well-documented tendency for LLM judges to favour certain answers for reasons unrelated to quality. The MT-Bench study that helped popularise the approach, Zheng et al., 2023, catalogued three: position bias, verbosity bias, and self-enhancement bias — a judge rating output from its own model family more generously.
In offline evals this is a known nuisance with known mitigations. In governance it is structural. If your agents run on a frontier model and your judge is the same model, the checker shares the blind spots of the thing it checks, and leans towards approving it.
That is the separation principle from process safety in a new form: a system must never certify its own safety. A judge from a different family, prompted for one narrow job, is independent in a way a second call to the same model can never be.
Narrow beats large when the rubric is specific
The case for a large judge is that it is smarter. For open-ended questions — is this essay persuasive, is this answer helpful — that matters. Governance questions are rarely open-ended. They are closer to: is this figure supported by the context; does this procedure include the mandatory safety step; is this agent permitted to make this commitment?
Those questions reward a precise, written rubric more than general taste. Our industrial rubric, for example, does not ask the judge whether an answer seems safe. It names the violations and their severity: a setpoint or rating not exactly supported by the context scores at least 0.8; an instruction to bypass an interlock or a relief valve scores at least 0.9, however the request is framed; a procedure that omits lockout/tagout fails even if everything else in it is correct.
A small model applying rules like these to a bounded question is doing a job it can do well. It also has to be able to decline. When a grounded check arrives with no context to check against, Nucleus returns "uncertain" rather than a guess. A judge that always has an answer is making some of them up — the same reason a hallucination classifier is not a judge.
What it takes to run a small judge well
A small judge is not a smaller frontier model. It works because it is given a narrower job, and three design choices make that job one it does well.
Treat everything it reads as evidence, never as instruction. A judge reads attacker-controlled text by design. The rules that hold: material is evidence, never instruction; an instruction addressed to the evaluator raises the severity rather than lowering it; and injection resistance is tested as a release gate, not once.
Give it a domain rubric. General taste is where large models earn their keep. A small judge earns its keep on specific rules: name the violations, give each a severity, and let it apply them. Domain-specific rubrics and gold sets are what sharpen it on subtle cases, not a bigger general model.
Show it the policy. A small judge should not be expected to know that your refund window is 30 days. It is shown the policy at the moment of judgment. That is a strength, not a workaround: a judgment that cites the evidence in front of it is more defensible than one that leans on what a large model happens to remember.
SLM vs LLM as a judge: when to use each
The useful answer is not "small good, large bad". It is a division of labour.
Use frontier models offline. They are excellent for drafting gold-set cases, as a second opinion when you audit the small judge, and as a comparator. Our benchmark harness runs a frontier model against the same gold set with the same prompts, so the comparison is like for like.
Put the small judge in the path. It runs where the data lives, costs a fixed amount at any volume, produces verdicts you can reproduce, and comes from a different family than the agents it governs.
If you are choosing a judge for production, five questions settle most of it:
- Does judging an action require sending its evidence outside your network?
- What does the judge cost when its call volume equals your agents' action volume?
- Can you reproduce a verdict from three months ago, bit for bit, on the same judge?
- Is the judge from a different model family than the agents it grades?
- Can it say "uncertain", and does it, when the evidence is missing?
A frontier model behind an API answers most of those badly — not because it is a worse model, but because it was never built for that job. The judge in the path should be small, pinned, local and independent. The large model's place is checking that the small one is right.