MiniCPM-OCR-Jev 输入输出完全指南：区域图、候选文本与渲染图怎么传才能正确打分

发布时间：2026/10/30 11:02:49

人工智能
大模型
OCR
多模态
计算机视觉

【免费下载链接】MiniCPM-OCR-Jev

项目地址：https://ai.gitcode.com/OpenBMB/MiniCPM-OCR-Jev

MiniCPM-OCR-Jev 是一个 2B 参数量的 OCR 正确性打分模型：给定一个文本/公式/表格区域图和一段候选 OCR 文本，它会输出一个 0–1 的分数，分数越高表示该候选结果越可能正确。本文面向新手，详解它的输入输出格式——区域图、候选文本、渲染图到底怎么传、传哪些，才能拿到正确的打分结果。

30 秒理解：MiniCPM-OCR-Jev 是做什么的 🎯

把它想象成一位"OCR 质检员"：

输入：文档中某个区域的原图 + 某个 OCR 引擎识别出的候选文本
输出：一个 0–1 的打分，分数越高 = 候选结果越可能是对的

典型用法有三类：

自动放行：高分区域直接通过，无需人工复核
人工路由：低分区域转人工审核，省下 80% 的复核量
多模型择优（best-of-N）：多个 OCR 模型跑同一区域，选分数最高的那个

它的效果相当能打：在 JevOCRBench 基准上，2B 小模型的决策 AUROC 达到93.6，甚至超过了 35B 和 397B 级别的大模型；在 MiniCPM-OCR 1.0、GLM-OCR、PaddleOCR-VL-1.6、Xiaomi-OCR-0 等不同解析器的结果上，AUROC 稳定保持在91.9–93.4。

一次打分需要什么？拆解输入输出 📥

一个"评估单元"= 区域图 + 候选结果

模型每次只评估一个区域（一段文本、一个公式或一张表格）加它对应的候选 OCR 结果，而不是整页文档。

项目	说明
评估单元	一个文本 / 公式 / 表格区域 + 它的候选 OCR 结果
原始区域图	从文档中裁剪出来的区域 crop 图
候选内容	OCR 识别出的文本 + 由该文本渲染生成的图
输出	0–1 分数，越高表示越可能正确

内部打分时，模型同时利用三样东西：配对的原始区域图、候选文本、渲染图——"图对图"加"图对文"双重比对，这也是它判别力强的关键。

区域类别（category）必须传对 🏷️

调用时需要指定区域类别：text（文本）、formula（公式）或 table（表格）。类别传错，模型会用错误的判读标准来打分，结果自然不可靠。

该传几张图？看你的部署方式 🚀

这是新手最容易踩坑的地方：不是所有部署方式都要传渲染图。

方式一：云 API / Docker / 带渲染器的 SDK

这些部署方式内置了渲染器（renderer），你只需要传：

✅ 原始区域图
✅ 候选文本
✅ 区域类别（text / formula / table）

渲染图由服务端自动生成，你不需要管。

方式二：不带渲染器的 SDK / 自建服务（如 vLLM、SGLang、llama.cpp、Ollama）

没有内置渲染器时，渲染图必须由调用方自己提供，即：

✅ 原始区域图
✅ 候选文本
✅ 你自己渲染好的候选文本图
✅ 区域类别

渲染时注意：渲染图的内容边界要与原始区域图保持一致——同一个区域的多个候选必须共享相同的裁剪范围和内容边界，否则打分没有可比性。

⚠️ 最重要的坑：先看 verdict，再看分数

拿到响应后，先检查verdict字段，只有scored才代表模型真正完成了打分。

如果请求在前置校验（precheck）、渲染或前向推理阶段就失败了，服务会返回一个固定值兜底——千万不要把这个固定值误读成"模型给出的低分"。比如它可能让你以为候选结果质量很差，实际上是流程根本没走到模型那一步。

一句话口诀：verdict == scored才看分，否则查错。

怎么定阈值？两个实用建议 📊

用你自己的业务样本调阈值：拿一批真实应用里的解析结果打分，画"自动放行率 vs 准确率"曲线，选一个业务可接受的平衡点
双向监控：阈值调高，自动放行的数量会变少；要同时盯着"自动通过结果的准确率"和"人工复核的量"这两个指标

多模型择优场景下还有一个细节：如果所有候选都低于应用阈值，该区域依然建议转人工审核，不要硬选最高分。

快速上手与仓库文件导航 🗂️

如果需要在本地部署，可以先克隆仓库：

git clone https://gitcode.com/OpenBMB/MiniCPM-OCR-Jev

本仓库是模型的 BF16 原始权重包，主要文件及其作用如下：

文件	作用
config.json	模型结构配置，注意`problem_type: single_label_classification`，说明输出头是二分类打分头，而非语言模型输出
generation_config.json	生成/推理时的 EOS、pad token 配置
preprocessor_config.json 与 processor_config.json	图像预处理配置：图片会做 RGB 转换、缩放（短边约 256 像素级约束）与 0.5/0.5 均值方差归一化，理解为什么区域图别压缩得太糊
chat_template.jinja	对话模板，图片会以`Picture N:`前缀编号嵌入，多张区域图时顺序要与文本对应
tokenizer.json 与 tokenizer_config.json	分词器及其特殊视觉 token 定义

一个值得注意的架构细节：MiniCPM-OCR-Jev 由 Qwen3.5-2B 训练而来，保留了视觉编码器与语言主干，只把原来的语言输出头（lm_head）换成了二分类打分头。从 config.json 的problem_type字段就能印证这一点——它天生就是"打分"，而不是"生成文字"。