OpenAI evaluation best practices
Current guidance on building repeatable evaluations, including the transition away from the legacy Evals platform.
Compute College
Track prompt changes, test representative cases, and detect quality or workload regressions before release.
Prompt versioning gives each instruction set an identifier, change history, owner, and test result. Regression testing runs a fixed or refreshed set of representative cases against a new prompt, model, or setting and compares quality, safety, latency, tokens, and cost. It turns prompt editing from an informal copy change into an observable release.
Memory trick: A prompt is code when it changes production behavior. Version it, test it, and keep a rollback.
Models, provider defaults, user distributions, and surrounding context change over time. A prompt that improves one example can degrade an edge case or increase output length across millions of requests. Version history and regression tests make the tradeoff visible and provide evidence for release, rollback, or a targeted follow-up.
Version `support-triage-12` adds a requirement to quote evidence. On a 50-case test set, first-attempt acceptance rises from 82% to 88%, but average input tokens rise 18% and output tokens rise 7%. The team can decide whether the accepted-result improvement justifies the recurring cost, then release behind a small traffic slice.
Example figures are illustrative calculations, not current quoted market prices.
Current example
OpenAI’s evaluation documentation describes repeatable evaluation workflows for testing model behavior. Prompt regression tests can use the same discipline while adding prompt IDs, workload metrics, and release decisions appropriate to the application.
Current guidance on building repeatable evaluations, including the transition away from the legacy Evals platform.
Source discipline: the reference explains the concept or method; it is not a substitute for measuring a production workload under its actual provider, model, and data conditions.
Keeping only the latest prompt erases the evidence needed to explain a change. Without a version ID and prior results, a team cannot tell whether behavior changed because of instructions, model updates, data drift, or evaluation noise.
Practical takeaway
Create a small prompt release record with an ID, owner, date, change summary, test set, model settings, quality results, workload metrics, and rollback target. Start with ten representative cases, then expand the set around every failure discovered in production.
Decision check: can the team reproduce the comparison and roll back to the previous known-good prompt without guessing which text changed?
Compute College track
Step 8 of 18: Prompt versioning and regression testing