文档花费了数十年的时间来顽固地保护其内容免受软件侵害。在 1960 年代后期,第一个 OCR(光学字符识别)技术将扫描的文档转换为原始文本。通过从这些数字化文档中索引和搜索文本,软件加快了以前费力的法律发现和研究项目。
今天,谷歌、微软和亚马逊提供高质量的 OCR 作为其云服务产品的一部分。但文档在软件工具链中仍未得到充分利用,有价值的数据在
普遍的假设是机器学习,通常被修饰为“人工智能”,是实现这一目标的最佳方式,取代过时和脆弱的基于模板的技术。这种假设是错误的。将绝大多数文档转换为结构化数据的最佳方法是使用下一代功能强大、灵活的模板,这些模板可以像人一样在文档中查找数据。
机器学习的承诺是,您可以在大量代表性文档上训练一次模型,然后平滑地推广到样本外的文档布局,而无需重新训练。例如,您想在 A、B 和 C 公司的家庭保险单上训练一个 ML 模型,然后从 Z 公司出具的类似文件中提取相同的数据。这在实践中很难实现,原因有以下三个:
您的目标通常是从每个文档中提取数十或数百个单独的数据元素。文档粒度级别的模型会经常遗漏其中一些值,而这些错误很难检测到。一旦您的模型尝试从样本外文档类型中提取这数十或数百个数据元素,您就会获得大量泛化失败的机会。
虽然一些简单的文档可能有一个扁平的键/值本体,但大多数都会有一个子结构:想想房屋检查报告中的缺陷列表或银行对帐单中的一组交易。在某些情况下,您甚至会遇到复杂的嵌套子结构:想想保险单列表,每个保险单都有索赔历史。您要么需要机器学习模型来推断这些层次结构,要么需要在训练之前使用这些层次结构和整体所需的本体手动参数化模型。
文档是可以放在一张或多张纸上并包含数据的任何东西!文档实际上只是一堆不同且任意的数据表示形式。表格、标签、自由文本、部分、图像、页眉和页脚:您命名它,文档可以使用它来编码数据。不能保证两个文档,即使具有相同的语义,也会使用相同的表示工具。
毫不奇怪,基于 ML 的文档解析项目可能需要数月时间,需要大量数据,导致结果不佳,并且通常是“艰苦的”(直接引用一个此类项目的参与者与该领域的领先供应商)。
这些问题强烈表明结构化文档的适当攻击角度是在数据元素级别而不是整个文档级别。换句话说,我们需要从表格、标签和自由文本中提取数据;不是来自一个整体的“文件”。在数据元素级别,我们需要强大的工具来表达文档中的表征模式与对软件有用的数据结构之间的关系。
所以让我们回到模板。
从历史上看,模板在表达表示模式和数据结构之间的映射方面一直很贫乏。例如,他们可能会指示:转到第 3 页并返回这些框坐标内的任何文本。由于多种原因,这会立即崩溃,包括:
这些对文档布局的微小更改都不会让人类读者感到不安。
对于能够成功构建复杂文档的软件,您需要一个能够避开长达数月的 ML 项目与脆弱模板之间的战斗的解决方案。相反,让我们构建一种特定于文档的查询语言,该语言(在适当的时候)将 ML 嵌入数据元素而不是文档级别。
首先,您需要描述表示模式(如标签/值对或重复的小节)的语言中的原语(即指令)并保持对典型布局变化的弹性。例如,如果你说:
“找到以这个词开头的一行并从中获取最低的美元金额”
您需要对空白变化、垂直抖动、封面和文档倾斜具有弹性的“行”识别,并且需要强大的类型检测和过滤。
其次,对于具有视觉或自然语言组件的数据表示,例如表格、复选框和自由文本段落,原语应该嵌入 ML。在这个级别的分析中,谷歌、亚马逊、微软和 OpenAI 都有现成的运行良好的工具。
Sensible正是采用这种方法:将强大而灵活的模板与机器学习相结合。和
SenseML 广泛的原语允许您将表示模式快速映射到有用的数据结构,包括复杂的嵌套子结构。在原语不使用 ML 的情况下,它们的行为具有确定性,以提供强大的行为和准确性保证。甚至对于我们的 ML 驱动的原语的非确定性输出(例如表格),验证规则也可以识别 ML 输出中的错误。
这意味着使用 Sensible 进行文档解析非常快速、透明和灵活。如果您想向模板添加字段或修复错误,这样做很简单。
Sensible 快速实现价值的代价是每个有意义的不同文档布局都需要一个单独的模板。但事实证明,这种权衡在现实世界中并没有那么糟糕。在大多数业务用例中,有无数种布局(例如,数十家货运承运人在美国生成费率确认;少数软件系统生成家庭检查报告)。我们的客户不会创建数以千计的文档模板——大多数只用几个就可以产生巨大的价值。
当然,对于每个广泛使用的税表、保险单和就业验证,我们只需创建一次模板即可。这就是为什么我们介绍了……
我们的开源
我们相信,这种混合方法是透明且有效地解决将文档转换为结构化数据的问题的途径,适用于包括物流、金融服务、保险和医疗保健在内的广泛行业。如果您想加入我们的旅程并将您的文档连接到软件,