Skip to content
Devinity Solutions

How to evaluate an AI system before you ship it

Most AI pilots stall because nobody defined what a correct answer looks like. Here is the evaluation process we run before any AI system goes into production.
Haider Ali

Chief Technology Officer

4 min read

An AI system is ready for production when you can state its accuracy as a number, measured on data it has not seen, against a definition of correctness you agreed before building it. If you cannot do that, you do not have a system — you have a demo that has not failed yet.

This is the process we run on every AI engagement, in the order we run it.

Define correct before you build anything

The first question is not which model to use. It is: what does a right answer look like?

For document extraction, that means agreeing every field, its format, and what should happen when a field is genuinely absent from the document. For classification, it means the label set and what belongs in each. For a system that drafts text, it means the properties a good draft has — because "good" is not a specification.

This conversation is uncomfortable, which is why it gets skipped. Two people in a room will frequently disagree about the correct answer for a specific example, and discovering that after six weeks of building is considerably more expensive than discovering it on day one.

Build the evaluation set

An evaluation set is a collection of real inputs with agreed correct outputs. Ours are typically 100 to 300 examples, drawn from the client's own data.

Three rules matter:

  1. Use real inputs. Synthetic examples are cleaner than reality and will tell you the system works when it does not.
  2. Include the hard cases. The malformed documents, the ambiguous ones, the edge cases someone in operations knows about. If your evaluation set only contains easy examples, your accuracy number is measuring the wrong thing.
  3. Hold some back. A portion the system is never tuned against, so you can tell whether you improved the system or fitted it to the test.

Measure the simplest approach first

Before any model work, measure the baseline. Sometimes the baseline is a regular expression. Sometimes it is the existing manual process, which has an error rate nobody has ever calculated.

This step regularly saves clients a great deal of money. If a rules-based approach reaches 94% and the AI approach reaches 96% at forty times the running cost, that is a decision the client should get to make with the numbers in front of them.

Score every change

Once an evaluation set exists, every change to the system is scored against it. This turns arguments about whether a change helped into a measurement.

It also catches the failure mode where fixing one category of error introduces another. Without a scored evaluation set, that trade is invisible, and systems drift sideways for weeks while feeling like progress.

Decide where a person stays in the loop

No system is right every time. The design question is what happens when it is wrong.

For each output, we set a confidence threshold with the client. Below it, the system routes to a person rather than proceeding. Where the cost of a wrong answer is high — a financial figure, a clinical note, a legal term — the threshold is set conservatively and the review interface gets as much design attention as the model.

A system that says "I am not sure about this one" is more useful in production than one that is confidently wrong 4% of the time.

Monitor after release

Model providers change behavior. Prompts that worked in March behave differently in September, and nobody sends you a notice.

So accuracy, latency and cost per request are tracked in production, with a periodic re-run of the evaluation set against live traffic. You should learn that a system has degraded from a dashboard, not from a customer.

What this looks like in practice

Our own FleetChart product reads freight rate confirmations from brokers, each formatted differently, and extracts rate, lane, dates and accessorial terms. Broker format variation is exactly what defeats rules-based parsing, which is why AI is the right tool. It is also why the evaluation set has to include the ugly documents, not the tidy ones.

The discipline is not glamorous, and it is most of what separates AI systems that reach production from AI systems that stay in a pilot forever.

  • evaluation
  • llm
  • production
  • accuracy

Tell us what you are trying to build.

A thirty-minute call is usually enough to tell you whether we are the right firm for it. If we are not, we will say so and point you somewhere better.

Or reach us directly: [email protected] · +1 321 335 0265