- 引言 — 为什么要超越 OCR
- 核心原理：传统 OCR 流水线及其局限
- 深入探讨 1：OCR-free 端到端文档理解
- 深入探讨 2：高分辨率、布局、表格、公式
- 深入探讨 3：多语言 OCR 与统一模型
- 深入探讨 3.5：阅读顺序与布局的难点
- 深入探讨 3.6：表格结构化的具体方法
- 深入探讨 4：基准测试与评估方法
- 深入探讨 5：推理流水线设计
- 深入探讨 6：手写、低画质、旋转等难题
- 对比表：传统 OCR 与 OCR-free
- 深入探讨 9.5：用提示词设计来把控输出
- 实务应用：收据、表单、文档
- 深入探讨 7：OCR-free 与传统 OCR 的混合方案
- 深入探讨 8：稳定获取结构化输出
- 深入探讨 9：成本与延迟视角
- 深入探讨 12：多语言文档的额外挑战
- 陷阱与局限
- 深入探讨 10：按领域应用时的考量
- 深入探讨 11：未来的方向
- 结语
- 参考资料
引言 — 为什么要超越 OCR
抠出收据的总额、抽取合同里的条款、把图表转成表格 — 这类文档理解任务长期以来都建立在 OCR(光学字符识别)之上。但 OCR 只擅长把字符读出来，至于这些字符是什么意思、属于哪一个格子，它并不会告诉你。
于是传统的文档处理把好几个阶段像链条一样串起来。先检测字符在哪里，再识别这些字符是什么，然后分析页面的布局，最后才解释其含义。阶段越多，某一处的误差就越容易传导到下一个阶段，形成误差累积问题。
最近，用一个模型整体替代这条链条的 OCR-free 方法兴起了。它把图像作为输入，直接给出我们想要的答案(文本、键值、表格)。本文将梳理传统流水线的局限、OCR-free 端到端模型，以及把检测-识别-解析合而为一的统一模型的走向。
OCR 与文档理解并不是一回事
先厘清术语。OCR 是把图像中的字符转写成文本的工作。文档理解则是弄清这段文本具有怎样的结构与含义。两者是不同的阶段，传统系统把它们分开处理。
OCR: 图像 -> "总额 32,500" (字符转为文本)
文档理解: "总额 32,500" + 位置/上下文 -> {字段: 总额, 值: 32500} (赋予含义)
OCR-free 方法的核心主张是，这两者其实没必要分开。如果一个模型在看图像的同时就同时把握字符和含义，就能保留那些在经过中间文本时会丢失的信息(位置、字体、布局上下文)。这就像人看收据时，并不会先逐字读完再单独去理解含义一样。
核心原理：传统 OCR 流水线及其局限
传统的文档理解流水线通常由以下几个阶段组成。
[文档图像]
|
v
[1. 文本检测] --> 找出字符/单词区域的框
|
v
[2. 文本识别] --> 把每个框里的字符转成字符串
|
v
[3. 布局分析] --> 把握标题/正文/表格/单元格结构
|
v
[4. 信息提取] --> 键值、表格、含义解释
每个阶段通常都是一个独立的模型，各自训练、各自调优。这种结构存在明显的局限。
- 误差累积：如果第 1 阶段的检测漏掉了字符的一部分，第 2 阶段的识别无论多强都无法把它找回来。误差会在每个阶段不断堆积。
- 阶段之间的信息断层：识别阶段只看字符的形状，无法利用语义上下文。想凭上下文去校正模糊的字符很困难。
- 布局的脆弱性：在表格的合并单元格、复杂的表单、混有手写的文档中，布局分析经常出错。
- 流水线维护成本：每个阶段都要管理各自的模型和规则，运维因此变得复杂。
这些局限正是 OCR-free 方法的动机。阶段越少，误差累积就越少；一个模型同时看到字符和含义，就能实现基于上下文的校正。
深入探讨 1：OCR-free 端到端文档理解
Donut 系列：无需 OCR，直接从图像输出结构化结果
Donut(Document Understanding Transformer)提出了一种彻底去掉 OCR 阶段的方法，直接从文档图像生成结构化输出(例如 JSON)。视觉编码器负责读取图像，文本解码器以自回归的方式生成我们想要的结果。
[文档图像]
|
v
[视觉编码器] --> 图像特征序列
|
v
[文本解码器] --> 结构化输出 (例如 JSON 键值)
这种方式的优势很明确。不需要单独的 OCR 框检测或识别模型，模型会把字符形状和含义一并学会。只要按想要提取的信息格式准备好答案数据用于训练，模型就能直接以那种格式给出答案。误差累积不复存在，流水线也变得简单。
不过它也有代价。由于没有显式的 OCR，它高度依赖答案格式和充足的数据。而且当解码器需要生成较长的输出时，速度可能成为问题。
基于 VLM 的文档理解
前文提到的视觉-语言模型(VLM)本质上就具备 OCR-free 的文档理解能力。它把图像转成视觉 token，让 LLM 与文本一起阅读，因此可以接收文档图像来回答问题，或提取表格。
[文档图像] --> [VLM] --> 用自然语言回答「总额是多少?」这类问题
--> 把表格结构化为 markdown/JSON
--> 甚至指出某个字段的位置(坐标)
VLM 的优势在于通用性。同一个模型能同时处理图像描述、VQA、OCR、grounding，并且可以用自然语言指令灵活获得想要的输出。得益于强大的语言能力，它往往能凭上下文推断出模糊或部分被遮挡的字符。
深入探讨 2：高分辨率、布局、表格、公式
文档不同于自然图像。它密布着细小的文字，还有大量表格、公式之类的结构。要妥善处理这些，需要一些专门的手段。
高分辨率处理
要读出文档里的小字，需要足够的分辨率。如果强行把图像缩小，字符就会糊成一团。因此 OCR-free 模型会采用处理高分辨率输入的策略。
- 切片/分块(tiling)：把大页面切成若干个小块，分别处理后再合并。
- 任意分辨率：类似前文提到的动态分辨率，保留原始比例和尺寸以保住细节。
高分辨率文档处理策略
方法 A：切片 大页面 -> 多个切片 -> 逐个处理 -> 合并
方法 B：动态分辨率 保持原始比例 -> token 数量随尺寸变化
分辨率越高，细节越好，但 token 数量和成本也会随之上升。这种权衡是文档模型设计的核心。
布局、表格、公式
- 布局：要在正确的上下文中提取信息，就必须理解标题、段落、页眉、表格等区域结构。OCR-free 模型不再靠单独的阶段完成这件事，而是通过训练把它内化。
- 表格：读取时必须保留行、列以及合并单元格的结构。训练时让输出生成 markdown 表格或结构化格式。
- 公式：公式具有二维结构(分数、指数、下标)，很难用普通文本表达。常见做法是训练模型将其转换为标准记法后再输出。
对这些结构性元素来说，答案数据的格式直接决定了模型的输出格式，因此准备一致的结构化答案数据非常重要。
深入探讨 3：多语言 OCR 与统一模型
多语言 OCR
文档由多种语言写成。传统 OCR 往往为每种语言单独维护识别模型或词典，而 OCR-free VLM 可以通过在多语言的图像-文本数据上一起训练，用一个模型处理多种语言。目前的努力不仅覆盖拉丁字母，也在扩展到中日韩这类表意文字，以及从右到左的文字。不过在训练数据较少的语言或罕见字体上，准确率仍可能下降，因此针对目标语言分布做数据增强很重要。
统一模型：把检测-识别-解析合而为一
近来的趋势是统一模型，把检测、识别、布局分析、信息提取整合进一个模型。传统流水线为每个阶段各配一个模型，统一模型则由单一的编码器-解码器一次性处理全部。
传统流水线： 检测模型 -> 识别模型 -> 布局模型 -> 提取模型
统一模型： 单一模型 -> (检测 + 识别 + 布局 + 解析) 同时完成
- 优点：误差累积减少、运维简化、可利用上下文进行校正。阶段之间的信息断层消失了。
- 灵活性：给同一个模型不同的指令，就能完成通读全文、提取特定字段、表格结构化等多种任务。
- 需要考量的地方：由于整个过程都靠训练内化，模型高度依赖数据质量与多样性，要保证输出准确性还需要额外的验证阶段。
深入探讨 3.5：阅读顺序与布局的难点
理解文档时常被忽视的一个难点是阅读顺序。人看多栏排版的报纸时，会很自然地知道先从上到下读完左栏，再转到右栏。但对模型来说，这并不是理所当然的事。
多栏布局示例
+------------------+------------------+
| 第1栏第一段 | 第2栏第一段 |
| 第1栏第二段 | 第2栏第二段 |
+------------------+------------------+
正确的阅读顺序：第1栏全部 -> 第2栏全部
错误的顺序： 按行左右交替读 (含义被打乱)
传统流水线在布局分析阶段会显式计算这个顺序。OCR-free 模型则必须通过训练来学会这一点，如果没有在足够多样的布局数据上充分训练，阅读顺序就可能被打乱。一旦混入表格、脚注、侧边栏、题注，难度还会进一步上升。
这个问题可以通过输出格式设计来部分缓解。比如训练模型按区域结构化输出，能让模型更意识到区域边界，从而更好地把握顺序。关键在于用验证数据确认模型是否能给出一致的阅读顺序。
深入探讨 3.6：表格结构化的具体方法
表格是文档理解中最棘手的元素之一，因为必须同时保留行列关系、合并单元格、表头层级。OCR-free 模型应该以什么格式来输出表格呢?
表格输出格式的选择
markdown 表格 简单，适合简单表格，表达合并单元格有限
HTML 表格 能表达合并单元格 (rowspan/colspan)，冗长
结构化 JSON 逐单元格指定坐标/内容，便于解析，最灵活
每种格式都有各自的权衡。markdown 便于人阅读，但难以表达复杂的合并单元格。HTML 表格能表达合并，但输出会变长。结构化 JSON 最灵活，但需要把答案数据统一准备成这种格式。
关键在于选择适合任务的格式，并把答案数据统一成该格式。因为模型会模仿答案格式，如果表格输出格式参差不齐，模型输出的表格也会不一致。另外，评估表格准确率时，不能只做简单的字符串匹配，而要按单元格、按结构逐一比较，才能抓住真实的质量。
深入探讨 4：基准测试与评估方法
该如何评估 OCR-free 模型?不同任务的衡量指标各不相同。
- 文本识别准确率：识别出的字符串与正确答案的一致程度，常用基于编辑距离的指标。
- 键值提取准确率：在收据、表单中是否按字段准确对上，看每个字段的精确率与召回率。
- 表格结构准确率：不仅评估单元格级别的匹配，还要评估行、列、合并结构是否正确。
- 文档 VQA 准确率：针对文档提出的问题,回答是否正确,看与标准答案的语义一致性。
评估视角小结
读到了什么 文本识别准确率 (编辑距离)
提取了什么 键值精确率/召回率
是否保留结构 表格单元格/结构一致性
是否理解含义 文档 VQA 准确率
重要的是,单一分数无法代表模型的全部能力。有的模型擅长读普通文本却在表格结构上偏弱,有的模型英语很强却在多语言上掉链子。因此,构建一套贴合自己实际文档分布的评估集,才是最稳妥的做法。公开基准分数只是一个起点,并不能如实反映真实业务数据的噪声与多样性。
深入探讨 5：推理流水线设计
要把 OCR-free 模型真正投入服务,推理流水线不会只是一次模型调用就结束。更好的做法是把它看成预处理、模型推理、后处理/验证三个阶段。
[原始文档]
|
v
[预处理] 分辨率归一化、旋转校正、去噪
|
v
[模型推理] OCR-free 模型 -> 生成结构化输出
|
v
[后处理] 格式验证 (JSON schema)、置信度判定、回退
|
v
[结果] 通过验证 -> 自动处理 / 失败 -> 人工复核
每个阶段的职责都很明确。
- 预处理：扫描文档常常存在倾斜或阴影。旋转校正与归一化能让模型看到更清晰的输入。
- 模型推理：用与任务匹配的指令(通读全文、提取字段、表格结构化)来调用模型。
- 后处理：验证输出是否符合预期的 schema,并对数字、日期这类字段再用格式规则确认一遍。如果置信度低,就转交人工复核。
这套结构的关键在于,把模型看作流水线中的一个环节,而不是信任的终点。只有建立在「模型可能出错」这个前提上去设计验证与回退,才能在实际业务中稳定运行。
深入探讨 6：手写、低画质、旋转等难题
真实文档不会只是干净的印刷品。以下整理了棘手输入会带来哪些问题。
- 手写：每个人的笔迹都不一样,识别很难。用手写数据做增强,或把置信度低的字段转交人工复核,是比较现实的做法。
- 低画质/压缩噪声：如果画面模糊或压缩伪影严重,小字就会崩掉。尽可能取得原始高画质,并用预处理降低噪声。
- 旋转/倾斜：扫描角度偏了会拖累识别效果。旋转校正的预处理会有帮助。
- 混合布局：多栏排版、侧边栏、脚注混杂的复杂页面容易让阅读顺序变乱。训练并验证模型能否给出一致的阅读顺序很重要。
这些难题很难仅靠模型独自完美解决。只有让提升输入质量的预处理,和过滤不确定输出的后处理协同配合,才能在实务中撑出经得起考验的准确率。
对比表：传统 OCR 与 OCR-free
| 项目 | 传统 OCR 流水线 | OCR-free / 统一模型 |
|---|---|---|
| 结构 | 检测-识别-布局-提取多阶段 | 单一模型端到端 |
| 误差累积 | 逐阶段堆积 | 大幅减少 |
| 上下文校正 | 困难(识别只看形状) | 可行(利用语言能力) |
| 表格/公式 | 需要单独的规则/模型 | 靠训练生成结构化输出 |
| 多语言 | 倾向于按语言各配模型/词典 | 一个模型覆盖多语言 |
| 运维复杂度 | 高(要管理多个模型) | 低(单一模型) |
| 数据依赖 | 各阶段的中间标注 | 依赖最终答案格式 |
| 输出准确性保证 | 各阶段验证较容易 | 建议额外增加验证阶段 |
深入探讨 9.5：用提示词设计来把控输出
基于 VLM 的 OCR-free 模型,即便是同一张图像,给出的指令(提示词)不同,输出也会不同。这既是强大的灵活性,同时也是变动性的来源。
同一张收据,不同的指令
「读一下这张收据」 -> 自由的自然语言总结
「只用数字回答总额」 -> 32500
「把品项提取成 JSON 数组」 -> 结构化列表
「把店名、日期、总额整理成键值」 -> 明确的字段映射
在实务中要获得稳定的结果,把提示词设计得具体且一致很重要。
- 明确输出格式：在指令中清楚写明想要的格式(JSON schema、字段列表)。
- 提供示例：展示一两个期望输出的例子,能提升格式遵循度。
- 给出不确定性处理指示：明确要求「找不到值就不要猜,给空值」,以减少幻觉。
- 固定一致性：同一任务始终用同一份提示词,以减少输出的波动。
提示词是无需重新训练模型、就能调整输出的最便宜的旋钮。但提示词无法解决的准确性问题,终究还是要靠数据、微调、后处理来解决。提示词是起点,不是万能解法。
实务应用：收据、表单、文档
按任务整理把 OCR-free 方法应用到实际业务时需要考虑的要点。
- 收据/发票：提取店名、日期、品项、总额这类键值。把输出定义为固定的 JSON schema,能让后处理更简单。金额这类数字一旦格式出错就是致命的,请务必加上验证逻辑。
- 表单/申请书：混有复选框、签名、手写内容。手写识别依然棘手,把低置信度字段转交人工确认的人机协作(human-in-the-loop)设计更安全。
- 表格较多的文档：财务报表、规格表等,核心在于保留表格结构。要用验证数据检查合并单元格与表头是否被准确抓取。
- 各式各样的表单：即便是同一类文档,不同厂商的版式也不同。OCR-free 模型对版式变化相对稳健,但用领域数据微调能大幅提升准确率。
共通之处在于,与其原样信任模型输出,不如同时配上格式验证、置信度阈值、人工复核这类安全网,这在实务中很重要。模型可能会自信满满地给出错误的值,字段越重要,就越应该加强验证。
深入探讨 7：OCR-free 与传统 OCR 的混合方案
由于 OCR-free 并非万能,实务中经常出现把传统 OCR 与 OCR-free 混合使用的混合式设计,借此发挥各自的优势。
混合式设计 (示例)
1. 用传统 OCR 快速提取文本与位置
|
v
2. OCR-free/VLM 结合该文本与图像一起解释含义
|
v
3. 交叉验证两条路径的结果,评估置信度
- 把 OCR 结果注入作为提示：把传统 OCR 提取出的文本一并输入 VLM,帮助模型更好地读出字符。
- 交叉验证：两条路径给出相同值时置信度高,不同则转交人工复核。这在准确性要求高的金融、法律文档中很有用。
- 速度与准确性的折中：先用快速的 OCR 做一次处理,只把困难的案例送去较重的 VLM,以此在成本与准确性之间取得平衡。
混合方案的教训很明确。与其让新技术彻底取代旧技术,不如把两者结合起来互补短板,在实务中往往更稳健。
深入探讨 8：稳定获取结构化输出
从 OCR-free 模型获取结构化输出(JSON、表格)时,模型并不总能给出完美的格式,需要一些机制来保证解析的稳定性。
结构化输出稳定化流程
[模型输出字符串]
|
v
[尝试格式解析] JSON 解析等
|
+-- 成功 --> [schema 验证] 检查字段是否存在/类型是否正确
| |
| +-- 通过 --> 采纳结果
| +-- 失败 --> 回退/重试
|
+-- 失败 --> [尝试恢复] 部分提取或重新生成
- 固定 schema：预先定义期望的字段与类型,验证输出是否与之相符。
- 重试策略：格式出错时,换一种提示词或设置再试一次。
- 部分采纳：如果只有部分字段可信,就只采纳那些字段,其余交给人工。
有了这些后处理机制,才能把模型输出安全地接入真实系统。设计时应默认模型偶尔跑出格式之外是正常现象。
深入探讨 9：成本与延迟视角
OCR-free 模型,尤其是基于 VLM 的模型,比传统 OCR 更重。需要一套管理成本与延迟的视角。
成本/延迟对比 (直观)
传统 OCR 轻量、快、便宜
小型 OCR-free 中等
大型 VLM 重、慢、贵,但灵活/准确
- 分级路由：简单文档走轻量路径,只把困难文档送去较重的 VLM,以此降低平均成本。
- 调整分辨率：如果没有细小文字,就降低分辨率,以减少 token 与成本。
- 批处理：大量文档不做实时处理,而是走批处理,以提升吞吐量。
- 缓存：同一版式的文档反复出现时,把提示词或中间结果缓存起来复用。
一味追求准确性,成本就会失控;一味追求成本,质量就会下降。在任务的准确性要求与预算之间取得平衡,是实务设计的核心。
深入探讨 12：多语言文档的额外挑战
多语言文档所面对的挑战,不只是识别多种语言这么简单。
- 语言混杂：一份文档里混着多种语言的情况很常见(例如英文正文加本地语言批注)。模型必须妥善处理语言边界。
- 文字方向：一旦混入从右到左的文字或竖排书写,阅读顺序会变得更复杂。
- 数字/日期格式：不同地区的日期、货币记法不同,提取之后需要归一化。
- 字体多样性：不同语言的字体变化很大,训练数据较少的语言准确率会更低。
多语言处理的各阶段
识别 把各种文字体系转成文本
|
v
结构理解 与语言无关地把握布局/表格
|
v
归一化 统一各地区的数字/日期/货币格式
关键在于,不能只考虑识别准确率,还要考虑识别之后的归一化,这样才能得到在实务中真正可用的结果。明确目标语言与地区,并准备与该分布相匹配的数据和后处理规则,是处理多语言文档的起点。
陷阱与局限
- 幻觉：模型可能煞有介事地生成文档中并不存在的值,在模糊或空白的字段上尤其危险。需要验证来过滤掉没有依据的输出。
- 罕见字体/语言：在训练数据较少的字体、语言、领域上准确率会下降。针对目标分布做数据增强很重要。
- 高分辨率成本：为了读出小字而提高分辨率,会让 token 与成本急剧上升。需要一个只按需提升的平衡点。
- 输出格式偏离：结构化输出有可能给出偏离 schema 的结果。请在解析阶段准备好格式验证与回退。
- 基准测试与真实场景的落差：即便基准分数很高,在真实业务文档的多样性与噪声面前,表现也可能不同。用自己的数据评估更安全。
深入探讨 10：按领域应用时的考量
把 OCR-free 模型应用到具体行业时,每个领域都有各自不同的约束与要求。
- 金融：数字准确性是绝对要求。哪怕只错一位数,都会酿成大问题,因此要配置强力的交叉验证与人工复核,合规所需的审计追踪也不可少。
- 医疗：处方笺、检验单上的术语专业,出错代价高。领域数据微调与保守的置信度阈值很重要。
- 法律：长文档、复杂布局、精确引用是核心。阅读顺序与结构保留尤其棘手。
- 物流/制造：发票、标签、条形码混杂,版式因厂商而异。对版式变化稳健的模型与后处理规则很有用。
按领域的优先级
金融 准确性 > 速度,强力验证
医疗 准确性 > 成本,领域微调
法律 结构/顺序保留,长文档处理
物流 应对版式多样性,吞吐量
共通的教训是,应按领域的出错代价来调整验证强度。一个领域里错误越致命,就越不能原样信任模型输出,越要把安全网叠得更厚。
深入探讨 11：未来的方向
文档理解模型正在快速发展。以下梳理几个值得关注的趋势。
- 更长的文档：一次处理多页的能力正变得越来越重要,如何在跨页之间维持上下文是一大课题。
- 效率化：通过 token 剪枝、自适应分辨率等手段降低高分辨率处理成本的研究很活跃。
- 与 Agent 结合：出现了把文档阅读与后续行动(检索、计算、调用 API)结合起来的 Agent 化趋势。
- 验证能力内化：正在研究让模型在给出输出的同时,也一并给出自身的置信度,自行标出不确定的部分。
这些方向都指向同一个目标：在减少人工介入的同时维持准确性。不过就目前而言,比起完全自动化,把模型与验证、人工复核结合起来的设计,在实务中依然最为稳健。
结语
文档 AI 已经把重心从「逐字阅读」的阶段链条,转移到了接收图像后直接给出含义的单一模型上。OCR-free 方法减少了误差累积,借助语言能力实现上下文校正,并把检测-识别-解析统一为一体,简化了运维。
当然它并非万能。幻觉、罕见领域、高分辨率成本等局限依然存在,要保证输出准确性还需要验证机制。尽管如此,让一个模型同时看懂字符与含义,这个方向本身就是文档理解领域一股强劲的潮流,并且随着 VLM 的发展,它的应用范围还会不断扩大。关键在于,既要理解这个工具的优势与局限,也要按任务对准确性的要求,配上恰当的安全网一起使用。
参考资料
- Qwen2-VL: Enhancing Vision-Language Model's Perception (arXiv: 2409.12191) — arxiv.org/abs/2409.12191
- Attention Is All You Need (arXiv: 1706.03762) — arxiv.org/abs/1706.03762
- FlashAttention: Fast and Memory-Efficient Exact Attention (arXiv: 2205.14135) — arxiv.org/abs/2205.14135
- Qwen 官方仓库 — github.com/QwenLM
- Hugging Face Transformers 文档 — huggingface.co/docs
- PyTorch 官方文档 — pytorch.org
- vLLM 文档(含多模态服务) — docs.vllm.ai
- vLLM 仓库 — github.com/vllm-project/vllm