MiniCPM-OCR pairs a 1.3B parser with a 2B model that flags OCR you shouldn't trust

OpenBMB's open MiniCPM-OCR parser and Jev verifier score each extracted region, so document pipelines can route only doubtful output to review.

Picture a two-person bookkeeping shop that takes a monthly shoebox of client receipts, supplier invoices and bank statements and turns them into ledger entries. Today the developer half of the shop runs every scan through an OCR tool, dumps the output into a spreadsheet, and the bookkeeper re-checks every page, because there's no signal for which pages are wrong. When the volume spikes at quarter-end, they spot-check instead. That's when a dropped decimal point or a unit price paired with the wrong row slips into the books and surfaces weeks later.

OpenBMB's MiniCPM-OCR release, published October 27, 2026, targets the missing piece: a second model, MiniCPM-OCR Jev, that looks at a document region and its OCR output and returns a 0–1 score for how likely the extraction is correct. As @omarsar0 put it, the setup is parse, score, then send low-scoring output to a human or a correction step, with the caveat that "Jev estimates reliability. It doesn't fix errors itself."

What it is

Two open models, both under Apache 2.0 for code, docs and weights, according to the GitHub repo:

The vendor numbers, all run by OpenBMB: 93.68 on Real5-OmniDocBench and 54.7 on OCRBench v2 for the parser. Jev posts an AUROC (×100) of 93.6 on JevOCRBench, versus 90.1 for JEV-35B-A3B and 93.8 for Qwen3.5-397B-A17B. The model card also reports a cross-parser test on 200 samples, where Jev's AUROC ranged from 91.9 to 93.4 across MiniCPM-OCR 1.0, GLM-OCR, PaddleOCR-VL-1.6 and Xiaomi-OCR-0. OpenBMB's launch post calls Jev "model-agnostic" and claims throughput of 1.49× PaddleOCR-VL-1.6 with its DSpark acceleration.

Alternatives, as our sources describe them:

Our research also flagged Docling and olmOCR, but the pages we fetched don't describe them in enough detail to compare fairly, so we won't.

Who it's for

Pick this up if you run a document pipeline on Chinese or English paperwork, already have a human who reviews output, and want to cut that review down to the regions most likely to be wrong. It suits you if you want to keep documents on your own hardware or score output from a parser you already use.

Skip it if your documents are mostly handwritten, in other languages, or if you want a fixed invoice schema on day one with no model hosting. Google's parser is the closer fit for that last case.

Before and after

Before:

  1. Scan or photograph the document.
  2. Run OCR; get text with no reliability signal.
  3. A person re-reads every page, or spot-checks at random.
  4. Errors that slip through surface downstream.

After, per the Jev model card:

  1. Parse with MiniCPM-OCR 1.0 (or another parser).
  2. Score each text, table or formula region with Jev.
  3. Regions above a threshold you set from your own samples proceed automatically; the rest go to human review.
  4. Optionally, parse each region with several OCR models and let Jev pick the highest-scoring candidate.

AI郵報 frames Jev as a tool for ordering the review queue, not a second human answer. It suggests testing on a batch you've already checked by hand, comparing errors caught against correct items sent to review. It also suggests always routing high-risk fields, like account numbers and totals, to a person regardless of score.

Try it

The repo offers a free API, local deployment, fine-tuning via LLaMA-Factory or Swift, and Agent Skills. Its suggested first step is to hand a coding agent the skill file. For the parser:

Read and execute https://github.com/OpenBMB/MiniCPM-OCR/blob/main/docs/SKILL_en.md

For a local Jev scoring service (Docker or SDK, on vLLM, SGLang, llama.cpp or Ollama):

Read and execute https://github.com/OpenBMB/MiniCPM-OCR/blob/main/docs/SKILL_jev_en.md

If you're calling Jev through the cloud API, Docker or the SDK with its built-in renderer, send the region image, the candidate text and the region category. The model card warns to check the verdict field first: only scored means the model actually ran. Fixed values returned for precheck or rendering failures must not be read as low scores.

On a laptop with no NVIDIA GPU, the dsh-pdf-router plugin docs document a llama.cpp setup. You download the Q8_0 GGUF (775 MB) plus an 859 MB vision projector, with ~16 GB system RAM listed as the floor, then serve an OpenAI-compatible endpoint:

# 3) serve an OpenAI-compatible endpoint on :18499
llama-server.exe --model MiniCPM-OCR-1_0-Q8_0.gguf --mmproj mmproj-model-f16-4x.gguf `
--host 127.0.0.1 --port 18499 --ctx-size 16384 --n-gpu-layers 999

That covers the parser only. The repo says to set your Jev threshold "only after checking it on a small batch from the real application."

Where it breaks

The pattern, scoring extraction before trusting it, is the useful part. Whether this particular verifier holds up on your shoebox is something only your own checked sample will tell you.

Sources