为什么你的文档提取器在最重要的合同上会失效
你的发票解析器可能运行得不错。给它一个来自世界 500 强供应商的清晰、数字化的 PDF —— 结构化的行、一致的列宽、机器生成的文本 —— 它就能以近乎完美的准确度提取行项目。但当有人上传一份来自区域供应商的多页合同、一份带有手写修改的扫描表格,或者一份表格标题在第 3 页而数据行延续到第 6 页的财务报表时,提取器就会悄无声息地失败,返回部分数据,或者自信地生成结构化输出,而这些输出的错误方式是任何下游校验都无法捕捉到的。
这是企业级文档智能的核心问题:使你的系统崩溃的文档并不是边缘案例。它们往往是具有最高业务价值的文档。
IDP(智能文档处理)市场在 2025 年达到了 105.7 亿美元,并以每年 26% 的速度增长 —— 这主要由自动化合同、发票、监管文件和保险索赔的真实需求所推动。然而,仍有 88% 的企业报告其数据管道中存在错误,团队每周要花费 6 小时或更长时间来修复所谓的自动化数据。“演示中有效”与“在真实的长尾文档中有效”之间的差距,正是大多数生产部署陷入困境的地方。
为什么固定布局提取器在真实的企业文档中会失效
基于模板的提取非常有诱惑力,因为它能立即见效。你使用固定坐标或正则表达式定义字段位置,针对代表性样本运行它们,就能达到 95% 以上的准确率。问题在于,“代表性样本”几乎从未能代表六个月后的生产流量情况。
多页表格是经典的陷阱。简单的提取器将每一页视为独立的单元。当表格标题出现在第一页,而数据行延续到第二页和第三页时,提取器要么完全丢弃这些行,要么将第二页视为没有标题的独立表格 —— 从而产生无法归属的列。这并不是罕见的边缘案例。财务附录、供应链清单和法律附件经常跨越多个页面,而 2024 年底发布的 PubTables-v2 基准测试是第一个专门解决多页表格结构识别的大型数据集,正是因为这一差距非常明显。
交叉引用解析暴露了更深层次的局限:OCR 识别出了字符,但完全丢失了语义。一个规定“定价调整请参阅附录 B”的合同条款,需要理解附录 B 存在于文档的其他地方,找到它,并将引用连接起来。固定布局提取器无法做到这一点。它们只返回条款文本,悄无声息地丢弃了其中的关联。
含有混合内容的扫描 PDF 会以复合方式导致质量退化。与数字 PDF 相比,扫描文档已经丢失了保真度 —— 倾斜、噪声和压缩伪影都会降低 OCR 的准确性。再加上手写修正(在合同和受监管行业表格中很常见),这种退化会加速。手写识别所需的模型与印刷体识别有着本质的不同,而大多数管道将文档视为同质的。
视觉上下文布局会使纯文本提取彻底失效。考虑一个合规性表格,其中复选框的含义取决于它相对于表格单元格的位置;或者一个财务图表,图像下方的说明传达了关键数字。如果不结合布局信息,从这些文档中提取的文本通常毫无意义或具有误导性。
核心问题在于基于模板和正则表达式的提取器将文档建模为文本序列。真实的企业文档是二维空间产物,其位置、邻近性、字体和视觉结构都承载着意义。
真正有效的预处理管道
生产环境下的文档智能不是单一的模型 —— 而是一个协调的管道,根据评估的质量和结构,将不同类型的文档路由到不同的处理路径。
从文档分类开始。 在进行任何提取之前,先对输入的文档进行分类:它是带有嵌入式可搜索文本的数字 PDF,还是需要 OCR 的基于图像的 PDF?数字 PDF 的原生文本提取比 OCR 快约 1,000 倍,并消除了一大错误来源。仅在文本不可选时才调用 OCR。在基于图像的文档中,进一步分类:扫描质量是高(300+ DPI,极小倾斜)还是已退化?在 OCR 之前,将退化的扫描件送入预处理环节 —— 纠偏、去噪、二值化。现代最先进 OCR 准确性的基准在各语言中为 98.5%,但该数字假设输入质量尚可。
在提取前使用布局检测。 标准的生产堆栈在尝试字段提取之前会运行布局检测模 型。诸如 PaddleOCR + PP-Structure 或 docTR + LayoutParser 之类的工具可以识别文档元素 —— 标题、正文、表格、插图、页码 —— 以及它们的空间关系。这一步将平面的图像或 PDF 页面转换为下游模型可以推理的结构化表示。从业者的一个关键发现是:使用成熟的 OCR 引擎(如 docTR、PaddleOCR)作为文本提取层,只有在获得高质量 OCR 文本后,再添加 LayoutLM 或 Donut 等复杂模型。在糟糕的 OCR 输出上叠加复杂性会放大错误,而不是纠正错误。
根据文档类型和置信度进行路由。 一旦拥有了布局结构,就将每个文档路由到特定类型的提取逻辑。合同需要法律条款识别和交叉引用解析;发票需要带有算术一致性检查的行项目解析;表格需要复选框检测和字段模式对齐。每种类型都有不同的失效模式和不同的下游校验规则。一个试图处理所有类型的单一提取管道对所有类型来说都不是最优的。
应用 OCR 质量评分作为闸门。 在将 OCR 输出发送到任何下游模型之前,对其进行评分。字符错误率(CER)和词错误率(WER)是标准指标,但在生产环境中,你还需要启发式方法:提取的文本是否存在不合理的字符分布?是否有一连串的乱码字符表明 OCR 区域识别失败?标记低置信度区域,而不是直接放行。这是许多管道失败的地方 —— 它们将 OCR 输出视为绝对真理,只有当下游字段提取返回荒谬的值时才发现错误。
显式处理多页表格。 对于带有表格的文档,运行专门的表格结构模型(不只是 OCR),该模型可以识别当前页面的表格是否是上一页表格的延续。这需要跨页跟踪表格边界 —— 这需要显式的架构支持,而不是事后修补。在带有多页表格注释的大规模企业文档数据集上训练的模型可以处理这一点 ,而通用的 OCR 则不行。
衡量核心指标的评估方法论
在文档智能领域,最常见的评估错误是在经过筛选的纯数字 PDF 数据集上衡量准确率。这会导致在演示中数据亮眼,但在生产环境中一败涂地。
根据文档状况对测试集进行分层。 一个具有生产代表性的评估集应涵盖:数字 PDF(高准确率基准)、高质量扫描件、低质量扫描件、带有手写部分的文档、多语言文档、多页表格、带有合并单元格的文档、无框表格,以及来自低业务量供应商(其布局最为特殊)的文档。你应该权衡测试集的比例,使其符合生产流量的实际分布,而不是使用清洗过的样本。
- https://www.runpulse.com/blog/evaluating-document-extraction
- https://landing.ai/developers/going-beyond-ocrllm-introducing-agentic-document-extraction
- https://arxiv.org/html/2512.10888
- https://nanonets.com/blog/the-ultimate-guide-to-assessing-table-extraction
- https://www.llamaindex.ai/blog/ocr-for-tables
- https://www.vellum.ai/blog/document-data-extraction-llms-vs-ocrs
- https://parseur.com/blog/why-ai-ocr-fail
- https://conexiom.com/blog/the-6-biggest-ocr-problems-and-how-to-overcome-them
- https://unstract.com/blog/comparing-approaches-for-using-llms-for-structured-data-extraction-from-pdfs/
- https://www.docsumo.com/blogs/intelligent-document-processing/intelligent-document-processing-market-report-2025
- https://sparkco.ai/blog/2025-ocr-accuracy-benchmark-results-a-deep-dive-analysis
- https://subhajitbhar.com/blog/idp/glossary/confidence-scoring-document-extraction/
- https://parseur.com/blog/hitl-best-practices
- https://arxiv.org/html/2410.21169v2
- https://developer.nvidia.com/blog/approaches-to-pdf-data-extraction-for-information-retrieval/
