Before improving a prompt, decide what improvement means. An evaluation dataset links representative inputs to an observable expectation. It should contain ordinary tasks, ambiguous inputs, and failures that would matter to users.
Separate dimensions
For a knowledge assistant, track answer support, relevance, refusal on missing evidence, latency, and cost. A fast answer that cites an unrelated source fails the task. A correct answer that takes too long may also be unsuitable for the workflow.
Start with a table:
| Input | Expected behavior | Evidence | Result |
|---|---|---|---|
| How do I cancel? | Explain cancellation steps | Policy section 2 | Pending |
| What is next year’s price? | State evidence is missing | None | Pending |
| Two conflicting policies | Flag conflict | Both policy versions | Pending |
Write expectations before tuning. Keep some cases held out so you do not optimize only for familiar examples. Human review is useful for subjective answers; automated checks work well for schema validity, citation IDs, and forbidden actions.
Compare architecture changes
Run the same cases against a baseline and one changed system. Changing the model, prompt, and retriever together makes improvements difficult to explain. Report the sample size and failures alongside averages.
Exercise
Create twenty cases and propose acceptance criteria before running them. Compare two retrieval settings with the same model and prompt.
Check: preserve case-level results, document regressions, and explain whether a quality gain justifies added latency or cost. A small passing dataset is evidence for a pilot, not a guarantee of universal correctness.