字节跳动Dolphin-v2：数字 PDF 拆开读、拍照文档整页读，自建拍照文档集平均编辑距离较原始 Dolphin降低约 91%

2026/7/29 5:44:24

同一页论文，从电脑里导出来，和用手机拍下来，内容一点没变。

可到了文档解析模型手里，它们最好别走同一条路。

电脑导出的 PDF 横平竖直，标题、段落、表格和公式都有清楚的边界。先把这些区域找出来，再分块识别，通常又稳又省事。手机拍下来的纸却不一样，页面会弯，会皱，会有透视和阴影。此时还拿一排矩形框硬切，框本身就可能先把文字和表格切坏。

论文的 Figure 5 把这个差别拍在了脸上。同一张发生弯折、透视和模糊的纸，Dolphin-v2 保留整页关系后，输出比对照方法更完整。当然，这只是一组案例，不是批量成绩，但它很适合拿来理解问题究竟出在哪。

Dolphin-v2 最有意思的地方就在这里。它没有继续争论整页读和拆开读到底谁更高级，而是先问了一个更实际的问题，这页东西到底是数字文档，还是拍照文档？

然后再决定，整页读，还是拆开读。

PDF链接：https://arxiv.org/abs/2602.05384

文档解析不是抄字，而是重建一页东西

很多人听到 OCR，脑子里还是把图片上的字变成文本。可一份真正可用的文档，远不止一串字符。

双栏论文要知道先读左边还是右边，表格要保留行列关系，公式要变成结构正确的 LaTeX，代码要留下缩进，标题、脚注和图注也得回到各自的位置。字都认对了，顺序却乱了，这份文档依然没法进入知识库。代码字符一个没错，Python 缩进丢了，程序照样跑不起来。

所以文档解析更像是重建页面，而不是抄写页面。

过去常见的做法，大致有两条。第一条是先做版面检测，把表格、公式、段落等区域裁出来，再交给不同能力处理。它的好处很直接，类型清楚，多个小块还能并行生成。但第一步一旦漏框、错框，后面看到的就是残缺输入，再强的识别模型也救不回来。

第二条是整页交给视觉语言模型，让它直接按阅读顺序生成 Markdown。全局关系保住了，弯曲和透视也不必强塞进方方正正的框里。代价同样明显，整页输出很长，自回归生成更容易漏内容或幻觉，推理负担也会变重。

这两条路没有谁天然更先进。它们解决的是不同输入条件下的问题。

先分类，再选择页面的读法

Dolphin-v2 用的是同一个 Qwen2.5-VL-3B 模型，只是让它在两个阶段扮演不同角色。

第一阶段先看完整页面，判断它属于 digital 还是 photographed。

如果是拍照文档，模型到这里就不再生成一堆元素框。第二阶段复用整页视觉特征，按阅读顺序直接生成页面内容，尽量保住透视、褶皱和不规则布局中的全局关系。

如果是数字文档，第一阶段会继续输出元素类别、绝对像素坐标和阅读顺序。第二阶段再把这些区域裁出来，表格、公式、代码和普通段落各用对应提示并行解析，最后按预测顺序拼回去。

论文的 Figure 3 就是整套方法的总览。上半部分先分类并做布局分析，下半部分才出现真正的分流，照片整页走，数字页面按元素并行走。

我更愿意把这里的 anchor 理解成页面上的路标，而不是一句神奇 prompt。路标里有这里是什么、它在哪、应该第几个读。第二阶段拿着这些信息，才知道眼前这块应该输出普通文本、HTML 表格、LaTeX 公式，还是保留缩进的代码。

这也是 Dolphin-v2 所谓 Scalable Anchor Prompting 真正有工程味的部分。同一个模型不是永远执行一个任务，而是由输入粒度、元素类型和提示接口共同决定此刻该做什么。

三张表不是成绩单，而是模型的工作词典

论文用 Table 1 列出 21 个布局标签，从论文标题、五级标题、段落、页眉页脚，一直到表格、公式、代码、目录、参考文献和列表。原始 Dolphin 只有 14 类，v2 把页面拆得更细。

Table 2 则给出六种任务提示。布局、整页、公式、代码、表格和普通段落各有入口。表格要求输出 HTML，公式走专门的公式提示，代码也有自己的读取方式。

Table 3 再往前走了一步，它列出的 14 个属性字段包括作者、单位、邮箱、发表日期、DOI、arXiv 编号、摘要、关键词和页码。输出不再只是这里有一段文字，而是试图告诉下游系统，这段文字在文档里扮演什么角色。

但这三张表需要用对读法。它们描述的是系统的能力词典和接口范围，不是字段级准确率成绩单。论文没有在这里证明 21 类元素都能同样稳定地解析，也没有给 14 个属性逐项报分。把 schema 支持直接等同于可靠抽取，反而会高估系统。

有些错误，人眼看不出来，机器却没法继续用

结构为什么这么重要，代码是最直观的例子。

论文的 Figure 6 展示了一页含 Python 代码的数字文档。对照输出把代码当成普通文字，字符大体还在，缩进层级却丢了。Dolphin-v2 先把代码识别成单独元素，再用专门提示保留空格和层级。

这张图能说明它做得到，却还不能证明代码能力已经全面解决。论文没有代码专项测试集、可编译率或缩进准确率。这里更适合把它看成一个能力样例。

公式的证据更完整一些。Figure 9 里的输出，肉眼看上去和原图很接近，但模型把一整段带公式的文字当成了独立展示公式。画面像，底层结构却错了。后面无论做检索、编辑还是重新排版，都会出问题。

这大概是我看这篇论文时最想保留的一层判断，下一代 OCR 的目标不只是让输出看起来像原文，而是生成下游机器还能继续操作的文档表示。

60 万张新数据和十倍参数，也得算进成绩里

Dolphin-v2 的变化不只有路由。

作者又合成了 20 万张拍照文档、20 万张代码图和 20 万张目录图。拍照数据用 Blender 模拟弯折、褶皱、透视、灯光和相机变化；代码覆盖 C++、Python、Go、JavaScript，每种 5 万张；目录则覆盖单双栏和不同层级。

模型也从原 Dolphin 的 0.3B 扩到了 3B，参数量增加十倍。与此同时，坐标从两位小数的归一化位置换成绝对像素坐标，布局类别从 14 种扩到 21 种，又加入类型分类、公式和代码专用处理。

所以后面的总成绩衡量的是整套升级系统。路由很重要，但不能把所有提升都算到路由头上。真正能单独支持某个设计的，是后面的两张消融表。

三个测试集，给出了三种不同强度的答案

先看数字文档。OmniDocBench 同时考文字、公式、表格和阅读顺序，Table 4 是这部分的主结果。

Dolphin-v2 的 Overall 是 89.78，排在 PaddleOCR-VL 的 91.93 和 MinerU2.5 的 90.67 后面。它没有拿到单项第一，但相对原 Dolphin 的 74.67，文字编辑距离、公式 CDM、表格 TEDS 和阅读顺序都明显改善。

这里有一个会影响精确增幅的口径差异。主表从 74.67 到 89.78，差值是 15.11 分；论文摘要和正文却写成 89.45 与增加 14.78 分。两组说法没有对齐。新稿采用主表的 89.78 描述榜单位置，不替作者猜哪个版本才是最终值。

再看作者自建的 RealDoc-160。它有 160 页，英文和中文各 80 页。页面先打印，再用手机在不同角度、光照、弯折和褶皱条件下拍摄。Table 5 的指标是 Edit Distance，越低越好。

Dolphin-v2 的英文、中文和平均值分别是 0.0046、0.0737 和 0.0392。原 Dolphin 的平均值是 0.4363，编辑距离相对减少约 91%。注意，这句话说的是错误量下降，不是准确率提高 91%。

中文单项也不是第一。Gemini-2.5 Pro 是 0.0681，低于 Dolphin-v2 的 0.0737。Dolphin-v2 的平均优势主要来自极低的英文编辑距离。

91% 很亮眼，但 RealDoc-160 毕竟只有 160 页，而且来自作者内部文档。于是还得看更大的外部拍照文档基准 DocPTBench。Table 6 一次给出英文、中文的文字、公式、表格和阅读顺序结果。

Dolphin-v2 的 Overall Edit 是英文 30.8、中文 37.3。和原 Dolphin 的 57.5、71.5 相比，错误分别相对减少约 46.4% 和 47.8%。这个幅度没有 RealDoc-160 那么夸张，但仍然是稳定的大步提升。

它在专用文档模型里拿到英文 Overall 第一，中文与 dots.ocr 并列。不过把通用大模型也放进来，Gemini-2.5 Pro 的 18.2、30.4 仍然更低。分项也各有强手，olmOCR 的文字编辑距离更低，Nanonets-OCR2 的表格 TEDS 更高，olmOCR 的中文阅读顺序也更好。

所以 Dolphin-v2 的优势更像均衡和跨场景，而不是每一列都横扫。