A 1.3B Model Reads Your Scans. The Interesting Part Is the 2B Model Checking Its Work
Synergised Consulting Ltd
Last Updated: 28 October 2026
OpenBMB has released two open-source models that split document reading into two jobs: a 1.3B parser for messy scans, and a separate 2B checker that decides which extracted pages a human must review. According to OpenBMB's own documentation [1], the checker scores every region of a parsed document from 0 to 1 and works across different OCR engines. That separation is what makes document handling safe enough to put near financial records.
What OpenBMB Actually Released
MiniCPM-OCR 1.0 is the first OCR-specific model in OpenBMB's MiniCPM-V family, at 1.3 billion parameters. According to OpenBMB's documentation [1], it parses Chinese and English documents and PDFs covering text, tables, formulas, charts and seals, and handles genuinely difficult inputs: scans, photographs, curved pages, skewed pages and re-photographed documents. It outputs Markdown or JSON, which means its output can drop straight into the systems downstream rather than needing another conversion step.
The performance figures are OpenBMB's own, and the company publishes a reproduction guide alongside them [1]. It reports a score of 93.68 on Real5-OmniDocBench, a real-world document-parsing benchmark, and 54.7 on OCRBench v2. With its DSpark decoding acceleration it reports 1.49 times the throughput of PaddleOCR-VL-1.6 and 3.62 times that of MinerU2.5 Pro, around 1.2 pages per second on the hardware it lists. Treat these as the vendor's published results, checked against its released weights rather than against independent audit; the reproduction guide exists precisely so a reader can do that checking themselves.
It runs where a small business already has capacity
The deployment story is ordinary in the best sense. In the discovery and build work behind Synergised's own agent deployments, the automations that stick are the narrow ones running on infrastructure the business already controls, not platform subscriptions that meter every page. That is what makes this release fit that pattern. According to OpenBMB [1], the model supports vLLM, SGLang, llama.cpp and Ollama from day one, ships in quantised versions, and has day-zero support across twelve chip vendors through FlagOS. A 1.3B model running under llama.cpp or Ollama runs on hardware a small business may already own, which is what separates this from a per-page cloud API bill: the parsing cost stops scaling with volume.
Why the Checker Is the Story
The second model, MiniCPM-OCR Jev, does no parsing at all. It takes an image and its OCR result and returns a per-region quality score from 0 to 1, distinguishing the regions that are probably right from the ones that need eyes. According to OpenBMB's documentation [1], a 2B-parameter Jev scores 93.6 on JevOCRBench, above JEV-35B-A3B at 90.1 and close to Qwen3.5-397B-A17B at 93.8; across parsing results from four different engines including MiniCPM-OCR 1.0, GLM-OCR and PaddleOCR-VL-1.6, its scores range from 91.9 to 93.4. That range is the point: Jev is model-agnostic, so a business can keep the parser it already has and bolt the checking layer on without swapping stacks.
The distinction between the two failure modes is what makes this architecture worth copying. In document workflows a false negative, sending a correct page to a human, costs a few minutes of review. A false positive, waving a wrong page through, puts a wrong number in the ledger, and nobody sees it until a payment, a VAT return or a reconciliation breaks. An ACM paper formalising exactly this problem [2] studied invoice validation on 11,253 real-world enterprise invoices and reached 73% auto-validation coverage while holding the field-level false positive rate below 1%. The paper's framing matches Jev's design: extraction accuracy alone is not the product, the trustworthiness decision is, and in financial workflows an undetected extraction error can trigger an irreversible erroneous payment while a flagged page only costs reversible review time.
What this looks like in a real workflow
To make the shape concrete, consider an illustrative purchase-invoice pipeline. Today a typical setup parses each invoice, matches it against a purchase order, and pays on match, which means a misread total can pass because both sides of the match were read by the same fallible process. With a scoring layer, each parsed region carries a confidence number: totals and bank details above threshold pass untouched, anything below goes to a short review queue sorted worst-first. The ACM study [2] shows the trade can be run with a bounded error rate rather than hope, which is the difference between automation an owner can defend and automation that merely works until the day it does not.
The Operating Point for a Small Business
The research community has converged on the same measurement discipline. An arXiv survey of invoice information extraction [3] argues that document automation should be judged on business KPIs, not benchmark scores: the straight-through processing rate, the manual review rate and, critically, the false auto-approval rate, with performance stratified by document conditions such as scan quality and unseen supplier layouts. Those three numbers are measurable in any business that parses documents today, before adopting anything new: what share of pages flow through untouched, what share a human reads, and how many errors slipped through to someone downstream.
That is the bridge from news to operating practice. A pair of open models does not make document automation trustworthy on its own; what changes is that the components for the trustworthy version, parse, score, route, are now free, small enough to run locally, and published with the numbers to reproduce. The decision it hands an owner is a threshold, not a purchase: how much parsed output is good enough to act on without a human, decided by someone who owns that answer rather than by whichever error surfaces first.
Sources
- [1] OpenBMB, MiniCPM-OCR repository and documentation (benchmark results are OpenBMB's own published figures; reproduction guide available) ACM, Safe Invoice Data Extraction: FPR-Constrained Validation with VLM Denoising arXiv, Invoice Information Extraction: Methods and Performance Evaluation
