Document extraction is the unglamorous bottleneck of enterprise RAG

Everyone building RAG systems discovers the same uncomfortable truth: retrieval quality is bounded by extraction quality. You can tune your embeddings, swap your vector database, and agonize over chunking strategies — but if your PDF parser loses table structure, misreads column boundaries, or silently drops rotated text, no amount of retrieval sophistication will recover what was never captured. The bottleneck sits upstream, in the unglamorous work of format-aware document extraction.

Enterprise documents arrive in three broad categories, each demanding a different extraction strategy. Text-born PDFs — the kind generated from Word or LaTeX — preserve a character-level layout model that tools like pdfplumber can reconstruct with high fidelity. The real work here is layout analysis: detecting multi-column flows, identifying table boundaries via explicit ruling lines, and handling edge cases like ligature expansion and password-protected files. Scanned PDFs require an OCR branch entirely, with heuristics to detect zero-character pages and route them to Tesseract, Azure Document Intelligence, or Textract. And DOCX files demand a different approach altogether, traversing the OOXML object model to reconstruct heading hierarchies and handle merged cells in tables.

The production extraction pipeline I've seen work follows a five-stage routing architecture. First, format detection gates the branch selection: PDF vs DOCX vs code vs HTML. Second, within PDFs, a type classifier routes text-born documents to layout-aware parsers and scanned documents to OCR services. Third, table-heavy documents get an additional TSR (table structure recognition) pass using models like LineCell for wired tables or TableFormer for borderless ones. Fourth, extracted content flows through format-specific normalization — markdown for LLM ingestion, JSON for structured storage. Fifth, metadata enrichment attaches breadcrumbs: document type, section path, page numbers, and extraction confidence scores. Each stage has fallback chains; when the primary extractor fails, the pipeline degrades gracefully rather than producing silent corruption.

Code presents its own extraction challenge, but one with a cleaner solution: tree-sitter. Instead of line-based or sliding-window chunking, you parse the concrete syntax tree and extract definition-level chunks — one chunk per function or class, with docstrings attached as metadata. This produces semantically complete units that respect the actual boundaries of the code, not arbitrary token limits. The CST includes all tokens (whitespace, comments, punctuation), and the AST view within it gives you the named nodes that matter for retrieval. Hierarchical chunking — class header plus per-method chunks prepended with the class signature — preserves context without duplication.

Benchmarking matters here because extraction quality compounds downstream. DocLayNet's 80K human-annotated pages across six categories (financial, laws, manuals, patents, scientific, tenders) provides F1, BLEU, and local alignment scores that separate marketing from reality. PyMuPDF leads on F1 for government tenders; pypdfium2 achieves the highest BLEU scores on financial documents; Docling's AI-driven pipeline (RT-DETR layout analysis, TableFormer for table structure, EasyOCR) runs at 1.27–2.45 pages per second with typed document assembly. But benchmarks measure extraction fidelity, not semantic preservation — the metric that actually matters for RAG. A chunking fidelity guarantee requires chunks to be complete, non-overlapping, and semantically coherent, which means extraction must preserve section hierarchy and table semantics, not just character sequences.

The economic layer is often the decision constraint. Cloud OCR services range from Azure Document Intelligence at $0.50 per 1,000 pages (best accuracy/cost ratio for general documents) to Google Cloud Vision and AWS Textract at $1.50 per 1,000 pages (better for handwriting and complex scripts). Self-hosted options like Tesseract are free but require binarization and deskew preprocessing. For high-volume enterprise pipelines, the routing decision becomes: which documents justify paid OCR, and which can stay on the free tier? The answer usually involves a hybrid approach — text-born PDFs on open-source parsers, scanned invoices and forms on Azure DI, and complex engineering drawings on Google Vision.

Here's the concession: for greenfield applications with API-first data sources, none of this matters. If your knowledge lives in a database, a CMS, or a structured API, skip the extraction pipeline entirely and ingest at the source. Document extraction is a brownfield problem — a tax you pay for the reality that enterprise knowledge arrived in the last decade as PDFs and Word docs, not as structured records. But if you're building RAG for an enterprise that has twenty years of product manuals, legal contracts, and financial reports in PDF form, extraction isn't a preprocessing step. It's the foundation your retrieval quality sits on, and it deserves the same engineering attention you'd give to your embedding model or your eval suite.