Writing the Grader Prompt for a Second-Model Check

The most common failure in a first grader prompt is asking for a score without asking for evidence. A bare "rate this from 1 to 10" invites the model to hedge toward the middle. Instead, ask for three fields: a verdict, a reason, and the evidence.

The verdict should be one of a small fixed set. A binary pass and fail is the strictest and the easiest to aggregate. A three level scale (pass, borderline, fail) gives you a place to route uncertain cases without inflating the pass rate. Anything with five or more levels tends to collapse in practice because the difference between a 6 and a 7 means nothing to the model and nothing to you.

The reason should be short and should refer to the rubric, not to general impressions. "The output fails criterion 3 because it states a refund window of 60 days, while the source says 30" is useful. "The output is decent but could be clearer" is not, and it is what you get without explicit instructions.

The evidence is the part most teams skip. Require the grader to quote the specific sentence or section of the candidate output it is judging, plus the source text it is comparing against. Arize's worked example of an unsupported claim does exactly this: the judge is given the retrieved context and the response, and it returns "NO, the response contradicts the context. The policy states 30 days, not 60" (Arize). That single sentence is auditable by a human in three seconds. A score of 0.3 is not.

Here is a schema that covers all three fields and is easy to parse:

{
  "verdict": "pass | borderline | fail",
  "reason": "one sentence naming the rubric criterion that decided it",
  "evidence": {
    "output_quote": "exact sentence from the candidate output",
    "source_quote": "exact sentence from the task or reference it should match"
  },
  "unsupported_claims": ["each claim with no supporting line"]
}

Promptfoo's rubric grader uses a similar shape, returning a reason, a score from 0.0 to 1.0, and a pass boolean, and its documentation notes that you can use knowledge of that structure to give special instructions inside the rubric itself (Promptfoo). The unsupported_claims array is the field I would add on top: it turns leniency into a countable number rather than a vibe.

Leniency is systematic, not random. A grader that has been asked to judge quality without a reference tends to reward fluent, confident prose. The survey literature on LLM-as-a-judge identifies bias as an inherent property of the approach rather than a bug in a particular prompt, which is why the fix has to live in the prompt and the surrounding process (ScienceDirect).

Four rules do most of the work.

Penalize unsupported claims explicitly. Add a rubric line such as: "Any factual claim that is not supported by the task input or reference material counts against the output. Two unsupported claims is an automatic fail." That converts a soft quality judgment into a hard threshold, and it is the failure mode that matters most in retrieval and agent outputs, where an answer can sound helpful while contradicting the documentation (Arize).

Demand evidence before the verdict. If the schema puts evidence before verdict and the prompt says "if you cannot quote a specific line, the verdict is fail," the grader has to do the retrieval work before it commits. Missing evidence becomes a fail by default rather than a pass by default. This is the same principle as the confirm-and-verify step at the end of a checklist: the run is not complete until the items are checked, not assumed (Varsity Tutors).

Use a strict scale. Define each level with a concrete example rather than an adjective. A three level scale where "pass" means every criterion met and no unsupported claims, "borderline" means one criterion missed or one unsupported claim, and "fail" means two or more, is decidable. The rubric-based evaluation literature makes the same recommendation: explicit multi-dimensional criteria, calibrated against human reviewers, are what make automated grading usable at scale (Medium, Adnan Masood).

Calibrate before you trust it. Run the grader over a set of outputs a human has already labeled, including failures, and compare. Arize's guidance is to validate the judge against reviewed examples before relying on its scores, and to inspect the failures it missed (Arize). A grader that passes everything your human reviewers failed is not a grader, it is a rubber stamp.

One more source of leniency is positional. A systematic study of position bias across 15 judges and over 150,000 evaluation instances found that judges favor answers based on where they appear in the prompt, and that the effect varies significantly across judges and tasks (arXiv). For a single-output grader this rarely bites, but the moment you compare two candidate outputs, randomize their order or grade them in separate calls.

Suppose you generate 1,000 candidate answers a day and route all of them to human review at four minutes each. That is about 67 hours of review per day, which is why teams skip it and ship unchecked output instead.

Put a first grader in front of the queue. Say it passes 700, fails 250, and marks 50 borderline. Human reviewers now see the 300 non-passes, which is 20 hours of review, and you have cut the queue by 70 percent. The catch is that some of the 700 passes are wrong. On a calibration set you measure that the grader misses 8 percent of true failures, so roughly 56 bad outputs slip through per day.

That is where the tier two check earns its cost. A second grader with a different focus, factual consistency rather than task compliance, re-examines only the 700 that passed. It catches half of the 56, so 28 reach the user, and you have spent two model calls per item instead of one to remove half your remaining risk. Whether that trade is worth it depends on the cost of a bad output in your domain, not on the cost of the tokens.

Tier two is not "run the same grader again." Two identical graders share the same blind spots, and averaging them just produces a confident version of the same mistake. The second grader should have a different job, a different rubric emphasis, and ideally a different model or prompt family.

The escalation rule should be explicit and boring. If tier one says pass and tier two says pass, ship it. If both say fail, reject it. If they disagree, escalate. That is the whole rule, and it is what makes the pipeline predictable. The agent-as-a-judge literature describes this pattern as a move from single-model judges toward multi-agent frameworks where agents play different roles and provide adversarial feedback, which is closer to how a panel of human reviewers works than any single grader (arXiv).

Two implementation details matter more than the architecture diagram. First, give tier two only the evidence it needs. If tier one's verdict is in the prompt, tier two will anchor on it and agree. Second, log both verdicts and the quotes, because the disagreements are your best training data for rubric edits. The checklist automation approach from DevOps makes the same argument about process discovery: record every run, check successes into version control, and let the record itself become the specification (Deep Roots).

If the grader calls are the bottleneck, running both models through one API keeps the plumbing simple. Quanta Inference serves text, image, video, audio and embedding models through one OpenAI-compatible key, which means tier one and tier two can sit behind the same client and the same prepaid balance (Quanta Inference).

A grader prompt is code that drifts. Models change, inputs change, and the rubric slowly stops matching the failures you actually see. Schedule a monthly pass with four steps.

1. Pull 50 recent items where the graders disagreed or a human overrode the verdict.
2. Label each one by hand and note which rubric line should have decided it.
3. Edit the rubric, not the examples, unless a criterion is genuinely missing.
4. Rerun the full calibration set and compare the agree rate before and after the edit.

Test case execution guidance from software testing applies directly: a high pass rate alone does not prove the system is stable, and teams need to consider coverage, remaining risks and the untested areas alongside the number (TestRail). If your grader passes 95 percent of outputs, that is a statement about your rubric as much as your model.

Keep the rubric short enough that a new team member can read it in five minutes and predict the verdict on a sample. If they cannot, the grader cannot either. The MCC writing guide's before-and-after examples make the point that clarity comes from cutting, not adding (MCC), and a rubric that has grown to forty lines usually has ten that do the work.