One-Shot Document Parsing: RAG Without Page-by-Page OCR

Run any parser page by page and four failures appear no matter how good the parser is.

A table that continues across a page break becomes two tables. The second inherits no header, so its columns are unlabeled, and a chunker downstream now has a block of numbers with no idea which row belongs to which line item. A section heading that lands at the bottom of page 4 orphans from the body that starts on page 5, so the chunk carrying the substance carries no title and retrieval loses the strongest topical signal in the document. Footnote markers separate from footnote text across the same boundary, which in a prospectus or a drug label is where the qualifying condition lives. Running headers and footers get re-emitted on every page as if they were content, seeding the index with one near-duplicate fragment per page.

None of these is fixed by a better OCR engine. They are fixed, or not, by what the parser is allowed to see at once. Teams usually reach for heuristics instead: overlap windows, header propagation rules, table stitchers that pattern-match column counts across consecutive pages. Those are inference over information that was already discarded, and they fail exactly where documents are irregular, which in regulated corpora is most of the time.

The damage does not stay in the parse. It propagates through chunking, where a broken table cannot be chunked back into shape, into embeddings that faithfully encode the corruption, and out through citations that point at the wrong page because the page mapping was the only structure the pipeline preserved. We covered the parser landscape itself, including the accuracy gap between heuristic and agentic engines, in Reducto vs LlamaParse vs Docling. This post is about the layer above that choice: what the parser is fed.

There is a second fork worth knowing about before you commit to any of this. If the answers in your corpus live in charts, diagrams or page geometry rather than in text, no parser recovers them, and embedding the rendered page directly is the better architecture. That is the argument in visual RAG vs OCR with ColPali. One-shot parsing solves boundary loss. It does not solve pixels-as-meaning.

The reason nobody shipped whole-document parsing earlier is the KV cache. A vision-language parser decodes markdown token by token, and with standard attention the cache grows with every token produced. Forty pages of dense text is one very long decode, so memory climbs through the document and per-token latency climbs with it. The page loop is not a design preference. It is a workaround for a cost curve.

Baidu's Unlimited-OCR (arXiv 2606.23050, submitted 22 June 2026, CC BY 4.0) attacks the curve rather than the symptom. Its decoder replaces every attention layer with a sliding-window variant the paper calls R-SWA, window width 128. Because each layer attends only within its window, the cache is bounded by window width times layer count and not by document length. The abstract's claim is precise: the model maintains a constant KV cache throughout the entire decoding process, and can transcribe dozens of pages of documents in a single forward pass under a standard maximum length of 32K.

Two consequences follow from that shape, and the paper reports both. Baseline inference memory scales linearly with the document while Unlimited-OCR's stays fixed. And the baseline shows a latency spike when the KV cache length crosses a certain alignment boundary, causing an abrupt drop in data transfer efficiency, which a constant cache never reaches. Sliding-window attention creates its own serving quirks in other stacks, which we documented from the opposite direction in full prompt re-processing on hybrid SWA models.

The rest of the architecture matters for reading the results:

The obvious question is what a 128-token window costs when a table header sits far outside that window from the row being decoded. The paper does not answer it. There is no ablation, and no experiment isolating cross-page reference resolution. That is the first thing to put on your own test plan, not a settled property.

On OmniDocBench v1.5 the headline of Baidu's own unreviewed technical report is a 6.22 point gain over the model it started from. Every figure in the two tables below is self-reported by that report.

Read the baseline row carefully. DeepSeek-OCR (arXiv 2510.18234) is the exact checkpoint Unlimited-OCR was continue-trained from, at the same parameter class. So the +6.22 is a before-and-after on one lineage, not a win against the field. Against the field, the same table puts DeepSeek-OCR 2 at 89.17, Qwen3-VL at 235B on 89.15, OCRVerse at 88.56, dots.ocr at 88.41 and Gemini-2.5 Pro at 88.03. The nearest contender is the baseline's own successor model, and the reported margin against it is 4.06 rather than 6.22.

Now the part that changes how you should use this result. That continue-training run changed two things at once: the attention mechanism and the data. It ran 4,000 steps at global batch 256 on 2M PDF-document-specific examples, with the encoder frozen so every parameter update landed in the decoder. The paper then states that this demonstrates the effectiveness of R-SWA. It does not. The word "ablation" does not appear anywhere in the paper. There is no run with the 2M examples and standard attention, and no run with R-SWA and the original data mix.

That confound is not academic nitpicking, it is the decision. If most of the 6.22 came from 2M in-domain PDFs, the lesson is that domain-specific continued training on documents pays, and it pays for any parser you can fine-tune, including the one you already run. If most of it came from the attention change, the gain transfers to your corpus for free. The published evidence cannot distinguish these, so do not re-architect an ingestion pipeline on the assumption that it was the architecture.

The v1.6 result needs the same treatment. Unlimited-OCR self-reports 93.92, which is the top row, and coverage has turned that into a state-of-the-art claim.

The lead is 0.02 points over Qianfan-OCR, which is Baidu's own platform brand. A 2B model has a better edit distance than the winner, 0.037 against 0.042, meaning it makes fewer raw transcription errors. Four models sit inside 0.66 points. This is a saturated benchmark where the top of the table is a coin flip, and any decision you make on a two-hundredths-of-a-point difference is noise-driven. The paper also explains why it keeps reporting v1.5 at all: v1.5 provides official metrics from more classic models, including its own baseline.

The number circulating everywhere is 35%. It comes from a table the paper itself titles a theoretical inference performance ceiling comparison, and the setup fixes the prefill length at 10 tokens.

The first row is the interesting one. At 256 output tokens the two models are within 0.2 tokens per second of each other, which is the point: the entire advantage is the shape of the curve as the cache grows, and it only opens up over long decodes. It is also measured with a 10-token prefill, and a 10-token prefill is not a page of a document, let alone forty.

The measured number on real documents is smaller and the paper reports it plainly: 5580 tokens per second against 4951 at 512 concurrency in Base mode on OmniDocBench, which it describes as a 12.7% speed increase, with the immediate caveat that the average document length in that benchmark is relatively short. So the honest statement is that one-shot parsing bought about 12.7% on short documents, and the theoretical curve suggests the gap widens on long ones, but nobody published the long-document throughput measurement that would confirm it.

Plan capacity on 12.7%. If a vendor comparison quotes you 35%, they are quoting a synthetic ceiling.

This is the section the coverage skips. The paper's long-horizon evaluation is a single table over an in-house test set with no fewer than ten books per category.

Four things about this table are load-bearing.

It is vendor self-reported on an unreleased private set. Not a benchmark, not reproducible, not independently checked. Treat every value as a vendor claim.

There is no baseline row. Nowhere in the paper's long-horizon evaluation is there a page-by-page comparison. The central thesis of the release, that one-shot beats page-by-page on long documents, is not tested in the paper against page-by-page.

Distinct-n is a repetition metric, not a correctness metric. The paper defines it as the ratio of unique n-grams to total n-grams in the generated text, so it detects degeneration, the failure where a long decode falls into a loop. Those high nineties mean the model did not start repeating itself. They do not mean it read the page correctly.

The Distinct-20 series is non-monotonic: 97.49% at 10 pages, then 99.92% at 15. Quality does not improve by adding pages. That is small-sample noise, and it tells you the confidence interval on this table is wide.

The most decision-relevant column is the one the paper summarizes as remaining below 0.11. Edit distance runs 0.0362 at 2 pages to 0.1069 at 40 and above, roughly a threefold increase. For a regulated corpus that number is your batch-size constraint: transcription error grows with the size of the one-shot window, so the right page count per call is wherever your own error curve is still flat, not wherever the context limit is. The context-length behavior here rhymes with what we found in long-context LLM performance: the advertised window and the usable window are different numbers.

There is a real cost to putting many pages in one context, and the paper names it. The encoder retains two resolution modes: Base at 1024x1024, used for multi-page, and Gundam dynamic resolution for single-page work. One-shot parsing forces the lower-fidelity mode, because N pages have to share a finite context.

The paper's own error analysis is precise about where that lands: examining cases with repeated errors, most occur where small text in the PDF is difficult to discern, primarily due to the use of DeepEncoder's Base mode at 1024x1024 resolution under multi-page conditions, rather than R-SWA losing direction in the long-horizon parsing process. Its stated limitation is that the approach cannot achieve truly unlimited parsing under a finite context.

That inverts the usual assumption. One-shot parsing is strongest exactly where structure spans pages and weakest exactly where the text is small and dense. Financial statement footnotes, drug labels, engineering drawing annotations and dense legal schedules are the documents most likely to break in multi-page mode, and they are also common in the corpora that most need accurate parsing. The practical answer is a hybrid: route page-spanning structural documents through one-shot parsing, route dense small-text pages through single-page high-resolution parsing, and decide per document class rather than per corpus.

The repository is MIT licensed, created 2026-06-18, and carried 21,955 stars when we checked the GitHub API on 2026-08-04. Open weights under a permissive license means it runs inside your own perimeter with no document leaving the network, which for healthcare, finance and legal corpora is usually the deciding constraint rather than a nice-to-have. That part is straightforwardly good.

Everything else needs verification you have to do yourself.

There is no published GPU sizing. The README states no parameter count and no GPU memory requirement. The only GPU figure in the paper is the training cluster, 8x16 A800 GPUs, which is not a serving number. Articles asserting it runs on a single specific card are not sourcing that from anywhere primary. Measure the footprint at your own page count and resolution mode. The MoE structure is relevant here: 3B total parameters with roughly 500M activated means compute and memory scale differently, so a dense-model rule of thumb will mislead you in both directions.

Verify the engine actually carries the constant-cache path. The paper says KV cache management for R-SWA was implemented in the Transformers library with corresponding support and optimizations in the SGLang inference engine. The README additionally advertises vLLM. The constant cache is the entire benefit, so confirm on your chosen engine that memory stays flat as page count rises rather than assuming the property travels with the weights.

Budget for output plumbing. The repository ships an OmniDocBench post-processing script whose job is stripping detection markers from raw output, so the model emits <|det|> markers your ingestion has to handle. Multi-page inference renders PDF pages through PyMuPDF, and the two image configurations differ in exactly the way that matters: gundam uses base_size=1024, image_size=640, crop_mode=True, while base uses base_size=1024, image_size=1024, crop_mode=False. The README pins its dependency versions, which is a reasonable signal about how tightly coupled the implementation is to specific library builds.

The mechanism is the real contribution. A constant KV cache turns whole-document parsing from a cost curve nobody wanted to pay into a tractable operation, and page-by-page ingestion genuinely is a structural flaw rather than a tuning problem. That argument stands on its own, and it stood before this model shipped.

The evidence for this particular implementation is thinner than its reception. The accuracy gain confounds architecture with 2M extra in-domain training examples and no ablation separates them. The v1.6 top spot is a 0.02-point lead over a sibling model that a smaller competitor beats on edit distance. The long-document results are vendor self-reported on an unreleased set with no baseline row and a non-monotonic series. The 35% throughput figure is a synthetic ceiling at a 10-token prefill, and the measured number is 12.7% on short documents. None of that makes the model bad. It makes it unproven on the specific claim that matters to you, which is whether it parses your documents better than what you run today.

So treat it as a candidate, not a conclusion. Open weights under MIT means you can answer the question yourself, on your own corpus, inside your own network, which is more than any hosted parser offers. For where parsing sits relative to chunking, retrieval and evaluation, start from our RAG systems pillar, and for the retrieval layer that decides what to fetch once the parse is clean, see agentic RAG and agent-controlled retrieval.

Particula Tech builds on-premise and private RAG for regulated environments, where a parser change is a compliance event as much as an engineering one. The work we do here is the shadow diff: your documents, your questions, your perimeter, and a number you can defend to a change board before an index moves.