How to reduce hallucinations in LLM document extraction
A hallucination in LLM document extraction is a value the model returns that does not appear in the document: an invented invoice total, a date lifted from the wrong field, a supplier name completed from the model's memory instead of the page. In an extraction pipeline this is worse than a missing value. A missing value gets flagged. A hallucinated one gets paid.
Hallucinations in this context tend to fall into a few recognizable patterns:
- Fabrication — a value with no basis anywhere in the document (an invented total).
- Misattribution — a real value from the document, pulled onto the wrong field or row (a date lifted from an unrelated field).
- Memory completion — a plausible value the model already "knows" from training, substituted for what the page actually says (a supplier name filled in instead of read off the page).
- Format hallucination — an invented value shaped closely enough like a real one (a well-formed date, a valid-looking ID) to pass a casual review.
The seven techniques below reduce how often that happens. The more important shift is conceptual, so it goes first: you cannot bring hallucinations to zero, but you can make every one of them detectable, and a detectable hallucination is a review task with a cost, no longer a risk you carry blind. That principle separates production extraction systems from demos.
| Technique | What it catches | What it does not catch |
|---|---|---|
| 1. Grounding | Values with no location in the document | A wrong value that does exist elsewhere on the page |
| 2. Calibrated confidence | Uncertain extractions, flagged for review | Confident errors (these need 6) |
| 3. Schema constraints | Wrong types and shapes (prose in a date field) | Plausible values of the right type |
| 4. Layout-aware parsing | Errors caused by scrambled reading order and broken tables | Errors in clean text |
| 5. Threshold routing | Turns 2 into an operating decision | Nothing by itself; it is the control loop |
| 6. Deterministic validation | Confident errors that break arithmetic or checksums | Errors in free-text fields |
| 7. Continuous measurement | Drift after model or prompt changes | Nothing in real time; it is the feedback loop |
1. Ground every extracted value in the source document
Grounding means every extracted field carries a pointer to the exact place in the document where the value was read: page, text span and, where the system supports it, the region on the page. If a value cannot be traced to the page, it should not survive the pipeline. Grounding turns "trust the model" into "click and check": a reviewer verifies a flagged invoice total in seconds because the extraction shows where it came from.
In anyformat, every extracted field is returned with its evidence in the same API response: the source text and the page number it was read from. In the review interface the evidence is highlighted on the page itself, so the person checking a field sees the location, not just the text. It also works in reverse: clicking a value on the page surfaces the field it was extracted into, so a reviewer can start from either the extraction or the document and land on the same place.
2. Use calibrated confidence scores, not raw model confidence
A confidence score is the number an extraction system attaches to a value to say how sure it is that the value is correct; it is calibrated when that number matches empirical accuracy, so a field scored 95 is correct 95% of the time, measured on real documents. Raw token probabilities from an LLM are not calibrated, and they tend to be highest exactly where the model is filling a gap. Calibration means evaluating the extraction system against ground truth on a large document set and adjusting the scores until they mean what they say.
anyformat's per-field confidence is calibrated: the score is derived from the extraction model's token probabilities and fitted against ground truth (Platt scaling), so a 90 means the same thing on a supplier invoice as on a bank statement.
Confidence is measured at each stage separately, not just once at the end: parsing has its own score for how well the document's structure and text were read, extraction has its own per-field score, and a document-level rollup summarizes both. That separation is what lets you tell whether a bad result came from a parsing problem or an extraction problem, instead of one opaque number covering the whole pipeline.
Two things this page does not claim: that calibration is unique to anyformat, and that any vendor's calibration is proven by the word alone. The evidence for a calibration claim is a published evaluation, which is what the number above is for.
3. Constrain extraction with an explicit schema
Schema-constrained extraction forces the model to return values of a declared type and shape: a date field cannot return prose, a currency field cannot return a sentence. A field typed as a date either returns a valid date like 2026-03-15, or nothing: it cannot return "sometime in March", or a stray "xxx" the model produced when the page was unclear. Free-form extraction invites the model to write. A schema forces it to read. Zero-shot schema definition means the same schema works on layouts the system has never seen, without training a template per supplier. Schemas do not stop a plausible wrong value of the right type; that is what techniques 2 and 6 are for.
4. Parse the layout before extracting: reading order is a hallucination source
Many extraction hallucinations are parsing failures wearing a different name: merged table cells, multi-column reading order, headers attached to the wrong section. If the parser feeds the model scrambled text, the model fills the gaps by inventing. Layout-aware parsing (tables reconstructed as tables, reading order preserved, page structure explicit) removes the ambiguity the model would otherwise hallucinate into. The effect is largest on complex tables and on long documents, where context degradation compounds with every page.
anyformat publishes its parsing quality: a Parse Score of 78.1% on a set of more than 1,000 real documents, ahead of Gemini 3.5 Flash (77.9%) and GPT-5.6 (74.2%) on the same table. On ParseBench, LlamaIndex's independent benchmark of about 2,000 human-verified pages, anyformat scores 80.83, ranking 4th of the 35 engines evaluated.
5. Route by confidence threshold: automate the confident, review the uncertain
Threshold routing sends every extraction above a calibrated confidence threshold straight through, and everything below it to a person. This is the operational payoff of calibration: because the score is trustworthy, the threshold becomes a business dial. Tighten it for payments, loosen it for archiving. In anyformat the threshold is set per workflow and the review queue shows the reviewer each uncertain field next to its evidence on the page.
Try it on your own documents: the free tier gives 50,000 credits with no credit card, enough to run a real sample through a workflow with confidence thresholds on. Start free.
6. Validate across fields with deterministic rules
LLMs should not be the last line of defence. Deterministic validation catches hallucinations that look confident: line items must sum to the invoice total, tax identifiers must pass checksum validation (a Spanish NIF has a verifiable control character), dates must fall in plausible ranges, currencies must match the supplier's country. A hallucinated value that passes the model's own confidence check rarely survives arithmetic.
7. Measure your hallucination rate on your own documents, continuously
A vendor's benchmark tells you how the system performs on the vendor's documents. Your hallucination rate on your documents is the only number that matters. Hold out a labelled evaluation set, re-run it on every model or prompt change, and track three metrics separately: field accuracy, hallucination rate (a wrong value returned confidently) and abstention rate (the system correctly says "not found"). A system that never abstains is hallucinating somewhere. anyformat's Monitoring runs these evaluations per workflow version, so a model swap shows up as a number before it shows up as a payment.
What "reducing" hallucinations means in production
Most guides stop at prompting tips and chunking strategies. Those help at the margin. The structural answer is that hallucination risk never reaches zero, so production systems are designed around detection and routing. The pipeline that holds up is the one where a hallucinated value has to get past a calibrated confidence score, a grounding check, a schema constraint and a validation rule, and where the rare one that does costs a human review rather than a wrong payment. None of that should cost you your data: the whole chain runs with zero document retention and, where required, fully air-gapped.
Related reading on anyformat.ai: what a confidence score means and how we calibrate it · anyformat vs LlamaParse · alternatives to AWS Textract · alternatives to Google Document AI · API integration · security and compliance at trust.anyformat.ai.
Frequently asked questions
Can LLM hallucinations in document extraction be eliminated completely?
No. They can be made rare through grounding, schema constraints and layout-aware parsing, and they can be made detectable through calibrated confidence and deterministic validation, so that undetected errors approach zero even though model errors do not.
What is the difference between confidence and calibrated confidence?
Confidence is a number the model emits. Calibrated confidence is a number that has been verified against ground truth so that 95 means 95% correct. Only the second one can safely drive automation decisions.
Do reasoning models or newer LLMs solve extraction hallucinations?
Each model generation shifts the error profile; none eliminates it. The practical consequence is technique 7: re-run your evaluation set on every model change.
What hallucination rate is acceptable for invoice processing?
The operational target is the undetected error rate after confidence routing and validation, not the model's raw error rate. Teams processing payments set the threshold so that undetected errors are measured in fractions of a percent, and accept the corresponding share of documents that go to review.
How do I know whether a vendor's confidence score is actually calibrated?
Ask for the evaluation: the document set, its size, and the accuracy observed inside each confidence band. A calibration claim without a published evaluation is a label.
Ready to measure it on your documents? Run a bake-off with anyformat: your files, your schema, the confidence and evidence on every field.
