01 / DefinitionWhat data extraction is
Data extraction is turning information locked in one form — documents, web pages, free text, images — into typed, structured values a table can hold and downstream tools can query. The extractor may be a parser following a format, a connector reading an API, or a model exercising judgement. What defines extraction is the output contract — every value lands in a declared column with a declared type — not the technique that produced it.
Holding onto that definition sorts a crowded market fast, because tools that look like competitors turn out to answer different inputs. It also names the quiet revolution: for fifty years the hard part of extraction was reading (OCR, parsing, selectors). Models made reading nearly free — and moved the hard part to believing: deciding which of the values that came back deserve to land.
02 / MapThe four families of extraction tool
| Family | Input | Failure mode | Cost shape |
|---|---|---|---|
| Document parsers & OCR | PDFs, invoices, scans, fixed forms | Loud on layout drift — fields come back empty or shifted | Per page, cheap at volume |
| Connectors & APIs | SaaS products, databases, feeds | Schema changes upstream; auth rot | Per seat/connector subscription |
| LLM extractors | Anything readable: pages, text, mixed documents | Quiet — plausible wrong values, format drift | Per token, or flat via an agent |
| Agent-run lines | Any of the above, as a standing pipeline | Refused batches — failure is recorded, not hidden | Flat agent subscription + cheap server |
The fourth row is not a fourth reading technique — an agent-run line uses parsers, connectors and models as workers. What it adds is the layer this guide keeps returning to: state, batches, checks and a ledger, so extraction behaves like production instead of like a heroic script. That layer is what Tablize is; the first three families it happily drives.
03 / ChoiceA decision path that follows the input
- Is the input fixed-format at volume? Invoices from the same template, statements, forms → a parser or OCR pipeline. A model here is paying judgement prices for clerical work.
- Does the data already live behind an API? → a connector. Extraction that re-scrapes what an API offers is technical debt with extra steps.
- Does getting the value require reading and judgement? Categories, risk flags, normalised entities, "which clause deviates" → an LLM extractor. No parser will ever do this; this is the genuinely new capability.
- Will the extracted column feed something downstream, repeatedly? → wrap whichever extractor you chose in a line: declared schema, batch acceptance, attempt ledger. One-off answers can skip this; standing columns cannot.
A real supplier-screening flow uses all four in one pass: a connector pulls the catalogue, OCR reads the certificates, a model judges "manufacturer or trader", and the line accounts for all of it. Tool-family debates dissolve once the pipeline is the unit of design — see the pipeline guide.
04 / The new partWhen the extractor is a model
"AI data extraction" earned its own noun because the failure profile inverted. Parsers fail loudly: layout drifts, fields come back empty, someone notices. A model always returns something — well-formatted, fluent, and possibly wrong. Three drifts dominate:
- Hallucinated values — the page doesn't state a founding year, the model
supplies a plausible one. The licence to answer
nullhas to be explicit in the schema, or the model will be helpful instead of honest. - Enum drift — the contract says
manufacturer | trader; the model returns"likely manufacturer". Harmless-looking, and it silently breaks every filter downstream. - Batch decay — quality at row 3 of a batch is not quality at row 40. Batches must be sized to what a model can hold with full attention, not to the context limit. The LLM extraction guide treats sizing in depth.
All three are manageable — with schema-first output (structured extraction), mechanical checks on every submission, and spot-checks against pinned answers. None are manageable by prompt-wording alone, which is the mistake the market keeps re-selling.
05 / The skipped layerThe accounting every comparison skips
Here is the question that separates extraction tools from extraction infrastructure: three weeks after the run, can you answer — for any single cell — which attempt produced this value, against which schema, and what checked it?
Tools answer with a shrug: the output folder is the output. Infrastructure answers from a ledger:
# the books, for one column
tablize ledger supplier-category
→ batches: 5 · attempts: 127 · accepted: 119 · refused: 8
→ refusals: 5 enum · 2 golden miss · 1 null-where-required
→ models: claude-sonnet-4.5 (5 batches) · gate: enforceNothing in that readout is sophisticated. It is bookkeeping — the same bookkeeping any production process keeps and almost no extraction stack does. It is also the answer to the second question this guide opened with: the basis for believing cell (3187, category) is not the model's reputation, it is that row's acceptance record.
06 / FAQQuestions that come up
What's the best data extraction tool?
Wrong question — follow the input. Fixed formats: parser/OCR. Behind an API: connector. Judgement over messy evidence: LLM extractor. Standing columns that downstream trusts: any of those, wrapped in a line with acceptance accounting. "Best" only exists per input and per stakes.
How do I extract data from PDFs?
Layer it: born-digital PDFs surrender text to a parser; scans need OCR first; then stable layouts get template parsing and varying layouts get a model read. Whatever did the reading, validate against a declared schema before anything lands — the reader and the believer are different jobs.
Are vendor accuracy claims real?
They are averages over someone else's corpus. Accuracy is per-column, per-corpus: 99% on invoices says nothing about your supplier categories. Measure on your own data by pinning answers for a sample — it takes an hour and replaces marketing with evidence.
Build or buy?
Buy the commodity readers (OCR, parsers, connectors — solved problems). The judgement layer rides the model your coding agent already runs on. Stand up the accounting layer — schemas, batch acceptance, attempt ledger — as infrastructure, because that is the part no single extractor ships and the part audits ask about.
Extraction vs enrichment vs cleaning?
Extraction creates structured values from unstructured input; enrichment adds columns to existing rows (by lookup or judgement); cleaning corrects what is already there. The verbs blur in vendor copy but verify differently — which is why this site keeps them on separate pages.
Adjacent reading, same production-line lens: