Write your evals first. An eval set of real inputs with expected outputs gives you a baseline, tells you whether prompting is already good enough, and lets you prove that a fine-tuned model is actually better. Without it, you are guessing.
Why first
OpenAI's model optimization guide frames the work as a loop of evals, prompt engineering and fine-tuning. It notes that LLM output is non-deterministic and that model behaviour changes between snapshots and families, so you need ongoing measurement. It even suggests you might write evals before you start writing prompts, like behaviour driven development.
Build the set
- Collect real inputs. Pull 100 to 300 from production logs or realistic samples. Invented inputs flatter the model.
- Write expected outputs or criteria. For classification, the label. For free text, a short list of must-have and must-not-have points.
- Include hard cases. Ambiguous inputs, typos, long inputs, and cases where the right answer is to decline.
- Freeze it. Never train on these examples and never edit them to make a run pass.
Pick a scoring method
- Exact match for labels and structured output.
- Schema checks for JSON validity and field types.
- Rules for forbidden words or required citations.
- Model graded for open text. The QLoRA paper presents GPT-4 based evaluation as a cheap and reasonable alternative to human evaluation, but a judge model has biases. Spot check its scores against a human on a sample.
- Human review for the final decision on anything high stakes.
Run the baseline
Score your best current prompt. Record the model version, the prompt text and the date. Then change one thing at a time: a clearer instruction, more examples, retrieval, a different model, finally a fine-tune. Rerun the same set after each change.
Avoid the usual traps
- Contamination. Eval examples leaking into training data inflate scores. Deduplicate across splits.
- Overfitting to the eval. If you iterate against it many times, it stops being independent. Keep a second hidden set for the final check.
- Averages hiding failures. Report results by category as well as overall.
- Drift. Rerun when the provider changes the model version.
Decide with it
If the best prompt already meets your bar, stop. If the failures are about format or tone, a fine-tune may help, see when to fine-tune or just prompt. If the failures are missing knowledge, add retrieval.
Compare cost as well as quality: tokens, latency and upkeep.
Quick check
How big should an eval set be?
Start with 100 to 300 real examples. That is a working rule of thumb, not a standard. Grow it as you find new failure types.
Can I use a model to grade a model?
Yes, with care. Check its grades against human judgement on a sample, and watch for bias toward longer answers.
Sources
- OpenAI model optimization guide, fetched 19 October 2026.
- QLoRA: Efficient Finetuning of Quantized LLMs, fetched 19 October 2026.
Last reviewed: 19 October 2026.