MiniCPM-OCR

一张扫描件转成文字，只完成了文档自动化的一半。表格单元格有没有错位、公式符号是否漏识、拍照阴影下的数字能不能直接入库，决定了后续知识库和业务系统是否可信。MiniCPM-OCR 的特别之处，在于同时提供负责识别的解析模型，以及评估识别结果的质量判别模型，让开发者有机会把“读出来”和“值得相信到什么程度”分开处理。

OpenBMB 于2026年10月28日发布 MiniCPM-OCR 1.0 和 MiniCPM-OCR Jev：前者为1.3B参数的文档解析模型，后者为2B参数的质量判别模型。代码、模型权重和配套文档按项目说明采用 Apache-2.0 许可。它更适合需要接入系统、搭建批处理流程的开发者，而不是只有一个上传按钮的轻量扫描工具。官方发布记录 · 项目仓库

解析模型负责把页面变成可使用的数据

MiniCPM-OCR 1.0 面向中文、英文及复杂文档内容，覆盖文字、表格、公式、图表、印章和字段抽取。扫描、手机拍照、倾斜、弯曲和翻拍都是官方列出的处理场景，但支持某种输入不等于对每份材料都能准确还原。

实际使用时，整页解析不只是调用一次模型。官方 SDK 会结合版面检测、区域识别与阅读顺序组织，输出 Markdown；表格可转成 HTML，公式保留 LaTeX 表达。这样的结果比纯文本更适合继续做检索、段落切分与结构化归档，也能减少多栏论文或表格在拼接时失去关系的问题。模型与解析流程

例如，一支整理技术资料的团队，可以先将扫描手册解析成 Markdown，再按章节建立索引，保存表格和公式，最后交给检索系统。若业务最终需要的是发票金额或合同日期，还应把字段规则、格式校验和原图位置一起保留下来，不宜仅凭一段看似流畅的输出直接写入业务库。

Jev 的价值是帮助安排复核

Jev 不替代 OCR 识别。它针对文本、公式、表格区域，对候选解析结果给出质量评分；服务可结合原始区域图片、候选内容及渲染结果判断二者是否一致。它也能为其他 OCR 系统的结果评分，因此不必为了增加复核环节就立刻迁移全部解析服务。Jev 推理说明

比较实用的接法，是先准备一批具有人工答案的业务样本，观察不同评分区间的错误分布，再决定哪些结果可以自动进入下游，哪些要排队复核。金额、身份证号、关键尺寸等高影响字段，应设置比普通段落更严格的检查。评分只是一个辅助信号，不能直接当成每个字段都正确的保证。

当两个解析器对同一区域给出不同结果时，也可以让 Jev 分别评分，再选出候选。但最高分不等于足够可靠：如果全部候选都低于业务阈值，仍应留给人工。对于遮挡、缺页或原图根本看不清的内容，质量分流比强行生成一个答案更有用。

和常见文档解析项目怎么选

这张表比较的是产品职责，不是统一测试条件下的排名。PaddleOCR 和 MinerU 都有完整的文档处理能力，不能因为 MiniCPM-OCR 增加质量判别，就断言它在每个识别任务上更强。已经运行稳定的系统，可以先测试 Jev 是否减少人工筛查成本，再决定是否替换解析主链路。PaddleOCR 官方仓库 · MinerU 官方仓库

部署门槛与成本不能只看参数量

项目提供在线体验与 API 接入，也提供本地部署路线。普通体验者可以先用公开或脱敏样本观察版面还原效果；涉及客户合同、身份材料和内部账目时，应先确定上传权限、数据处理范围及所选服务的要求。公开代码可部署在自己的环境，并不意味着在线演示自动满足企业的数据边界。

官方快速开始使用 Linux x86_64 与 NVIDIA 环境，给出的已验证配方为 RTX 5090 32GB、Python 3.12、相应驱动与 CUDA 版本，并要求预留至少40GB磁盘。识别后端与 SDK 需要分别配置。上述是官方验证环境，不是承诺所有用户都必须购买这张显卡，也不能反过来用“1.3B小模型”推导普通笔记本可无门槛处理大批文档。部署指南

开源许可降低了软件使用门槛，但算力、存储、运维和人工复核仍有成本。仓库宣传免费 API，具体额度、持续时间与账号限制应以实际服务页面为准，不宜理解为无限量免费。官方性能数字也依赖硬件、页面复杂度、并发和加速设置；选型时更该记录自有样本的错误类型、每页总耗时和复核比例。

MiniCPM-OCR 最值得试的场景，是中文扫描档案、技术文档和知识库入库流程中，已经发现“识别完成不代表能直接使用”的那一步。先用小样本建立错误清单，把解析与复核接起来，再扩大处理量，比单独追求一个漂亮的识别分数更接近实际收益。

官方入口

• 中文产品文档
• 中国站在线体验
• 开源代码与模型入口