Model-Based Evals

The questions a computed check cannot answer

Deterministic evals covers everything your code can decide: the JSON parses, the cited document is the right one, the refund amount is 40, the forbidden phrase is absent. Those run free, return the same verdict every time, and should be exhausted first.

Then there are the questions that need someone to read the answer. Is this reply polite. Does it stay faithful to the article it cites. Would a customer find it helpful. Is the tone right for our brand.

A model-based evaluation, usually called a judge, is a second model asked to make that call. It is the expensive tier: it costs a model call per case, and unlike a computed check it can be wrong.

Writing a rubric a judge can apply repeatably

The failure mode is asking for a number with nothing behind it. "Rate this reply from 1 to 10" produces a number, and nothing in the prompt makes a 6 mean the same thing twice.

OpenAI's guidance for score-model graders is to write "extremely detailed prompts" with "step-by-step instructions and many specific examples", and to establish ground-truth grades from human experts.

In practice that means three things.

Use a small scale with described anchors. Three or four points, each defined by what it looks like, beats ten undefined ones. Graders return a numeric score in a range, typically 0 to 1, which supports "partial credit for an answer, rather than a binary 0 or 1", and partial credit is only meaningful if the partial points are defined.

Put examples in the rubric. One example per anchor does more than another paragraph of description.

Ask one question at a time. A rubric that scores politeness and factual accuracy together produces a number that cannot be acted on, because you cannot tell which half moved.

Validating the judge against people, by ranking rather than score

A judge nobody has checked is a number generator. The documented check is cheaper than it sounds, because it tests ordering rather than agreement on values.

Take a handful of cases, have an expert rank the candidate answers, and confirm the judge ranks them the same way. If a human says answer_1 > answer_2 > answer_3, then you want model_grader(answer_1) > model_grader(answer_2) > model_grader(answer_3).

Ranking is the right bar because it is what you use a judge for. You rarely need to know that a reply scores 0.72. You need to know whether this week's prompt produces better replies than last week's, which is a comparison. A judge whose absolute numbers are miscalibrated but whose ordering is right still answers that question.

Stability is the second check: run several candidate responses through the judge to confirm "grading is stable and aligned with preference." A judge that returns a different verdict on the same input is not yet usable as a gate, and regression testing covers how to gate on a rate rather than a single verdict when some variance remains.

The judge's own failure modes

Three are worth testing for, and two of them are cheap to test.

Grader hacking. Documented plainly: models being evaluated "sometimes learn to exploit weaknesses" in the grader. The detection method is to compare model grader results against expert human results, and treat high model scores alongside poor human evaluations as evidence the judge is being gamed. This matters most when the judge is in a loop that is optimizing against it.

Position bias. A judge shown two answers may prefer whichever came first. Testing costs nothing: swap the order and re-score. If the winner changes, the position is doing work the content should be doing.

Verbosity bias. Longer answers often score higher regardless of quality. Test by scoring a concise correct answer against a padded one that says the same thing.

Position and verbosity effects are widely reported rather than quantified here, and their size depends on your rubric and your judge model, which is why the tests above are worth running on your own setup rather than taking a number from anyone's paper.

What changes when the judge model changes

A judge is a model call, so it carries every property pre-trained models describes, including a retirement date.

When the judge changes, your historical scores stop being comparable. A drop of four points across the board after a judge upgrade is not a quality regression, and telling the two apart afterwards is difficult.

Two habits make it survivable. Record which judge model produced every score, so a shift can be attributed. And keep a small set of cases with human labels, so you can re-validate a new judge against the same ordering rather than trusting that it behaves like the old one.

Further reading

• OpenAI, Graders: the grader types, rubric guidance, the ranking validation, and grader hacking.
• Deterministic evals: everything to exhaust before reaching for a judge.
• LLM evaluations: the tiers this one sits in.
• Context evaluation: judging retrieval rather than the answer.