OvisOCR2 技术报告

TL;DR OvisOCR2 是一个 0.8B 参数的端到端文档解析模型，可直接将页面图像转换为 Markdown，凭借数据引擎与强化学习训练在 OmniDocBench 等基准上达到 SOTA，首次将端到端方法推至此前由流水线方法主导的榜单顶端。

问题

问题背景

文档解析正从单纯 OCR 转向端到端的页面级结构重建，业界追求将扫描页或图片直接转换为保留完整版式、阅读顺序和语义元素的 Markdown 表示，以支撑检索增强生成（RAG）等下游应用。

现有方法局限

传统方案普遍采用 pipeline 架构：先用检测模型定位文本块、表格、公式等，再逐区识别，最后依据布局规则拼装。这种多阶段串行处理容易形成误差级联，尤其是面对复杂版面（密集表格、嵌套公式、不规则分栏）时，单模块的轻微偏差会严重破坏最终输出。此外，规则驱动的后处理很难覆盖长尾版式，导致泛化性差。此前虽出现端到端生成模型，但大多受限于训练数据规模与多样性，未能全面超越精心调优的 pipeline 系统，尤其在版面复杂的学术论文、财务报告等场景中差距明显。

为什么这个问题难/重要

文档页面的构成元素高度异构，需同时理解文本、公式、表格结构和视觉区域（如图表），并要求模型在自然阅读顺序下正确组织多元素。标注成本极高：人工对齐页面与 Markdown 既缓慢又易出错；而合成数据又常缺乏真实文档的噪声和版式变化。此外，评价本身也困难，单一指标难以衡量排版与内容精度的平衡。业界对轻量、高效、端到端的文档解析方案需求迫切，因为它是知识库构建、文档智能等系统的关键入口，直接影响下游模型的事实性和检索召回率。

行业类比

这类任务可类比图像到代码生成（如手机截图转 Flutter 代码），都需要准确把握视觉元素的坐标、样式和层级关系，并输出严格结构化的表示，任一细节偏差都会导致可读性或可用性下降。

核心洞察

• **端到端 0.8B 模型超越传统多阶段 Pipeline**：OvisOCR2 仅用 0.8B 参数就在 OmniDocBench v1.6 上取得 96.58 的总体分，证明单模型直接输出 Markdown 可以全面超越由独立 OCR、布局分析、表格解析、公式识别等模块级联构成的流水线方案。这一结果突显端到端范式在文档解析中不仅能减少误差传递，还能通过联合优化捕捉跨元素依赖关系，为工业部署提供了更简洁且性能更高的替代路线。
• **同源 HTML 合成数据消除噪声对齐**：论文构建的数据引擎从 HTML 源码同时渲染页面图像和生成 Markdown 真值，确保图文像素与标注结构精确定齐。这种设计绕开了真实文档标注中常见的错位、遗漏或格式不一致问题，使训练信号更加干净，并配合难例挖掘和 Agent 多样性增强，让模型在长尾场景中仍能稳健泛化。
• **大模型 RL 策略蒸馏至小模型的训练配方**：先对 4B 分支进行多组件奖励设计的强化学习，再通过 on-policy 蒸馏将能力迁移给 0.8B 模型，并结合模型融合，实现了在推理效率下的高性能。该流程平衡了大模型的价值探索与小模型的生产可行性，为受限资源下构建顶尖文档解析器提供了可复现的训练范式。

方法

输入与目标

OvisOCR2 接收单页文档图像，直接输出符合自然阅读顺序的 Markdown 表示，覆盖文本、公式、表格与视觉区域。该端到端设计避免了对多个独立模块的拼接，简化了工程链路。

核心数据引擎

模型能力高度依赖数据质量，因此构建了混合数据工厂：

• 真实文档管线：对原始文档图像进行基于规则的结构化解析，将检测到的文本块、表格、公式等序列化为 Markdown；再通过人工抽检和子集过滤，剔除噪声样本，确保标注的语义一致性。
• 合成数据管线：通过难例挖掘从真实分布中提取具有挑战性的布局模板，利用 Agent 驱动的 HTML 多样化扩增差异性；从同一份 HTML 源码同时渲染出文档图像与对应的 Markdown 真值，再经迭代质量控制校验渲染保真度与标注正确性。

多阶段训练策略

• 第一阶段：监督微调（SFT） 在混合数据上训练基础生成能力，使模型初步学会图像到 Markdown 的映射。
• 第二阶段：强化学习（RL） 在参数量更大的 4B 分支上进行，设计多组件奖励（覆盖内容完整性、排版顺序、表格对齐等维度），并结合在线难例构建，增强模型对复杂版面的鲁棒性。
• 第三阶段：在线策略蒸馏（OPD） 将 4B 教师模型在 RL 中探索出的更优生成策略，迁移回 0.8B 学生模型，实现高效压缩与性能保留。
• 最终阶段：模型融合 综合多个训练版本的优势，进一步提升泛化性。

差异点

与先前在OmniDocBench v1.6（得分 96.58）等榜单上占优的分步式流水线不同，OvisOCR2 以单一端到端模型完成全部解析，通过 RL 与蒸馏组合突破小模型上限，证明了紧凑模型在文档解析领域的竞争力。

实验

实验设计

评估在三个数据集上进行：OmniDocBench v1.6（综合文档解析基准）、PureDocBench（侧重版面保持）以及一个内部构造的长尾/挑战场景基准。OvisOCR2 作为端到端模型，输入页面图像，直接输出自然阅读顺序的 Markdown。对比方法涵盖领域内 SOTA 流水线方案与先前端到端模型。主要指标包括文本、公式、表格、版面保真度的子评分与总体分。

关键发现

• OvisOCR2 在 OmniDocBench 达到 96.58 总体分，刷新 SOTA，且是首次由端到端模型在该榜单（曾由流水线主导）排名第一。
• 在 PureDocBench 上，Avg3 得分 75.06，同样最高。
• 内部基准进一步证实其泛化性与鲁棒性，覆盖更多长尾文档类型。
• 仅 0.8B 参数便取得此成绩，凸显数据引擎（真实过滤+合成数据同源生成）与训练策略（SFT、RL、蒸馏、融合）的有效性。

与基线的深度对比

此前文档解析普遍采用分步流水线（例如独立的 OCR、表格识别、公式识别、版面分析模块），各模块误差会累积，且系统复杂、维护成本高。OvisOCR2 以单一 VLM 架构统一视觉编码与结构化生成，消除了模块间接口误差。其优势来源：

1. 数据同源性：合成数据中渲染图像与 Markdown 标注源自同一 HTML，保证标签严格一致。
2. 多阶段训练：通过 RL 在 4B 教师模型进行策略优化，再用 on-policy 蒸馏迁移至 0.8B 学生，兼顾性能与效率。
3. 模型融合：进一步集成多轮热启动，稳定输出。 该工作表明，端到端文档解析已具备工业部署潜力，且小模型通过精细数据与训练设计可超越专用流水线。

行业影响

落地场景

OvisOCR2 作为一个端到端的 0.8B 参数文档解析模型，可直接应用于需要将文档图片转换为结构化 Markdown 的产品与业务中：

• 企业知识管理：自动化解析合同、财报、技术手册，构建可检索的知识库。
• 在线教育与学术服务：将扫描的教材、论文转换为可复制的文本与公式，提升内容可访问性。
• 政务与金融单据处理：对身份证件、票据、申请表单进行结构化提取，对接 RPA 流程。
• 电商与内容平台：从商品详情图、宣传册中抽取规格表、描述文本，辅助自动上架或内容审核。
• 医疗病历数字化：将手写或印刷病历、检查报告转为结构化数据，加速临床研究。

商业价值

1. 降本增效：取代传统的多级流水线（检测 - 识别 - 排版分析），减少人工标注与规则维护成本，尤其适用于长尾版式。0.8B 的轻量尺寸可使单页推理成本低于同类大模型。
2. 体验提升：端到端生成自然阅读顺序的 Markdown，直接适配下游检索、翻译、语音播报等任务，减少后处理摩擦。
3. 规模化能力：通过合成数据引擎与 in-house benchmark 验证的鲁棒性，模型可快速扩展到新的文档类型，无需逐场景重新收集标注数据。

与现有产品/工作流的接口

OvisOCR2 以 图像输入 → Markdown 输出 的形式提供服务，易于集成到现有技术栈：

• API 化部署：结合 νLLM 或 TGI 类似框架，提供 RESTful 或 gRPC 接口，输入 base64 编码的文档图像，返回结构化文本。
• 与检索增强生成（RAG）系统衔接：输出的 Markdown 可直接注入向量数据库或全文搜索引擎，作为企业级知识问答的语料来源。
• 可编排的工作流节点：在 Airflow、Prefect 等工作流中作为单个步骤，上游对接扫描仪、PDF 拆分服务，下游对接 NLP 模块（如实体识别、摘要）。

该模型在 OmniDocBench 上以 96.58 分达到 SOTA，证明了端到端方案在解析精度上已超越传统流水线；在 PureDocBench 上的 Avg3 得分 75.06 也体现出对复杂布局的强适应性。

局限

• 模型规模仅0.8B，容量有限，对于布局极其复杂、包含大量密集表格或高分辨率图文混排的页面，可能无法完整捕获所有细节，导致信息丢失或结构错误；且模型以单页图像为输入，未显式支持多页文档的跨页上下文理解，限制了在长篇文档解析任务中的应用。
• 数据引擎高度依赖合成数据，合成页面的HTML模板来源于真实文档的硬样本挖掘，但自动化生成的多样性可能不足，尤其是对于长尾、非标准排版（如手写批注、古籍、票证等），模型在这些场景下的鲁棒性尚未充分验证。内部基准虽覆盖部分长尾，但实际部署中仍可能暴露出分布偏移导致的质量下降。
• 作为端到端模型，OvisOCR2直接生成Markdown，缺乏显式的中间表示（如区域检测、识别、阅读顺序等模块输出），这使得模型行为不易解释，错误溯源困难。与流水线方法相比，当输出不符合预期时，用户难以通过调整中间步骤来修复，这在需要高度可控性的场景（如法律、金融文档的结构化抽取）中可能是一个劣势。