What should I check when inspecting a sample of mismatch cases?
A checklist for reviewing a sample before wider use, covering hand-solving, automated consistency checks, shortcut tests, decoys, non-fix outcomes, document realism, disclosure resemblance and grader separation.
Run these checks on a small sample before deciding whether to widen scope.
- Solve several cases by hand and compare your reasoning with the labelled root causes and expected outcomes. - Run automated checks that totals balance, links resolve and dates fall in a sensible order. - Test a trivial strategy, such as trusting the newest record, and see how often it scores well. - Confirm that decoy explanations fail on the evidence supplied, rather than on knowledge outside the case. - Check that escalate, wait and no-action cases are present and follow from the stated policy. - Read the notes, emails and procedure text for domain-appropriate wording, formats and level of detail. - Search for details that resemble a specific organisation or person, since generation does not rule this out. - Confirm the grader file is separate from the model-facing view and cannot be read by the model.
Running these checks on a small sample is a cheap way to find weaknesses before committing to a larger release.
- Audience:
- Model labs
- Content type:
- Checklist
- Buyer question:
- How to evaluate it
Content release: r-a220eb6e099b243b
Related questions
- How does path-level scoring separate two agents that both match the totals?
- How can a buyer inspect the quality of generated mismatch cases?
- What checks should I run on a pack before using it for evaluation?
- How should I score an agent that reaches the right fix for the wrong reason?
- Where do reset, trace and grading hooks fit around an agent run?
- How do we know a generated mismatch case is solvable from what the agent can see?