OpenAI Evaluate AI Applications

A test set shows only what you put in it. You draw cases from real traffic and real users, add the awkward and rare ones, and label them so the set reflects how the application is truly used.

• Sampling real inputs from logs or users
• Covering common, rare and adversarial cases
• Writing expected answers or criteria
• Labeling cases and agreeing on the labels
• Keeping the set separate from prompt tuning
• Growing the set as usage changes

You build A labeled test set drawn from real inputs to your application.

Each task needs a way to score it. You choose between exact checks, rubrics and model-based graders, and test those graders against human judgment before you trust their scores.

• Exact-match and schema checks
• Writing a rubric that graders agree on
• Using a model as a grader
• Calibrating a grader against human labels
• Scoring several qualities separately
• Knowing when a person must grade

You build A grading setup, checked against human labels, for one test set.

A failed case is a clue. You group failures, trace each to the stage that caused it, whether instructions, retrieved context, a tool call or the model, and fix the cause rather than the symptom.

• Reading traces from input to output
• Grouping failures into patterns
• Telling prompt, retrieval, tool and model failures apart
• Reproducing a failure on demand
• Fixing causes, not single examples
• Confirming a fix helps without harming other cases

You build A failure analysis that links groups of failed cases to causes and fixes.

Prompts, models and tools change, and quality can slip without notice. You run evaluations on every change, set thresholds that block a release, and compare each result with the previous version.

• Running evaluations on every change
• Versioning prompts, models and settings
• Setting score thresholds that block a release
• Comparing against a baseline
• Handling noise and run-to-run variance
• Adding real incidents as new test cases

You build An automated evaluation run that compares each change with a baseline.

Results must lead to a decision. You report scores with their uncertainty, say what changed since the last check, and state plainly whether the application meets its goal and what remains weak.

• Reading scores with sample size in mind
• Reporting results by category, not one average
• Showing what changed since the last run
• Stating confidence and known gaps
• Deciding whether to ship, fix or stop

You build An evaluation report that ends in a clear ship, fix or stop recommendation.