端到端模型第一次赢了流水线
文档解析是RAG（检索增强生成）和AI知识库的基础。一张文档图片进来，要输出带格式的Markdown——文本、表格、公式、图表、阅读顺序，全都要保留。
过去做得最好的方案都是流水线式的：先做版面分析检测出表格区、公式区和文本区，然后分别用专用模型识别，最后拼回一份Markdown。每个环节一个模型，部署复杂，误差累积。端到端方案一次推理搞定，简单优雅，但精度一直追不上流水线——直到OvisOCR2出现。
2026年7月15日，阿里巴巴ATH-MaaS团队（Token Hub模型即服务团队）发布了OvisOCR2。这是一个基于Qwen3.5-0.8B的端到端文档解析模型，仅0.8B参数。但在OmniDocBench v1.6上，它拿下了96.58分，首次让端到端方案超越了所有流水线方案，登顶全球第一。模型采用Apache 2.0许可，可商用。
文档解析是过去一年AI基础设施竞争最激烈的赛道之一。百度PaddleOCR-VL-1.6以96.33分霸榜，智谱GLM-OCR紧随其后，DeepSeek-OCR-2不断迭代。这些模型大多采用"版面分析+区域识别"的流水线架构，精度高但部署复杂。OvisOCR2的出现第一次证明：端到端方案在精度上不输流水线，在部署简单度上全面超越。
0.8B参数如何拿下96.58分
OmniDocBench v1.6是目前文档解析领域最具权威性的榜单之一。榜单前三此前被PaddleOCR-VL-1.6、GLM-OCR等流水线方案占据，OvisOCR2是第一个超越它们的端到端模型，而且仅用了0.8B参数。
在PureDocBench上，OvisOCR2同样以75.06的Avg3分取得最高成绩，在Clean和Digital两个子榜单上均位列第一。内部构建的难度分级评测覆盖了超1000页文档，包含简单、中等、困难三个档次，以及手写体和复杂表格等场景。OvisOCR2在所有这些维度上都领先所有对比方法——包括参数量几十倍于它的流水线方案。
0.8B参数能做到这个水平，靠的不是模型架构创新（基座就是Qwen3.5-0.8B），而是一套精密设计的后训练管线：数据引擎+SFT+RL+蒸馏+融合。
数据引擎：真实+合成双管线
OvisOCR2的数据引擎由两条管线组成，互补互足。
真实文档管线使用PaddleOCR-VL-1.5或MinerU2.5-Pro等专业解析器处理真实文档，产出结构化JSON，再通过一套归一化规则转换为统一Markdown。转换过程包含类别校验——未知类别直接拒绝；文本合并——合并相邻文本块，根据编号推断标题级别；公式格式修正——\(...\)转$...$、\[...\]转$$...$$；表格增强——加border=1、去除畸形HTML。转换后的数据经过人工抽检，保留只有少量错误的数据子集，丢弃频繁出错的子集。
合成文档管线走的是"同一HTML产出图片和标注"的路线。从HTML模板出发，用Playwright渲染成文档图片，同时从HTML直接序列化出标准的Markdown标注。这就避免了"用模型A标注数据训练模型B"的噪声循环——标注是确定性的，不是模型预测的。
合成管线还通过Agent驱动的多样化过程自动生成各种文档布局和内容变体，覆盖表格密集型、手写体、不规则结构等长尾场景。具体来说，先用多模态模型分析失败案例，生成初始HTML模板，然后Agent在内容层面做语义字段和术语替换，在结构层面做表格拓扑、章节层级和列布局的变化。质控层面执行小批量预览→审核→大规模渲染→移除配对失败和空标注的完整流程。
两种管线的互补让OvisOCR2既拿到了真实文档的多样性，又确保了合成数据的标注精度。
OvisOCR2的数据管线还有一个值得一提的细节：真实数据经过人工子集级抽检，合成数据经过小批量预览→审核→大规模渲染→移除失败的完整质控流程。这样的双重质检保证了训练数据的整体质量——论文中提到，对于频繁出现错误的真实数据子集会整批丢弃，而不是试图修补每个错误标注。这种"要么全好，要么全扔"的保守策略在数据工程中是行之有效的做法。
SFT→RL→蒸馏→融合：四阶段训练
OvisOCR2的训练方案分为四个阶段，每个阶段解决一个具体问题。
第一阶段是监督微调（SFT）。对Qwen3.5-0.8B和Qwen3.5-4B两个模型同时做全参数微调，使用真实加合成的完整数据混合。0.8B训练2个epoch，4B训练0.2个epoch以节省成本。最大序列长度16K token，支持动态分辨率输入。
第二阶段是强化学习，在4B分支上使用GRPO算法。GRPO（Group Relative Policy Optimization）是一种不需要独立价值模型的策略优化方法。它对每个提示采样多个响应，计算组内相对优势来更新策略。这样做的好处是省去了价值模型的训练和推理开销，在长序列文档场景下尤其重要。
奖励函数包含三个组件，每个组件衡量一个核心维度。文本保真度用归一化编辑距离，公式匹配度用CDM（字符检测匹配），表格相似度用TEDS（树编辑距离相似度）。最终页面得分为各组件得分的加权平均，权重取决于该页面中实际存在的元素类型。如果某页面没有表格，表格组件就不参与计算。
RL阶段只使用合成数据，因为合成数据的标注是确定性的（从HTML直接序列化），能提供准确的奖励信号。少量高质量真实文档也被加入以增加多样性。训练前还做了一次"在策略过滤"——去掉极简单、极困难或奖励平坦的样本，确保RL专注于那些做对做错有明显差异的样本。
之所以不在0.8B上直接做RL，是因为小模型在RL训练中更容易退化。团队的做法是在4B上做RL学到好的策略，然后蒸馏回0.8B。
第三阶段是在策略蒸馏（OPD）。4B教师模型生成输出，0.8B学生模型学习教师的输出分布而非地面真值硬标签。这样学生能学到教师的策略分布和决策边界。
第四阶段是模型融合。将多个候选变体的参数做平均，加权系数根据验证集表现确定。融合后的模型在稳定性和泛化能力上进一步提升。
部署：4GB显存就能跑
OvisOCR2只有0.8B参数，BF16权重约1.6GB，INT4量化后更低。入门级消费GPU（4GB-8GB显存）即可运行，这在当前显存价格飞涨的背景下是一个实际优势。
推荐使用vLLM 0.22.1+部署，一条命令启动OpenAI兼容API服务。最大生成token数16384，支持动态分辨率输入（448×448到2880×2880自适应），可批量处理多张图片。也支持SGLang作为推理后端。
模型的Prompt设计也很简洁。核心指令是：以自然阅读顺序提取图片中所有可读内容，以单个Markdown文档输出。公式用LaTeX格式，表格用HTML格式，图表等视觉区域用带边界框坐标的<img>标签表示。输出后处理会自动清除末尾的重复模式和空行。
对RAG应用来说，OvisOCR2的端到端设计优势明显：不需要维护版面分析加VLM识别加结果合并的流水线，一个模型装上去，图片进去，Markdown出来。部署和运维成本比流水线方案低得多。
端到端文档解析的时代
OvisOCR2的意义不只是又一个高分模型。它用0.8B参数、Apache 2.0许可证明了端到端文档解析可以做到比流水线更好。
在技术层面上，这套训练方案——SFT建立基础能力→GRPO强化长尾场景→OPD蒸馏回小模型→融合提升稳定性——是对小模型后训练的一次系统性探索。GRPO的三组件奖励函数设计覆盖了文本、公式、表格三个核心维度，Agent驱动的合成数据引擎解决了长尾覆盖问题。
在实用层面上，0.8B模型跑在4GB显存上就能达到96.58分的文档解析质量，这对中小团队尤其友好。不需要采购高端GPU，不需要维护多模型流水线，一个模型就能完成过去整套方案的工作。
OmniDocBench 96.58分的记录未必会保持很久——文档解析领域的竞争非常激烈。但OvisOCR2代表的信号很清楚：端到端方案在精度上已经不输流水线，在部署简单度上全面超越。对于正在做RAG知识库、文档数字化、票据识别、合同解析的团队，一个0.8B模型就能搞定以前需要整套流水线才能完成的任务，部署门槛大幅降低。
如果你正在做RAG相关的项目，当前的文档解析选型可以考虑OvisOCR2。安装只需一条pip命令，vLLM启动服务后直接调用OpenAI接口格式即可。不需要配置版面分析模型，不需要串联多个识别模块，也不需要处理各模块之间的数据格式转换。一份文档进去，Markdown出来——就是这么简单。
核心配置单
-
• 发布：2026年7月15日 | 阿里巴巴ATH-MaaS -
• 模型：OvisOCR2 | 参数：0.8B | 基座：Qwen3.5-0.8B -
• 任务：文档图片 → Markdown（文本+公式+表格+图表） -
• 训练：SFT → GRPO(4B) → OPD蒸馏 → 模型融合 -
• 部署：vLLM / SGLang | 推荐显存 ≥4GB