A 1.3B OCR slips into production, relying on a 2B model to score it

The most troublesome thing about OCR is that it fails quietly. Agents now read PDFs, invoices, and papers all day long; if one table is extracted incorrectly, every subsequent step carries the error forward. The tweet author elvis gives an example: OpenBMB and ModelBest's MiniCPM-OCR splits parsing and review into two models.

First, look at the parser. MiniCPM-OCR 1.0 has only 1.3B parameters. It handles Chinese and English documents and PDFs, including scans, photos, curved pages, skewed pages, and re-photographed files, and it also supports key information extraction. Official numbers: Real5-OmniDocBench 93.68, OCRBench v2 54.7. Throughput is 1.2 pages/second, roughly 1.49 times that of PaddleOCR-VL-1.6 and 3.62 times that of MinerU2.5 Pro. After enabling DSpark decoding, end-to-end efficiency improves by 55%. On the deployment side, it supports vLLM, SGLang, llama.cpp, and Ollama, and both the weights and fine-tuning framework are open.

What does this mean? A dedicated 1.3B parser can already produce usable results on many documents. But it still makes mistakes, especially with dense tables, formulas, and paper photographed with a phone. And the failure modes differ: a table error is obvious at a glance, while a formula error in one exponent can leave the page looking completely normal. One commenter in the replies said formulas are the first thing he would test.

So the second model, Jev, enters. MiniCPM-OCR Jev is a 2B OCR-correctness decision model. It scores by region rather than giving a vague evaluation of the whole page. The input is a screenshot of a block of text, a formula, or a table, plus a candidate OCR result; it outputs a score from 0 to 1, where higher means more likely to be correct. It does not fix errors; it only estimates reliability. This positioning is crucial: fixing errors is a separate problem, and only by first knowing where to look can human review be placed into the process.

Jev's score can do three things: automatically accept high-scoring regions; send low-scoring regions to human review or correction steps; and when multiple OCR models are run on the same region, choose the candidate with the highest score. In the official data, Jev's AUROC on JevOCRBench multiplied by 100 is 93.6, higher than JEV-35B-A3B's 90.1 and close to Qwen3.5-397B-A17B's 93.8. After switching parsers, AUROC ranges from 91.9 to 93.4. The sample and parser combinations are limited, but at least it shows that this 2B checker does not only recognize its own outputs.

The workflow in the tweet is simple: MiniCPM-OCR parses, Jev scores text, formulas, and tables, and low-scoring results go to a human or into correction. One commenter added a more practical point: low scores need somewhere to go, otherwise they are just prettier logs. Another commenter warned that before routing, check the verdict first; rendering or inference failures may return a fixed value, so don't mistake a broken verifier for a difficult document. This detail matters more than benchmark rankings: error paths in production must be handled separately.

If there are multiple OCR candidates for the same region, Jev can also do best-of-N. The premise is that the candidates share the same crop and content boundaries; it only chooses among existing candidates, so the quality ceiling is determined by candidate coverage.

For Chinese document parsing results, you can look at this set of animated images: the original document on the left, layout detection in the middle, and Markdown on the right:

For people building document agents, the thing most worth testing is not clean PDFs. Dense tables, formulas, and phone photos are the real examination room for this combination. The value of a 1.3B parser plus a 2B scoring model is not in small parameter counts, nor in one more point on a benchmark. It makes review cost follow how dirty the document is, and page count is no longer the main cost. Only when low-scoring content has somewhere to go and high-scoring content passes automatically does this pipeline hold up.

Project links:
GitHub: https://github.com/OpenBMB/MiniCPM-OCR
MiniCPM-OCR 1.0: https://huggingface.co/openbmb/MiniCPM-OCR-1.0
MiniCPM-OCR Jev: https://huggingface.co/openbmb/MiniCPM-OCR-Jev