OCR 最麻煩的地方，常常是不知道它哪裡讀錯。一份讀出來的合約，可能九成九都對，只有一個金額少了一位數，要找到它，還是得從頭校對到尾。OpenBMB 的 MiniCPM-OCR 處理的就是這件事：1.3B 的 MiniCPM-OCR 1.0 負責把文件讀出來，2B 的 MiniCPM-OCR Jev 再逐區塊打分，高分的自動放行，低分的才送人工確認。
兩個模型的程式碼、文件與權重都以 Apache-2.0 授權公開，另有免費 API 與線上 Demo。下文的數字都出自 OpenBMB 的 README 與模型卡，是他們自己測的，目前還沒有看到第三方重現。
兩個模型怎麼分工？
官方把流程寫成「解析 → 驗證 → 分流」三步。
MiniCPM-OCR 1.0（1.3B）是 MiniCPM-V/o 家族第一個專做 OCR 的模型。它解析中英文文件與 PDF，涵蓋文字、表格、公式、圖表和印章，也能做關鍵資訊抽取（KIE）。掃描、拍照、彎曲、歪斜和翻拍的文件都在支援範圍內。推論框架支援 vLLM、SGLang、llama.cpp 和 Ollama，有 GGUF、AWQ、GPTQ 量化版，也可以再微調。
MiniCPM-OCR Jev（2B）是評分模型。它從 Qwen3.5-2B 訓練而來，保留視覺編碼器和語言骨幹，把語言模型的輸出頭 lm_head 換成二元分類頭。也就是說，它不生成文字，只回答一件事：這段 OCR 結果對不對。
Jev 的評分單位是一個區塊，可以是一段文字、一個公式或一張表格。每次評分，它看三樣東西：
- 從原文件裁下來的區塊圖片；
- OCR 讀出的候選文字；
- 把候選文字重新渲染成的圖片。
輸出是 0 到 1 的分數，越高表示越可能正確。透過雲端 API、Docker 映像或內建渲染器的 SDK 呼叫時，只要給原圖、候選文字和區塊類別，渲染由服務處理。
Jev 不限定自家的解析器，任何 OCR 模型的結果都能交給它打分。官方列的第二種用法是多模型擇優：用同一份版面切割，讓幾個 OCR 模型各自解析每個區塊，Jev 替同一區塊的候選打分、挑最高分的，再依閱讀順序拼回整頁。所有候選都低於門檻時，這個區塊照樣送人工。
官方數字要怎麼讀？
解析品質
MiniCPM-OCR 1.0 在 Real5-OmniDocBench 拿到 93.68，在 OCRBench v2 拿到 54.7，官方稱兩者都是 SOTA。README 的比較對象是圖表裡列出的開源 OCR 模型，沒有包含大型通用模型。
速度
速度的宣傳是：用 DSpark 推測解碼（speculative decoding）加速後，端到端效率提升 55%，吞吐量約是 PaddleOCR-VL-1.6 的 1.49 倍、MinerU2.5-Pro 的 3.62 倍。
這組數字的測試條件是：單張 RTX 5090，跑 OmniDocBench v1.6 的全部 1,651 張圖，一次處理一張圖（圖內的多個區塊仍可並行辨識），各系統都用自己的加速設定。MiniCPM-OCR 1.0 跑出每秒 1.217 頁，PaddleOCR-VL-1.6 是 0.818 頁，MinerU2.5-Pro 是 0.336 頁。
同一張表裡，GLM-OCR 跑出每秒 1.179 頁，跟 MiniCPM-OCR 1.0 幾乎一樣快。宣傳文案挑的是差距比較大的兩個對手。把同時處理的圖片數提高到 8 張，MiniCPM-OCR 1.0 的吞吐量升到每秒 2.133 頁。
Jev 的 AUROC
Jev 在 JevOCRBench 的 AUROC（×100）是 93.6，高於 JEV-35B-A3B 的 90.1，接近 Qwen3.5-397B-A17B 的 93.8。
「2B 贏過 35B、逼近 397B」聽起來很懸殊，但這兩個對手都是混合專家（MoE）模型，名稱裡的 A3B、A17B 指每次推論實際啟用的參數，大約是 3B 和 17B。Jev 比的是一個總參數 35B、每次只動用約 3B 的模型，差距沒有字面上那麼大。
JevOCRBench 是 OpenBMB 自己建的測試集，有 2,267 筆中英文資料。負例取自前沿 OCR 模型的真實錯誤，經人工審核標註。測試集和模型出自同一家，Jev 在上面拿高分，要等別人用其他資料重現才算數。
官方另做了一個跨解析器實驗：從 JevOCRBench 隨機抽 200 筆，交給四個 OCR 模型各自解析，人工標出每個結果的對錯，再讓 Jev 打分。四組的 AUROC 分別是 MiniCPM-OCR 1.0 92.7、GLM-OCR 91.9、PaddleOCR-VL-1.6 93.4、Xiaomi-OCR-0 93.1，最大差距 1.5 分。這說明 Jev 不太挑解析器，但樣本仍然來自同一個測試集。
部署前要自己做什麼？
AUROC 量的是排序能力：隨機抽一個讀對的區塊和一個讀錯的區塊，AUROC 就是模型給讀對那一個較高分的機率。93.6 既不表示能挑出 93.6% 的錯，也不表示高分結果有 93.6% 是對的。OpenBMB 的文件也寫明，AUROC 不直接決定自動放行結果的正確率，現有結果也沒有給出通用的預設門檻。
門檻要拿自己的資料定。官方建議的做法是：
- 從實際應用抽一批樣本，人工標出對錯。
- 用 Jev 打分，在幾個門檻下量兩個數字：自動放行的比例，以及放行結果的正確率。
- 依可以容忍的錯誤率選門檻，再用另一批樣本驗證。
換了解析器或文件類型，就要重做一次。如果要把分數當成「正確的機率」直接使用，還得另外檢查分數區間和實際正確比例是否吻合。
分數要配著 verdict 看。透過內建渲染器的服務呼叫時，回應裡的 verdict 是 scored，才表示模型真的打了分。前置檢查、渲染或推論失敗時，服務會回傳固定值，這個值不能當成低分解讀。
多模型擇優的上限是候選本身。Jev 只在現有候選裡挑，每個候選都讀錯時，它挑不出對的答案。同一區塊的候選也必須來自相同的裁切範圍與內容邊界，分數才能互相比較。
這個 Jev 和 DecisionRAG 的 Jev 無關
最近另一篇論文 DecisionRAG 也用了一個叫 Jev 的「決策模型」，那是 TypeSafe AI 的閉源商用模型，用來判斷檢索候選的相關性。MiniCPM-OCR Jev 借用了相同的名字和「決策模型」的說法，但它是 OpenBMB 從 Qwen3.5-2B 訓練出來的開放權重模型，只做 OCR 評分，兩者沒有關係。DecisionRAG 的整理見〈DecisionRAG：不先檢索，讓決策模型沿著文件階層一路找下去〉。
從哪裡下手？
- 先用線上 Demo（中國、國際）丟幾份自己的文件試解析效果。
- 要接進系統，可以用免費的文件解析 API 或 pip 套件
minicpm-ocr；本機部署照 GitHub 上的 SDK 教學。 - Jev 的部署方式（Docker、vLLM、SGLang、llama.cpp、Ollama）列在模型卡；動手前先準備一批人工標好的樣本，門檻要靠它來定。
參考資料
- OpenBMB，MiniCPM-OCR GitHub（README、MiniCPM-OCR 1.0 說明與吞吐量測試、MiniCPM-OCR Jev 說明）。
- 模型卡：MiniCPM-OCR-1.0、MiniCPM-OCR-Jev。
- 測試集：JevOCRBench。
- 官方介紹：openbmb.cn。