AI evaluation datasets
Write the expected behaviour before tuning the prompt
Start each evaluation case with a clear decision about success. This prevents the current model's answer from quietly becoming the standard it is judged against.
In this article
Choose one task and its evidence
Take a support question about whether a particular purchase needs approval. Use a synthetic policy with a spending rule and an exception. Record the policy version so later edits do not silently change the expected answer.
Write the required behaviour before running the candidate. The answer must mention the exception, avoid claiming blanket permission and identify the relevant evidence. If the information is incomplete, the expected behaviour may be a clarification rather than a guessed answer.
Have someone familiar with the task review the expectation. A technically convenient assertion can still encode the wrong business rule.
Use fields that explain the case
Give the fixture an identifier, task category, input, source references and explicit assertions. Keep a short rationale explaining why the case matters. This helps a future maintainer distinguish a deliberate edge case from an accidental oddity.
{
"caseId": "purchase-restricted-item",
"task": "policy-answer",
"sourceVersion": "fixture-policy-v3",
"question": "Does a low-cost restricted item need approval?",
"mustInclude": ["Restricted items require approval regardless of the usual threshold"],
"mustNotClaim": ["Low cost removes the approval requirement"],
"reason": "The exception changes the action the requester should take"
}These fields are an example application contract. The test runner still needs an appropriate way to assess meaning. Exact matching may work for identifiers and numeric fields, while prose claims may need reviewed rules or a calibrated evaluator.
Capture intermediate evidence
Save the retrieved passages, proposed tool calls and application decisions needed to locate a failure. If the answer misses the exception, the trace should show whether the exception was retrieved at all.
Keep model configuration, prompt version and source snapshot with the run. Avoid placing sensitive raw material in unrestricted test output. Synthetic fixtures make many mechanism tests easier to share safely.
Distinguish harness errors from product failures. A missing source file or evaluator timeout should not be counted as an incorrect answer without explanation.
Establish a baseline before changing behaviour
Run the current system and inspect failures manually. Correct invalid fixtures and unclear expectations, but do not rewrite valid expectations merely to match the current answer.
Then compare a candidate on the same cases. Review changed outcomes, including newly refused tasks and correct answers that became incomplete. Once the fixture has influenced prompt tuning, keep it as a regression test and use additional held-out cases to assess unfamiliar work. This preserves the difference between fixing known failures and demonstrating broader improvement.
Primary sources
Microsoft Learn: retrieval and answer evaluatorsMicrosoft Learn: evaluation and observabilityReferences checked 11 September 2026.