对于处理大量文件（如合同、发票、简历和报告）的现代公司来说，高效处理和检索相关数据对于保持竞争优势至关重要。然而，传统的文件存储和搜索方法耗时且常常需要大量努力才能找到特定的文件，尤其是涉及手写内容时。如果有一种智能处理文件并具有高准确性的搜索方式，会怎样呢？
Amazon Textract与OpenSearch的快速搜索功能相结合，实现了这一目标。在本文中，我们将带您快速构建和部署一个文档搜索索引解决方案，帮助您的组织更好地利用和提取文档中的洞察力。
无论您是人力资源部门寻找员工合同中的特定条款，还是金融分析师在大量发票中筛选提取付款数据，这个解决方案都旨在赋予您以前所未有的速度和准确性访问所需信息的能力。
通过所提出的解决方案，您的文档将自动被导入，其内容被解析，并随后索引到高响应和可扩展的OpenSearch索引中。
我们将介绍如何将Amazon Textract、AWS Lambda、Amazon Simple Storage Service（Amazon S3）和Amazon OpenSearch Service等技术整合到一个无缝处理文档的工作流中。然后，我们将深入探讨如何将这些数据索引到OpenSearch中，并展示您可以轻松使用的搜索功能。
无论您的组织是刚刚迈入数字转型时代的第一步，还是一家寻求加速信息检索的成熟巨头，本指南将指引您探索AWS智能文档处理和OpenSearch提供的机遇。
本文中使用的实现利用了Amazon Textract IDP CDK构建——AWS Cloud Development Kit（CDK）组件用于定义智能文档处理（IDP）工作流的基础架构——它允许您构建特定用例的可自定义IDP工作流。IDP CDK构建和样例是一个用于定义AWS上的IDP流程的组件集合，并发布在GitHub上。主要使用的概念是AWS Cloud Development Kit（CDK）构建、实际的CDK堆栈和AWS Step Functions。使用机器学习自动化和大规模处理文档的工作坊是学习更多关于定制工作流程和使用其他示例工作流程作为基础的好起点。
解决方案概述
在本解决方案中，我们专注于将文档索引到OpenSearch索引中，以便快速搜索和检索信息和文档。将PDF、TIFF、JPEG或PNG格式的文档放入Amazon Simple Storage Service（Amazon S3）存储桶中，然后使用此Step Functions工作流将其索引到OpenSearch中。
图1：Step Functions OpenSearch工作流
OpenSearchWorkflow-Decider检查文档并验证其是否是受支持的MIME类型（PDF、TIFF、PNG或JPEG）。它由一个AWS Lambda函数组成。
DocumentSplitter从文档中生成最多2500页的块。这意味着即使Amazon Textract支持多达3000页的文档，您也可以传入更多页面的文档，该过程仍能正常工作，并将页面放入OpenSearch并创建正确的页码。DocumentSplitter是作为AWS Lambda函数实现的。
Map State并行处理每个块。
TextractAsync任务使用异步的应用程序编程接口（API），按照最佳实践使用Amazon Simple Notification Service（Amazon SNS）通知和OutputConfig调用Amazon Textract。它由两个Amazon Lambda函数组成：一个用于提交文档进行处理，另一个在Amazon SNS通知时触发。
由于TextractAsync任务可以生成多个分页输出文件，TextractAsyncToJSON2进程将它们合并为一个JSON文件。
在SetMetaData步骤中，Step Functions上下文被丰富了应该在OpenSearch索引中进行搜索的信息。示例实现添加了ORIGIN_FILE_NAME、START_PAGE_NUMBER和ORIGIN_FILE_URI。您可以添加任何信息来丰富搜索体验，例如来自其他后端系统的信息、特定ID或分类信息。
生成OpenSearchBatch接受生成的Amazon Textract输出JSON，将其与SetMetaData设置的上下文信息结合，并准备一个优化后的文件，用于批量导入OpenSearch。
在OpenSearchPushInvoke中，将该批量导入文件发送到OpenSearch索引，并可进行搜索。此AWS Lambda函数与AWS Solutions库中的aws-lambda-opensearch结构连接，使用m6g.large.search实例，OpenSearch版本2.7，并将Amazon Elastic Block Service（Amazon EBS）卷大小配置为通用目的2（GP2）200 GB。您可以根据需要更改OpenSearch配置。
最后的TaskOpenSearchMapping步骤清除上下文，否则可能超过Step Functions的配额：任务、状态或执行的最大输入或输出大小。
前提条件
要部署示例，您需要一个AWS帐户，需要AWS Cloud Development Kit（AWS CDK），需要当前的Python版本和Docker。您需要具有部署AWS CloudFormation模板的权限，推送到Amazon Elastic Container Registry（Amazon ECR），创建Amazon Identity and Access Management（AWS IAM）角色，Amazon Lambda函数，Amazon S3存储桶，Amazon Step Functions，Amazon OpenSearch集群和Amazon Cognito用户池。确保您的AWS CLI环境已设置相应的权限。
您还可以启动一个预安装了AWS CDK、Python和Docker的AWS Cloud9实例来启动部署。
步骤
部署
- 在设置了前提条件后，您需要首先克隆存储库：
git clone https://github.com/aws-solutions-library-samples/guidance-for-low-code-intelligent-document-processing-on-aws.git- 然后进入存储库文件夹并安装依赖项：
cd guidance-for-low-code-intelligent-document-processing-on-aws/
pip install -r requirements.txt- 部署OpenSearchWorkflow堆栈：
cdk deploy OpenSearchWorkflow使用GitHub示例的默认配置设置，部署需要大约25分钟，并创建一个Step Functions工作流，当将文档放在Amazon S3存储桶/前缀中并且随后该文档的内容被索引到OpenSearch集群中时调用。
以下是包括有用链接和信息的示例输出，这些链接和信息是通过cdk deploy OpenSearchWorkflow命令生成的：
OpenSearchWorkflow.CognitoUserPoolLink = https://us-east-1.console.aws.amazon.com/cognito/v2/idp/user-pools/us-east-1_1234abcdef/users?region=us-east-1
OpenSearchWorkflow.DocumentQueueLink = https://us-east-1.console.aws.amazon.com/sqs/v2/home?region=us-east-1#/queues/https%3A%2F%2Fsqs.us-east-1.amazonaws.com%2F123412341234%2FOpenSearchWorkflow-ExecutionThrottleDocumentQueueABC1234-ABCDEFG1234.fifo
OpenSearchWorkflow.DocumentUploadLocation = s3://opensearchworkflow-opensearchworkflowbucketabcdef1234/uploads/
OpenSearchWorkflow.OpenSearchDashboard = https://search-idp-cdk-opensearch-abcdef1234.us-east-1.es.amazonaws.com/states/_dashboards
OpenSearchWorkflow.OpenSearchLink = https://us-east-1.console.aws.amazon.com/aos/home?region=us-east-1#/opensearch/domains/idp-cdk-opensearch
OpenSearchWorkflow.StepFunctionFlowLink = https://us-east-1.console.aws.amazon.com/states/home?region=us-east-1#/statemachines/view/arn:aws:states:us-east-1:123412341234:stateMachine:OpenSearchWorkflow12341234此信息也可在AWS CloudFormation控制台中获取。
当将新文档放置在OpenSearchWorkflow.DocumentUploadLocation下时，将为该文档启动一个新的Step Functions工作流。
要检查此文档的状态，OpenSearchWorkflow.StepFunctionFlowLink提供了一个链接，用于在AWS管理控制台中查看StepFunction执行的列表，显示每个上传到Amazon S3的文档的处理状态。教程“在Step Functions控制台上查看和调试执行”提供了AWS控制台中组件和视图的概述。
测试
- 使用样本文件进行第一次测试。
aws s3 cp s3://amazon-textract-public-content/idp-cdk-samples/moby-dick-hidden-paystub-and-w2.pdf $(aws cloudformation list-exports --query 'Exports[?Name==`OpenSearchWorkflow-DocumentUploadLocation`].Value' --output text)- 选择StepFunction工作流链接或打开AWS管理控制台并转到Step Functions服务页面后，可以查看不同的工作流调用。
图2：Step Functions执行列表
- 查看当前运行的样本文档执行，您可以跟踪各个工作流任务的执行情况。
图3：一个文档的Step Functions工作流执行
搜索
流程完成后，我们可以验证文档是否在OpenSearch索引中建立了索引。
- 为此，首先我们创建一个Amazon Cognito用户。Amazon Cognito用于对用户进行身份验证，以访问OpenSearch索引。选择cdk deploy的输出中的链接（或查看AWS管理控制台中的AWS CloudFormation输出），名称为OpenSearchWorkflow.CognitoUserPoolLink。
图4：Cognito用户池
- 接下来，选择创建用户按钮，跳转到一个页面，输入用于访问OpenSearch仪表板的用户名和密码。
图5：Cognito创建用户对话框
- 选择创建用户后，点击CDK部署输出中的OpenSearchWorkflow.OpenSearchDashboard，继续访问OpenSearch仪表板。使用先前创建的用户名和密码进行登录。首次登录时，需要更改密码。
- 登录到OpenSearch仪表板后，选择Stack Management部分，然后选择Index Pattern以创建搜索索引。
图6：OpenSearch仪表板Stack Management
图7：OpenSearch索引模式概览
- 索引的默认名称为papers-index，使用papers-index*作为索引模式名称可以匹配它。
图8: 定义OpenSearch索引模式
- 点击下一步后，选择时间戳作为时间字段并创建索引模式。
图9: OpenSearch索引模式时间字段
- 现在，从菜单中选择发现。
图10: OpenSearch发现
在大多数情况下，您需要根据上次摄取的情况更改时间跨度。默认值为15分钟，而在过去的15分钟内通常没有活动。在本例中，将其更改为15天以可视化摄取过程。
图11: OpenSearch时间跨度更改
- 现在您可以开始搜索了。已索引一本小说，您可以搜索任何词语，如call me Ishmael，并查看结果。
图12: OpenSearch搜索词
在本例中，术语call me Ishmael出现在文档的第6页，该文档位于给定的统一资源标识符（URI），该标识符指向文件的Amazon S3位置。与手动翻阅相比，这使得识别文档和在大量PDF、TIFF或图像文档中查找信息更快捷。
大规模运行
为了估计索引过程的规模和持续时间，实施方案使用93,997个文档进行了测试，总共包含1,583,197页（平均每个文档16.84页，最大文件有3755页），所有文档都被索引到OpenSearch中。在美国东部（弗吉尼亚北部 – us-east-1）地区使用默认的Amazon Textract服务配额，处理所有文件并将其索引到OpenSearch中共耗时5.5小时。下图显示了18:00开始的初始测试，接着是21:00的主要摄取，全部在2:30完成。
图13: OpenSearch索引概述
对于处理过程，tcdk.SFExecutionsStartThrottle被设置为executions_concurrency_threshold=550，这意味着并发文档处理工作流被限制在550个，并且超出的请求将排队到Amazon SQS先进先出（FIFO）队列，当当前工作流完成后将被排空。550的阈值基于us-east-1地区的Textract服务配额为600。因此，队列深度和最旧消息的年龄是值得监控的指标。
图14: Amazon SQS监控
在此测试中，所有文档一次性上传到Amazon S3，因此可见消息的近似数量呈急剧增加，然后随着没有新文档摄取而缓慢下降。直到处理完所有消息，最旧消息的近似年龄会增加。Amazon SQS的消息保留期设置为14天。对于处理时间可能超过14天的非常长的积压处理，可以先处理一小部分具有代表性的文档，并监控执行的持续时间，以估计可以在超过14天之前传递多少文档。对于大量积压文档的使用情况，Amazon SQS的CloudWatch指标看起来类似，一次性摄入然后完全处理。如果您的使用情况是文档的稳定流动，两个指标，可见消息的近似数量和最旧消息的近似年龄将更加线性。您还可以使用阈值参数将稳定的负载与积压处理混合使用，并根据处理需求分配容量。
另一个需要监控的指标是OpenSearch集群的健康状况，您应该根据Amazon OpenSearch Service的操作最佳实践进行设置。默认部署使用m6g.large.search实例。
图15：OpenSearch监控
下面是OpenSearch集群的关键绩效指标（KPI）的快照。没有错误，持续的索引数据速率和延迟。
Step Functions工作流执行显示每个单独文档的处理状态。如果您看到处于失败状态的执行，请选择详细信息。一个好的指标是用于监控Step Functions的AWS CloudWatch自动仪表板，它公开了一些Step Functions CloudWatch指标。
图16：Step Functions监控执行成功
在这个AWS CloudWatch仪表板图中，您可以看到随时间变化的成功的Step Functions执行。
图17：OpenSearch监控执行失败
而这个图显示了执行失败的情况。这些值得通过AWS控制台Step Functions概览进行调查。
下面的截图显示了一个由于源文件大小为0而失败的执行示例，这是有道理的，因为文件没有内容，无法处理。重要的是过滤失败的流程并可视化失败，以便您返回到源文档并验证根本原因。
图18：Step Functions失败的工作流
其他失败可能包括不是mime类型的文档：application/pdf、image/png、image/jpeg或image/tiff，因为Amazon Textract不支持其他文档类型。
成本
处理1,583,278页的总成本分摊在用于实施的AWS服务上。以下列表为近似数，因为实际成本和处理持续时间取决于文档的大小，每个文档的页面数，文档中信息的密度以及AWS区域。Amazon DynamoDB消耗了$0.55，Amazon S3消耗了$3.33，OpenSearch Service消耗了$14.71，Step Functions消耗了$17.92，AWS Lambda消耗了$28.95，Amazon Textract消耗了$1,849.97。此外，请记住，部署的Amazon OpenSearch Service集群按小时计费，并且在运行一段时间后将累积更高的成本。
修改
很可能，您希望修改实施并根据您的用例和文档进行定制。使用机器学习自动化和处理大规模文档的研讨会提供了关于如何操作实际工作流程、更改流程和添加新组件的很好概述。要向OpenSearch索引添加自定义字段，请查看工作流中的SetMetaData任务，使用set-manifest-meta-data-opensearch AWS Lambda函数向上下文添加元数据，该元数据将作为字段添加到OpenSearch索引中。任何元数据信息都将成为索引的一部分。
清理
如果您不再需要示例资源，则可以使用以下命令删除它们，以避免产生未来的费用：
cdk destroy OpenSearchWorkflow在与cdk deploy命令相同的环境中。请注意，这将删除所有内容，包括OpenSearch集群、所有文档和Amazon S3存储桶。如果您想保留这些信息，请备份您的Amazon S3存储桶并从OpenSearch集群创建索引快照。如果您处理了许多文件，那么您可能需要首先使用AWS管理控制台清空Amazon S3存储桶（即在备份或将它们同步到不同的存储桶后，如果您想保留这些信息），因为清理函数可能超时，然后销毁AWS CloudFormation堆栈。
结论
在本文中，我们向您展示了如何部署一个完整的解决方案，将大量文档导入到一个OpenSearch索引中，以便用于搜索用例。我们讨论了实现的各个组件，以及扩展考虑因素、成本和修改选项。所有代码都可以在GitHub上以IDP CDK示例和IDP CDK构造的形式进行访问，以便从头开始构建自己的解决方案。作为下一步，您可以开始修改工作流程，在搜索索引中添加信息，并探索IDP研讨会。请在下方评论您的经验和扩展当前解决方案的想法。