跳到主要内容

为什么视觉模型在基准测试中表现卓越,却在你的企业级 PDF 上折戟沉沙

· 阅读需 12 分钟
Tian Pan
Software Engineer

一个在文档理解数据集上达到 97% 准确率的基准测试结果看起来非常有说服力,直到你针对公司的实际发票存档运行它,才发现它正在静默地搞乱 30% 的行项目。模型不会报错,也不会返回低置信度,它只是产生了一个看起来合情合理但却是错误的输出。

这是生产级文档 AI 的典型失效模式:静默损坏 (silent corruption)。与崩溃或异常不同,静默损坏会发生传播。乱码的单元格流入下游聚合,聚合信息喂给报告,报告驱动决策。当你意识到问题时,追踪根本原因就像是在搞考古。

文档 AI 在基准测试表现与生产环境表现之间的差距是真实存在的、持久的,且被评估这些模型的团队所低估。理解为什么会存在这种差距——以及如何防御它——正是本文要解决的工程问题。

基准测试与现实的差距并非舍入误差

看看这些数字。在受控条件下,干净印刷文本的 OCR 准确率可达 96.5–99%。但在带有公式和复杂图表的学术论文上,顶尖的多模态模型准确率会下降到 60% 左右。对于带有手写批注的合同或医疗表格等手写文档,准确率会降至 80% 左右。在劣质扫描件上——如低分辨率手机照片、褪色的墨迹、复印过五次的文档——表现差异巨大,如果不针对你特定的文档分布进行测试,几乎无法预测。

结构化数据使情况变得更糟。文本提取准确率和结构恢复准确率并不是同一个指标。在针对 800 多份文档和 7 个前沿模型的一项基准测试中,一个备受推崇的模型实现了 75% 的文本准确率,但结构恢复准确率仅为 13%。该模型能读出文字,但无法重建表格。

核心问题在于基准测试数据集是经过策划的。它们代表了最佳情况:干净的扫描件、标准的布局、单一语言、无标注、无水印。而企业文档库代表了最坏的情况:文档在多年实际使用中积累的一切问题。基准测试分布与生产分布的重合度并没有准确率数字所暗示的那么高。

OmniDocBench 是一个 2025 年的基准测试,涵盖了来自 10 种文档类型和 5 种语言的 1,651 个 PDF 页面,研究发现即使是最先进的 pipeline 方法在处理学术论文和包含混合布局的文档时也表现吃力。没有任何单一模型能在所有类别中占据主导地位。更重要的是,该基准测试包含了与典型训练数据完全不同的文档类型——手写笔记、报纸、带有嵌入图表的财务申报。同一模型在不同文档类型上的性能差异超过 55 个百分点。

企业文档中究竟哪里出了问题

有几类失效模式值得作为独立的工程问题来对待:

旋转和倾斜的扫描件。 人工扫描的文档并不总是与坐标轴对齐。对于依赖边界框 (bounding-box) 坐标的模型来说,两度的旋转就会干扰其空间推理。一些模型在应该纵向阅读列时,会静默地横向跨行阅读。输出在语法上看起来是有效的,但在语义上是错误的。

多栏和复杂布局。 主要在网页和书籍文本上训练的模型具有强烈的从左到右、从上到下的阅读顺序先验。双栏学术论文、三折页保险单以及并排对比表违反了这些先验。模型通常会合并相邻列的文本或完全跳过某些列,从而产生一段读起来连贯但却是重构出来的叙述。

嵌入式表格。 表格提取是一个难题,值得单独归类。常见的失败模式包括:检测框切掉了最后一列或最后一行;标题行被吸收到正文中并失去了语义功能;无边框表格通过空白推断行边界,而在比例字体或紧密行间距的情况下会失效;以及小字体表格,在典型的扫描分辨率下,小数点和千位分隔符变得无法区分。

水印和背景元素。 叠加在文本上的水印产生了一种层叠的视觉信号,模型很难将其分解。对角线盖在段落上的“机密 (CONFIDENTIAL)”印章会导致字符级的误读,看起来像是随机的替换错误。表格中的彩色或图案背景在低分辨率扫描中也会导致类似的性能下降。

手写批注。 带有手写填充内容的打印表格要求模型同时处理两种截然不同的视觉范式。大多数模型偏向于主导范式(打印表格),而将手写内容视为噪声或部分识别。这对于签名、日期和复选框状态尤为有害——而这些恰恰是下游系统最关心的字段。

混合语言文档。 法律文件、国际合同和多语言地区的医疗记录通常在段落中途或表格内包含语言切换。在孤立状态下能妥善处理每种语言的模型,有时会在切换边界处失败,产生翻译或幻觉而非识别出转换。

这些失效模式共有的最危险属性是,模型给出的输出看起来置信度正常。没有任何信号表明出了问题。

预处理管道是你的第一道防线

将文档视为无差别的像素块或扁平的文本流是大多数静默损坏的根源。一个更具防御性的架构始于在将文档路由到视觉模型之前对其进行分解。

在提取前进行分类。 在选择提取策略之前,先确定文档类型(发票、合同、扫描件、表单)。不同的文档类型需要不同的模型、不同的置信度阈值和不同的回退路径。将每个文档都通过单一的通用管道意味着接受该管道最坏情况下的准确率。

按内容类型进行细分。 PDF 包含多种截然不同的内容类型:文本块、表格、图像、矢量图、表单字段、页眉和页脚。这些需要不同的处理方式。纯文本块可以通过轻量级提取器。表格应被隔离并发送到专门的表格提取管道。图像应结合适当的上下文进行单独处理。在视觉模型看到它们之前尝试将这些内容扁平化为单一的文本表示,会丢弃模型正确重构所需的结构信息。

检测文档质量信号。 在进行任何 AI 处理之前,运行轻量级分类器来检测:旋转角度、扫描分辨率、文本密度、手写内容的存在、水印的存在以及语言分布。这些信号让你能够做出路由决策——是在发送到模型之前对文档进行预处理,使用哪个模型,以及应用什么置信度阈值。一项对 AWS Textract 的评估发现,尽管平均准确率为 99.3%,但在某些异常图像上的准确率为 0%——早期的异常检测可以防止这些情况静默地污染你的管道。

结合 OCR 和视觉信号。 一种在生产环境中表现良好的模式是:同时将 OCR 转录文本和原始文档图像发送给视觉模型。转录文本为解析提供了可靠的文本内容;图像则提供了布局上下文、字段位置以及转录文本无法捕捉的视觉元素。两者缺一不可。结合使用时,它们让模型能够根据结构交叉引用文本,从而捕捉到两种表示形式不一致的情况。

置信度评分与回退架构

静默故障之所以持续存在,是因为大多数文档 AI 管道将提取视为二元的:模型要么运行成功,要么报错。将置信度评分构建到每个提取阶段,是让故障变得可见的结构性变革。

每个阶段的置信度评分都会创建一个决策边界。高于阈值的提取会自动进行。低于阈值的提取则路由到人工审核、二级提取模型或返回结构化空值而非不确定值的保守回退方案。阈值本身可以根据文档类型和字段重要性进行调整——供应商名称字段可能比行项目金额字段更能容忍较低的置信度。

对于回退架构,其关键属性包括:完整性(有输出总比崩溃好)、可追溯性(系统记录采取了哪条路径及其原因)以及不向下传播(不确定的值被标记为不确定,而不是静默地作为确定值传递给下游)。

一个实用的文档提取分层回退方案:

  • 主路径: 具有空间理解能力的视觉模型,按字段进行置信度评分
  • 次要路径(在置信度低于阈值时触发): 针对失败的特定内容类型使用备选模型或基于规则的提取器
  • 第三路径: 返回带有置信度元数据的空值;标记人工审核
  • 绝对禁止: 将不确定的值作为确定值返回给下游消费者

回退决策应记录足够的上下文以便诊断模式——如果次要路径在某个特定文档供应商上触发了 40% 的时间,这就是一个信号,表明你应该改进该供应商格式的预处理,而不是无限期地接受回退成本。

“生产就绪” 究竟需要什么

当一个文档 AI 管道能够以可观测、可控制的行为处理上述故障模式时,它才算达到了生产就绪标准。这意味着几个不可协商的属性:

端到端管道评估,而非仅模型评估。 孤立地对视觉模型进行基准测试很难告诉你完整管道的表现。提取准确率、结构恢复和下游推理准确率是三个不同的指标,它们以乘法方式组合。一个具有 95% 提取准确率、80% 结构恢复和 90% 推理准确率的管道,其端到端准确率约为 68%——这低于大多数生产应用所能忍受的水平。

文档分布测试。 在针对生产文档进行部署之前,先描述你的实际文档分布:扫描件与原生 PDF 的比例是多少,旋转分布如何,表格密度如何,出现了哪些语言。针对实际分布的分层样本测试管道,而不是基准测试数据。基准测试数字只是广告,你的文档分布才是真正的测试。

生产中的字段级准确率追踪。 管道的总准确率会掩盖关键的偏差。95% 的总准确率可能意味着简单字段的准确率为 99%,而驱动财务决策的复杂表格的准确率仅为 70%。按字段类型、文档类型和供应商追踪准确率。异常情况会在造成下游损害之前作为回归问题浮现。

实际测试过的优雅降级路径。 仅存在于文档中而未在负载测试中运行过的回退路径在真正需要时是不可靠的。刻意测试降级路径:屏蔽主模型,验证次要路径是否激活、是否产生了合理的输出并记录了回退事件。

核心总结

文档 AI 中的视觉模型失效模式并非罕见的边缘情况。旋转的扫描件、复杂的表格、手写批注以及混合布局,都是企业级文档集合中的常态。那些在学术基准测试中表现优异的模型,大多并未针对这些特性进行评估,或者是在经过人工精选、无法反映真实文档熵(entropy)的版本上进行的测试。

工程层面的应对方案并非寻找一个更值得信赖的基准测试分数,而是构建一套流水线:在提取之前先进行分类,按内容类型分解文档,在每个阶段生成置信度信号,并实现优雅降级,而非静默失败。该流水线会定义每个字段的“足够准确”意味着什么,将不确定的案例路由至人工审核,并记录每一项决策的来源(provenance)。

这种架构并不能消除视觉模型的失效。但它使这些失效变得可见、可控且可恢复 —— 这正是生产系统真正需要的。

References:Let's stay in touch and Follow me for more thoughts and updates