4.3.1. Extracting Structure: Layout, Prebuilt, and Custom Models
💡 First Principle: Document extraction comes in three flavors matched to how predictable the document is — layout extraction (structure-agnostic: text, tables, headings from any document), prebuilt models (for common known types: invoices, receipts, IDs), and custom models (trained on your own document type when no prebuilt fits). Match the model to the document's predictability.
The layout model articulates document structure — headings, paragraphs, tables, reading order — and notably powers the structure-aware Document Layout chunking skill from 4.1.2, which is why extraction and chunking connect. Prebuilt models handle standardized documents (invoices, receipts, business cards, identity documents) out of the box with named fields. Custom models are trained on examples of your document type when it's neither generic-layout nor a covered prebuilt — for example, a company-specific claim form. Content Understanding extends extraction across modalities (documents, images, audio, video) for multimodal information extraction.
| Model type | Use when | Example |
|---|---|---|
| Layout | Any document, need structure | Headings/tables for chunking |
| Prebuilt | Common standardized type | Invoice, receipt, ID |
| Custom | Your unique document type | Company-specific claim form |
⚠️ Exam Trap: Don't train a custom model for a document a prebuilt already covers (invoices, receipts, IDs). Custom models cost training effort and data; the requirement-correct answer for a standard document type is the prebuilt model. Reaching for custom when a prebuilt fits is over-engineering — and conversely, forcing a prebuilt onto a truly bespoke form is the opposite error.
Reflection Question: You must extract fields from a company-specific warranty registration form that no prebuilt model covers, and separately extract tables from arbitrary research PDFs. Which model type fits each, and why is "always use custom" wrong?
