Skip to content
←

필사 모드: 超越 OCR — OCR-free 文档理解与统一模型

中文
0%
정확도 0%
💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

引言 — 为什么要超越 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 的发展,它的应用范围还会不断扩大。关键在于,既要理解这个工具的优势与局限,也要按任务对准确性的要求,配上恰当的安全网一起使用。

参考资料

현재 단락 (1/228)

抠出收据的总额、抽取合同里的条款、把图表转成表格 — 这类文档理解任务长期以来都建立在 OCR(光学字符识别)之上。但 OCR 只擅长把字符读出来，至于这些字符是什么意思、属于哪一个格子，它并不会告诉...

작성 글자: 0자원문 글자: 9,414자작성 단락: 0/228