Document Retrieval-Aware Chunking (D-RAC): Universal Retrieval-Aware Ingestion of Enterprise Documents via PDF Normalization and Multimodal Markdown Conversion

AI summary

Overview

Research area: Document ingestion and retrieval-augmented generation (RAG) — specifically, converting heterogeneous enterprise documents into retrieval-optimized chunks. The paper is posted under Computer Vision (cs.CV), reflecting its reliance on a multimodal model reading rendered page images.

Technical level: Advanced. The paper assumes familiarity with RAG pipelines, dense-vector retrieval, embeddings, chunking strategies, token-based LLM pricing, and multimodal inference.

Scope: One sentence — the paper introduces D-RAC, a pipeline that normalizes any enterprise document to PDF, converts rendered pages to retrieval-aware Markdown with a single multimodal LLM pass, and then chunks by planning over element identifiers rather than regenerating text, evaluated on the 236-document, 795-page PDF subset of the RAG-Multi-Corpus benchmark.

What This Paper Is About

Enterprise knowledge bases are full of documents — PDFs, Word files, presentations, spreadsheets, scans — whose content is trapped inside visual layouts, multi-column pages, and dense tables. Common ingestion pipelines either use rule-based extraction or OCR (which destroys reading order, flattens tables, and loses heading hierarchy) or run a large language model over the raw text to produce coherent chunks (which is expensive and risks hallucination because the model rewrites the document). The goal of D-RAC is to recover enough structure from rendered document pages that the authors' earlier W-RAC chunking machinery applies unchanged, letting one pipeline ingest every renderable document format while paying for LLM text generation only once.

Key Contributions

1. D-RAC, a format-agnostic pipeline. D-RAC extends retrieval-aware chunking to arbitrary enterprise documents by normalizing any input (DOCX, PPTX, XLSX, scanned images, or native PDF) into PDF, then applying a single multimodal conversion pass before parsing and chunk planning proceed exactly as in W-RAC.

2. A retrieval-aware table normalization strategy. Markdown table syntax is forbidden; every table row becomes one self-contained prose sentence that uses column headers as context, with an explicit no-merge rule so that distinct rows (for example, Policy Term=16, PPT=8 and Policy Term=20, PPT=10) are never collapsed into a disjunctive sentence such as "a Policy Term of 16 or 20 years."

3. A scalable sectioning algorithm. Large converted documents are recursively split at header boundaries, preferring the coarsest heading level that fits the 60-element planning budget, with a fixed-size fallback for header-free regions and merging of adjacent small sections. Each section carries its parent-header context into the planning call, enabling chunk planning over documents of 500+ pages.

4. An empirical evaluation and cost analysis. The paper measures conversion throughput, chunking efficiency, retrieval quality, and scalability on the 236-document (795-page) PDF subset of RAG-Multi-Corpus across five enterprise domains, and compares chunking-stage tokens and cost against agentic chunking with frontier LLMs (GPT-4.1 and Gemini 2.5 Pro).

Main Findings

• Zero-error conversion of a full corpus. All 236 documents (795 pages) converted with zero conversion errors across five domains, producing 1,020,219 characters of Markdown. Cumulative conversion time was 3,758.5 seconds (62.6 minutes), and 71.7 minutes wall clock including chunk planning. Average cost was 15.9 seconds per file and 4.7 seconds per page.

• Stable throughput across domains. Effective conversion cost stayed within 3.9–5.5 seconds per page across Aventro Motors, Cendara University, CloudWay-24, Velvera Technologies, and ZX Bank, despite widely varying layouts. The authors attribute this to per-file API latency rather than content complexity dominating for short enterprise documents.

• Linear scalability to long documents. A separate 503-page financial prospectus converted in 21.6 minutes with Gemma-3 27B and 13.4 minutes with Gemma-3 12B, with per-page cost consistent with small documents. A 5,060-element document was planned in 68.7 seconds across 95 parallel section calls.

• Cheap chunk planning. Planning over the whole corpus produced 1,748 chunks from 5,584 elements in 541.8 seconds — 14% of conversion time — at an average of 2.3 seconds per document, with zero chunking errors and every content element covered by exactly one chunk. Average chunk size ranged from 581 to 846 characters across organizations, with an overall average of 705 characters.

• Retrieval beats the traditional PDF baseline. Over 762 queries, D-RAC improved Recall@6 from 0.717 (fixed-size chunks over PyMuPDF extraction) to 0.798 (+11.3% relative), MRR from 0.602 to 0.690 (+14.6%), and NDCG@6 from 0.764 to 0.801.

• Parity with agentic chunking on every overall metric. D-RAC reached R@6 0.798, R@3 0.743, P@6 0.199, P@3 0.321, MRR 0.690, NDCG@6 0.801, NDCG@3 0.726, all at or above the agentic baseline (0.795, 0.726, 0.197, 0.316, 0.682, 0.793, 0.716). The agentic reference chunks were produced from clean structured sources, while D-RAC worked from rendered PDF pages.

• Largest gains on boundary-sensitive query types. Temporal queries (Recall@6 0.85 vs. 0.73 fixed-size), comparative (0.79 vs. 0.72), and analytical (0.61 vs. 0.56) benefited most. Boolean queries (106) were the one category where agentic chunking retained an edge (Recall@6 0.86 agentic vs. 0.82 D-RAC; MRR 0.68 vs. 0.60).

• Retrieval quality is stable across domains. D-RAC's Recall@6 varied by only 0.022 across the four organizations with annotated queries (within 0.790–0.812).

• Output tokens collapse by 95.7%. Agentic chunking produced 270,454 output tokens versus 11,714 for D-RAC planning, while input tokens were comparable (325,855 agentic vs. 264,954 D-RAC) because element previews are truncated to 200–400 characters.

• Cost reductions of 77.8% to 85.6%. Under GPT-4.1 pricing ($2.00/$8.00 per 1M input/output tokens), total chunking cost fell from $2.815 to $0.624 (77.8% reduction). Under Gemini 2.5 Pro pricing ($1.25/$10.00), it fell from $3.112 to $0.448 (85.6% reduction). Agentic chunking spends 77–87% of its cost on output tokens.

• Time falls by 75%. D-RAC's measured planning time of 541.8 seconds compares to 2,167.5 seconds of agentic processing time measured in the authors' earlier W-RAC experiments — a 75.0% reduction.

• Zero hallucination surface during chunking. The 11,714 output tokens contain no prose, only element IDs validated against the element table, so no chunk text can be silently altered during chunking.

• Savings compound on re-indexing. Extrapolated to a 1M-page enterprise corpus, chunking costs drop from approximately $3,540 to approximately $785 (GPT-4.1) per full re-index. Because converted Markdown and element IDs are persisted, changing retrieval strategy requires only ID-level re-planning, never re-conversion of the source PDF.

Methodology in Plain English

The pipeline has four stages.

Stage 1 — Normalize and render. Any document that is not already a PDF is converted to one using standard deterministic tools (headless LibreOffice for office formats, print-to-PDF for HTML, image wrapping for scans). No LLM is involved. Each page is then rendered to a PNG at 200 DPI, downscaled if needed so no dimension exceeds 1,568 pixels, matching common vision-encoder input limits. Rendering costs 1–7 seconds per document in the corpus.

Stage 2 — One multimodal conversion pass. Rendered pages go to a multimodal LLM in batches of 5, with up to 5 batches processed in parallel. The evaluated models are Gemma-3 27B and Gemma-3 12B via AWS Bedrock. The prompt enforces retrieval-aware rules: preserve all text verbatim, forbid Markdown table syntax and convert each row into one self-contained sentence using column headers, never merge distinct rows with "or," ignore images and graphics entirely rather than describing them, emit explicit heading levels, and insert a page-provenance comment. A deterministic post-processing pass strips code fences, removes residual image references, and converts any escaped table syntax to per-row prose. Failed page ranges become inline error markers rather than aborting the document.

Stage 3 — Deterministic parsing and sectioning. The Markdown is parsed into ID-addressable elements (headers h1, h2, ... and content blocks p1, p2, ...). When a document exceeds the 60-element planning budget, a recursive algorithm splits at header boundaries, preferring the coarsest level that fits and descending only where needed, with a fixed-size fallback and merging of small adjacent sections. Each section carries the chain of active ancestor headings from its start position.

Stage 4 — Plan chunks over IDs. The LLM receives only element IDs, truncated text previews (200–400 characters), and hierarchy metadata, and returns chunk plans as ordered ID lists. It is instructed to group 3–8 content blocks per chunk around single topics, reuse header IDs for context, and cover every content ID exactly once. Coverage is verified programmatically; any missing IDs go into a fallback chunk. Chunks are reconstructed locally by mapping IDs back to verbatim converted text, prefixed with the full ancestor-heading chain and a human-readable breadcrumb.

Evaluation setup. All experiments used AWS Bedrock at temperature 0.1, with a maximum of 8,192 output tokens per conversion batch and 16,384 tokens per planning section call, 5-page batches, 5 parallel workers, and exponential-backoff retry (3 attempts). Retrieval evaluation embedded all chunks and queries with Titan Text Embeddings V2 at 1,024 dimensions, used cosine top-K retrieval within each organization's index, and judged a chunk relevant when at least 60% of a supporting fact's content words appeared in it. The 762 queries cover four of the five organizations; CloudWay-24 has no annotated queries in the reference set. The same judge was applied to all three systems compared: fixed-size chunks (1,000 characters with 200-character overlap over PyMuPDF extraction), the benchmark's agentic-chunking reference chunks, and D-RAC's 1,748 chunks.

Why This Matters

Impact on research. The paper argues that traditional PDF ingestion, not embedding quality, is the bottleneck for retrieval over enterprise documents — the fixed-size baseline's Recall@6 of 0.717 versus D-RAC's 0.798 supports that. It also decouples expensive, once-per-document understanding from cheap, repeatable chunk planning, which changes how retrieval strategies can be iterated on. The retrieved-context position of the D-RAC work is that ID-based planning avoids the output-token cost and hallucination surface of agentic chunking.

Real-world applications:

• Enterprise knowledge bases containing mixed formats — product sheets, FAQs, policy and procedure documents, parts catalogs, and service guides — that need one ingestion pipeline rather than per-format parsers.
• Insurance and financial documents, where benefit-illustration tables and fee schedules must remain individually retrievable; the paper explicitly names insurance brochures, product one-pagers, financial prospectuses, and fee schedules.
• Tabular and regulatory content where a cell value stripped of its row and column context is semantically meaningless, so row-level prose conversion protects precision.
• Multi-tenant or policy-driven deployments where chunk size targets and grouping policies change frequently and re-chunking at planning-only cost is preferable to full re-conversion.

Industry relevance. The cost argument is framed in production terms: a measured 77.8% to 85.6% chunking-cost reduction, a 75% latency reduction, and an extrapolated drop from approximately $3,540 to approximately $785 per full re-index of a 1M-page corpus under GPT-4.1 pricing. The pipeline also produces explicit, inspectable artifacts (parsed elements, sections, chunk plans), which the authors present as determinism and observability benefits for production systems.

Future Directions

• Extending to entity-aware chunking, graph-based retrieval, and policy-driven chunk recomposition. The conclusion names these as natural extensions, enabled by the fact that converted Markdown and ID-addressable elements are durable artifacts.

• Closing the boolean-query gap. Boolean queries are the one category where agentic chunking retained an edge (Recall@6 0.86 vs. 0.82; MRR 0.68 vs. 0.60), which is not explained in the paper and suggests a target for chunk planning improvements.

• Evaluating on non-PDF native inputs. The paper claims format agnosticism, but states that because all inputs in these experiments are natively PDF, Stage 1 normalization is the identity. DOCX, PPTX, XLSX, and scanned image inputs are not empirically evaluated here.

• Extending evaluation beyond retrieval. The reported evaluation covers retrieval metrics only; downstream generation or answer quality is not reported. Reporting conversion-cost comparisons for the 12B versus 27B models beyond the single 503-page stress-test timing would also be a natural next measurement.

Target Audience

Engineers and researchers building RAG ingestion pipelines over enterprise document corpora, particularly those dealing with table-heavy or layout-rich PDFs. It will also interest teams evaluating the cost trade-offs between agentic and non-generative chunking, and readers already familiar with the authors' W-RAC work who want the document-format extension.

Authors’ abstract

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.