Data extraction is getting a record out of a system that will not export one
The source may be a portal, a PDF, an email attachment or a mainframe screen. What unites them is that the information is visible and the system offers no sanctioned way to hand it over.
Four sources, four different problems
The word covers several jobs that share a name and almost nothing else.
Structured, with an interface
A database, a documented API, an export button. This is not really extraction; it is integration, and if it is available you should be using it. Half the extraction projects that get started should have been an afternoon of reading someone's API documentation.
Semi-structured on a screen
A portal table, an invoice list, a search result. The structure is real but implicit, encoded in layout rather than in a schema. A browser can read it reliably; the difficulty is that the layout is not a contract and can change without warning.
Documents
PDFs, scans, spreadsheets sent as attachments. Position on a page carries meaning that no markup records, which is why document extraction has its own tooling and its own failure modes around tables spanning pages.
Free text
Notes, emails, descriptions. There is no structure to find, only structure to impose, which is what makes this the part language models genuinely improved and also the part that needs the most validation.
Building an extraction you can trust
Trust is the deliverable. Volume is easy; being able to defend the numbers is not.
-
Define the record before you write the extractor
Name the fields, their types and which are mandatory. Doing this first turns extraction into a checkable job and gives validation something to check against.
-
Capture the evidence alongside the value
Store where each field came from: the URL, the timestamp, ideally the raw fragment. When someone disputes a number in six months this is the difference between an answer and a shrug.
-
Extract the strictest way that works
A selector on a stable attribute beats a model reading a screenshot, because it fails loudly. Reserve the flexible method for the cases where the strict one genuinely cannot apply.
-
Validate on shape, not just on presence
Check types, ranges and cross-field consistency. An invoice total that is not the sum of its lines is a caught error; a populated string field is not evidence of anything.
-
Track fill rate over time
The signature of a broken extractor is not a crash, it is a field that quietly drops from ninety-eight per cent populated to sixty. Alert on the derivative, not the absolute.
-
Decide what happens to a low-confidence record
Route it to a person, or discard it, but decide. Silently writing an uncertain value into a system of record is how extraction projects lose their credibility.
Common questions
Is data extraction the same as ETL?
Extraction is the E. ETL assumes a source that will cooperate, typically a database or a file drop. Extraction in the sense used here is what you do when there is no cooperative source and the interface built for a person is the only interface there is.
Do language models make extraction solved?
They made the hard cases tractable and the easy cases more expensive. A model reading a screenshot handles a layout no selector could, but it costs orders of magnitude more per record and it fails quietly rather than loudly, which is a real regression in operability.
How accurate does extraction need to be?
It depends entirely on what happens downstream. Feeding a dashboard tolerates a few per cent of noise. Feeding an accounting system does not, and there the useful design goal is not accuracy but knowing which records to hold back.
What is the most common mistake?
Skipping the validation layer because the first hundred records looked right. Extraction quality degrades gradually and invisibly, and the first hundred records are never the ones that break.
Extraction from portals that need a login
Sessions that stay signed in, credentials kept out of the model context, and a record of every run.