6.1.1. Extracting Information from Documents and Forms
💡 First Principle: Document extraction finds the meaningful fields in a document, not just its text. An analyzer is configured to know a document's structure — an invoice has a vendor, date, line items, and total — and returns those as named values, so your app gets total: 142.50 rather than a wall of text it must parse.
This is the bread-and-butter use case: invoices, receipts, contracts, and forms. You choose a prebuilt analyzer for common document types or build a custom analyzer for your own forms, then submit the document and receive structured fields. The value over plain text extraction is that the output is immediately usable — ready to drop into a database, trigger a workflow, or feed another model.
⚠️ Exam Trap: Extraction is more than OCR. OCR gives you the raw text on the page; extraction identifies which text is the total, the date, the customer name, and returns them as structured fields. A scenario needing specific values pulled into an app is extraction, not just OCR.
Reflection Question: Why is "return the invoice total as a field" more useful to an application than "return all the text on the invoice"? What work does extraction save the developer?
