Why demos mislead

A demo uses clean examples chosen to look good. Real workflows contain smudged scans, unusual phrasing, missing fields and edge cases you did not think of. An automation that shines in a demo can fail one case in ten in production, and without measurement you will not know which one.

Testing turns “it seems to work” into a number you can decide on.

Step 1: build a test set from real cases

  • Collect real examples from your own history: emails, invoices, tickets, forms.
  • Include the messy and rare cases, not just typical ones.
  • Have an experienced person label the correct answer for each. Where experts disagree, discuss and record the rule.
  • Aim for at least 50 to 100 examples for a narrow task, and more for varied inputs. Cover each category you expect.
  • Keep part of the set hidden from anyone tuning prompts, so you can check you have not just fitted the examples.

Step 2: pick metrics that fit the task

Task typeUseful measuresNotes
ClassificationAccuracy, precision and recall per categoryLook at the categories that matter most, not just the average
Data extractionField-level accuracy, share of records fully correctOne wrong field may invalidate the record
MatchingCorrect match rate, false match rateA wrong match can be worse than no match
Drafting textRubric scores from reviewers, edit rateDefine the rubric in advance
Question answeringCorrect answer rate, correct source cited, correct refusalsTest questions with no answer in the documents
Routing and decisionsAgreement with expert decisionsReview disagreements case by case

Step 3: weight errors by cost

Not all mistakes are equal. A misspelled company name in a summary is trivial. A wrong bank account on a payment is serious. List the types of error, estimate their consequences and set the required accuracy accordingly. For high-cost errors, require a human check regardless of confidence.

Step 4: set acceptance thresholds before you test

Decide in advance what result is good enough to proceed, for example a minimum field accuracy and a maximum rate of serious errors. Setting the bar after seeing results invites wishful thinking.

Step 5: run in shadow mode

Let the system process live work while people continue doing the real work. Compare outputs, log disagreements and review them weekly. Shadow mode shows how the system behaves on real volume and surprises you with cases your test set missed.

Step 6: roll out in stages

  • Automate the safest category or the highest-confidence cases first.
  • Keep human review on the rest.
  • Expand as accuracy stays above the threshold.
  • Keep a quick way to switch off automation if something goes wrong.

Step 7: monitor in production

  • Sample a fixed number of outputs each week for review.
  • Track overrides: how often people correct the system, and why.
  • Watch for drift when inputs change, such as a new supplier invoice format or a new product line.
  • Re-run the test set after any change to prompts, models or integrations.
  • Log inputs, outputs and versions so problems can be traced.

Be careful with AI judging AI

Some teams use one model to grade another’s output. It can help scale, but it is imperfect. Check its grades against human review on a sample before relying on it, and keep humans in the loop for important decisions.

Mistakes to avoid

  • Testing only on examples used to design the prompt.
  • Reporting an average that hides a weak category.
  • Skipping rare but costly cases.
  • Treating launch as the end of testing.

FAQ

How do I measure the accuracy of an AI workflow?

Build a test set of real examples with correct answers, run the workflow on it, and score results using measures that suit the task, such as field-level accuracy for extraction or precision and recall for classification.

How many test cases do I need?

For a narrow task, 50 to 100 examples is a reasonable start, and more is better when inputs vary a lot. Make sure every category and common edge case is represented.

What is shadow mode?

Shadow mode runs the automation alongside your current process without acting on its output. You compare its results with what people did, review the differences and decide when it is safe to go live.

How often should I re-test?

After every change to the prompt, model or integration, and regularly in production through weekly samples. Accuracy can drift when your data or the underlying model changes.

Sources and further guidance

Platform features and requirements change. Check the linked primary documentation for your implementation.

TURN INSIGHT INTO ACTION

Let’s talk about your next step.

Share your workflow, your current systems and what you want to improve. We’ll help shape a practical way forward.

Discuss your project ↗