Evaluate AI Output Before You Depend on It

Elena's revised prompt sounds better. The answers are shorter, friendlier, and easier to read. In a small comparison, it also answers more questions correctly.

Then one draft guarantees an appointment the business has not confirmed.

Should the team accept the improved average, reject the new prompt, or investigate further? They need a clear definition of success before the results arrive.

Mesa Equipment Service, its evaluation cases, and all scores below are fictional teaching examples. No model performance is being reported.

Your result from this chapter: an evaluation plan with clear criteria, representative cases, traceable scores, and a decision rule.

Define success at the level of the task

An evaluation, often shortened to eval, is a structured check of whether a system meets a stated requirement. A public benchmark can tell you something about performance on its particular tasks. It does not determine whether your customer-service workflow is ready to use.

For Mesa, success means the draft answers the question from the current policy, keeps conditions intact, avoids unauthorized commitments, and requires a manageable amount of review.

Start with an objective, a set of cases, measures, and a plan to repeat the check as the workflow changes. OpenAI's evaluation guidance describes that general pattern. The method can be carried out in a spreadsheet or another maintained tool; it does not require the provider's hosted evaluation platform. Evaluation best practices.

Write a rubric people can apply consistently

A rubric turns “good” into observable checks. Use separate dimensions so a pleasant tone cannot hide a false promise.

Define a critical failure separately. For this pilot, an unauthorized booking promise or disclosure of restricted information is critical. A minor wording preference is not.

Agree how a case passes overall. For example, the owner may require all factual, evidence, and boundary checks to pass, while allowing light copy editing. Record that rule before scoring the candidates.

Include ordinary work and difficult cases

A test set should reflect what the workflow will face and include cases designed to expose important failure modes.

For Mesa, include ordinary fee questions, questions with missing information, policy conflicts, and messages that try to override instructions. Keep categories visible in the results.

Fictional cases are useful for early development and precise edge conditions. Appropriately approved real cases can reveal vocabulary, ambiguity, and task combinations you did not anticipate. Neither source alone guarantees representative coverage.

Remove unnecessary personal information and follow the data rules from Part 1. Where rights, consent, or access limits apply, resolve them before using records in testing.

Keep some cases out of prompt development. If you use a held-back result to revise the prompt, it has now influenced development. Set aside new cases for the next independent check.

Score what the system produced, then score the finished work

Record the original output before a reviewer edits it. Otherwise the evaluation may measure the reviewer's skill while hiding the assistant's mistakes.

Then record corrections, review time, the final answer, and any problem discovered later. These answer different questions:

• How often does the assistant produce an acceptable draft?
• How much work is needed to make the result usable?
• How often does the combined human-and-tool process let an error reach the customer?

A workflow can be useful with imperfect drafts if review is reliable and affordable. It can also be costly despite excellent-looking final replies if the reviewer must repair most of them.

Use automatic checks for what they can actually establish

Programs can check whether JSON parses, required fields exist, arithmetic matches stated rules, source IDs belong to an allowed set, or a phrase appears where it should not.

These checks are useful but narrow. A source ID can be valid while supporting the wrong claim. A calculation can be arithmetically correct while using the wrong population or units. A forbidden-word check can miss an unauthorized promise phrased differently.

Use automatic checks to catch well-defined defects, and use evidence-aware review for meaning. The Part 2 practice verification script checks fixture arithmetic and consistency. It does not test a language model or establish the quality of a deployed workflow.

Use AI-assisted grading carefully

Another model can help flag possible omissions, compare drafts against a rubric, or organize review notes. Treat its judgment as something to evaluate too.

Try it on cases a knowledgeable person has already scored, including plausible wrong answers and awkward but correct answers. Check whether it rewards confident style, verbosity, or the order in which alternatives are presented.

If comparing two outputs, hide their product labels where practical and vary their presentation order. Ask the grader to point to the output and evidence behind each proposed finding. Do not accept an unsupported score merely because it is expressed to several decimal places.

For consequential decisions, retain an appropriate human review process. A model's approval of another model's answer is not independent verification of the underlying business facts.

Examine an illustrative comparison

Suppose Mesa evaluates two prompts on the same 20 cases under a defined rubric:

Prompt A passes 16 of 20 cases, or 80%. Prompt B passes 18 of 20, or 90%. In this invented example, B's failed adversarial case contains an unauthorized booking promise, while A has no critical failure in the sample.

The higher overall pass rate does not resolve that critical failure. If the agreed release condition excludes unresolved critical failures, B does not meet it. A may also need improvement if its ordinary-case results fall below the quality requirement. The appropriate result may be to revise both rather than declare a winner.

This is a deliberately constructed teaching example. It is not evidence that one prompting style is safer or more accurate in general.

Count failure modes with the right denominator

Suppose a separate escalation exercise contains 30 cases. Ten truly require escalation under the approved rubric. The assistant flags eight cases, seven of which really require escalation.

Correct escalations: 7
Unnecessary escalations: 1
Missed escalations: 3

Precision = correct escalations / all flagged cases = 7 / 8 = 87.5%
Recall = correct escalations / all cases requiring escalation = 7 / 10 = 70%

Precision asks how often a flag is warranted. Recall asks how many of the cases needing a flag were caught. A high precision figure can coexist with too many missed cases.

The remaining 19 cases were correctly not escalated. The numbers describe this fictional set only. Whether a missed escalation is acceptable depends on its consequences, not solely on a percentage.

If a denominator is zero, report the measure as undefined for that set instead of substituting a flattering value. Preserve the underlying counts.

Compare quality, time, and cost together

Measure total staff effort from input preparation through acceptance and recording. Include rejected outputs, manual fallback, and maintenance. Separate elapsed waiting time from active staff effort when people can do other work during generation.

For cost per accepted output, choose a consistent period and define the costs included. A subscription, per-use charges, reviewer time, and setup effort may need different treatment depending on whether you are reporting cash expenditure, staff capacity, or total economic cost.

Do not count only successful attempts in the cost numerator while excluding the resources spent on failures. Do not call released salaried time a cash saving unless an expense actually falls or a separately verified financial benefit occurs.

Quality remains visible alongside these measures. A cheap answer that creates complaints may be expensive to the business.

Be honest about small samples and changing conditions

Twenty successful cases do not prove a system will never fail. A test set can miss rare conditions, unfamiliar language, new documents, and changes in the tool itself.

Report the sample size, selection method, case categories, configuration, date, and known gaps. Repeat relevant cases when variation matters. Broaden evaluation when the intended use becomes more consequential or less similar to the original sample.

Avoid borrowing a benchmark's impressive score without its task definition, version, and test conditions. Your business needs evidence about its own work.

Make the result lead to a decision

Record whether the workflow is approved for its limited scope, needs revision, or should stop. Name the remaining failures and the evidence required to resolve them.

Keep the cases and rubric available for regression checks: rerunning known checks after a change to see whether something that worked has broken. Add genuinely new cases from observed use while preserving a clear distinction between development and independent evaluation.

Recheck when source policies, permissions, task types, prompts, models, or connected tools change. Decide who investigates a failed check and how the business falls back to its manual process.

Your next step: complete the evaluation plan and score the practice answers. Then move into Part 3, Operations, to apply these habits to email, meetings, procedures, documents, and internal knowledge.