原始来源：OpenBMB / 面壁智能
原始来源：配套原始说明
原始来源：配套原始说明
发现渠道：AIHOT · 精选线索（非原帖直采）
扫描文件里的困难不只有字符模糊，还包括多栏阅读顺序、公式和表格结构。MiniCPM-OCR 系列把处理分成两个角色：约 13 亿参数的解析模型负责读，约 20 亿参数的 Jev 判别模型负责判断候选结果是否与图像一致。公开权重与实现让使用者能够分别选择解析和复核路径，而不必把所有工作塞进一次大模型回答。
解析流程先用版面检测切出区域，再逐块识别，最后按顺序拼成 Markdown。Jev 则同时查看区域图、候选文本以及候选重新渲染出的图像，输出一个分数。它可以帮助挑选候选或把可疑区域送给人工，但如果所有候选都错了，判别器不会凭空补出正确答案。模型卡报告 AUROC 为 93.6；这是区分正误样本的排序指标，不能写成“93.6% 的文件保证正确”。
团队在 RTX 5090、指定加速配置下报告约每秒 1.2 页，测量覆盖 OmniDocBench v1.6 的 1651 张图，页面并发为一但区域内部可以并行，不能外推为普通手机速度。实际问题也出现在模型之外：一位用户报告，开启图片区域 OCR 后，工程图文字已经识别出来，却在 Markdown 拼装时被空图片链接替代。维护者承认该路径需要修复；本轮未核实修复已经合入，因此保留问题发生的条件。
可信度 65 · 重要性 85 · 新颖度 85
技术与主题
JSJ189
针对提交 50b74eba 的工程图处理；开启图片区域 OCR，描述识别与最终拼装的差别。
忠实转述（非原句）：他报告中间识别能读出工程图中文字，最终 Markdown 却只留下空图片链接；自定义图片格式也没有按预期插入文字。他希望在保留原图时一并交付已识别内容。这是具体流水线问题报告，不是模型完全无法识别工程图。
caowanxia123
维护者在同一问题下回应用户；与项目作者同源。
忠实转述（非原句）：维护者确认需要修复该路径并表示会处理。本轮读到的问题关联了后续修改入口，但没有核实修复已经合入或验证成功，因此不把回应写成问题已解决。
编辑评读
判别模型的意义，是把人工注意力从整页平均分配，转向具体可疑区域。这样的流程是否省事，取决于分数阈值下有多少错误被放过，以及多少正确结果被送去复查。AUROC 只能帮助了解排序能力，真正的业务判断还需要接受结果的错误率与人工工作量。
工程图反馈进一步说明，端到端质量不能只盯识别模型。用户已经取得正确的中间文字，最终文件仍可能丢失它；换更强模型未必解决拼装阶段的缺陷。测试时应保存区域、识别候选和最终文档之间的对应关系，才能区分“没读懂”与“读懂后没交付”。
这里也有一个可复用的设计机会：生成器与判别器可以各自升级，并允许不同解析器提供候选。不过独立组件不自动意味着独立错误；相似训练资料、渲染方式和版面困难仍可能让它们一起失败。比较方案时，应加入候选全错、表格错位和公式符号替换等样本。这是从公开机制推导的验证建议，本刊没有运行这些测试。
需要留意
- 判别分数不是逐文档正确概率；已有用户报告最终拼装会丢失图片区域文字。