Source-linked AI summary
Document Retrieval-Aware Chunking (D-RAC): Universal Retrieval-Aware Ingestion of Enterprise Documents via PDF Normalization and Multimodal Markdown Conversion
Uday Allu, Abhivanth Sivaprakash, Pratik Singh, Aman Manocha
TL;DR
Enterprise PDFs and other documents can be difficult to ingest reliably because their visual layouts obscure reading order, tables, and heading structure. D-RAC normalizes documents to PDF, converts rendered pages into retrieval-optimized Markdown, and plans chunks over identifiers rather than regenerating text. On the evaluated PDF benchmark subset, it reports lower chunking tokens, costs, and time than agentic chunking, with zero errors across the full corpus.
Problem
PDF layouts can disrupt reading order, collapse tables, and obscure headings, limiting the reliable structure available to deterministic ingestion.
Source: §1 · p. 2, §2.1 · p. 2Method
D-RAC converts documents to PDF and retrieval-optimized Markdown with one multimodal pass, then uses W-RAC-style ID-based planning without regenerating chunk text.
Source: §1 · p. 2, §7 · p. 12Results
95.7% fewer chunking-stage output tokens, 77.8% (GPT-4.1) to 85.6% (Gemini 2.5 Pro) lower chunking cost, and 75% less chunking time than agentic chunking.
Source: §7 · p. 12Takeaways & Limitations
Persisted Markdown and ID-addressable elements decouple one-time document understanding from repeatable chunking, enabling retrieval-strategy iteration at planning-only cost.
Source: §7 · p. 12The cost comparison uses published GPT-4.1 and Gemini 2.5 Pro rates.
Source: §6.4 · p. 11
Abstract
from arXiv · showhide
Retrieval-Augmented Generation (RAG) systems over enterprise knowledge bases must ingest heterogeneous document formats -- PDFs, Word documents, presentations, and scans -- whose content is locked inside complex visual layouts, multi-column pages, and dense tables. Rule-based extraction and OCR destroy reading order, flatten tables, and lose heading hierarchy, while fully agentic chunking over extracted text incurs high token costs and hallucination risk. We present Document Retrieval-Aware Chunking (D-RAC), an extension of our Web Retrieval-Aware Chunking (W-RAC) framework to arbitrary document formats. D-RAC first normalizes any input document into PDF, exploiting the fact that virtually every format has a faithful, deterministic PDF rendering. A single multimodal LLM pass then converts rendered pages into retrieval-optimized Markdown -- rewriting tables as self-contained prose statements and preserving heading hierarchy -- after which chunking proceeds exactly as in W-RAC: deterministic parsing into ID-addressable units followed by lightweight LLM-based chunk planning over identifiers rather than text. Source text is never regenerated during chunking, preserving W-RAC's cost, determinism, and observability benefits while unlocking every renderable format as a first-class input. On the 236-document, 795-page PDF subset of the RAG-Multi-Corpus benchmark spanning five enterprise domains, D-RAC converts and chunks the entire corpus in 72 minutes with zero errors, producing 1,748 retrieval-ready chunks. Compared to agentic chunking with frontier LLMs, D-RAC reduces chunking-stage output tokens by 95.7%, cutting chunking cost by 77.8% (GPT-4.1 pricing) to 85.6% (Gemini 2.5 Pro pricing) and chunking time by 75%. D-RAC scales linearly to documents of 500+ pages.
1 Introduction
PDF’s visual layouts make the reliable structure required by W-RAC difficult to recover. D-RAC adds PDF normalization and a retrieval-aware multimodal conversion pass, then applies W-RAC’s unchanged chunking approach; its benchmark evaluation reports lower chunking tokens, cost, and time than agentic chunking.
1 Introduction
- PDF extraction disrupts reading order, interleaves multi-column layouts, collapses tables, and often mangles heading structure, leaving W-RAC’s deterministic parser without reliable structure.Source: §1 · p. 2
- D-RAC normalizes documents to PDF, converts rendered pages into retrieval-optimized Markdown with one multimodal pass, and leaves the rest of W-RAC unchanged.The conversion rewrites table rows as self-contained prose and reconstructs heading hierarchy.Source: §1 · p. 2
- D-RAC’s table strategy turns each row into self-contained prose, so tabular facts can be retrieved without fragmented cells.Source: §1 · p. 2
- D-RAC recursively sections large converted documents at header boundaries while carrying parent-header context into planning, supporting documents of 500+ pages.Source: §1 · p. 2
- The evaluation covers 236 PDF documents totaling 795 pages across five enterprise domains in the RAG-Multi-Corpus benchmark.Source: §1 · p. 2
- 95.7% fewer chunking-stage output tokens, 77.8–85.6% lower chunking cost, and 75% lower chunking time than agentic chunking with frontier LLMs.The cost reduction is 77.8% with GPT-4.1 pricing and 85.6% with Gemini 2.5 Pro pricing.Source: §1 · p. 2
2 Background and Limitations of Traditional Document Ingestion
Traditional document-ingestion approaches face different limitations: text extraction can damage structure, layout systems still struggle with unusual layouts and tables, and agentic or vision-guided chunking can retain high text-generation costs.
2.1 Rule-Based Text Extraction
- Rule-based PDF extraction can break multi-column reading order, interleave headers and footers, fragment tables, and infer heading hierarchy only heuristically.Source: §2.1 · p. 2
2.2 Layout-Analysis and OCR Pipelines
- Layout-analysis systems such as LayoutLM [3], LayoutLMv2 [4], and Docling [5] improve structure recovery but can struggle with unusual layouts and still emit tables as grids.A cell separated from its row and column context can be semantically meaningless.Source: §2.2 · p. 3
2.3 Agentic Chunking over Extracted Text
- Agentic chunking over extracted PDF text must repair extraction damage and regenerate the document, increasing output tokens, latency, and hallucination surface [1].The cited prior analysis reports output tokens as approximately four times more expensive than input tokens under standard pricing [1].Source: §2.3 · p. 3
2.4 Vision-Guided Chunking
- Using a large vision model for both document understanding and chunk generation retains agentic chunking’s full output-token cost; D-RAC instead converts once and plans over IDs [6] [8].Source: §2.4 · p. 3
3 Document Retrieval-Aware Chunking (D-RAC)
D-RAC combines PDF normalization and multimodal Markdown conversion with deterministic parsing and ID-based chunk planning. Its design preserves converted text while making document structure and chunk plans explicit and inspectable.
3.1 Design Principles
- D-RAC’s principles combine format-agnostic PDF normalization, one retrieval-aware conversion pass, ID-based planning without text regeneration, and deterministic, inspectable artifacts.Conversion favors retrieval-ready prose tables and explicit hierarchy over visual fidelity, while the pipeline minimizes LLM output tokens and calls.Source: §3.1 · p. 3
3.2 System Architecture
- The four-stage architecture normalizes and renders documents, converts pages, parses and sections Markdown, then plans and reconstructs chunks.In Figure 1, orange denotes LLM stages and green denotes deterministic stages; the multimodal model reads document content only in Stage 2.Source: §3.2 · p. 4, Figure 1 · p. 4
3.2.1 Stage 1: PDF Normalization and Page Rendering
- Non-PDF inputs are deterministically converted to PDF, then rendered as page images at 200 DPI, downscaled when needed to fit a 1,568-pixel dimension limit.Normalization is lossless with respect to visual content; rendering takes 1–7 seconds per document in the reported corpus.Source: §3.2.1 · p. 4
3.2.2 Stage 2: Multimodal Markdown Conversion
- The multimodal conversion preserves text, rewrites each table row as a self-contained sentence, suppresses decorative images, and reconstructs heading hierarchy.A deterministic post-processing pass removes residual image references and converts escaped table syntax to row-level prose.Source: §3.2.2 · pp. 4–5
3.2.3 Stage 3: Deterministic Parsing and Sectioning
- When a document exceeds the 60-element planning budget, recursive sectioning splits at header boundaries and carries ancestor-heading context into each planning call.The algorithm prefers coarser headings where possible and merges adjacent small sections to avoid fragmentary calls.Source: §3.2.3 · p. 5
3.2.4 Stage 4: LLM Chunk Planning and Reconstruction
- The planner receives element IDs, truncated previews, and hierarchy metadata, then returns ordered ID lists; reconstruction maps IDs to converted text and prefixes ancestor headings.Plans target 3–8 content blocks per chunk, reuse header IDs, and are checked for complete content-ID coverage, with missing IDs placed in a fallback chunk.Source: §3.2.4 · p. 5
4 Retrieval Awareness in D-RAC
D-RAC applies retrieval awareness during document conversion, especially by preserving table-row context and heading hierarchy. Persisted converted Markdown and element IDs also let later chunking strategies be replanned without reconverting source PDFs.
4 Retrieval Awareness in D-RAC
- D-RAC moves retrieval awareness earlier than W-RAC by incorporating it into document format conversion.Source: §4 · p. 6
- Each table row becomes a self-contained declarative sentence, keeping row and column context together so each tabular fact can be independently embedded and retrieved.The approach builds on prior findings that contextualized tabular prose improves LLM summarization and QA over tables [7].Source: §4 · p. 6
- The conversion forbids merging distinct rows into disjunctive statements, which could make a query about one configuration retrieve a sentence asserting several.Source: §4 · p. 6
- Reconstructed headings guide sectioning and planning, then accompany each chunk so embeddings include broader topical context alongside local content.Source: §4 · p. 6
- Persisted converted Markdown and element IDs let retrieval-strategy changes use replanning alone, without repeating source-PDF conversion or OCR.The passage gives chunk-size targets, entity-aware grouping, and per-tenant policies as examples of changes.Source: §4 · p. 6
5 Evaluation Corpus
The evaluation uses the RAG-Multi-Corpus PDF subset, covering five enterprise organizations and realistic, layout-rich documents. Retrieval evaluation uses curated, supporting-fact queries from four organizations, categorized by query type.
5 Evaluation Corpus
- The PDF subset contains 236 documents and 795 pages across five fictional enterprise organizations, with realistic, table-heavy materials such as FAQs, policies, catalogs, and service guides.All inputs are natively PDF, so normalization is the identity in these experiments.Source: §5 · p. 7
5.1 Query Distribution
- The retrieval query set contains 762 queries across four organizations, with CloudWay-24 excluded because it has no annotated queries.Each query has one or more verbatim supporting-fact snippets linked to their source document.Source: §5.1 · p. 7
- The seven query types cover factual recall, reasoning, comparison, and procedural understanding, including categories sensitive to chunk boundaries and table handling.The passage names descriptive, analytical, comparative, boolean, temporal, procedural, and open-ended queries.Source: §5.1 · p. 7
5 Evaluation Corpus
- Table 4 reports PDF-to-Markdown conversion performance by organization and records zero conversion errors across all 236 documents.Experiments use Gemma-3 27B, 5-page batches, 5 parallel workers, and 200 DPI rendering.Source: §5 · p. 7, Table 4 · p. 8
6 Experimental Results
D-RAC matches or exceeds agentic chunking across overall retrieval metrics while costing less, and improves retrieval over fixed-size PDF extraction. Conversion and planning complete with zero errors, while chunking-stage output, cost, and time are substantially reduced.
6.1 Conversion Throughput
- Across all 236 documents, conversion takes 3,758 seconds of cumulative time and 71.7 minutes wall-clock including planning, with zero conversion errors.A separate 503-page prospectus converts in 21.6 minutes with Gemma-3 27B and 13.4 minutes with Gemma-3 12B, at per-page cost consistent with small documents.Source: §6.1 · p. 8
6.2 Chunk Planning Efficiency
- Chunk planning takes 542 seconds for the corpus, or 14% of conversion time, and produces 1,748 chunks with zero chunking errors and exactly-once content coverage.Across organizations, average chunk sizes range from 581–846 characters; the 503-page stress-test document is planned in 68.7 seconds across 95 parallel section calls.Source: §6.2 · pp. 8–9
6.3 Retrieval Performance
- Across 762 queries, D-RAC matches or exceeds agentic chunking on every overall retrieval metric while costing 77.8–85.6% less to produce.The comparison uses agentic reference chunks produced from clean structured sources, whereas D-RAC processes rendered PDF pages.Source: Table 6 · p. 9, §6.3 · p. 10
- Recall@6 rises from 0.717 to 0.798 (+11.3% relative), MRR from 0.602 to 0.690 (+14.6%), and NDCG@6 from 0.764 to 0.801 versus fixed-size PDF extraction.The comparison is against 1,000-character chunks with 200-character overlap over rule-based PyMuPDF extraction.Source: §6.3 · pp. 9–10
- D-RAC has its largest fixed-size-baseline gains on temporal (Recall@6 0.85 vs. 0.73), comparative (0.79 vs. 0.72), and analytical (0.61 vs. 0.56) queries; agentic chunking retains an edge on boolean queries.D-RAC’s Recall@6 varies by only 0.022 across the four organizations.Source: §6.3 · p. 10
6.4 Cost Analysis
- D-RAC reduces chunking-stage output tokens by 95.7% (270,454 → 11,714), because its planner emits element-ID arrays rather than rewritten text.The cost analysis reports 77–87% of agentic chunking cost comes from output tokens; D-RAC’s output is 95.7% smaller.Source: Table 9 · p. 11, §6.4 · p. 11
- D-RAC planning takes 541.8 seconds versus 2,167.5 seconds for agentic chunking on the same 236-file corpus, a 75.0% reduction.D-RAC’s planning input is 265k tokens versus 326k for agentic chunking, with previews truncated to 200–400 characters.Source: §6.4 · p. 11
- For a 1M-page enterprise corpus, extrapolated chunking costs fall from ∼$3,540 to ∼$785 per full re-index at GPT-4.1 pricing.D-RAC re-chunking does not repay the one-time conversion cost, whereas agentic re-chunking regenerates text each time retrieval strategy changes.Source: §6.4 · p. 11
7 Conclusion
D-RAC extends retrieval-aware chunking to enterprise documents by normalizing inputs to PDF and adding one retrieval-aware multimodal conversion pass. It retains ID-level chunk planning and reports substantial efficiency and scalability results.
7 Conclusion
- PDF normalization and one retrieval-aware multimodal pass extend D-RAC to office formats and scans while keeping chunking as ID-level planning with verbatim text reconstruction.The multimodal pass recovers structure and normalizes tables from page images; chunking preserves W-RAC’s determinism and observability.Source: §7 · p. 12
- 95.7% fewer chunking-stage output tokens, 77.8%–85.6% lower chunking cost, and 75% less chunking time than agentic chunking with frontier LLMs.The cost reductions are 77.8% with GPT-4.1 pricing and 85.6% with Gemini 2.5 Pro pricing.Source: §7 · p. 12
- D-RAC processed 236 PDF documents in 72 minutes with zero conversion or chunking errors, and scales linearly beyond 500 pages.It plans chunks for a 5,000-element document in about a minute.Source: §7 · p. 12
- Durable Markdown and ID-addressable elements separate one-time document understanding from repeatable chunking, supporting retrieval iteration at planning-only cost.The framework also extends naturally to entity-aware chunking, graph-based retrieval, and policy-driven chunk recomposition.Source: §7 · p. 12
A.1 PDF-to-Markdown Conversion Prompt
The PDF-to-Markdown prompt directs conversion into structured Markdown while preserving source content, table distinctions, and heading hierarchy.
A.1 PDF-to-Markdown Conversion Prompt
- The prompt asks for well-structured Markdown conversion of specified PDF pages.It specifies the page range and total page count as prompt inputs.Source: §A.1 · p. 13
- Tables must become natural prose with one sentence per row, using column headers as context and keeping distinct row combinations separate.The prompt prohibits Markdown tables and bullet lists for table data.Source: §A.1 · p. 13
- The prompt requires accurate text preservation, heading hierarchy, and formatting, while instructing the model to ignore images and output raw Markdown only.It also requires a page comment before each page’s content.Source: §A.1 · p. 13
A.2 Chunk Planning Prompt
The chunk-planning prompt asks an LLM to group ID-addressable document elements into semantically coherent chunks under explicit coverage and context rules.
A.2 Chunk Planning Prompt
- The prompt frames chunking as grouping a document section’s identified headers and content blocks into coherent RAG/search chunks.It distinguishes header IDs from content-block IDs and allows optional parent context for hierarchy.Source: §A.2 · p. 14
- Each chunk should cover one topic, include relevant section headers, and keep closely related content together, with a target of 3–8 content blocks.Headers may repeat across chunks to provide context.Source: §A.2 · p. 14
- Every content ID must appear in exactly one chunk, and the output must be a JSON array of ID arrays.The prompt gives an example of the required array structure.Source: §A.2 · p. 14
A.3 Implementation Details
The implementation specifies rendering, model-call, post-processing, and sectioning settings for conversion and chunk planning.
A.3 Implementation Details
- PDF pages are rendered with PyMuPDF at 200 DPI, capped at 1,568 pixels on the longest dimension.Source: §A.3 · p. 14
- Conversion and planning use AWS Bedrock Converse with temperature 0.1, five-page batches, five parallel workers, and up to three exponential-backoff retries.Retries apply to throttling and server errors.Source: §A.3 · p. 14
- Post-processing removes code fences and image references and applies a rule-based table-to-prose fallback.Source: §A.3 · p. 14
- Sectioning uses a 60-element budget, coarsest-first header-level splitting, fixed-size fallback, and small-section merging.Source: §A.3 · p. 14