Information Extraction: The Structure Hiding Under the Text

Information extraction is where most people's mental model is thinnest. They imagine optical character recognition producing a stream of words, and then something clever picking values out of that stream. That picture is wrong in an important way, and the correction is the whole point of this note: before any field is extracted, the content has to be turned into a structured representation, and how well that step goes determines the ceiling on everything above it.

Two layers, not one

Extraction from documents happens in two distinct layers. The lower one is content extraction, which forms the foundation of document analysis and transforms unstructured documents into structured, machine-readable data. The upper one is field extraction, which produces the named values you asked for.

Keeping these separate explains failures that otherwise look mysterious. When a total is pulled from the wrong column, the fault usually lies in the lower layer — the table was never reconstructed correctly, so the upper layer was reasoning over scrambled input. Debugging the prompt or the field description will not help. The structure was already lost.

What the lower layer actually captures

Content extraction is far richer than "reading the words", and the inventory is worth knowing because each item corresponds to information a naive text dump destroys.

On the content side it handles printed and handwritten text across many languages; selection marks such as checkboxes and buttons, which is how a form records a decision that has no words at all; barcodes of many linear and two-dimensional types; mathematical formulas preserved in a structured notation; images, figures, diagrams and charts along with their captions; hyperlinks embedded in the file; annotations such as strikethrough, underline and highlight; signatures, including their location and any text inside them; and document metadata such as author, creation date and title.

On the structure side it detects paragraphs and categorises them by the role they play, recognises tables including complex ones with spanning cells and layouts that continue across pages, and maps hierarchical sections through headings and nesting.

Read that list as a set of questions a plain text extract cannot answer. Was the box ticked? Was this clause struck through or is it still in force? Which table did this figure belong to? Is this a heading or a body sentence? Those distinctions are frequently the entire point of the document.

Segmentation: deciding what a unit is

Between the two layers sits a step that is easy to overlook. A single file is often not a single document. Loan packets, claims bundles, and scanned mail arrive as one PDF containing many things.

Segmentation divides content into logical sections so each can be handled appropriately — splitting a file by document type, or breaking a video into scenes. Paired with classification, it produces the pattern that dominates real intake processes: work out what each part is, then route each part to the analyzer that specialises in it. Skipping this and pointing one analyzer at a mixed bundle produces poor results that get blamed on extraction accuracy when the real error was a scoping mistake.

Normalisation and why the output is not a screenshot

Once fields are produced, typed values such as dates and numbers are automatically converted to a canonical form, and the returned value is the normalised one. This is deliberate and it is not configurable.

It also has a consequence people find surprising in practice. A date printed on the page in one national convention comes back in a standard machine form, so the extracted value is not always character-identical to what the page shows. Downstream code that expects a verbatim copy will break. The system is producing data for computation, not a transcript of ink.

Two extraction traditions living together

A final piece of context. Two lineages coexist under one umbrella. Purpose-trained document models deliver deterministic, high-accuracy extraction from structured document types with common templates, prized where consistency and low latency matter. Generative analyzers handle unstructured, high-variation, and multimodal content, including fields that must be inferred rather than located.

You are not expected to choose sides. You are expected to notice which characteristics a scenario emphasises: a stable template with a precision requirement points one way; wildly varying layouts, no labelled data, and a need for judgement points the other.

Mistakes to avoid

• Treating layout as cosmetic. Position and role carry meaning; flattening a document to plain text discards it.
• Ignoring non-text marks. Checkboxes, signatures, and strikethroughs often decide the outcome.
• Assuming one file is one document. Segment and classify first.
• Expecting verbatim values. Typed fields come back normalised by design.

What to carry forward

Information extraction is structure recovery followed by value selection. Get the structure right and field extraction has a chance; get it wrong and no amount of tuning at the top layer will rescue the result.