📢 转载信息
原文作者：Jeremy Jacobson, Rado Fulek, Earl Bovell, Jordan Ratner, and Vincil Bishop
本文由Ricoh的Jeremy Jacobson和Rado Fulek联合撰写。
本文展示了企业如何通过结合生成式AI、无服务器架构和标准化框架，来克服文档处理的扩展性限制。Ricoh利用AWS GenAI智能文档处理（IDP）加速器工程化了一个可重复、可重用的框架。该框架将客户的上线时间从数周缩短到数天。它还增加了处理新AI密集型工作流（需要复杂文档拆分）的能力，预计容量将增长七倍，达到每月超过70,000份文档。此外，该解决方案使每次部署的工程小时数减少了90%以上。
Ricoh USA, Inc.是一家全球技术领导者，为200多个国家的客户提供服务。在其医疗保健部门，Ricoh每月为其客户处理数十万份关键文档，包括保险索赔、申诉、上诉和临床记录。他们面临着企业现代化文档密集型工作流中一个常见挑战：过度依赖定制的手动工程。每个新的医疗保健客户实施都需要专业工程师进行独特开发和调优。此外，部署需要定制的提示工程、模型微调和集成测试，这些都无法在客户之间重复使用。虽然这为Ricoh客户提供了卓越的、定制化的体验，但所花费的时间和精力造成了限制业务扩展的瓶颈。面对预期中七倍的业务量增长，Ricoh抓住了创新的机会。
挑战不仅在于流程自动化。更重要的是构建一个可扩展的解决方案，为文档提取和代理工作流提供最先进的AI。该解决方案需要满足严格的合规标准，包括HITRUST、HIPAA和SOC II。这些要求通常与快速的AI创新相冲突。合规框架通常限制数据共享，从而限制了模型的训练能力。它们还要求严格的安全控制，这可能会阻碍迭代AI开发和部署所需的敏捷性。尽管面临这些挑战，Ricoh仍将克服这种紧张关系作为其客户的优先事项。Ricoh以Amazon Bedrock上可用的基础模型（FMs）为基础，并结合Amazon Textract，使客户能够在符合最严格合规标准的同时，从尖端的自动化中受益。
本文探讨了Ricoh如何使用AWS GenAI IDP加速器作为基础，构建了一个标准化的、多租户的自动化文档分类和提取解决方案，从而将文档处理从定制工程的瓶颈转变为可扩展、可重复的服务。
客户概览
Ricoh USA, Inc.是一家全球技术领导者，为200多个国家的组织提供数字工作场所服务、文档管理和业务流程自动化解决方案。在其医疗保健部门，Ricoh每月为其主要健康保险支付方、管理式医疗组织和医疗保健提供商处理数千份关键文档，包括保险索赔、申诉、上诉和临床记录。
Ricoh的投资组合解决方案开发AI架构师Jeremy Jacobson表示：“在Ricoh智能业务平台中，需要最高级别智能的关键IDP任务工作流经历了爆炸性增长。我们需要从定制构建转向平台化。” “对于我们的客户，我们集成、运营和演进AI，让他们不必这样做。将我们专有的IDP模式和技术与AWS GenAI IDP加速器相结合，放大了这一优势。有了这些支持，我们交付了一个通过HITRUST CSF认证的可配置IDP平台，将我们的客户与AI前沿技术联系起来。”
医疗保健文档通常是非结构化且高度多变的。单个数据包可能包括多种文档类型——传真封面、临床笔记和申诉表格——每种都有不同的布局和命名约定。文档长度从15到50页不等，有些包含封面信，有些则没有。不同的医疗保健提供商在不同的医疗保健提供商之间使用不同的文档结构、字段命名约定和关键信息的放置位置。基于模板的提取方法被证明是无效的。
对于Ricoh的智能业务平台服务，功能性要求包括从非结构化或半结构化文档的扫描件中捕获数据属性，并为每个数据属性分配一个置信度级别，该级别可靠地识别何时需要人工审查。所有置信度级别低于预定义阈值的属性都将由人工进行验证以确认准确性与合规性。人工审阅者验证提取的数据，更正错误，并验证关键的医疗保健信息——如成员ID、诊断代码和索赔金额——是否符合监管合规和索赔处理所需的质量标准。这种人工干预的闭环方法实现了两个关键业务成果：在保持医疗保健支付方所需的高准确性水平（通常为98-99%）的同时，与完全手动处理相比，将人工审阅成本降低了60-70%。
该解决方案需要从文档的各个部分提取关键数据，例如成员ID、提供者信息和索赔详情，并有能力在封面信中找不到信息时搜索临床笔记和其他部分。非功能性要求解决了几个关键的运营需求：
- 性能和可扩展性 – 能够在几分钟内处理多达1,000份文档的流量高峰，同时在低流量期间避免计算资源浪费
- 准确性和质量 – 满足交付截止日期和数据准确性的严格服务级别协议（SLA）
- 成本优化 – 启用可配置的置信度阈值，平衡准确性要求和人工审阅成本——使错误捕获的属性保持在商定SLA之下，同时最大限度地减少昂贵的人工审阅
- 运营效率 – 通过配置更改而不是代码更改实现快速的客户上线
复杂文档处理工作流的挑战
在一段时间内，Ricoh团队一直将传统的光学字符识别（OCR）——检测和提取扫描文档中的文本——与可以同时理解文本和图像的多模态AI模型相结合。这种方法有助于解决从具有多个姓名和地址的文档中提取数据时区分相似字段等复杂挑战。
在Amazon Bedrock上可以使用多模态FM后，很快就发现，对Amazon Bedrock进行简单的API调用——即发送扫描文档以及提示——不足以处理复杂的工作流。当文档由多个部分或部分组成时，例如封面、合同或授权响应，提取规则通常取决于首先成功对部分类型进行分类。
该解决方案需要处理复杂的文档分类，区分索赔、申诉、电子邮件和传真封面单，而不会将数据包分解为细粒度的文档类型。此外，大型语言模型（LLM）具有上下文窗口限制，并且随着上下文的填充，遵循指令的性能会下降。文档页面大小限制要求Ricoh团队对更大的文档使用替代方法。
Ricoh团队还需要灵活性，以便与其现有的高容量文档处理工作流（包括文档路由系统、案例管理服务和下游业务应用程序）集成，同时保持对处理步骤和模型选择的控制。这包括根据医疗保健提供商或患者信息拆分文档等独特要求。
为了提高准确性，Ricoh团队利用了更复杂的动态将上下文插入提示的技术——这是一种技术，其中先前提取的字段、文档结构信息和相关文档元数据会根据正在处理的特定文档以编程方式添加到AI模型的指令中。这种上下文感知的提示比静态提示将提取准确性提高了15-20%，有助于模型理解文档关系和字段依赖性。
尽管取得了这些显著的进展，但在尝试重现这种成功时，Ricoh团队遇到了一个持续存在的障碍：这些工作流需要每个客户花费40-60小时的开发人员时间来设置，例如整合底层模型新发布的特性。Ricoh与AWS生成式AI创新中心合作开发了IDP加速器，以解决这些可扩展性挑战。
解决方案概述
Ricoh与AWS合作实施了GenAI IDP加速器，这是一个参考框架，旨在帮助您部署生产级的文档处理解决方案。该加速器提供了针对不同文档类型和工作流优化的多种处理模式。
团队选择了处理模式2，它结合了Amazon Textract进行OCR——将文本图像转换为机器可读文本的技术——与Amazon Bedrock FMs进行智能分类和提取。此模式专为需要文本提取和AI驱动理解的复杂、多部分文档而设计。该方法提供了对模型编排的完全控制，非常适合处理Ricoh的多部分医疗保健文档，因为它支持顺序处理（先分类，然后根据分类进行提取），并通过分块处理来处理超出典型LLM上下文窗口限制的文档。
该解决方案的架构旨在符合严格的医疗保健合规要求。对于HIPAA合规性，受保护的健康信息（PHI）使用AWS密钥管理服务（AWS KMS）在静态时加密，并使用TLS 1.2+在传输中加密。访问控制遵循最小权限原则，AWS身份和访问管理（IAM）策略将数据访问限制为授权人员。
对于HITRUST认证要求，该架构通过Amazon CloudWatch和AWS CloudTrail实施了全面的审计日志记录，捕获数据访问和处理活动。SOC 2 Type II合规性通过使用维护其自身SOC 2认证的AWS服务，结合Ricoh关于变更管理、事件响应和持续监控的文档化操作控制来支持。
按使用付费的定价模式消除了闲置基础设施成本——Ricoh只需为实际的文档处理付费，在不活动期间无需付费。这种成本可预测性对于支持具有不同文档量的多个客户至关重要，因为每个客户的成本与其使用量成比例扩展，而不是需要固定的基础设施投资。
文档通过Amazon Simple Storage Service (Amazon S3) 进入，触发事件驱动的工作流。AWS Lambda函数调用Amazon Bedrock模型来确定文档类型，例如索赔、申诉、传真、申诉、预授权请求和临床文档。Amazon Textract解析文本和布局，结果与Amazon Bedrock模型结合用于结构化数据提取。自定义业务规则——特定于每个客户需求的配置逻辑，例如字段验证规则、文档路由标准和数据转换规范——与置信度评分一起工作，以确定哪些字段需要人工审阅。
置信度评分是通过比较来自多个来源（Amazon Textract和Amazon Bedrock）的提取结果并分配一个数值（0-100%）来计算的，该数值表示系统对每个提取字段的确定性。得分低于客户定义阈值（通常为70-85%）的字段会被标记以供人工验证。最终输出存储在Amazon S3中，低置信度案例通过审阅队列路由以供人工验证，操作员在这些队列中验证提取的数据、更正错误并提供反馈以改进未来的处理。
AWS GenAI IDP加速器的核心IDP-Common引擎充当集成层，帮助Ricoh维护其既定工作流。IDP通用包是一个Python库，为AWS上加速的智能文档处理解决方案提供共享功能。此解决方案通过使用AI服务自动提取和处理文档信息，从而消除了手动数据输入并提高了准确性。
每个客户部署都使用一个可配置的AWS Serverless Application Model (AWS SAM) 应用程序实例部署为一个AWS CloudFormation堆栈，支持快速上线。这抽象化了基础设施细节——包括Amazon Virtual Private Cloud (Amazon VPC) 配置、安全组规则、IAM角色策略和服务限额——因此团队成员可以只关注客户相关的参数，例如Lambda预留并发或数据库连接详细信息。在上线新客户时，这种集中的方法非常宝贵。
模块化设计帮助Ricoh将特定的参数和自定义功能（如客户定义的专有文档分类、行业特定表格的自定义数据提取或出于PII合规性目的的编辑规则）集成到其现有的高容量工作流中，而不会干扰既定流程。这种方法通过自动化部署帮助团队保持运营效率，从而将客户上线时间从数周缩短到数天，同时为文档处理（包括智能文档分类和非结构化表格的自动化数据提取）增加了先进的AI功能。
架构细节
该架构的设计有三个主要目标：通过配置而非代码更改实现快速的客户上线、帮助符合医疗法规（HIPAA、HITRUST、SOC 2）以及为可变文档量提供具有成本效益的可扩展性。选择无服务器方法是为了消除基础设施管理的开销并将成本直接与使用量挂钩，多租户设计和每个客户队列平衡了资源效率和工作负载隔离。决定使用处理模式2（Amazon Textract和Amazon Bedrock）而不是仅使用Amazon Bedrock，是出于处理超出LLM上下文窗口限制的文档的需要，以及对结构化文本提取的需求，可以根据文档类型选择性地包含在提示中。
实施中使用了无服务器架构，其中在扫描文档上传到Amazon S3后会自动调用Lambda函数。Lambda函数处理对AI服务（Amazon Textract和Amazon Bedrock）的调用，并将捕获的属性及其置信度评分输出到Amazon DynamoDB数据库。
该架构结合了AWS Well-Architected Framework的原则，涵盖多个支柱。在安全性方面，数据使用带有客户管理密钥的AWS KMS在静态时加密，使用TLS 1.2+在传输中加密。IAM角色强制执行最小权限访问，按功能分隔，并为文档摄取、处理和检索设置了单独的角色。CloudTrail记录API调用以供审计跟踪，CloudWatch Logs捕获应用程序级别的事件以进行安全监控。
在可靠性方面，无服务器设计消除了单点故障，自动重试和死信队列（DLQ）处理瞬态错误。在性能效率方面，Lambda并发限制和Amazon Simple Queue Service (Amazon SQS) 队列限速有助于防止API配额耗尽，同时保持高吞吐量。在成本优化方面，按使用付费模式消除了闲置资源成本，Amazon S3生命周期策略自动将已处理的文档过渡到成本较低的存储层。
在运营卓越性方面，使用AWS SAM和CloudFormation的基础设施即代码（IaC）实现了持续的部署，CloudWatch仪表板和警报提供了对处理指标和错误率的实时可见性。
架构的一个关键部分是一个SQS队列，它通过控制Lambda并发设置和Amazon SQS可见性超时来控制消息处理速度，使团队能够控制向Amazon Textract和Amazon Bedrock API端点发出请求的速度。此设计有助于他们保持在服务配额限制内（例如Amazon Textract的每秒事务数和Amazon Bedrock的每分钟请求数）。此外，Amazon SQS无缝地促进了重试和将未处理的消息发送到DLQ。
每个客户都有自己的Amazon EventBridge规则和SQS队列，实现了多租户隔离（有助于防止一个客户的高容量影响其他客户）和独立扩展（允许按客户进行并发限制和吞吐量控制）。
该架构使用Amazon S3进行文档存储。创建了不同的存储桶来管理来自各种来源（包括传真、扫描和SFTP系统）的文档。DynamoDB表存储文档元数据和处理状态，帮助防止多次尝试同时更新同一文档。CloudWatch提供了对成功提取率和处理异常的全面监控和日志记录。
与AI服务的实际交互使用Amazon Textract，通过从扫描文档中提取的结构化数据来增强Amazon Bedrock提示。在这里，团队利用了他们以前基于Amazon Textract的解决方案，并将其用作提取值的另一个事实来源，这使得通过比较来自两种提取方法的可靠置信度评分成为可能。在初始部署阶段使用了这种双重提取方法来验证准确性，在对新系统的信心建立后，遗留系统被逐步淘汰。
对于文档处理，该解决方案使用Amazon Textract从大型医疗保健文档中提取文本，解决了当文档作为图像处理时超出FM上下文窗口限制的挑战。例如，如果以图像形式发送，一份50页的临床记录将超出大多数LLM的上下文窗口，但Amazon Textract将其转换为结构化文本，可以根据需要选择性地包含在提示中。Amazon Bedrock FMs处理智能分类和提取任务，并提供针对医疗保健数据量身定制的指令，旨在识别文档类型并提取特定于医疗保健的信息，如成员ID、提供者详细信息和索赔信息。
对于文档分类和拆分，团队使用LLM智能识别文档类型，并根据提供者或患者信息拆分多文档数据包。
关于新客户的快速上线，团队使用一个可配置的AWS SAM应用程序，为每个客户部署为一个CloudFormation嵌套堆栈。这抽象化了基础设施细节——例如VPC配置、安全组规则、IAM角色策略和服务配额——因此团队成员在上线新客户时只需关注客户相关的参数。
模块化架构帮助Ricoh只部署他们需要的组件，同时保留了将来添加附加功能（如文档摘要或知识库集成）的选项。
结果和成果
Ricoh通过衡量和实现人工索引文档的显著减少，成功地降低了一个重要医疗保健客户的价格。现在，人工索引人员将时间集中在困难的文档和提取上，AI作为他们过程中的合作伙伴，而不是执行常规数据输入。
Ricoh的智能业务平台通过自动化实现了显著的运营改进和超过1,900人/时的潜在年度节省，极大地减少了文档处理所需的手动工作量。
自动化分类系统成功地区分了保险持有人申诉和上诉索赔，这是医疗保健合规性和工作流管理的关键能力。这些文档类型具有不同的监管时间表（申诉通常需要30天解决，上诉需要60天），并且必须路由到不同的处理团队。错误分类可能导致错过截止日期、监管处罚和成员不满。
该解决方案展示了有助于最大程度降低处理错误导致的财务处罚的提取准确性水平，这在高度监管的医疗保健行业中是一个至关重要的成果。置信度评分功能实现了有效的人工干预流程，有助于标记需要专家验证的文档，同时允许高置信度的提取自动进行。
Ricoh成功创建了一个可跨多个医疗保健客户重复部署的框架，为将其文档处理服务扩展到未来的用例提供了可扩展的基础。该解决方案目前每月处理超过10,000份医疗保健文档，并具备随着客户需求增长扩展到70,000份文档的基础设施。
智能业务平台实现了显著的运营改进，如下表所示。
| 关键绩效指标 | 之前（遗留系统） | 之后（AWS IDP加速器） | 影响 |
|---|---|---|---|
| 上线时间 | 4–6周 | 2–3天 | >90% 减少 |
| 月吞吐量 | ~10,000 份文档 | >70,000 份文档 | 7倍增长 |
| 每次部署的工程小时数 | ~80 小时 | <5 小时 | >90% 减少 |
| 处理能力 | 有限 | 几分钟内处理 1,000 份文档 | 处理流量高峰 |
最佳实践和经验教训
Ricoh的实施突出了在生产环境中部署IDP解决方案的几项最佳实践：
- 选择合适的处理模式 – 从AWS IDP加速器中选择模式2为处理复杂的医疗保健文档要求提供了所需的灵活性，同时保持了对模型选择和处理步骤的控制。对于处理独特的文档拆分要求和与现有工作流的集成，此选择至关重要。
- 使用结合了OCR和FM的混合方法 – 团队发现，使用Amazon Textract通过结构化数据增强Amazon Bedrock提示，为不同大小和复杂性的文档提供了可扩展性和准确性。这种结合了OCR和FM的混合方法解决了处理文档图像时围绕上下文窗口大小的实际限制——Amazon Textract可以处理不同大小的文档，而Amazon Bedrock提供对提取文本的智能理解，从而实现可扩展性（无文档大小限制）和准确性（AI驱动的字段提取和验证）。在验证阶段利用以前基于Amazon Textract的解决方案作为另一个事实来源，帮助团队在不产生额外重大成本的情况下计算出可靠的置信度评分，因为在新的架构中Amazon Textract已经被用于文本提取。
- 从一开始就集成置信度评分 – 从一开始就集成置信度评分使得有效的人工干预工作流成为可能，允许系统自动标记不确定的提取以供专家审查。这种方法平衡了自动化带来的好处与医疗保健文档处理的准确性要求。可配置的置信度阈值对于满足客户要求至关重要——帮助团队将错误捕获的属性保持在商定SLA之下，同时最大限度地减少人工审阅的成本。
- 使用SQS队列实现速率限制 – 实施SQS队列来限制对Amazon Textract和Amazon Bedrock API端点的调用速率，帮助团队保持在配额限制内，同时无缝地促进重试和DLQ处理。这个架构决策有助于防止限流问题并提高了整体系统可靠性。
- 使用配置而非代码进行标准化 – 使用配置而非代码更改进行标准化是快速客户上线的关键推动因素。为每个客户部署的可配置AWS SAM应用程序作为CloudFormation嵌套堆栈抽象化了基础设施细节——例如VPC配置、安全组规则、IAM角色策略和服务配额——因此团队成员在上线新客户时只需关注客户相关的参数。这种方法减少了维护工作量，并为新客户实现了快速上线。
- 使用模块化架构进行集成 – GenAI IDP加速器的模块化架构在与现有系统集成方面非常有用。核心IDP-Common引擎帮助Ricoh通过AI能力（包括文档分类、智能字段提取、置信度评分和自然... [内容被截断]
🚀 想要体验更好更全面的AI调用？
欢迎使用青云聚合API，约为官网价格的十分之一，支持300+全球最新模型，以及全球各种生图生视频模型，无需翻墙高速稳定，文档丰富，小白也可以简单操作。
评论区