Reference architecture: AI document processing pipeline
A document processing pipeline takes documents in (email, upload, API, scanner), classifies them, parses text and tables, extracts fields into a schema with an LLM or a specialised model, validates the fields with rules, sends low-confidence or failed fields to a person for review, and exports clean data to the system of record. It runs as background jobs, not as chat. Check whether classic NLP or OCR is enough before you use an LLM, and measure field-level accuracy, because one wrong total on an invoice matters more than a fluent summary.
Where this is used
Invoices, purchase orders, contracts, insurance claims, resumes, bank statements, medical forms, shipping documents. These are the "boring" problems with clear value: people retype data from documents into systems every day, and errors cost money.
Architecture
intake (email, upload, API, scanner)
│
▼
queue ──> workers
│
▼
classify document type
│
▼
parse text, tables, OCR for scans
│
▼
extract fields into schema (per type)
│
▼
validate (rules, cross-checks, lookups)
│ pass │ fail or low confidence
▼ ▼
export to ERP/CRM review UI (source highlighted) ──> export
│
└── corrections become eval cases
Components
| Component | Role |
|---|---|
| Intake | Email, upload, API, scanner |
| Queue and workers | Async processing with retries. See async job queue |
| Classifier | Document type (invoice, contract, resume) |
| Parser | Text, tables, OCR for scans. See document parsing |
| Extractor | Schema-constrained extraction per document type |
| Validator | Rules: totals add up, dates are valid, IDs exist in the system |
| Review UI | A person checks flagged fields with the source highlighted |
| Export | ERP, CRM, database |
Validation is where accuracy comes from
Extraction models make mistakes. Rules catch many of them without any AI:
- Line items add up to the subtotal, and subtotal plus tax equals the total.
- Dates are valid and in a sensible range.
- Vendor and customer IDs exist in your system.
- Currency and amounts match the document's country and format.
A field that fails a rule, or that the model marked as low confidence, goes to review. See structured outputs for schema-constrained extraction.
Key decisions
- Which fields always need human review (bank details, totals above a limit), and which only when validation fails.
- Whether a classic NLP or OCR approach is enough before using an LLM. For clean, consistent templates, it often is.
- How long documents and images are kept, and who can see them, because these documents are full of personal and financial data.
Metrics
- Field-level accuracy, per field and per document type.
- Straight-through rate (documents processed with no human touch).
- Review time per document.
- Cost per document.
From the floor
In the resume analyzer project lab, I started with classic NLP rather than an LLM, using spaCy for named entity recognition to pull out emails, phone numbers and other fields, and I said why: in projects like this, NLP should be your first approach, and if the results aren't good enough, then you move to generative AI.
In the same session, I described an OCR project where the client first wanted an NLP-only solution because of the cost of LLMs, and after testing, they decided accuracy mattered more, because many of their PDFs were tables rather than written text, so the problem had to be split into categories, with NLP for some cases and other methods for the rest.
Related
- Design a document extraction pipeline
- Document parsing
- Async job queue
- Structured outputs and function calling