This paper introduces D-RAC, a new preprocessing method for getting every kind of enterprise document format (PDF, Word, presentations, scanned copies) into a RAG (Retrieval-Augmented Generation) system. The core idea: standardize every document to PDF first, convert it into "retrieval-optimized Markdown" in a single multimodal-LLM pass, and then chunk by identifier (ID) rather than regenerating the text. Per the abstract, this cuts chunking-stage output tokens by 95.7% and reduces cost by 77.8–85.6%.
To put internal knowledge into a chatbot or search system, a company first has to break its documents into small, searchable pieces (chunking). But real enterprise documents come in all shapes: PDFs, Word files, PowerPoint decks, and even scans of printed paper, all mixed together. On top of that, the information inside is trapped in complex visual layouts, multi-column pages, and dense tables.
The trouble is that it's very hard for a machine to unpack these documents "in the order they're meant to be read." The paper argues that both of the existing approaches have real limitations.
First, rule-based extraction or OCR (Optical Character Recognition). This is like blindly scanning a newspaper page top to bottom: it breaks the reading order, flattens tables into mush, and loses the heading hierarchy. Picture reading a two-column page straight from top-left to bottom-right, and you can see how the context gets tangled.
Second, "fully agentic chunking," where an LLM handles everything on top of the extracted text. The quality can be better, but because the LLM has to rewrite the text from scratch, the token cost is high and there's a real risk of hallucination, making up content that isn't there.
In short: push for accuracy and your cost and hallucination risk climb; go cheap with rule-based methods and the document structure falls apart. D-RAC takes aim at exactly this dilemma.
D-RAC extends W-RAC (Web Retrieval-Aware Chunking), a framework the authors previously published for web documents, to arbitrary document formats. As the name says, it's "Retrieval-Aware" chunking. Here's how it works, in everyday terms.
Step 1: standardize every document to PDF. Whether it's Word, PPT, or a scan, the method leans on the fact that virtually every format has a "faithful, deterministic PDF rendering" — deterministic meaning you get the same result every time. It's like how any file, once sent to a printer, comes out as the same shape on paper. You funnel the diversity of inputs through a single gateway: PDF.
Step 2: a multimodal LLM — a model that reads not just text but images and layout together — makes a single pass over the rendered pages and turns them into "retrieval-optimized Markdown." Two things matter here. Tables are rewritten as "self-contained prose" that makes sense on its own, without surrounding context. For example, a single cell in a "Quarter / Revenue" table becomes a complete sentence like "Q3 2026 revenue was …," so that even if it later gets sliced off into a fragment, its meaning survives. At the same time, the heading hierarchy is preserved as is.
Step 3: the resulting Markdown is chunked exactly the way W-RAC does it. First it's parsed deterministically into "ID-addressable units." Think of it as putting a numbered tag on each document fragment. Then a lightweight LLM looks at a short text preview of each fragment (roughly 200–400 characters) along with the heading-hierarchy information, and plans which fragments to group and how (chunk planning). The key is that instead of rewriting the original text, the plan's "output" is expressed using only the fragments' identifiers (numbers). It's like a librarian who, rather than copying out a book's entire contents, skims the cover summary and classification info but writes only the call number into the final catalog.
The decisive advantage of this design is that "the original text is never regenerated during chunking." The LLM consults the previews and hierarchy information but emits only numbers as output, so there's no room to make up content (preserving observability) and the output token count is tiny (low cost). That said, the deterministic parts here are the parsing that splits Markdown into fragments and the reconstruction step that re-stitches the text according to a given ID plan. The planning itself — deciding which fragments to group and how — is still generated by the LLM (the paper's experiments use temperature 0.1), and outputting only IDs does not guarantee that the chunk composition will be identical on every run. Even so, D-RAC keeps the observability and low cost that W-RAC enjoyed on the web, while making "any renderable format" a first-class input.
The paper evaluated D-RAC on the PDF subset of the RAG-Multi-Corpus benchmark. This subset spans 236 documents across five enterprise domains, totaling 795 pages. The figures reported in the abstract are as follows.
| Metric | Result (per abstract) |
|---|---|
| Total corpus conversion + chunking time | 72 minutes, zero errors |
| Retrieval chunks generated | 1,748 |
| Chunking-stage output tokens | 95.7% reduction |
| Chunking cost savings | 77.8% (GPT-4.1 pricing) – 85.6% (Gemini 2.5 Pro pricing) |
| Chunking time | 75% faster |
| Scalability | Scales linearly even for documents over 500 pages |
The comparison here is against "agentic chunking using a frontier LLM." In other words, measured against letting a state-of-the-art large model do the chunking on its own, D-RAC's headline achievement is cutting output tokens to about a twentieth while processing the 795-page corpus with zero errors. Dropping cost to roughly a fifth under GPT-4.1 pricing and about a seventh under Gemini 2.5 Pro pricing is a saving that companies handling large document volumes feel immediately.
The phrase "linear scaling" matters too. It means that even past 500 pages, processing time grows in proportion to page count rather than exploding. In enterprise settings — where thousand-page manuals, contracts, and rulebooks are common — that offers a predictable cost structure.
Judging from the abstract alone, a few points deserve to be stated honestly.
ONTLE is a "dispatched AI project manager SaaS" aimed at taking repetitive work off the hands of small businesses and solo founders. In a product like that, RAG over internal documents is the foundation for "getting the AI to read company materials accurately and answer from them." D-RAC's approach offers some practical lessons here.
First, the idea of absorbing input-format diversity through a single "PDF standardization" gateway fits the reality — where each client has Word, Excel, PPT, and scans all jumbled together — very well. It reduces the burden of building and maintaining a separate parser for every format.
Second, the principle of "never regenerating text during chunking" matters for both cost and reliability. In a product like an AI PM that has to process large volumes of documents repeatedly, cutting output tokens lowers operating cost, and when the result of a grouping is left as fragment numbers rather than freshly written sentences, it's easier to trace "why was this fragment grouped this way" (observability). The more a tool has to explain its reasoning to customers, the more this observability matters as much as quality.
Third, the strategy of unfolding tables into self-contained prose directly helps retrieval quality. The core information in real business documents is often concentrated in tables, and storing it in a form whose meaning survives even when sliced into fragments makes the evidence citations behind an answer more stable.
That said, from the ONTLE standpoint the limitations above still hold. The final retrieval and answer-quality metrics have to be checked separately in the body of the paper, and the accuracy of the Markdown-conversion step is best validated with a small-scale pilot on your own documents before adoption. The cost-savings figures are impressive, but the right attitude is that reproducing them on our own data is a separate question.
Because even when formats differ — Word, PPT, scans, and so on — almost every format can produce a "faithful PDF rendering that comes out the same every time." Funneling the diversity of inputs through a single PDF gateway lets you unify the later stages without building separate processing logic for each format.
Per the abstract, compared to agentic chunking using a frontier LLM, it cut chunking-stage output tokens by 95.7%, reduced chunking cost by 77.8% under GPT-4.1 pricing and 85.6% under Gemini 2.5 Pro pricing, and shortened chunking time by 75%.
D-RAC does not regenerate the original text during the chunking stage. The LLM consults a short text preview of each fragment (roughly 200–400 characters) and the heading-hierarchy information, but it expresses the plan's output using only the identifiers (numbers) attached to the fragments, which reduces the room to hallucinate by writing new content. That said, the plan itself — deciding which fragments to group and how — is generated by the LLM (the experiments use temperature 0.1), so the chunk composition is not guaranteed to be exactly identical on every run. The Markdown-conversion step before it, too, still depends on the multimodal model's comprehension.
The figures the abstract offers are mainly about the cost, speed, and processing stability of the chunking stage. Unfolding tables into self-contained prose and preserving the heading hierarchy is designed to favor retrieval, but since the abstract does not spell out concrete numbers for final retrieval and answer quality, you'll need to check the detailed evaluation in the body of the paper.