Baidu released Unlimited-OCR 2 on 27 October 2026. It makes long-document parsing worth reevaluating, but a useful pilot must examine more than whether a file produces text. Test the relationships between pages, the resources consumed by the complete request and the work needed to accept the result.
The practical question is whether the parser can turn your documents into reliable evidence for the next step. A table that continues across a page break, a repeated header or a footnote several pages away can matter more than a clean paragraph. If those relationships are lost, a downstream agent may confidently act on incomplete information.
This guide uses Baidu's current model card, checked on 28 October. It provides a proposed acceptance process rather than an independent benchmark. No model inference or hardware performance test was run for this article.
- 01Bounded attention is a component-level claim.Image decoding, output storage, concurrency and other pipeline stages still need their own resource budget.
- 02Test the joins between pages.Continuing tables, repeated headings and distant references expose failures that isolated-page checks can miss.
- 03Keep provenance with extracted content.A useful result should let reviewers trace a field or passage back to the source page.
- 04Adopt on accepted output, not a demonstration.Include critical-field accuracy, review time, failure handling and total processing cost in the decision.
01 — The releaseWhat changed in the parsing approach
The Unlimited-OCR 2 model card describes Sparse Reference Sliding Window Attention, which keeps bounded working references while parsing long documents. Our evaluation question is whether the resulting extraction preserves the relationships a downstream task needs.
That is different from simply advertising a larger context window. A larger window can postpone a limit while still leaving costs that grow with sequence length. A bounded working representation tries to change that scaling behaviour. The trade-off a buyer should investigate is what information is retained well enough for later pages and what can be lost at a boundary or after a long gap.
Imagine a specification whose early pages define abbreviations used in a table near the end. The parser does not need to reproduce its internal state for a user, but the resulting extraction must preserve the intended meaning and source relationship. A demonstration that emits text from every page is not enough. The acceptance question is whether the output retains the details that the downstream task depends on.
Working references
Ask how working state changes as documents grow, then measure the chosen configuration under realistic concurrency.
Document meaning
Verify that cross-page structures and critical fields survive in the extracted output.
02 — Scope of claimThe complete pipeline still consumes resources
A document parser is more than its attention mechanism. It may decode page images, prepare batches, allocate model weights and buffers, retain output and serve several requests at once. Even if one internal operation has bounded state, those surrounding stages can depend on document length, image resolution or concurrency. “Unlimited” should not be turned into a promise of unlimited throughput or zero resource growth.
Baidu warns that smaller page windows reduce peak memory but can hurt cross-page merging. Test that trade-off directly: keep the same source file and expected relationships, change one setting, and review where errors move. A configuration that finishes successfully may still produce less useful output.
Measure peak memory and processing time for the complete request, with realistic page images and the expected number of simultaneous jobs. Separate model loading from steady-state processing. Keep failed jobs and retries in the cost record. If a long file fails near the end and must be restarted, its operational cost is different from a short successful demonstration. Resource testing should therefore include recovery, not only a successful forward pass.
Report which component was measured. Attention state, GPU allocation, host memory and total job storage are different quantities; none should silently stand in for the others.
03 — Page boundariesBuild tests around the places documents break
Many important document errors occur between apparently readable pages. A table can continue without repeating its column headings. A section number can reset in an appendix. A note can qualify a figure several pages earlier. An extraction that looks fluent page by page can still join those elements incorrectly and produce a misleading combined record.
Create a representative set of boundary cases from consented or synthetic documents. Include a table split across pages, a repeated header that should not become body text, a footnote marker and its explanation, and two sections with similar labels. Record the expected relationship, not merely the expected words. For example, a quantity should remain attached to the correct item and unit after the table is merged.
A useful failure analysis distinguishes recognition errors from association errors. Misreading a digit is different from correctly reading a digit but attaching it to the wrong row. The second can be harder to catch because each isolated token looks valid. Reviewers need the source page and the extraction context together. The parser's quality should be judged by the structure the application will consume, not only by whether a paragraph appears readable.
| Boundary case | Acceptance question |
|---|---|
| Table continues on the next page | Do rows retain the correct columns and units? |
| Header or footer repeats | Is repeated furniture excluded from the document body? |
| Footnote qualifies a value | Can the qualification still be traced to that value? |
| Similar section titles recur | Does each extracted block retain its source location? |
| Appendix changes numbering | Are references resolved without merging unrelated sections? |
Proposed document acceptance cases. These are not measured results for Unlimited-OCR 2.
04 — Evidence chainDo not discard the page that proves the answer
A downstream agent may turn extracted text into a summary, a decision or a database update. If the extraction loses its connection to the original page, a reviewer has to search the entire document to verify a disputed field. That can erase the time saving from automated parsing, especially when only a few values are consequential.
Design the output record so the application can preserve source location where the parser and integration support it. A field should be traceable to a page and, where available, a region or source span. Do not claim a particular provenance feature is present merely because it would be desirable; verify what the selected output format actually supplies and add application-level tracking where necessary.
For a proposed purchase-order workflow, keep the original file, extracted items and review decisions linked. If a quantity is corrected, the correction should not erase the original evidence or make the parser appear to have produced the revised value. This is a design example rather than a measured implementation. Its purpose is to make the human review faster and the final record more explainable, especially when the model's output is plausible but wrong.
A field without a source location can be expensive to verify. Preserve enough provenance to let a reviewer find the evidence quickly, and distinguish extracted values from later human corrections.
05 — Deployment pathUse the documented serving route
The public checkpoint is approximately 3B parameters under MIT, with native Transformers and SGLang instructions. Baidu reports testing on an A800 80GB; that is not an established minimum. Measure your workload rather than extrapolating capacity from parameter count or example hardware.
Model repositories often display generic deployment widgets alongside the author's instructions. The model-specific instructions are the better starting point for unusual architectures and custom code. Verify the runtime version, checkpoint revision and required implementation before relying on a familiar API shape. A server that loads a file successfully has not yet demonstrated correct multipage behaviour.
Keep the first deployment isolated and bounded. Use non-sensitive fixtures, inspect outputs and measure resources before connecting the parser to a business workflow. Custom model code is executable software, so follow the organisation's normal dependency and code-review process. The goal is not to create a new obstacle around open weights; it is to make the runtime configuration reproducible enough that a later quality or performance regression can be investigated.
| Item to record | Why it matters |
|---|---|
| Checkpoint revision | Separates model changes from application changes |
| Runtime and custom-code version | Determines actual architecture and serving support |
| Page/image preparation | Affects input quality and resource use |
| Concurrency and page window | Can change memory and cross-page behaviour |
| Output format | Determines what structure and provenance survive |
Deployment record proposed from Baidu’s model-specific instructions. No minimum-memory claim is made.
06 — Evaluation designMeasure critical fields before overall neatness
A buyer needs an evaluation tied to the intended task. Clean-looking Markdown can conceal a wrong total, omitted exception or swapped row. An overall text score may not give those errors the importance they have in the business process.
Define critical fields and relationships before running the comparison. For a financial document, that might include the amount, currency and which item a line belongs to. For a technical manual, it might include the warning attached to a procedure. Use qualified reviewers for the document domain and retain a clear expected answer. These examples are proposed test design, not advice to automate consequential decisions without review.
Track the time needed to accept or correct the output. A parser that produces more text with more hidden association errors can increase reviewer effort even if its raw throughput is better. Include abstentions and failed documents in the report. If a parser cannot confidently handle a file, an explicit failure that routes it to manual processing may be operationally preferable to a complete-looking but unreliable extraction.
Count correct critical fields and relationships, then measure the review needed to approve the result. Keep a separate category for failures and unsupported document types.
07 — Downstream useParsing success does not authorise an action
Document content can include instructions, links and requests that were never intended to control an AI agent. Once parsed, that content remains evidence from a document. It should not become a new authority to disclose data, change an account or override the user's task. The same separation applies whether the document was processed by OCR, a vision model or a human transcription service.
A useful first integration returns structured draft data for review. A subsequent step checks required fields, reconciles conflicts and determines whether an external change is authorised. Keep those stages visible. If the parser reads a note asking for a bank-account change, the extraction can preserve the note without granting the agent permission to execute it.
This also makes recovery easier. A failed parser job can be retried or replaced without automatically repeating an already completed business action. Store the extraction version and the reviewed record separately, and inspect destination state if a later write becomes uncertain. The parser is one component in a workflow whose correctness includes permissions, duplicate prevention and a verified final result.
Extract instructions as document content. Execute actions only under the user’s or workflow’s existing authority, with validation of the resulting state.
08 — Pilot decisionCompare the whole review workflow
A practical pilot compares Unlimited-OCR 2 with the current parser on the same representative documents. Record the input preparation, runtime and output format, then review critical fields without relying on the model's own confidence as the verdict. Include documents that are long because they contain repeated simple pages and documents that are long because their structure is genuinely complicated.
Measure accepted documents, review time, resource use and recovery effort. The complete cost includes failed attempts and the work required to repair output. If the new parser is better only on a particular document class, route that class deliberately instead of replacing every existing path. A specialised improvement can be valuable without becoming the universal default.
Unlimited-OCR 2's architecture makes long-document work worth reevaluating. The strongest adoption case will come from the joins it preserves, the evidence it retains and the review it saves on your files. Keep the vendor's scaling claim separate from your application's result. That gives the team a clear reason to deploy, revise the configuration or retain the existing parser.
Deploy for the document classes that pass the acceptance criteria. Keep the failed classes and their manual or alternative route visible rather than hiding them inside an average.
Continue with the original Unlimited-OCR release, visual document retrieval, safe agent recovery. For implementation support, explore our AI transformation services.
Make long documents easier to verify, not merely easier to ingest.
The useful result is an extraction that preserves meaning and evidence at an acceptable total cost. Test page boundaries, critical fields and recovery in the full workflow, then adopt the model where those results support it. Keep the scaling mechanism and the business outcome as separate claims.