巧用机器学习托管服务，自动化合约处理从此不在话下！

2021 年 12 月 23 日
本文字数：6897 字
阅读完需：约 23 分钟

处理合约及协议等文档资料是一项费时费力的任务。在传统意义上，对典型的合约签订工作流进行审计往往涉及合约条款的加载、阅读及提取等多个步骤，这往往需要耗费大量人工与劳力。

以往，Amazon Finance and Global Business Services (Amazon FGBS)每月也曾投入 150 多个人工处理这方面工作。在此期间，众多分析师需要将上百份合约一次性手动输入至 Excel 表格当中。

最近，专门负责分析合约协议的 Amazon FGBS 团队开发建立一条自动化工作流，借此高效处理传入文档。其目标非常简单——把专业财会资源从繁琐的日常劳作中解放出来，将更多精力投入到增值性财务分析当中。

最终，该团队构建了一套解决方案，能够在 1 分钟之内以高保真度与可靠的安全性持续解析并存储整个合同中的重要数据。现在，整个自动化流程每月只需要 1 位分析师工作 30 小时即可完成平台的维护与运行。处理时长缩短至之前的五分之一，生产效率得到显著提高。

整个应用由两项亚马逊云科技支持的机器学习（ML）托管服务实现，分别为 Amazon Textract（可高效实现文档内容提取）以及 Amazon Comprehend（可提供下游文本处理，负责提取关键术语）。

本文将介绍整套解决方案的基本架构，深入研究架构设计并简要探讨其中的设计取舍。

合约工作流

下图所示，为这套解决方案的基本架构：

Amazon FGBS 团队在亚马逊云科技机器学习（ML）专业服务（ProServe）团队的帮助下，构建起一套自动化、持久且可扩展的合约处理平台。传入的合约数据被存储在 Amazon Simple Storage Service (Amazon S3)数据湖当中。此解决方案使用 Amazon Textract 将合约转换为文本形式，而后使用 Amazon Comprehend 进行文本分析与术语提取。从合约中提取到的关键条款及其他元数据，将被存储在 Amazon DyanmoDB（一套可接收键-值与文档类型数据的数据库）当中。财会用户可以通过由 Amazon CloudFront 托管的自定义 Web 用户界面访问数据内容，并执行关键用户操作，例如错误检查、数据验证以及自定义术语输入等。此外，他们还可以由完全托管应用程序流服务 Amazon Appstream 管理的 Tableau 服务器生成结果报告。您还可以使用 Amazon CloudFormation 模板在亚马逊云科技生产环境中启动并托管这套端到端合约处理平台。

构建高效且可扩展的文档输入引擎

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 Comprehend 提取标准与非标准条款

下图所示，为关键词提取功能的基本架构：

本解决方案将 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 条目的大小限制。解决方案将其上限设置为 400 KB。对于体量较大的合约与提取条款列表，某些合约的输出结果会超过此限制，因此我们需要在条目提取功能中执行检查，及时将较大条目拆分为多个 JSON 对象。

通过自定义 Web UI 保护数据访问与验证

下图所示，为自定义 Web 用户界面（UI）与报告架构：

为了与提取到的合约数据进行有效交互，团队构建了一套自定义 Web UI。使用 Angular v8 框架构建的 Web 应用程序通过 Amazon S3 托管在云内容交付网络 Amazon CloudFront 上。当访问 Amazon CloudFront URL 时，我们首无使用具有严格权限约束的用户池对用户进行授权及身份验证，借此判断其是否有权查看此 UI 并与之交互。在完成验证之后，会话信息将被保存下来，确保用户仅在设定的时段之内保持登录状态。

在登陆页面上，用户可以通过链接导航至面板上显示的三套关键用户方案处：

Search for Records – 查看并编辑合约记录
View Record History – 查看合约记录的历史编辑记录
Appstream Reports – 打开 Appstream 托管的报告仪表板

要查看特定记录，系统会提示用户使用特定的客户名称或文件名称进行文件搜索。在使用前一种方式时，搜索将返回具有相同客户名称的各份合约的最新记录。对于后一种方式，搜索将仅返回具有该文件名的特定合约的最新记录。

在用户找到需要检查或编辑的正确合约之后，即可选定其文件名称并跳转至 Edit Record 页面。系统将显示合约条款的完整列表，并允许用户编辑、添加或删除这些提取自合约的信息。您可以使用不同的术语从表单字段中检索最新记录，选择不同的值为验证数据；如果发现错误，则及时编辑数据。用户还可以选择 Add New Field 并为自定义术语输入键-值对来添加新的字段。

使用编辑或新的字段更新条目之后，用户可以选择 Update Item 按钮。这项操作将触发使用 POST 方法把新记录的数据从前端通过 Amazon API Gateway 传递至PostFromDynamoDB函数的过程，生成一个 JSON 文件，此文件将被推送至保存全部已提取到的术语数据的 S3 存储桶内。该文件触发相同的UpdateDynamoDB 函数，此函数会在第一次 Amazon Textract 处理运行之后将原始术语数据推送至 DynamoDB 表。

验证完成之后，用户可以选择 Delete Record，借此通过统一删除 DynamoDB 以及存储到 S3 存储桶内所有已提取到的各合约版本中的数据。这项操作由 DELETE 方法所启动，将触发用于删除数据的DeleteFromDynamoDB函数。在合约数据验证及编辑期间，对于推送字段的每一次更新都会创建一条新的数据记录。此记录将根据登录配置文件自动记录时间戳与用户身份，借此确保对历史编辑记录进行细粒度跟踪。

要发挥编辑跟踪的作用，用户可以搜索合约并查看合约中全部记录的集合（按时间戳排序）。以此为基础，用户可以快速比较跨时间段进行的编辑操作，包括添加任何自定义字段，并将这些编辑链接回编辑器标记。

为了确保团队能够从这套解决方案中实现业务价值，他们还向架构当中添加了报告仪表板管道。报告应用程序实例由完全托管应用程序流服务 Amazon AppStream 2.0 负责托管。Amazon Glue 爬取器则为 Amazon S3 中的数据建立 schema，并由 Amazon Athena 查询并将数据加载至 Amazon AppStream 实例与报告应用程序当中。

考虑到这部分数据对于 Amazon 而言相当敏感，我们的团队还纳入了不少安全考量，确保能够安全地与数据进行交互，同时严格阻断未授权第三方的访问。Amazon Cognito 授权程序负责保护 API Gateway 的安全。在用户登录期间，将由采用双因素身份验证的 Amazon 内部单点登录机制对申请访问 Amazon Cognito 用户池的团队成员进行验证。

要查看历史记录，用户可以搜索合约并检查单一合约的完整记录集合，快速查看一切错误或可疑的编辑结果，并准确追溯编辑时间与编辑者身份。

该团队还采用其他应用程序强化步骤，用以保护架构及前端。请确保根据最低权限原则缩小亚马逊云科技角色与策略的应用范围。对于 Amazon S3 与 DynamoDB 等存储位置，一切访问将默认被阻断，通过启用服务器端加密以实现静态加密，同时提供版本控制与日志记录功能。对于传输数据加密，Amazon PrivateLink 支持的 VPC 接口端点将各亚马逊云科技服务连接起来，确保数据只通过亚马逊云科技私有端点（而非公共互联网）进行往来传输。在一切 Lambda 函数中，全面使用 Python 临时文件库以应对时间攻击（TOCTOU），由此遵循临时数据处理方面的最佳实践。顺带一提，所谓时间攻击，是指攻击者抢先将文件放置在指定位置，以时间差的方式完成入侵目标。由于 Lambda 属于无服务器服务，因此在调用 Lambda 函数之后，存储在临时目录中的所有数据都将被删除，除非用户明确要求将数据推送至另一存储位置（例如 Amazon S3）。

客户数据隐私一直是 Amazon FGBS 团队乃至整个亚马逊云科技服务团队的头等大事。虽然在 Amazon Textract 及 Amazon Comprehend 等亚马逊云科技服务中合并其他训练数据，能够显著提高机器学习模型的最终性能，但大家请务必保持严格的数据保留限制。为了防止将 Amazon Textract 与 Amazon Comprehend 生成的合约数据存储下来供后续模型训练，Amazon FGBS 团队建立起客户数据清退机制以及时清理客户数据。

为了在处理特定敏感数据时验证应用程序的完整性，团队还执行了内部安全检查与来自外部供应商的渗透测试。其中包含动态代码审查、动态模糊测试、表单验证、脚本注入与跨站点脚本（XSS），并针对 OWASP 十大 Web 应用程序安全风险做出响应。为了解决分布式拒绝服务（DDoS）攻击，团队在 API Gateway 上设置了限制，并使用 CloudWatch 警报对调用阈值限值加以监控。

将安全要求整合至应用程序当中，整个解决方案即可被编入 Amazon CloudFormation 模板，而后将解决方案交付至团队的实际生产流程内。CloudFormation 模板将多个嵌套栈组成，其中描述了应用程序基础设施中的各关键组件（前端服务与后端服务）。使用 Amazon CodeBUIld 设置的持续部署管道，帮助团队及时构建并部署指向应用程序代码或基础设施的一切更改。开发及生产环境在两个相互独立的亚马逊云科技账户当中创建，并通过在相应账户中设置的环境变量来管理两套环境的具体部署。

总结

这款应用程序现已上线，而且每月通过成百上千份合约进行测试。最重要的是，该团队已经切实体会到业务流程自动化所带来的时间节约与价值提升效益。

Amazon ProServe 团队目前正与 Amazon FGBS 团队合作推进项目的第二阶段，旨在进一步增强这套解决方案。为了提高术语提取的准确性，他们尝试使用经过预训练及定制化设计的 Amazon Comprehend NER 模型。他们将建立起重新训练管道，确保平台智能可以随着时间推移与新数据的供给实现改进。他们还考虑引入 Amazon Augmented AI（Amazon A2I）这一新服务，利用其中的 AI 代码审查功能发现低置信度 Amazon Textract 输出结果，并生成新的训练数据以持续改进模型。

随着亚马逊云科技不断推出更多激动人心的全新机器学习服务，Amazon FGBS 团队也期待不断增强这套解决方案，运用现代化、自动化成果逐步取代传统财会工作用例。

立即体验！欢迎大家在亚马逊云科技管理控制台上使用本文中提到的服务及更多其他服务支持您的用例。

本篇作者