一个0.9B 参数的小模型在文档解析的权威评测 OmniDocBench 里拿了总分第一92.86 分。第二名 MinerU2.5 是 90.67差的不是很多。但你再往下看GPT-4o 只有 75.02Qwen2.5-VL-72B 只有 87.02Gemini 2.5 Pro 也只有 88.03。0.9B 对 72B。参数差了 80 倍分数反超了将近 6 分。这个数据大部分人看到的第一反应是OCR 这东西不是早就解决了吗微信扫一扫都能把图片转文字有什么好卷的。说实话我以前也是这么想的。直到去年我自己搭 RAG 系统的时候被 PDF 文档解析折磨了整整两周。你有一份三栏排版的学术论文里面有表格有公式有图表你把它丢给一个普通的 OCR 工具。结果呢文字倒是读出来了但公式变成了乱码表格的列全串了图表干脆被识别成了「图片」阅读顺序更是乱七八糟第一段读到一半直接跳到第三栏去了。你心想那我换个 GPT-4o 试试。结果它确实能读出来一些东西但公式还是错的表格结构还是烂的而且跑一次要等好几秒一份 50 页的 PDF 跑下来喝杯咖啡回来还没跑完。这时候你才意识到OCR 和文档解析根本是两件事。OCR 只负责认字它不认识表格的结构不知道公式的上下标关系看不懂图表的纵轴和横轴。它就像一个只会认字的小学生你给他一篇论文他能把每个字都念出来但完全不知道这篇论文在说什么。而文档解析要做的是看懂整篇文档的结构。哪段是正文哪块是表格哪个是公式哪个是图表这些东西的阅读顺序是什么最后把它们全部转成结构化的格式比如 Markdown。这个差距在过去这一年突然变得特别重要。因为 RAG 系统爆发了每个人都在给自己的 AI 接文档但很少有人意识到文档解析的质量直接决定了 AI 回答的靠谱程度。你喂给 AI 的是一堆乱码它吐出来的答案能对吗。但问题不止于此。就算你理解了文档解析比 OCR 难你大概率还是会觉得这种复杂任务肯定是大模型更擅长吧。回到开头说的那篇论文来自百度的PaddleOCR-VL。它在 OmniDocBench v1.5 上拿了第一 92.86 分好几个子项的表现也很好。先说文字识别。编辑距离只有 0.035几乎是零错误。这个数字什么概念呢第二名的 MinerU2.5 是 0.047GPT-4o 是 0.217。编辑距离越低越好0.035也就是每 1000 个字符里只错 35 个而且大部分可能还是标点符号这种级别的。公式识别就更夸张了。公式CDM 分数91.22比第二名 MinerU2.5 的 88.46 高出将近 3 分。你别看 3 分好像不多在公式识别这个子任务上上一代最好的模型 MonkeyOCR-pro-3B 才 87.25Qwen2.5-VL-72B 是 88.27。PaddleOCR-VL 直接把天花板往上推了一截。表格结构还原也是断层级的。表格TEDS 分数90.89比 MinerU2.5 的 88.22 高了 2 分多。表格 TEDS-S 达到了 94.76这个指标衡量的是表格结构还原的精度包括单元格合并、行列对齐这些。以前做表格识别最怕的就是合并单元格一合并就乱PaddleOCR-VL 在这个指标上的表现是断层式的。而且它不是只赢了这几个指标。阅读顺序编辑距离 0.043和最好的水平持平。英文表格 TEDS 在 OmniDocBench v1.0 上略低一些88.0但论文里解释了这个差距主要是标注错误导致的中文表格 TEDS 是 92.14几乎是碾压级的。但更有意思的是它不是只赢了大模型它还赢了所有专用模型。说真的我一开始看到 0.9B 拿第一的时候脑子里想的是是不是只在 OmniDocBench 这一个评测上运气好。毕竟单榜第一这种事有时候换个评测集就现原形了。结果它在olmOCR-Bench上也拿了第一。80.0 分比 dots.ocr 的 79.1 高了将近 1 分比 MinerU2.5 的 77.5 高了 2.5 分比 MonkeyOCR-pro-3B 的 75.8 高了 4 分多。olmOCR-Bench 是一个更细粒度的评测包含 1402 个 PDF 文档和 7010 个测试用例涵盖了 ArXiv 论文、旧版扫描件、数学表格、多栏文本、长微小文本等各种复杂场景。两个权威评测都是第一。怎么说呢这就不是运气了。我顺着论文把各个维度的对比拉了一遍大概是这样文字识别上编辑距离 0.035全面领先表格识别上TEDS 90.89领先所有竞品公式识别上CDM 91.22断层领先图表识别上RMS-F1 0.844远超 72B 大模型的 0.730推理效率上比 MinerU2.5 快 53%。这里展开说一下效率。论文里测了端到端的推理速度在单张 A100 上跑 512 份 PDFPaddleOCR-VL 用FastDeploy部署总耗时 605.6 秒每秒处理 1.62 页。而 MinerU2.5 用 vLLM 部署总耗时 927.3 秒每秒 1.06 页。页面吞吐量高了 53%Token 吞吐量高了 51%。又准又快说真的这在文档解析领域确实是很少见的组合。那问题来了0.9B 的小模型凭什么能打 72B 的大模型。我觉得这事最值得讲的地方不是技术有多炫而是思路有多对。传统的大模型做文档解析思路是端到端的。一张图扔进去让模型一次输出所有内容文字、表格、公式、图表全部混在一起输出。这个思路的问题很明显长文档的输出序列巨长模型容易产生幻觉而且速度慢因为每输出一个 Token 都要和前面的所有 Token 做注意力计算。PaddleOCR-VL 的做法完全不一样。其实吧它把整个过程拆成了两步。先用一个轻量级的布局分析模型 PP-DocLayoutV2先把文档里的各种元素找出来文字在哪个位置表格在哪公式在哪图表在哪它们的阅读顺序是什么。这一步不需要大模型一个目标检测器就够用了。再把识别出来的每个元素区域裁剪出来喂给 PaddleOCR-VL-0.9B 做精准识别。这个 0.9B 的 VLM 虽然小但它的视觉编码器用了NaViT 架构可以处理任意分辨率和长宽比的图片不需要像传统 ViT 那样把图片暴力压缩成固定尺寸。语言模型是 ERNIE-4.5-0.3B专门针对文字、表格、公式、图表四种元素做了指令微调。而且这四种元素是同一个模型统一处理的。不需要文字识别一个模型表格识别一个模型公式识别一个模型图表识别一个模型。一个模型搞定所有。所以核心思路其实很简单把复杂问题拆成两个简单问题每个问题用最合适的工具解决。布局分析不需要大模型就用轻量检测器元素识别需要理解能力但不需要理解整篇文档的上下文只需要理解「这一小块是什么」所以 0.9B 就够了。还有一个细节推理的时候用了多线程异步流水线。数据加载、布局分析、VLM 推理三个环节分别跑在不同的线程里数据通过队列传递当队列里的元素积攒到一定数量或者等待时间超过阈值就触发一次批量推理。这个设计让不同页面的元素可以聚合在一起处理最大化并行度。你说这个思路有多高深吗好像也没有。但它就是比端到端的大模型更有效。而且吧这模型的能力边界比我想象的要宽得多。论文里有一个细节让我印象很深。它自己建了一个叫 In-house-OCR 的评测集覆盖了109 种语言和 13 种文字类型包括手写中文、手写英文、印刷体、繁体中文、古籍、拼音、生僻字、竖排文字、单字符、Emoji、艺术字等等。109 种语言从阿拉伯语到泰米尔语从韩语到希腊语它的编辑距离都是最低的。拉丁语系编辑距离 0.013几乎是完美识别。日语 0.096韩语 0.052泰语 0.081这些被认为「OCR 很难搞」的语言它都做得很好。手写体这块也很有意思。在 Ocean-OCR 手写评测上中文手写编辑距离 0.034这什么概念呢Qwen2-VL-7B 是 0.113差了快 4 倍。英文手写 0.118也比 Qwen2-VL-7B 的 0.127 要好。古籍识别也是一样。竖排从右到左字迹斑驳传统 OCR 基本上直接崩溃但 PaddleOCR-VL 的编辑距离只有 0.198。繁体中文 0.048几乎是印刷体级别的精度。这些场景背后是同一个模型的同一套架构。它不需要为手写体单独训练一个模型不需要为古籍单独训练一个模型不需要为每种语言单独训练一个模型。一个 0.9B 的模型覆盖了所有这些场景。我觉得这就回到了文章开头那个问题。为什么 0.9B 能打 72B。因为 72B 的大模型是通用模型它要处理的任务太多了写代码、写文章、翻译、推理、对话文档解析只是它上千种能力中的一种。而 PaddleOCR-VL 的 0.9B从训练数据到模型架构到推理流水线全部围绕文档解析这一个任务设计。3000 多万个训练样本覆盖了文字、表格、公式、图表、手写、古籍、109 种语言。它不干别的就干这一件事。所以它不是「虽然小但很强」而是「因为专所以强」。在 AI 的世界里不是参数越大越好而是越对路越好。这篇论文的模型已经开源了如果你正在搭 RAG 系统或者需要处理大量 PDF 文档值得去看看。它支持 FastDeploy、vLLM、SGLang 三种部署方案消费级显卡就能跑。感谢阅读。点个关注不迷路我们后续会持续跟进文档解析、OCR、多模态模型等前沿技术动态第一时间为你解读。