What is a model grader?

The question a grader answers

You edit a prompt, run it once, read the answer, and it reads better than before. That is not evidence. The same prompt on a different input may be worse, and nothing you just did would tell you. An evaluation - an eval, in practice - is the fix: a fixed set of test cases you re-run every time the prompt changes, so "better" stops being an impression and becomes a number you can compare.

An eval has four parts, and the last one is the subject of this article:

• An input - one realistic case. A support ticket, a question, a document.
• The prompt under test - the thing you are changing.
• The output - what the model produced for that input.
• A grader - the part that looks at the output and returns a score.

Run 50 inputs through the prompt and you have 50 outputs. Nobody is going to read 50 outputs twice a day, and that is exactly the problem the grader solves: it turns one output into one score, the same way every time, so 50 outputs collapse into an average you can watch move between prompt versions.

Two words for the standard it grades against, because both come up. A golden answer is a hand-written example of a good response for that one input, and the grader compares against it. A rubric is a written description of what good means, used when there is no single right answer - which is most of the interesting work.

Three ways to grade

Only three things can do the scoring, and choosing between them is the whole design of an eval.

• A code grader. An ordinary program checks the output: does it match the golden answer exactly, does it contain the required phrase, is it valid JSON, is it under 200 words. Instant, free, and identical every time you run it. The limit is that it can only check what is mechanically checkable.
• A human grader. A person reads the output and scores it against the rubric. This works on almost any task, including every task nobody can write a rule for, and it is the most trustworthy score available. It is also slow and expensive, which caps how often you can afford to run it.
• A model grader. Another model reads the output and scores it against the rubric. It runs at roughly the speed and cost of code, on the kind of judgment that used to need the human.

So, plainly, because it is the question people arrive with: the type of grader that uses another AI model to assess the quality of outputs is the model grader, also written as model-based grading and widely called LLM-as-judge. It is the only one of the three that does the scoring with a model rather than with a program or a person.

Picking between them is not a matter of taste. Code grading wins wherever it reaches, because a rule that can check something will always be faster and steadier than a judgment call. Reach for a model grader precisely when the quality you care about is easy to describe and impossible to check: was this summary faithful to the ticket, is the tone right for a customer, did the answer use only the passages it was given. And keep a human in the loop on a sample, for the reason section 04 gets to.

What a model grader is

There is no special machinery. A model grader is a second prompt, and this is the whole of it: the standard, the output to judge, and a request for a verdict in a form your code can read.

Three details in there are doing the work, and dropping any one of them is how model graders get a bad name:

• The rubric is specific enough to agree on. "A good summary" scores more or less at random. The rubric above names what to look for and what not to forgive, so two careful readers - human or model - land in the same place.
• Reasoning comes before the verdict. Asking for the thinking first makes the model actually work through the rubric instead of guessing, and it leaves you something to read on the day a score looks wrong.
• The verdict is a tiny vocabulary. One word inside a tag, or an integer from 1 to 5. Your harness has to parse thousands of these without a human present, and a paragraph of warm praise is not a score.

A five-point scale is the other common shape, and it is what the evaluation screen in the Claude Console uses for response quality. Start with correct and incorrect anyway: a binary verdict is far easier to agree on, and an average of ones and zeros is already a percentage.

Where it misleads

A model grader is a proxy for human judgment, not a measuring instrument. It is worth knowing the four ways it bends before you build a graph on it.

• It has leanings. Judge models tend to reward longer answers, prose in a style close to their own, and whichever option came first in a side-by-side comparison. None of those track quality, and all of them move your average.
• It drifts. Change the grading model or edit the grader prompt and every score shifts underneath you. Numbers from two different graders are not comparable, so a jump in the average can just as easily mean the grader changed as the prompt did.
• It has to be calibrated before it counts. Grade 30 to 50 outputs by hand, run the model grader over the same ones, and compare. Mostly agreeing earns it the rest of the suite. Disagreeing means the rubric needs work - the fix belongs in the rubric, not in the graph.
• It costs a model call per test case. Cheap per call and not free: a 500-case suite on every commit is 500 extra calls on every commit.

The rule of thumb falls out of those: code-grade whatever you can, model-grade what code cannot reach, and keep a small hand-graded sample to hold the model grader honest. A grader you have never checked against a human is not a measurement, it is a second opinion you have decided to believe.

One thing a model grader is genuinely good at, and worth pointing out because it comes up constantly: checking whether an answer stayed inside the material it was given. That is the failure described in Why do AI models hallucinate?, and it is the property a RAG prompt is trying to buy, which makes grading it the usual first job.

Grading a chat answer is the easy case: one input, one output, one thing to read. Scoring an agent instead - twenty hidden steps, a confident summary, and a success condition that must be checked outside the model - is a harder problem with its own playbook: How to evaluate an agent.