The decision that matters
Include ordinary examples, ambiguous requests, missing information and cases where the correct response is to stop. Keep sensitive data anonymized or use carefully constructed fixtures. Separate what must be exact, such as an invoice identifier, from what allows variation, such as a friendly explanation. Define the scoring rule before looking at the model’s answer so the review does not shift to match a persuasive response.
A practical scenario
A ticket-drafting assistant might be tested on a known procedure, a contradictory document and a request outside its scope. The second case should expose how the assistant handles disagreement; the third should test escalation. A set containing only easy questions may show impressive accuracy while missing the situations that create operational risk.
Before you ship
- Include refusals and missing-data cases, not just successful answers.
- Keep a stable baseline for comparison.
- Review failures individually before reducing them to a percentage.
A useful next step
Start with a small set your team can inspect carefully. Add a regression example whenever production exposes a new failure pattern. Over time, the evaluation set becomes a record of what the system must handle, rather than a one-time benchmark assembled for launch.
Primary reference & further reading
This guide combines general engineering recommendations with an illustrative scenario. Provider behavior can change; check current documentation before applying it. Read our editorial approach.