← 返回 PaperDaily
视觉与图像
0.8B端到端文档解析SOTA：OvisOCR2怎么做到的
阿里这次没玩虚的，直接把文档解析从“流水线拼装”拉到“端到端一把梭”。0.8B 小模型能在公开榜单上登顶，关键不在嘴上说模型小，而在数据引擎和训练 recipe 真把小模型喂明白了。
龙哥读论文
阅读 3
查看原文
🐉 龙哥读论文知识星球来了！公众号每日8篇拆解不够看？星球无上限更AI领域论文、资讯、招聘、招博、开源代码，一站式干货，每日2分钟刷完即赚！
👇扫码加入「龙哥读论文」知识星球，前沿干货、实用资源一站式拿捏～
龙哥推荐理由：
阿里这次没玩虚的，直接把文档解析从“流水线拼装”拉到“端到端一把梭”。0.8B 小模型能在公开榜单上登顶，关键不在嘴上说模型小，而在数据引擎和训练 recipe 真把小模型喂明白了。
原论文信息如下：
用0.8B小模型干翻所有同行！阿里OvisOCR2实现端到端文档解析SOTA
文档解析这件事，表面看是“把图片里的字抠出来”，真干起来才知道它有多烦：标题、正文、表格、公式、页眉页脚、图注、阅读顺序，任何一个环节掉链子，最后生成的 Markdown 就像被风吹乱的书页，能看但不好用。
OvisOCR2 的狠劲就在这里：它没有继续把系统拆成一堆流水线模块，而是直接做成一个端到端页面级文档解析模型。给一张文档页图片，直接吐出自然阅读顺序下的 Markdown，文本、公式、表格、视觉区域一起处理。更离谱的是，核心模型只有 0.8B 参数，却在公开榜单上把一堆“更大、更重、更会拆零件”的方案按在地上摩擦。
端到端vs流水线：一图看尽OvisOCR2的优雅与强悍
先把话说人话：流水线方案像“分工明确的工厂”，先做版面分析，再做区域识别，再拼回整页；端到端方案则像“一个人从头读到尾”，直接从页面图像生成结构化结果。前者通常更稳，后者通常更省心，但过去常常是“省心不够强，强的又太复杂”。
OvisOCR2 选择了后者，而且不是随便试试。它的目标很明确：用一个小模型，顶住页面级文档解析的全链路压力。这意味着模型不仅要识字，还要知道哪里是表格、哪里是公式、哪里该换行、哪里该保留图像占位符，最关键的是，输出顺序得像人读书，而不是像扫描仪乱翻页。
这套路线的聪明之处在于，它没有要求 0.8B 模型硬扛所有高难度学习任务，而是先让 4B 分支做“高容量老师”，再把老师的偏好传回小模型。这样做的直觉很简单：大模型更能稳住长输出和复杂结构，小模型更适合部署，但直接拿小模型去做高强度强化学习，容易学着学着就跑偏，甚至把表格学成“散装文本”。
数据炼金术：真实与合成数据的完美融合，为小模型注入大能量
这篇论文真正值钱的地方，不只是模型结构，而是数据引擎。因为文档解析最怕的不是模型不够大，而是训练数据“看起来很多，实际上很脏”。真实文档有自然分布，但标注噪声大；合成文档标签干净，但太像“样板间”，一旦合成得太假，模型很容易学成纸上谈兵。
真实数据管线做的事并不花哨：先用现成 OCR/文档解析器拿到结构化结果，再统一成 Markdown schema，然后用规则过滤掉明显坏样本，再做子集级抽查。这里的关键不是“全自动神奇修复”，而是宁可少收一点，也别把脏标注整锅端进训练集。对长输出任务来说，低质量样本会把模型的阅读顺序、表格结构和公式格式一起带歪，后果比普通分类任务更糟。
合成数据管线则更像“定向造题”。论文不是随便画几页假文档糊弄模型，而是从难例里反推模板：先挖失败样本，再让多模态模型把这些难例抽象成 HTML 模板，接着用 agent 去扩展内容和结构，最后用同一份 HTML 同时生成图片和 Markdown。这样做的好处很直接：图像和标签来自同一源头，不会出现“图像长这样，标签却像另一个世界”的尴尬。
这套思路其实很朴素：真实数据负责覆盖现实世界的脏乱差，合成数据负责补齐罕见但关键的结构模式。比如复杂表格、密集公式、长页面、多栏阅读顺序、手写文档，这些都不是普通“多采点数据”就能解决的，必须靠有针对性的合成策略去补短板。
训练三部曲：SFT打基础，RL精优化，蒸馏保性能
OvisOCR2 的训练不是一口吃成胖子，而是三步走。第一步是监督微调（SFT, Supervised Fine-Tuning，监督微调），先让模型学会“像样地写 Markdown”；第二步是强化学习（RL, Reinforcement Learning，强化学习），再用可验证奖励把结构质量往上拽；第三步是在线蒸馏（OPD, On-Policy Distillation，基于当前策略轨迹的蒸馏），把 4B 分支学到的好习惯压缩到 0.8B 里。
先说 SFT。它用真实数据和合成数据的混合训练，把模型先调成“会写、写对、写顺”的基础状态。这里最重要的不是追求极致分数，而是先把输出格式、页面完整性、表格和公式的基本语法训稳。没有这一步，后面的 RL 很容易像拿着方向盘在泥地里飙车，越练越歪。
再看 RL。论文没有拿一个粗糙的文本相似度硬怼，而是设计了多组件奖励：文本看编辑距离归一化后的得分，公式看 CDM（Character Detection Matching，字符检测匹配，一种用于公式识别的图像级指标），表格看 TEDS（Tree Edit Distance-based Similarity，基于树编辑距离的相似度，用来衡量表格结构与内容匹配）。这说明论文很清楚：文档解析不是单纯“字对不对”，而是“结构对不对”。
RL 这一步最有意思的是它用的是 GRPO（Group Relative Policy Optimization，组相对策略优化）。简单说，就是同一个页面采样多个答案，再在组内比较谁更好，而不是单看一个答案的绝对分数。这样做对长文档特别合适，因为长输出里很多错误是局部结构错误，组内比较比单点监督更能抓住“哪个回答更像一个完整页面”。
但这里也有个现实问题：直接对 0.8B 小模型做 RL，容易不稳定。论文自己也做了对比，发现小模型直接 RL 的 KL 漂移更大，表格质量还会掉。于是它换了个更稳的做法：先让 4B 分支做 RL，得到一个更强的老师，再把老师的偏好通过 OPD 蒸馏给小模型。这个思路很实用，属于“先让大车跑稳，再把路线图交给小车”，比硬让小车自己在山路上试错靠谱得多。
OPD 的核心是只在学生模型的 top-k 支持集上对齐老师分布，避免全词表蒸馏把显存和算力烧穿。说白了就是：不是让老师把整本字典都讲一遍，而是只对学生最可能选的那几个词做精修。这种设计很工程化，也很符合长输出任务的现实成本。
最后还有模型融合。论文不是迷信单个 checkpoint，而是训练多个变体后做加权参数平均，把不同配置学到的优势揉在一起。这个步骤不花哨，但常常很有效，尤其在这种“数据、训练、奖励都很复杂”的任务里，融合往往能帮模型少犯一些偏科错误。
全面领先！OvisOCR2在OmniDocBench、PureDocBench和内部基准上的统治级表现
实验部分最能说明问题：这不是“某个子集涨一点点”的小打小闹，而是公开榜单和内部长尾场景一起上，结果都能站住。尤其在 OmniDocBench v1.6 这种传统上更偏流水线方案占优的榜单上，OvisOCR2 直接把端到端模型送上了第一梯队，这个信号很强。
再看 PureDocBench，OvisOCR2 的 Avg3 也拿到第一。这里的价值在于，它没有只在一个榜单、一个任务定义里刷分，而是在不同评测体系下都保持了领先。对工程落地来说，这比单点爆发更有说服力，因为真实业务不会只给模型一类页面。
更值得看的是内部基准。论文自己构建了超过 1000 页的长尾测试集，覆盖更复杂的场景，比如手写、复杂表格、阅读顺序混乱、局部结构难恢复等。这里不是为了“自家数据自家赢”，而是为了补公共基准看不到的盲区。公开榜单再强，也不代表真实业务里不会翻车；内部长尾能赢，才更接近“能上生产”的味道。
论文还单独展示了手写和复杂表格子集的结果，这两个方向都很能代表真实痛点。手写本来就比印刷体更容易失真，复杂表格则是文档解析里的老大难：行列关系一乱，整张表就废了。OvisOCR2 在这两类子集上的表现都更强，说明它不是只会“识字”，而是确实学到了页面结构。
如果把这些结果串起来看，能得到一个很清楚的判断：OvisOCR2 的领先不是单靠模型堆大，而是数据、训练、奖励和蒸馏四件事协同起来的结果。尤其是“真实 + 合成”数据引擎和“4B 教师 → 0.8B 学生”的路线，基本把小模型能做到的上限往前推了一大截。
总结与展望：小模型撬动大未来，端到端文档解析的黄金时代即将到来？
这篇工作最值得记住的，不是“0.8B 有多小”，而是“0.8B 为什么能赢”。答案并不玄学：先把数据做干净，再把训练分阶段做稳，再把结构性奖励和蒸馏接上，最后用融合收尾。文档解析这种任务，拼的本来就不是一招鲜，而是系统工程。
当然，这条路线也不是没有代价。它依赖高质量的数据引擎、较复杂的训练基础设施，以及对表格、公式、阅读顺序等组件的精细评估。换句话说，它不是“随便拿个模型就能复刻”的轻量玩法，更像是一套成熟团队才能稳定跑通的工程体系。对普通团队来说，最可借鉴的未必是完整复现，而是它的三个原则：数据要可控、奖励要可验证、部署目标要尽早锁定。
从行业角度看，OvisOCR2 释放了一个很明确的信号：端到端文档解析不是“理论上优雅、实际不够强”的备胎路线，它已经能在公开榜单上和流水线方案正面竞争，甚至反超。接下来真正值得关注的，不是它能不能赢一次，而是这种“端到端 + 小模型 + 强数据引擎”的组合，能不能在更多语言、更多版式、更多业务场景里稳定复制。
龙迷三问
这篇论文到底解决了什么问题？它解决的是“怎么把一页文档图像直接变成可用的 Markdown 结构”这个问题，而且尽量不靠复杂流水线。核心目标不是只识字，而是同时保住文本、公式、表格、视觉区域和阅读顺序。
GRPO、OPD 这些缩写分别是什么意思？GRPO 是 Group Relative Policy Optimization，中文可理解为“组相对策略优化”，它让模型在同一批采样答案里做相对比较；OPD 是 On-Policy Distillation，中文可理解为“基于当前策略轨迹的蒸馏”，这里指让学生模型沿着自己生成的轨迹，去学习老师模型的偏好。
为什么这篇工作里数据和训练比“模型结构”更重要？因为文档解析的难点大多不是“模型会不会看图”，而是“有没有足够干净、足够覆盖长尾、足够能验证结构的训练信号”。结构再花哨，数据不行也白搭；训练再猛，奖励设计不对也容易把模型带偏。
如果你还有哪些想要了解的，欢迎在评论区留言或者讨论~
龙哥点评
论文创新性分数：★★★★☆。端到端文档解析不是新概念，但把数据引擎、RL、OPD 和模型融合拧成一套完整可落地的体系，并在公开榜单上把小模型推到第一，创新性是实打实的。
实验合理度：★★★★☆。公开榜单、内部长尾、手写和复杂表格子集都覆盖到了，且有训练稳定性对比，实验链条比较完整；如果能再补更多消融，会更硬。
学术研究价值：★★★★☆。它证明了小模型也能靠系统设计打穿文档解析长链路，对后续结构化生成、长输出强化学习和数据合成都有启发。
稳定性：★★★★☆。4B 教师 + 0.8B 学生的路线明显比直接小模型 RL 稳，但整体仍依赖较复杂的数据和训练管线，不是开箱即用的玩具。
适应性以及泛化能力：★★★★☆。对真实文档、长尾结构、手写和复杂表格都有覆盖，但跨语言、跨版式极端场景仍需要更多验证。
硬件需求及成本：★★★☆☆。推理侧 0.8B 很友好，但训练侧的数据引擎、RL 和蒸馏都不便宜，属于“部署轻、研发重”。
复现难度：★★★☆☆。模型和项目已开源，但完整复现数据引擎、RL 奖励和内部基准并不轻松，工程门槛不低。
产品化成熟度：★★★★☆。从“能不能用”看已经很接近生产级，尤其适合页面级文档解析；但要进更复杂业务链路，仍需做领域适配和容错评测。
可能的问题：亮点在系统工程而非单点算法，若数据引擎迁移不到位，效果可能打折；内部基准虽强，但外部泛化仍需更多跨域验证。
主要参考文献
[1] OvisOCR2 Technical Report. arXiv:2607.13639v1, 2026.
[2] PureDocBench main table. 论文中引用的公开基准结果来源。
[3] PaddleOCR-VL-1.5 technical report. 论文中用于真实数据管线的结构化解析器之一。
[6] MinerU2.5-Pro technical report. 论文中用于真实数据管线的结构化解析器之一。
[7] OpenDataLab OmniDocBench v1.6 leaderboard.
[13] Playwright. Browser automation and rendering toolkit.
*本文仅代表个人理解及观点，不构成任何论文审核或者项目落地推荐意见，具体以相关组织评审结果为准。欢迎就论文内容交流探讨，理性发言哦～ 想了解更多原文细节的小伙伴，可以点击"阅读原文"，查看更多原论文细节哦！
欢迎加入龙哥读论文粉丝群，
扫描下方二维码或者添加龙哥助手微信号加群：kangjinlonghelper。
一定要备注：研究方向+地点+学校/公司+昵称（如 图像处理+上海+清华+龙哥），根据格式备注，可更快被通过且邀请进群。
文档解析、图像增强、大模型、Agent、机器人，群里都能聊，少走弯路，多看门道。
