Test AI extraction against documents with known answers
Build a reviewed document test set with explicit match rules and critical-field checks. Measure corrections before using AI extraction in business work.
Test AI document extraction against documents whose answers a reviewer has already established. Compare the fields needed for the next business step, including missing values and unreadable source material. A plausible-looking output is not evidence that the extracted customer, quantity, unit or date is correct.
Define the workflow before choosing a pass threshold. Extracting text for an internal search has different consequences from preparing a purchase order or a customer charge. The same overall match rate can hide very different business risks.
NIST's voluntary AI Risk Management Framework supports considering trustworthiness during AI design, use and evaluation. The evaluation sheet below is an original practical method, not a NIST certification or a validated accuracy standard. NIST AI Risk Management Framework.
Create a reviewed answer set
Select permitted documents that represent the intended task. Include ordinary examples and the difficult conditions the team actually encounters: revised documents, poor scans, missing fields, several addresses or conflicting units.
For each document, have a reviewer identify the expected answer and its source location. A second person should resolve ambiguous answers before the document becomes a reference. If people cannot agree on what the source establishes, the test should mark that uncertainty rather than pretend a single answer is known.
The AI data permission guide helps define which documents may enter the test environment. Preserve access boundaries when saving reference answers and model outputs.
Define what counts as a match
Write comparison rules before running the test. Decide whether surrounding whitespace, capitalization or a harmless date format can be normalized. Preserve distinctions that affect the business, including units, currency, negative values, identifiers and the difference between blank and zero.
| Evaluation field | What to record |
|---|---|
| Document and revision | Exact source used for the run |
| Target field | The fact required by the next step |
| Expected answer | Reviewed value or an explicit missing/uncertain state |
| Source location | Page, row, label or other reproducible reference |
| Comparison rule | Exact match or a defined normalization |
| Observed output | Original extracted value, kept unchanged |
| Error category | Wrong value, wrong field, omitted value or unsupported value |
| Consequence | Whether the error stops the next business action |
Do not improve the observed output before measuring it. Record the correction separately so the review work remains visible.
Measure critical fields separately
In an illustrative test, 96 of 100 eligible field checks match the reviewed answers after the agreed normalization. The field-match rate is 96 ÷ 100 = 96%. That number alone says little about whether the workflow is ready.
Suppose two errors concern descriptive capitalization while two put the wrong quantity on a proposed order. The aggregate rate treats them equally, but the business should not. Report the critical-field failures and affected documents separately. The 96% example is not a recommended acceptance threshold.
Define the denominator carefully. If the task requires a field and the source supplies it, an empty output is a failed check, not a reason to remove the field from the test. If the source does not supply it, the expected behavior may be an explicit missing state. Inventing a value in that case is a different failure that also deserves its own count.
Keep a test set aside
Use one group of documents to improve prompts or extraction rules and another reviewed group to check the resulting version. Repeatedly tuning against the same examples can make those examples look good without showing how new documents will behave.
A small test set cannot establish performance across every supplier, form or scan quality. State what was included and which document types remain untested. Add a new type deliberately, review its reference answers and test it before expanding the live workflow to that population.
For estimating documents, the quantity-versus-scope guide explains another boundary: extracting a correct dimension does not approve the work or the allowance derived from it.
Judge the complete review step
Measure time spent checking sources, correcting fields and resolving exceptions, not just extraction time. Use the AI pilot measurement method to compare the full task with a real baseline.
Write acceptance conditions by field and consequence. Some outputs may remain useful as drafts with mandatory review; others may be unsuitable for the next action until a recurring error is corrected. Keep uncertain cases in a visible queue with an owner.
The decision record should identify the tested model or tool version, document population, comparison rules, observed errors and permitted next use. Rerun the affected checks when the model, prompt, document format or downstream action changes. That gives the team evidence for a bounded extraction task instead of a broad claim that the AI “reads documents accurately.”