阿里近期开源了OvisOCR2，一个参数量只有0.8B的文档解析模型。它没有沿用传统级联式OCR加版面分析的路线，而是直接把文档图像映射为结构化的Markdown或HTML文本，并且在OmniDocBench文档解析基准上拿到了综合第一。这个结果引起了不少讨论，因为以往登顶该榜单的模型大多参数规模远超0.8B，有的甚至达到7B或更大。OvisOCR2的出现说明，在文档解析这个特定任务上，端到端建模和高效的视觉编码策略可能比单纯堆参数更关键。
小参数模型如何感知复杂版面
文档解析的难点不在于识别单个字符，而在于理解版面结构：哪里是标题、哪里是段落、表格跨页怎么处理、公式和正文如何混排。OvisOCR2在0.8B参数规模下能处理这些问题，主要依赖两部分设计：动态分辨率视觉编码和视觉token压缩。传统的多模态模型通常把整张图片缩放到固定尺寸，例如448×448或1024×1024，这对于A4文档会导致文字边缘模糊，表格线和上下标细节丢失。OvisOCR2采用动态分块策略，把高分辨率文档图切割成多个局部区域，每个区域独立编码，再通过位置编码拼接，这样即使长文档也能保留局部细节。
视觉token压缩是另一个关键。如果直接让语言模型处理所有图像token，序列长度会迅速膨胀，0.8B的模型容量根本不够用。OvisOCR2在视觉编码器之后引入了一个压缩层，对每个图像块中的冗余token进行合并，只保留对文字和结构敏感的表示。这个操作不是简单的下采样，而是在训练过程中让压缩模块学习保留表格线、公式符号和文本行之间的相对位置关系。压缩后的token再送入语言模型，由语言模型根据任务指令生成对应的Markdown内容。
训练数据同样值得关注。文档解析模型的效果很大程度上取决于训练样本的多样性和标注质量。OvisOCR2的训练集覆盖了中英文文档、表格、数学公式、代码块、发票、合同等多种类型。对于表格和公式，标注不是简单的文本转录，而是带有LaTeX或Markdown结构的完整表示。例如一个跨页表格会被标注成带合并单元格信息的Markdown表格，而不是两页各自独立的文本。这样的数据设计让模型在训练阶段就学会了结构对齐和跨页连续性的概念。
端到端方案相比级联方案消除了哪些误差
传统文档解析通常分为多个阶段：先做版面检测，圈出文字块、表格、公式区域；然后分别调用文本识别、表格结构识别、公式识别模型；最后通过规则把这些结果拼接成一个完整文档。这条链路每多一个阶段，就会多一次误差累积的可能。版面检测把公式区域误判为图片，后续公式识别就不会执行；表格检测框偏移几个像素，表格结构还原就可能少一行或者多一列。级联方案的另一个问题是中间表示不一致，文本识别输出纯文本，表格识别输出HTML片段，公式识别输出LaTeX，最终拼接时需要额外规则处理边界冲突。
OvisOCR2把这些问题压缩到一个生成任务里。输入是一张文档图像，输出直接是结构化的Markdown或HTML文本。模型内部自己决定哪些区域属于公式、哪些区域属于表格、表格的单元格如何合并、段落顺序如何排列。这个过程不需要人工设计中间表示，也不存在模块之间的接口矛盾。从生成结果看，它对复杂版面中公式与正文交替出现的情况处理得更自然，因为语言模型在生成时能够利用上下文信息推断公式的语义边界，而不是孤立地对某个区域做分类。
端到端方案带来的另一个好处是训练目标统一。级联方案需要分别训练多个模型，每个模型有自己的损失函数和优化目标，调优时很难平衡各部分性能。OvisOCR2只需要一个交叉熵损失，所有子任务共享同一个优化方向。当模型在表格结构预测上犯错时，梯度会同时影响视觉编码器和语言模型，这比单独调整表格识别模块更高效。对于需要快速迭代的工程团队来说，端到端模型也降低了部署和版本管理的复杂度，虽然推理时可能需要更多的显存，但整体链路更简洁。
OmniDocBench登顶背后的指标拆解
OmniDocBench是一个面向文档解析的综合评测基准，覆盖版面元素识别、阅读顺序判断、文本转录、表格结构还原、公式识别等多个维度。它不是只看单一指标，而是通过加权综合多类任务的表现来评价模型的文档理解能力。OvisOCR2能在综合排名上登顶，说明它在多数子任务上没有明显短板。尤其是在表格结构还原和公式识别这两个传统级联方案容易翻车的任务上，OvisOCR2的端到端建模展现出明显的上下文优势。
表格结构还原之所以难，是因为表格不仅有单元格内容，还有合并、跨行、缩进、嵌套等结构信息。级联方案通常先用检测模型切出表格区域，再用结构识别模型输出HTML表格，但检测框的轻微偏移会导致结构识别模型看到不完整的表格线，进而产生错误合并。OvisOCR2在生成Markdown表格时，会同时根据视觉特征和已生成的内容来判断下一步应该输出分隔线还是单元格内容，这种条件生成方式对边界模糊的表格线更鲁棒。
公式识别方面，文档中的公式经常与正文字体相似，但又有上下标、分式、根号等复杂排版。传统公式识别模型往往只处理裁剪出来的公式图片，丢失了公式前后的语义上下文。OvisOCR2在生成过程中能看到公式周围的文字，相当于利用上下文来判断某个符号到底是字母还是运算符号。例如公式中的小写l和数字1在孤立识别时容易混淆，但在推导语境中往往能通过上下文纠正。这种全局上下文的利用，是它在OmniDocBench上提升明显的可能原因之一。
快速上手：推理与微调示例
OvisOCR2的推理代码比较简洁，官方提供了基于transformers库的加载方式。下面是一个单张文档图片解析为Markdown的示例。
from transformers import AutoModel, AutoProcessor model_path = "AIDC-AI/OvisOCR2" processor = AutoProcessor.from_pretrained(model_path, trust_remote_code=True) model = AutoModel.from_pretrained(model_path, trust_remote_code=True) image = "document.png" prompt = "请解析这张文档图片，输出完整的Markdown格式内容，保留表格和公式结构。" inputs = processor(text=prompt, images=image, return_tensors="pt") outputs = model.generate(**inputs, max_new_tokens=4096) result = processor.decode(outputs[0], skip_special_tokens=True) print(result)
对于多页PDF，可以先使用PyMuPDF或pdf2image把每页渲染成图片，然后逐页调用模型，最后把返回的Markdown按顺序拼接。需要注意的是，如果文档中存在跨页表格，逐页解析后仍需要额外的后处理来合并表格片段。OvisOCR2本身已经学习了一部分跨页连续性的表示，但在工程实现中，单页输入仍然是常见方式。对于超长文档，可以尝试将相连两页拼接成一张长图输入，但要注意显存占用和序列长度限制。
如果要在自己的业务数据上微调，建议使用LoRA而不是全参数微调。0.8B模型虽然参数不多，但全参数微调仍然可能过拟合到小规模标注集。LoRA可以只训练少量适配器参数，保留预训练的通用文档理解能力。训练数据格式与推理时保持一致，输入为图像和提示词，输出为目标Markdown文本。学习率建议在1e-4到5e-5之间，批次大小根据显存调整。微调后的模型可以在特定版式或特定领域文档上获得明显提升，例如医疗检验单、财务报表等。
适用场景与已知限制
OvisOCR2适合文档数字化、合同关键信息抽取、论文PDF转Markdown、企业知识库RAG前置解析等场景。0.8B的参数规模意味着推理成本较低，在普通CPU上也能运行，只是速度会比GPU慢一些。对于每天需要处理大量扫描件的业务，可以用它替代传统的OCR加版面分析流水线，简化维护成本。输出Markdown后，可以进一步送入下游的大语言模型做摘要、问答或信息提取，因为结构化的Markdown比纯文本更容易被语言模型理解。
不过OvisOCR2也有一些限制。手写体识别仍然是一个弱点，尤其是连笔手写和低对比度的扫描件。此外，极度复杂的科学排版或者非常古老的中文竖排文档，模型可能无法完全还原原始版式。虽然OmniDocBench登顶证明了它在评测集上的能力，但真实世界文档的多样性远高于基准测试覆盖的范围。如果业务中涉及大量特殊版式，建议先在自己的样本上做一轮效果验证，再决定是否替换现有方案。
总体来看，OvisOCR2的意义不只是提供了一个小模型，更重要的是验证了端到端文档解析在低参数规模下的可行性。它的开源会让更多团队尝试用生成式模型统一处理文档理解任务，而不是继续维护多级联的复杂管线。对于文档解析方向的开发者来说，这个模型值得上手测试。
OvisOCR2OmniDocBench文档解析修改时间：2026-10-03 05:07:35