Documents are not text, and parsing is where most retrieval quietly fails

Retrieval projects tend to be debugged from the top. The answer was wrong, so the prompt is examined, then the model, then the chunking strategy. The layer that is almost never examined is the first one: what the text actually looked like after it came out of the document.

In our experience that is where a surprising share of the problem lives.

What goes wrong between a document and a string

Reading order. A two-column layout can extract as alternating fragments from both columns, producing sentences that are individually grammatical and collectively meaningless.

Tables. A table carries meaning in its structure. Flattened to a sequence of cell values, the relationship between a row label and its figure is gone, and an agent asked about the figure will associate it with whatever happens to sit nearby.

Headers, footers and page furniture. Repeated on every page, extracted every time, they dilute every chunk they land in and can dominate a short one.

Footnotes and captions. Rendered at the bottom for a reason, and frequently spliced directly into the paragraph they annotate.

Scanned pages. Sometimes there is no text layer at all, and the extraction is silently empty rather than loudly broken.

The reason it goes unnoticed

Every one of these produces output that looks like text. There is no error, no exception, nothing to alert on. The pipeline reports success, the index builds, and the degradation only appears much later as an agent that is inexplicably unreliable on one class of question.

By the time anyone investigates, the parsing step is three layers of abstraction away and has been working fine since the project started.

What to do about it

Read your own extracted text. Not a sample of the clean documents, the awkward ones: the scanned contract, the report with the landscape table, the form. Ten minutes of reading extraction output tells you more than a week of prompt adjustment.

Preserve structure where it exists. Headings, tables and section boundaries are the natural units for chunking, and they are only available if the parser kept them.

Carry provenance on every chunk: the document, the page, the section. When an answer is wrong, this is what turns debugging into a lookup rather than a search.

Handle scanned documents deliberately rather than hoping. A page with no text layer needs recognition, and recognition needs its own quality check.

How it connects to everything else

Parsing sets a ceiling. No retrieval strategy, no model and no prompt can recover a table whose structure was destroyed at extraction. It is the cheapest layer to fix and the most expensive to ignore, because every downstream improvement is measured against a corrupted baseline.

This is also why evaluation sets should include your difficult documents rather than your representative ones. A set built from clean PDFs will report that everything is fine right up until someone asks about the scanned one.

Next

The parsing pages cover supported formats and structure preservation. The developer documentation covers chunking and retrieval, which is the layer immediately above this one and depends entirely on it.