Chunkless RAG relocates the retrieval decision into the layout parser

Start with what runs at query time. Docling turns a PDF into a structured representation that keeps headings, tables and section hierarchies, and the agent walks that structure instead of running cosine similarity over chopped-up text ^[2]. Every query therefore opens with a choice of which node to read. The dev.to author's argument is that this choice is still a retrieval or classification problem underneath, now with agent call overhead added to it ^[8].

That leaves two upstream stages that can fail independently. If the extracted tree is wrong, an answer-level score tells you the answer was wrong and not whether the parser mis-read the layout or the agent opened the wrong section. Separating the two needs labelled trees for a sample of the corpus, a second annotation job.

The post lists the corpora it expects this to fail on: legal contracts with inconsistent heading hierarchies, scanned PDFs where Docling's layout parser confidently returns garbage, internal wikis where someone put the entire product spec in one enormous table, support ticket exports, Slack export dumps and email threads ^[4]. Docling will return a hierarchy for a scan either way. On corpora like these, the author writes, you have replaced lost context from arbitrary splits with hallucinated structure from a bad parser, and the second failure is harder to detect because it looks like the system understood the document ^[5].

The author also puts structure loss second in the causal order. In most pipelines the post has seen documented, retrieval fails because the query and the relevant passage do not share enough lexical or semantic overlap for retrieval to work at all. That shows up hardest on multi-hop questions whose answer sits in sections semantically distant from the query ^[7].

One commenter named a project called Knowhere that combines MinerU parsing with BM25 and prompt mutation and gets good results, according to the post ^[10]. In that arrangement the parse output does not decide which sections the model is allowed to see ^[17]. BM25 and the dense vectors score text, and prompt mutation works the query side ^[9].

Against those six messy corpus types, the post names three document classes where it expects structure navigation to win ^[16]. The example it gives is knowing that the answer to "what is the data preparation methodology" lives in section 2.2 and navigating there directly, instead of hoping the embedding space put the question and that section close together ^[12]. A legaltech commenter said their team is building exactly this kind of system, and the post grants that for structured legal documents the argument is more plausible ^[13]. Its own reformulation is "for well-structured documents, structure-aware retrieval outperforms flat chunking" ^[14].

This is one developer's argument: it attributes the term to IBM without citing IBM documentation, and it puts no benchmark figures behind either approach ^[15]. I would run structure navigation where I can spot-check extracted trees against the source pages and where section numbering is consistent across the corpus. I would keep BM25 in the path regardless. The post's wider complaint is that the brand encourages teams to treat chunking strategy as the core failure in their pipeline ^[18].