解决合约及协定等文档资料是一项费时费力的工作。在传统意义上，对典型的合约签订工作流进行审计往往波及合约条款的加载、浏览及提取等多个步骤，这往往须要消耗大量人工与劳力。
以往，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团队也期待一直加强这套解决方案，使用现代化、自动化成绩逐渐取代传统财会工作用例。
立刻体验！欢送大家在亚马逊云科技管理控制台上应用本文中提到的服务及更多其余服务反对您的用例。
本篇作者
Han Man
亚马逊云科技业余服务团队高级数据科学家
他领有美国西北大学工程学博士学位，并领有多年治理参谋教训，负责为制造业、金融服务以及能源畛域客户提供咨询服务。现在，他与各行各业的客户积极合作，在亚马逊云科技上开发并施行各类机器学习与人工智能解决方案。
**Amazon Finance
Global Business Services团队**
Carly Huang
Amazon Accounting supporting
亚马逊云科技revenue高级财务分析师
她领有西蒙弗雷泽大学工商管理学士学位、注册业余会计师（CPA），并在技术与制造业企业领有多年客户审计教训。她乐于应用亚马逊云科技服务摸索改善及简化现有财会流程的新办法。业余时间，她喜爱旅行和跑步。
Shonoy Agrawaal
Amazon Accounting supporting
亚马逊云科技revenue高级经理
他领有华盛顿大学工商管理学士学位、注册会计师，在批发与金融服务行业领有多年客户审计教训。目前，他负责为亚马逊云科技业务提供会计与财务报告方面的反对。在业余时间，他喜爱旅行和与亲朋好友共度时光。
Amazon ProServe团队
Nithin Reddy Cheruku
亚马逊云科技业余服务团队高级AI/ML架构师
致力于使用新兴技术帮忙客户推动数字化转型。他热衷于通过种种翻新形式解决商业及社区中的新兴问题。在工作之余，Nithin喜爱打板球和乒乓球。
Huzaifa Zainuddin
亚马逊云科技业余服务团队云基础设施架构师
他在多个技术岗位上领有多年工作教训。他目前与客户单干，帮忙设计基础设施并在亚马逊云科技上部署及扩大应用程序。在业余时间，他喜爱烧烤、旅行，偶然也玩玩电子游戏。
Ananya Koduri
亚马逊云科技业余服务团队——西海岸应用程序团队应用程序云架构师
她领有计算机科学硕士学位，领有5年技术行业参谋经验，曾在政府、采矿业及教育等畛域服务泛滥客户。目前，她与客户严密单干，独特在亚马逊云科技上建设业务架构。在业余时间，她喜爱短途徒步旅行，同时也是一位具备业余水准的古典舞者。
Vivek Lakshmanan
亚马逊云科技公司数据与机器学习工程师
他领有圣何塞州立大学软件工程硕士学位，主攻数据迷信方向。Vivek热衷于在云端为客户利用前沿技术，并构建各类AI/ML解决方案。他对AI/ML畛域的统计量、自然语言解决（NLP）以及模型解释性等议题抱有浓厚兴趣。在业余时间，他喜爱打板球和安顿说走就走的公路旅行。