发布于: Nov 30, 2022
【概要】深度学习与机器视觉的应用会逐步减小我们对文本审查的工作量。科研人员针对这一问题，借助深度学习模型，开发了一套可以用于识别文档内容的高效工具。
深度学习与机器视觉的应用会逐步减小我们对文本审查的工作量。以往在我们的工作中面对大量的合同等文件，需要工作人员逐一审查，这必定会耗费大量的人力和时间成本，科研人员针对这一问题，借助深度学习模型，开发了一套可以用于识别文档内容的高效工具。
Amazon FGBS 团队负责处理的合约往往相当复杂，因此以往只能通过人工审查以解析并提取相关信息。这些合约的格式随时间推移而不断变化，且具体篇幅及复杂性各不相同。除此之外，文档中不仅包含自由文本，同时也有着大量涉及重要上下文信息的表格与表单。
为了满足这些需求，这套解决方案使用 Amazon Textract 作为文档输入引擎。Amazon Textract 是一项功能强大的服务，以一组经过预先训练的机器学习计算机视觉模型为基础，这些模型通过复杂的调优对来自文档（例如图像或 PDF）的文本及数字执行光学字符识别（OCR）。Amazon Textract 能够识别出文档中的表格与表单，保留每个单词的上下文信息。该团队希望从每一份合约中提取出重要的核心条款，但也有一些合约中并不包含任何条款集。例如，可能有多份合约共同同一主表，此表左侧列出术语名称，右侧列出该术语的值。我们的解决方案可以使用 Amazon Textract 的表单提取功能将其转化为一个键-值对，其链接至合约条款中的名称与值。
下图所示，为 Amazon Textract 中的批处理架构：
管道使用由分布式消息队列服务 Amazon Simple Queue Service (Amazon SQS) 启用的异步 Amazon Textract API 处理传入的合约。Amazon Lambda 函数 StartDocumentTextAnalysis 负责启动 Amazon Textract 处理作业，而此函数会在有新文件被存放至 Amazon S3 的合约数据湖时触发。由于合约以分批形式加载，而且异步 API 能够在不预先将合约转换为图像文件格式的情况下直接处理 PDF 文件，因此设计人员决定构建异步流程以提高方案的可扩展性。此解决方案使用 DocumentAnalysis API（而非 DocumentDetection API），用以实现对表格及表单的识别。
在 DocumentAnalysis 作业完成之后，解决方案会返回 JobID 并将其输入至另一个队列当中，此队列负责以 JSON 对象的形式从 Amazon Textract 中检测已经完成的输出。响应结果将以大型嵌套数据结构，同时容纳提取到的文本以及文档元数据。GetDocumentTextAnalysis 函数将 JSON 输出的检索与存储放置在 S3 存储桶内，以待后续处理及术语提取。
下图所示，为关键词提取功能的基本架构：
本解决方案将 Amazon Textract 处理后的合约输出结果存放在 S3 存储桶内，而后启动术语提取管道。此管道的主要工作程序为 ExtractTermsFromTextractOutput 函数，此函数对术语提取所得到的情报进行编码。
此步骤包含以下关键操作：
- 合约被拆分为多个部分，提取其中的基础属性，例如合约标题与合约 ID 编号。
- 标准合约条款将被标识为键-值对。使用 Amazon Textract 输出结果中发现的表关系，本解决方案可以从包含关键术语的表中找到正确的术语与对应值，同时采取其他操作将术语值转换为正确的数据格式，例如解析日期。
- 可以将一组非标准术语添加至表内，或者嵌入至合约特定部分的自由文本当中。该团队使用 Amazon Comprehend 自定义分类模型识别这些需要关注的重要部分。
为了为这套模型生成适当的训练数据，Amazon FGBS 团队的主题专家对大量历史合约进行了标记，借此识别出合约中的标准部分（不包含任何特殊术语）与非标准部分（包含特殊术语及用语）。这套托管在 Amazon SageMaker 实例之上的标记平台能够显示单一合约中的各个部分，各部分由之前使用的 ExtractTermsFromTextractOutput 函数拆分而来，以便用户能够相应标记这些内容。
经过训练的最终自定义文本分类模型将负责对各段落进行分类，识别出 F1 得分超过 85% 的内容，并由 Amazon Comprehend 管理非标准部分。使用 Amazon Comprehend 进行文本分类的核心优势，在于其对训练数据格式的要求非常宽松，该服务能够自主完成文本预处理步骤，例如特征工程并解决类别不平衡问题。这些都属于需要在自定义文本模型中需要解决的典型问题。
在将合约划分成多个部分之后，这些部分的一个子集将由 ExtractTermsFromTextractOutput 函数传递至自定义分类模型端点处，检测其中是否包含非标准术语。DynamoDB 表中记录了已检查完成的合约部分与被标记为非标部分的最终列表。接下来，系统会通知会计师们检查需要人工核查以进行解释的非标合约语言，并挑选出有必要明确记录的条款。
在完成这三个阶段（合约拆分、提取标准条款、以及使用自定义模型对非标部分进行分类）之后，解决方案使用条款的键-值对创建一份嵌套字典。针对每份合约，系统还会生成一个错误文件，确切指定提取到的哪个术语引发了错误以及相应的错误类型。这个错误文件被存放在存储合约条款的 S3 存储桶当中，以便用户可以将单一合约中的任何失败提取追溯至相应的单一条款。错误日志中还包含一个特殊的错误警报短语，用以简化对 Amazon CloudWatch 日志的搜索，借此查找发生提取错误的具体点。最终，系统会为每个合约生成一个包含多达 100 个或者更多条款的 JSON 文件，并将其推送至中间 S3 存储桶当中。
从每份合约中提取的数据将被发送至 DynamoDB 数据库进行存储与检索。之所以选择 DynamoDB 作为持久数据存储载体，主要出于以下两个理由：
- 此键-值与文档数据库相较于关系数据库具有更大的灵活性，因为其能够接受大字符串值及嵌套键-值对等数据结构，而且无需依赖预定义 schema，因此用户可以随合约发展随时向数据库内添加新的术语。
- 这套完全托管数据库能够以规模化方式提供个位数毫秒级性能，因此可以将自定义前端与报告功能集成在这项服务之上。
此外，DynamoDB 能够支持连续备份与时间点恢复，借此将表内数据恢复至过去 35 天周期内的任意一秒钟。这项功能，也让我们的解决方案赢得了整个团队的信任。它能够保护关键数据免遭意外删除或编辑，并为重要的下游任务（例如财务报告）提供业务连续性支持。数据上传期间，系统需要执行一项重要检查——检查 DynamoDB 条目的大小限制。解决方案将其上限设置为 400KB。对于体量较大的合约与提取条款列表，某些合约的输出结果会超过此限制，因此我们需要在条目提取功能中执行检查，及时将较大条目拆分为多个 JSON 对象。
相关文章