openbmbは、OCR結果の品質を領域単位で評価する2BモデルMiniCPM-OCR JevのGPTQ W4A16量子化版openbmb/MiniCPM-OCR-Jev-GPTQをHugging Faceで公開しました。元モデルはJevOCRBenchのdecision AUROC(×100)で93.6を記録し、JEV-35B-A3B(90.1)を上回り、Qwen3.5-397B-A17B(93.8)に近い値を示しています。
何をするモデルか
MiniCPM-OCR Jevは、text、formula、tableの領域画像と候補OCR結果を受け取り、0から1のスコアを返します。スコアが高いほど候補が正しい可能性が高いことを意味します。用途は、信頼できる領域の自動受け入れ、低信頼結果の人手確認への振り分け、複数OCRモデルの候補からの選択です。
アーキテクチャはQwen3.5-2Bを基にしており、vision encoderと言語バックボーンを保持したまま、出力ヘッドlm_headを二値分類ヘッドに置き換えています。今回のリポジトリは元のBF16重み(openbmb/MiniCPM-OCR-Jev)ではなく、GPTQ W4A16量子化版で、ライセンスはapache-2.0です。Qwenは、Alibaba Cloudが開発する大規模言語モデルのファミリーです。
評価結果
JevOCRBenchは、領域画像・候補1件・そのレンダリングを人手で正誤ラベル付けしたブロック単位のベンチマークで、指標はAUROC(×100)です。JevOCRBenchから無作為に抽出した同じ200 samplesを4つのOCRモデルで独立に解析し、各候補を人手でラベル付けしたうえでJevが採点した結果は次の通りです。
| OCRモデル | AUROC (×100) |
|---|---|
| MiniCPM-OCR 1.0 | 92.7 |
| GLM-OCR | 91.9 |
| PaddleOCR-VL-1.6 | 93.4 |
| Xiaomi-OCR-0 | 93.1 |
4モデル間の最大差は1.5 pointsです。
利用方法と要件
提供形態はCloud API、Docker / local SDK、vLLM backendの3つです。vLLMは大規模言語モデルの推論とAPI配信のためのライブラリです。
- Cloud API、Docker image、組み込みレンダラー付きSDK serviceでは、元のregion image、candidate text、region
category(text/formula/table)を入力します。レンダリングはサービス内部で行います。 - レンダラーを持たないサービスでは、候補テキストを画像化したrendered imageも入力する必要があります。
- 複数OCRモデルの候補選択では、同じ領域を各モデルで解析し、Jevが最高スコアを付けた候補を選び、読み順に結合します。候補同士は同じcropとcontent boundariesを共有する必要があり、品質は既存候補の網羅性と正確さに縛られます。
しきい値の決め方
openbmbは、AUROCはランキング性能の指標で、自動受け入れ結果の精度ではないとし、既存のAUROC結果だけでは普遍的なデフォルトしきい値は確立されないと述べています。推奨手順は次の通りです。
- 対象の文書種類とOCRエラーを網羅するサンプルを集め、各候補をラベル付けする。
- 複数のしきい値でauto-accept rateとaccepted resultsのaccuracyを測る。
- 許容できるエラー予算からしきい値を選び、held-outサンプルで検証し、パーサーや文書分布が変わったら再検証する。
まだコメントはありません。