Skip to content
AP.

Part 1 of 3

Document understanding pipelines

Parsing, extraction, and structuring of unstructured content — where most quality is lost, least measurement happens, and the token bill is decided.

September 11, 202612 min read · 8 topics

Every retrieval system, every copilot, every agent that reasons over documents sits on top of a pipeline that turned bytes into something a model can use. That pipeline is usually the least examined part of the stack. It was built early, it "works," and nobody looks at its output because looking at it is tedious. Meanwhile it is quietly deciding what the model can and cannot know.

My position is that the document understanding pipeline is the highest-leverage, least-instrumented component in an enterprise AI stack, and that it should be engineered with the same rigor as a data pipeline that feeds a financial report: idempotent, versioned, replayable, measured at every stage, and designed so that expensive work is done once and reused.

This piece is about how I think that pipeline should be built.

In this part

  1. 01
    Parsing

    Parsing is where the quality is lost

    2 min read

  2. 02
    Canonical document model

    Normalize to a canonical document model before doing anything else

    2 min read

  3. 03
    Deduplication and versioning

    Deduplicate and version at the door

    1 min read

  4. 04
    Chunking

    Chunking is a retrieval design decision, not a preprocessing default

    2 min read

  5. 05
    Extraction and annotations

    Extract signals once, and store them as annotations

    2 min read

  6. 06
    Pipeline engineering

    Engineer it like a data pipeline

    1 min read

  7. 07
    What to measure

    1 min read

  8. 08
    Common mistakes

    The mistakes I see most

    1 min read