Docling holds a narrow lead over LlamaParse for maintaining structural integrity and table layouts in complex PDF pipelines. LlamaIndex is the usual answer when pipelines need to ground answers in tables or turn complex documents into vectors.
For a large collection of complex PDFs, I’d recommend a layout-aware document ingestion pipeline that preserves tables, reading order, and document structure before generating embeddings.
The biggest mistake is treating every PDF as plain text, splitting it into fixed-size chunks, and embedding the result. That often destroys table relationships, mixes headers with unrelated paragraphs, and loses context that retrieval needs to answer questions accurately.
A robust pipeline should separate five concerns:
Document extraction — recover text, tables, page structure, and layout.
1. Docling — best starting point for complex layouts
(My default pick)
Good for multi-column PDFs, structured tables, headings, scanned pages, and keeping document structure intact. Its HybridChunker supports structure-aware chunking for RAG.
Best when you want local processing and control over the extraction pipeline.
2. Unstructured — best for a broad ingestion ecosystem
Offers PDF partitioning strategies, high-resolution layout detection, table extraction, and integrations for document ingestion workflows. Use its high-resolution strategy when table structure matters.
Best when you have many file formats and want a configurable ingestion framework.
A managed parsing option to evaluate when PDFs contain complicated tables, visual structure, or mixed content and you want to reduce parser infrastructure work.
Best when a hosted service fits your privacy, cost, and operational requirements.
These are starting recommendations, not a universal accuracy ranking. The best parser depends on whether your corpus contains digital PDFs, scans, financial tables, scientific papers, or forms.
Recommended ingestion architecture
1. PDF corpus
Object storage · document IDs · checksums
2. Classify and parse
Digital text · scanned pages · layout and tables
3. Normalize structure
Sections · reading order · table headers · page references
Start with Docling and preserve its structured output rather than immediately converting everything into a flat string.
python
from docling.document_converter import DocumentConverter
converter = DocumentConverter()
result = converter.convert("report.pdf")
doc = result.document
markdown = doc.export_to_markdown()
Docling can preserve reading order, table structure, and page-level provenance.
For scanned PDFs, test OCR quality separately. For difficult visual layouts, compare the standard parser with a vision-based approach on representative pages.
2. Chunk tables differently from prose
This is the most important design decision.
Content type
Recommended chunking
Narrative text
Split by section and paragraph, then enforce a token limit
Tables
Preserve the title, column headers, units, and relevant row groups
Very large tables
Create row-group chunks with repeated headers; optionally index individual records separately
Figures and charts
Preserve captions and nearby explanatory text; use visual embeddings or image descriptions when needed
Footnotes
Attach them to the relevant table or section where possible
For example, don't embed this isolated fragment:
2024 | 1.8 | 2.4
Instead, embed a contextualized representation:
Section: Annual Revenue. Table: Revenue by Region. Columns: Year, North America Revenue (USD billions), Europe Revenue (USD billions). Row: 2024, 1.8, 2.4.
This makes the numbers interpretable when retrieved independently.
3. Use structure-aware chunking
Docling's HybridChunker is a good fit because it works with the parsed document structure and a tokenizer-aware chunk limit.
python
from docling.chunking import HybridChunker
chunker = HybridChunker()
for chunk in chunker.chunk(doc):
text = chunker.contextualize(chunk)
# Generate an embedding for `text`
# Store it with document and page metadata
Choose the chunk token limit based on your embedding model and retrieval needs. A reasonable starting experiment is 256–512 tokens for ordinary passages, with separate handling for tables that need more context.
4. Store provenance alongside vectors
Each indexed chunk should retain metadata such as:
document_id and document version
page_number and, where available, bounding-box coordinates
section_path
content_type — prose, table, figure, or other
table_id and caption, when applicable
access-control metadata, if documents have different permissions
Keep the original PDF and structured extraction in durable storage. That makes it possible to re-chunk, re-embed, or correct extraction errors without reparsing the entire corpus.
5. Benchmark before processing the whole corpus
Select 50–100 representative PDFs, including your worst tables, scanned pages, multi-column layouts, and long documents. Run the same evaluation set through Docling and Unstructured, adding a managed parser if appropriate.
Measure:
Table cell and header accuracy
Reading-order errors
OCR accuracy on scans
Parsing throughput and memory use
Retrieval recall and answer accuracy on known questions
Cost per page, including retries and manual correction
Only scale up after reviewing the extracted results and testing actual retrieval queries. Parser quality alone does not guarantee good vector search.
My final recommendation
Use Docling + structure-aware chunking + your preferred embedding model + a vector database with metadata filtering as the first implementation. Add a separate structured database or table index if users need precise numerical queries across large tables. Consider hybrid vector-and-keyword retrieval for exact identifiers, dates, codes, and financial values.
One question that would materially change my recommendation: what kind of PDFs are you processing most often?
1. Document type
Business reports, manuals, and multi-column documents
Financial reports, scientific papers, and dense tables
When turning PDFs with complex layouts, multi-column text, and intricate tables into vectors, traditional regex or basic text-extraction libraries (like PyPDF or pdfminer) fall short because they destroy spatial context.
Top-tier options depend on your constraints regarding privacy, budget, and cloud vs. local infrastructure:
1. Best Open-Source & Local-First: Docling (by IBM)
Why it shines: It has emerged as a leader for local, privacy-compliant, heavy-duty processing. It uses advanced layout and table structure models (TableFormer) to accurately map complex hierarchical tables and multi-column reads.[](https://www.llamaindex.ai/insights/best-table-parsing-ai)
2. Best Managed / Cloud-Native API: LlamaParse (by LlamaIndex)
Why it shines: Built specifically for RAG (Retrieval-Augmented Generation) pipelines, LlamaParse uses agentic/vision-based parsing to handle messy layouts, nested tables, and charts with zero manual template training. It natively outputs Markdown or structured JSON optimized for chunking.
Integration: Plugs seamlessly into LlamaIndex data loaders, but the markdown output can be used with any vector database or orchestration framework (like LangChain).
3. Best Specialized for Irregular Tables & Bounding Boxes: Reducto
Why it shines: In rigorous evaluations for irregular tables with merged cells and dense data sheets, Reducto scores exceptionally high. It emits robust HTML for tables (preserving complex row/column spans that Markdown flattens) and retains exact bounding boxes and citations back to the source page.
Best for: Financial statements, invoices, and dense legal/insurance packets where a single misplaced table cell changes the meaning entirely.
Parse & Convert: Send the raw PDF through a layout-aware parser (Docling or LlamaParse ) to get structured Markdown or HTML (for tables).
Semantic Chunking: Instead of splitting by arbitrary character count, chunk the Markdown by headers (#, ##, ### ) and keep HTML table blocks intact so tabular data doesn't get split mid-row.
Embed & Vectorize: Pass the semantically coherent chunks to your embedding model (e.g., OpenAI text-embedding-3 , Cohere, or local BGE models) and store them in your vector database (Pinecone, Qdrant, PGVector, etc.).
To help narrow down the ideal pipeline for your project, let me know:
Are you required to run this locally/on-premise for data privacy, or is a cloud API acceptable?
What kind of documents are these (e.g., financial statements, academic papers, technical manuals, or invoices)?
