Working premise
A model-based evaluator is another model system with its own bias, variance, prompt sensitivity, and failure modes. It needs a reference set and a calibration process before its scores can gate releases.
Operational context
A model-based evaluator is a measurement system with its own prompt, model, examples, parameters, and failure modes. Agreement with a reference score is necessary but insufficient: teams also need to understand false-pass and false-fail behavior at the boundaries that influence release decisions.
Calibration starts with observable rubric criteria. Vague labels such as good or helpful encourage the evaluator to substitute its own preferences. Criteria should identify what evidence is required, which defects are material, and how partial compliance differs from failure.
The reference set should include difficult disagreements, not only obvious examples. Independent expert labels, adjudication notes, and segment-level analysis reveal where the judge is unreliable. Low-confidence or high-impact cases should remain eligible for human review.
Questions to resolve first
Which decision will rely on the evaluator and what error is more costly?
Can each rubric level be distinguished through observable evidence?
Does the calibration set represent difficult boundaries and important segments?
How will changes to the judge model or prompt be revalidated?
Recommended method
- P1
Write a rubric with observable criteria and examples for each score level.
- P2
Build a balanced calibration set that includes disagreements and difficult boundaries.
- P3
Compare evaluator outputs with independent expert labels and adjudicate material differences.
- P4
Test prompt, model, and temperature changes against the frozen calibration set.
Common failure modes
The same model family grades behavior without independent reference or challenge cases.
A strong overall correlation hides false passes in the segment that matters most.
The evaluator sees privileged evidence unavailable to the production system and rewards impossible behavior.
Control points
- Keep evaluator and application model changes independently versioned.
- Route low-confidence or high-impact cases to human review.
- Monitor agreement by segment rather than only in aggregate.
- Prevent the evaluator from using data unavailable to the production decision.
Implementation sequence
- S1
Write criteria and counterexamples with domain reviewers before selecting the judge model.
- S2
Create a frozen, balanced reference set with independent labels and adjudicated disagreements.
- S3
Measure false-pass, false-fail, agreement, and calibration by segment and severity.
- S4
Version the evaluator and rerun calibration whenever its model, prompt, rubric, or input context changes.
Measures worth reviewing
Choose metrics around the decision cost. A release gate usually needs false-pass and false-fail rates, not only correlation. Track inter-reviewer agreement as well so evaluator performance is not judged against inconsistent human labels.
Primary references
This note is an editorial synthesis of public standards, primary institutional guidance, and common engineering control patterns. It is intended to support engineering design and review. It is not a substitute for legal, security, safety, audit, or other professional advice for a specific system.