What problem does the paper address?
Retrieval-augmented generation (RAG)[4], where an LLM answers questions using documents retrieved from an internal knowledge base, is being tried in many organisations. Its quality often depends less on the model than on ingestion: reading documents, splitting them into meaningful pieces (chunking), and storing them in a searchable form.
Enterprise documents come in mixed formats: PDFs, Word files, presentations and scans. Their content is locked inside multi-column pages, complex layouts and dense tables. According to the authors, rule-based extraction and OCR destroy reading order, flatten tables and lose heading hierarchy. Fully agentic chunking, where an LLM reads extracted text and rewrites it into chunks, runs up high token costs and risks hallucinating content that is not in the source.
The paper proposes an ingestion approach that absorbs format differences while keeping cost and hallucination risk down.
What does it propose?
The core idea is: normalise everything to PDF first, and never rewrite source text during chunking. D-RAC extends the authors' earlier W-RAC framework[2] to arbitrary document formats.
The pipeline has three stages. First, every input document is converted to PDF, exploiting the fact that virtually every format has a faithful, deterministic PDF rendering. Second, the rendered pages go through a single multimodal LLM pass that converts them into retrieval-optimised Markdown. Tables are rewritten as self-contained prose statements, and heading hierarchy is preserved. Third, chunking follows W-RAC exactly: deterministic parsing into ID-addressable units, then a lightweight LLM step that plans chunk boundaries over identifiers rather than over the text itself.
Because source text is not regenerated at the chunking stage, the authors argue that D-RAC keeps W-RAC's advantages in cost, determinism and observability.
What did it show?
The results stated in the abstract are limited to the following. The evaluation used the 236-document, 795-page PDF subset of the RAG-Multi-Corpus benchmark, spanning five enterprise domains. D-RAC converted and chunked the whole corpus in 72 minutes with no errors, producing 1,748 retrieval-ready chunks.
Compared with agentic chunking using frontier LLMs, D-RAC reduced chunking-stage output tokens by 95.7%. Chunking cost fell by 77.8% at GPT-4.1 pricing and by 85.6% at Gemini 2.5 Pro pricing, and chunking time fell by 75%. The authors also state that D-RAC scales linearly to documents of 500+ pages.
This paper is a preprint that has not been peer reviewed, and the results above are the authors' claims.
A worked example
Consider a department building search over its internal procedures and past reports. Procedures are Word files, reports are scanned PDFs, and training material is in presentation format.
Letting an LLM rewrite extracted text into chunks
Different extraction tools are used per format, and the resulting text is fed to an LLM that rewrites it into meaningful chunks. If table values break during extraction, or the LLM adds wording that is not in the source while summarising, it is hard to trace where it happened. Cost grows with every new document.
Normalising to PDF and planning chunks over IDs
All documents are turned into PDF and converted page by page into Markdown. At the chunking step the LLM only decides boundaries by looking at a list of IDs; it does not rewrite the text. Each chunk can be traced back to its IDs. However, the conversion step, which rewrites tables as prose, does involve the LLM generating text.
In the second approach, the guarantee that source text is not rewritten applies only to chunking. The accuracy of the conversion step has to be checked separately. Keeping that distinction in view is the key point when deciding whether to adopt it.
What is not new, and where are the limits?
Normalising documents to PDF, converting page images to Markdown with a multimodal LLM, and chunking after preserving structure are all practices already in use. The chunking method is W-RAC unchanged; what D-RAC adds is the normalisation and conversion in front of it. The authors themselves describe D-RAC as an extension of W-RAC.
The largest limit concerns what was evaluated. The abstract reports processing time, absence of errors, chunk count, and reductions in tokens, cost and time. It does not report retrieval accuracy or final answer quality. Lower cost means little in practice if retrieval quality drops. The abstract does not show the conditions on this point.
Next, rewriting tables as self-contained prose is a step in which the LLM generates text. Transcription errors in numbers or misreadings can enter there, and the abstract does not say how conversion accuracy was checked. The comparison is also limited to agentic chunking; there is no retrieval-quality comparison against rule-based ingestion. The evaluation covers a subset of one benchmark, and the authors are the same group behind W-RAC.
Why is this topic getting attention now?
At collection time the paper had 35 upvotes on Hugging Face Daily Papers. It had 0 GitHub stars, and no public repository could be confirmed. Upvotes measure how much readers noticed a paper; they say nothing about whether the method is correct or effective.
In this collection run no independent papers on the same question were found, so the cluster size was 1. This looks less like a topic taking shape and more like a single paper that caught the eye. Its keywords include chunking, ingestion, markdown, multimodal and enterprise.
The reason for the interest is easy to see. Many organisations that have tried RAG stumble on ingestion rather than on model choice. Handling business documents full of tables and multi-column layouts is a shared pain point, and the paper puts concrete percentages on cost savings.
Where does it connect to pharma and regulatory work?
Pharmaceutical documentation is a textbook case of the heterogeneous enterprise documents this paper targets. SOPs, clinical trial protocols, investigator's brochures, submission documents and quality records vary in format and layout and are full of tables. In RAG projects for internal search or inquiry handling, ingestion quality directly sets answer quality.
The idea worth taking away is to separate, and record, the stages at which source text is rewritten. A design that does not regenerate text at chunking helps trace an answer back to its source document. The table-to-prose conversion, however, is generation. In documents that contain doses or specification limits, the converted output needs to be checked against the original tables.
For regulated uses, conversion accuracy has to be verified, the version of the model used for conversion has to be recorded, and each converted output has to be linked to its source document. The abstract does not address these, so any organisation considering adoption would need to establish them itself.
Summary
D-RAC is a preprint describing an ingestion pipeline that normalises any document to PDF, converts it to Markdown with a multimodal LLM, and chunks it without rewriting the source text. The authors claim large savings in cost and time compared with agentic chunking. Retrieval and answer quality, however, are not reported in the abstract, and the accuracy of the table-to-prose conversion has not been shown. It is worth reading with an eye on where generation happens, not only on the cost figures.