How do you approach AI model testing on messy real data?

01Why messy data breaks AI that looked fine in the demo

Demos use tidy inputs. Production does not. Think of a pitch deck with financials in a screenshot, a contract half in English and half in another language, or a product title that says "2015 and up" instead of a model year. These are normal in established products, and they are where AI quietly fails. This is part of our larger guide, LLMOps for SaaS: keep AI features working in production.

Two things make this worse in brownfield work. First, the AI output has to land in an existing system, with existing fields and rules, so a wrong extraction is not just a bad answer. It is a bad record. Second, real customer data is often the last thing to arrive. Legal reviews, access approvals and privacy concerns all slow it down. If testing waits for that data, the team builds for weeks on assumptions.

Google's long-standing guidance on production machine learning makes a related point. The gap between how a model behaves in training and how it behaves on live data is one of the main sources of failure. You should test on data that looks like what the system will actually see.

02Build the messy test set yourself

We create test inputs early and on purpose. The goal is to cover the shapes of mess the real data will have, before the real data exists.

1. 01

   List the input types.

   PDFs, slide decks, spreadsheets, scanned images, short videos, scraped web pages, database rows. Each one fails differently.

2. 02

   List the known kinds of mess.

   Long documents, inconsistent layouts, missing sections, multiple languages, numbers in images, free-text fields with no fixed format.

3. 03

   Write dummy documents that combine them.

   A deck with financials split across slides. A bilingual memo. A response from an issuer or user that answers only half the questions.

4. 04

   Write the expected output for each.

   What should land in each field? What should be left empty or flagged? This is your reference.

5. 05

   Include negative cases.

   Inputs the AI should refuse, flag or hand to a person. A test set with only answerable inputs teaches you nothing about failure.

6. 06

   Run every case on every change.

   Prompt edits, model upgrades and new parsers all go through the same set.

7. 07

   Add real cases as they arrive.

   When client data comes in, every surprise becomes a new test case. The synthetic set does not go away; it grows.

03What to measure in AI model testing

Accuracy alone hides most of the problems. These are the checks we use for extraction and matching work.

The last row matters most in regulated or high-stakes products. Storing the AI-generated version next to the human-entered one, and showing both, turns every real record into a test case without risking the record itself.

04Trade-offs to plan for

Synthetic data is not proof. Dummy documents tell you the system handles the shapes of mess you imagined. They do not tell you about the ones you did not. Treat them as a floor, not a ceiling.

Reference outputs take expert time. Someone who knows the domain has to say what the correct extraction is. Budget for it. It is usually the most valuable hour in the project.

Rules versus models. For some matching problems, text similarity and rules beat a generative model, because they are predictable and cheap to test. Choose the method by testing both against the same messy set.

Data refresh. If the source data changes daily, the test set needs refreshed samples too, or it will drift away from reality.

For more on evaluating agents before they reach users, see why AI agents fail in production.

05What we see in production

For an established, regulated private investment platform, we built AI agents that read pitch decks, memos and financials and turn them into structured deal records. Deal documents are long, inconsistent and sometimes bilingual, and the extracted data had to land in the right database fields without conflicts. Waiting for real client documents would have delayed any honest testing, so we wrote dummy decks, dummy issuer responses and complex bilingual documents to test extraction early, alongside the requirement and testing documents.

The issuer agent parses a deck into a structured deal template in about 30 seconds. We stored the AI-generated deal next to the human-entered one and showed them side by side, with a pre-publish gate that needs human confirmation, so differences surfaced as review items rather than as published errors.

For a multi-tenant AI sales assistant built for a retail and point of sale sales services company, one assistant had to combine uploaded documents, CSV files and live database rows in a single answer. It also had to return product comparisons in a form a sales widget can show. Our business analyst evaluated every deployment against the user stories before release, and negative scenario queries, the questions the assistant should not answer, were tested and tracked as bugs. That habit catches the failures that a test set of only good questions misses.

Earlier, for an automotive industry executive building an accessory recommendation plugin for dealer websites, the mess was in free text. Vehicle titles on dealer sites and compatibility text on accessory sites, such as a model name followed by "2015 and up", rarely matched exactly, so a plain lookup failed. We separated collection from matching: daily scrapers pulled accessories and compatibility lists into a normalized database, and a text matching algorithm mapped each vehicle title to compatible accessories from the same manufacturer. No generative model was involved. Testing the matcher against those inconsistent titles was the core of the work, because that is where every real-world failure would have come from.

Because the fitment matcher relied on rules and text similarity rather than a model, a person could check every match it made. Every per site crawler returned the same fields into one catalog, so matching never depended on how a single site was built.

06A short checklist for your next AI test plan

• Synthetic messy inputs exist before real data arrives.
• Every input type and every known kind of mess has at least one case.
• Each case has a reference output written by someone who knows the domain.
• Negative cases are part of the set, not an afterthought.
• The set runs on every prompt, parser or model change.
• AI output and human entry are compared side by side once real data flows.
• Every production surprise becomes a new test case.

Frequently asked questions