跳到正文
AWS Machine Learning Blog· Erik Cordsen·· 3 小时前精选AI 评分59

用 Amazon Bedrock AgentCore 构建自改进文档处理系统

Build self-improving document processing using Amazon Bedrock AgentCore

AI 导读

AWS 发布教程,介绍如何用 Amazon Bedrock AgentCore 构建多智能体文档处理系统,通过识别、训练、自动化三条工作流自动分类、抽取、校验并复用提取指令。

推荐理由

原文给出可部署的多智能体文档处理方案与实测耗时对比,读者可参考其自学习指令复用机制。

正文 · AI 翻译

IDC 研究显示,与文档相关的挑战每年给每个信息工作者所在的组织造成 19,732 美元的损失,并使生产力降低 21.3%。从数百家供应商接收发票的组织常常面临因开票方而异且随时变化的版式。基于模板的系统在这种规模下需要持续维护。员工最多可将 30% 的时间花在与文档相关的任务上,而手动数据录入的错误率在 1–4% 之间。传统的智能文档处理(IDP)解决方案能缓解部分负担,但它们需要针对每种文档格式进行大量前期配置,并且当不同供应商的版式存在差异时就会失效。

在本文中,您将学习如何使用 Amazon Bedrock AgentCore 构建一个代理式 IDP 系统,该系统能够以最少的人工干预对业务文档进行分类、提取、验证并从中学习。Amazon Bedrock AgentCore 是一个平台,可使用任意框架或模型大规模构建、连接和优化代理。您的代理会自动处理新的文档格式,例如供应商发票、采购订单、保险理赔和贷款申请。读完本文后,您可以:

  • 部署一个多代理 IDP 系统,通常只需不到 20 分钟。
  • 无需手动配置模板即可处理新的文档类型。
  • 让代理针对每种新文档格式进行自我训练并复用所学内容,这样该类型的后续文档可直接进入提取环节,无需重新训练。

基于规则的文档处理面临的挑战

许多 IDP 流水线要求您为每种文档格式预先定义模板、提取规则和验证逻辑。当新供应商发来版式不同的采购订单时,流水线就会中断。这带来了三个核心挑战:

  1. 模板僵化:每种新文档格式都需要手动配置,甚至细微的版式变化都可能导致提取失败。
  2. 无法学习:相同的提取错误会在类似文档中反复出现,因为系统不会保留以往更正中的知识。
  3. 扩展负担:每新增一个供应商或文档变体都会使维护工作量成倍增加,而处理来自数百个来源的文档的组织将面临持续的运营成本。

代理式方法可以应对这些挑战。AI 代理不再依赖静态模板,而是分析每份文档、生成提取指令、验证结果,并自动从更正中进行学习。随着时间推移,您的系统会构建起文档格式的知识库,从而以最少的额外配置处理类似文档。

解决方案概览

在此解决方案中,八个专用代理在 Amazon Bedrock AgentCore 上运行的两个基于图的工作流中协同工作。

下图展示了使用 Strands Agents(一个用于构建 AI 代理的开源 SDK)构建的多代理工作流图。

图 1:多代理编排工作流图

  • 识别工作流:Analyzer 代理使用 Amazon Textract 提取文本,并识别文档类型和发送方。Matcher 代理使用 Amazon S3 Vectors(Amazon Simple Storage Service(Amazon S3)的一项功能)中的向量相似度搜索类似文档。
  • 训练工作流(新文档类型):当未找到匹配项时,Instructions agent 生成提取提示词,Extractor agent 提取结构化数据,Validator agent 在 Amazon Aurora DSQL 中根据 schema 和业务规则检查结果。如果验证失败,Instructions Fixer agent 会优化提示词并重试。成功后,Save Instructions agent 会持久化保存指令以供复用。
  • 自动化工作流(已知文档类型):当找到匹配项时,Extractor agent 使用现有指令。如果验证失败,Troubleshooter agent 会直接修复提取的数据,而不修改指令。

工作原理

下图展示了该解决方案的基础设施架构。

图 2:AWS 上的 Agentic IDP 基础设施架构

  1. 业务文档通过 Amazon Simple Email Service(Amazon SES)送达,或直接上传到 Amazon S3。
  2. Amazon EventBridge 触发一个 AWS Lambda 函数,该函数在 Amazon DynamoDB 中创建跟踪任务,并调用 AgentCore runtime(Amazon Bedrock AgentCore 的一项能力)。
  3. AgentCore runtime 通过 Strands Agents 编排文档处理。
  4. 你的 agent 通过由 AgentCore Identity(Amazon Bedrock AgentCore 的一项能力)和 Amazon Cognito 管理的机器对机器凭证,安全地访问 AWS 资源。
  5. 你的 Lambda 函数通过 AgentCore Gateway(Amazon Bedrock AgentCore 的一项能力)的 Model Context Protocol(MCP)接口,成为与 agent 兼容的工具。
  6. Agent 使用 Amazon Textract 提取文本,使用 S3 Vectors 中的向量嵌入对文档进行分类,并根据 Aurora DSQL 中的业务规则验证数据。
  7. Agent 通过 MCP 服务器访问企业数据,以根据业务规则验证提取的内容。
  8. 你通过托管在 Amazon Elastic Container Service(Amazon ECS)上的支持聊天的仪表板来监控状态并排查问题。
  9. 你通过 AgentCore Observability(Amazon Bedrock AgentCore 的一项能力)和 Amazon CloudWatch 遥测数据来了解 agent 的性能表现。

部署解决方案

按照以下步骤将解决方案基础设施和 Web UI 部署到你的 AWS 账户。

先决条件

要部署此解决方案,你必须具备:

  1. Clone the repository and set up the environment:
    git clone https://github.com/aws-samples/agenticidp-guidance.git
    cd agenticidp-guidance
    
    uv venv
    source .venv/bin/activate
    uv pip install -r requirements.txt
    
    cd ui/orchestrator
    npm install
    cd ../..
  2. Deploy the stacks:
    uv run deploy.py --admin-email [email protected]

这将部署六个 AWS CloudFormation 堆栈:Core(S3、Cognito、DynamoDB)、Gateway(Lambda 工具、AgentCore Gateway)、Aurora(Amazon Aurora DSQL)、Agent(AgentCore runtime、容器)、UI Orchestrator(API 端点)和 Modern UI(Amazon CloudFront 上的 React 应用)。部署大约需要 15–20 分钟。

  1. 通过检查每个堆栈在 CloudFormation 控制台中是否显示 CREATE_COMPLETE 来验证部署。

处理文件并查看结果

部署完成后,您会收到一封电子邮件,其中包含 CloudFront URL、用户名和临时密码。

处理文档

  1. 登录 Web UI,然后选择 Process Document。
  2. 从 infrastructure/sample_data/purchase_orders/training/ 上传一份示例采购订单。
  3. The document enters the agent workflow:
    • Analyzer agent 提取文本并识别发件人和文档类型。
    • Matcher agent 在向量存储中搜索相似文档。
    • 对于新文档类型,训练工作流会生成提取指令、提取数据、验证数据,并保存指令以供将来使用。
    • 对于已知文档类型,自动化工作流会使用现有指令提取数据并进行验证。
  4. 在 Review Jobs and Instructions 选项卡中查看结果,以验证提取的数据、验证结果和生成的指令。

示例:新文档类型(训练工作流)

假设您上传来自新零售商 Two Wheel Store 的第一份采购订单。Matcher agent 搜索向量存储,未找到相似文档,并将该作业路由到训练工作流。

Analyzer agent 使用 Amazon Textract 提取原始文档文本:

# PURCHASE ORDER
FROM: Two Wheel Store
Order #: PO-2026-0102-2584
Date: 2026-01-02

## Items Ordered
AC-021  Advanced Computer     Qty: 1   $75.61
        Colors: cr4321        @ $75.61
...
SB-004  Folding Classic       Qty: 8   $9634.32
        Colors: cb8901 I Sizes: S     @ $1204.29

TOTAL: $14931.54

Instructions agent 根据 schema 生成提取提示,Extractor agent 生成结构化 JSON:

{
  "po_number": "PO-2026-0102-2584",
  "retailer_name": "Two Wheel Store",
  "order_date": "2026-01-02T00:00:00Z",
  "line_items": [
    { "sku": "AC-021", "product_name": "Advanced Computer", "quantity": 1, "unit_price": 75.61, "line_total": 75.61 },
    { "sku": "SB-004", "product_name": "Folding Classic",   "quantity": 8, "unit_price": 1204.29, "line_total": 9634.32 }
  ],
  "order_total": 14931.54
}

Validator agent 根据 schema 检查结果并失败:

validation_status: INVALID
error: 'SB-004' does not match '^AB-[A-Z]{2}-\d{3}$'

供应商的 SKU 格式(SB-004)与 Acme Bikes 的内部格式(AB-SB-004)不匹配。Instructions Fixer agent 诊断出这一不匹配,并向提取提示中添加了一条明确的 SKU 转换规则:为供应商 SKU 添加前缀 AB-。在第二轮中,七个行项目全部验证成功,Save Instructions agent 将优化后的提示持久化到向量存储中。此首次运行的端到端时间:3 分 49 秒。

示例:已知文档类型(自动化工作流)

当来自 Two Wheel Store 的第二份采购订单到达时,Matcher agent 找到首次运行中存储的指令,置信度分数为 3.946(阈值:3.7),并将该作业路由到自动化工作流:

  • Extractor agent 直接应用存储的指令,因此编排器跳过提示生成。训练期间学到的 SKU 转换规则会自动应用(EL-002 → AB-EL-002,HB-071 → AB-HB-071,PD-002 → AB-PD-002)。
  • 三个行项目在第一轮中全部验证通过,订单总额为 $5,979.19。
  • 端到端处理在 1 分 30 秒内完成,低于首次运行的 3 分 49 秒。

使用交互式聊天

仪表板包含一个用于故障排除的聊天界面:

  • 询问 what tools do you have 以查看可用的 agent 能力。
  • 询问 list instructions 以查看存储的提取指令。
  • 询问 what is the status of job XXXX 以检查处理进度。
  • 询问 what went wrong with job XXXX, how can we update the instructions? 以诊断失败。

了解准确率如何随时间提升

系统通过两个反馈循环随时间改进:

  • 训练循环:当 Instructions Fixer agent 在验证失败后优化提取提示时,改进后的指令会被保存并复用于相似文档。
  • 处理循环:当 Troubleshooter agent 修复提取错误时,它会提供详细分析,帮助识别文档格式变化中的模式。

更换模型时,请使用 AgentCore Evaluations(Amazon Bedrock AgentCore 的一项能力)来确认提取质量仍然可接受。该解决方案已使用 AgentCore Observability,因此具备所需的插桩能力。

预估成本

您只需为实际用量付费,因为该解决方案运行在无服务器和按需资源上,没有闲置成本。对于每月 10 份训练文档和 1,000 份已处理文档的工作负载(美国东部(弗吉尼亚北部)),预估成本约为每月 58 美元。通过 Amazon Bedrock 进行的基础模型(FM)推理约占总成本的 85%,每份文档约 0.055 美元。实际成本在很大程度上取决于分配给每个代理的模型。模型选择集中在 agents/orchestratorgraph/utils/config.py 中,因此您可以为较简单的任务使用成本较低的模型,并在需要时使用更强大的模型。有关详细定价,请参阅 Amazon Bedrock 定价页面。

为您的用例自定义解决方案

您将获得一个采购订单处理用例,其中包含一个合成的自行车公司数据集、一个预构建的 JSON schema,以及一个验证 Lambda 函数,用于根据模拟 ERP 数据库中的产品和供应商记录检查提取的数据。要处理您自己的文档,您必须将包含的 schema 和验证逻辑替换为您自己的。

定义您的文档 schema

创建一个 JSON schema,定义您要为每种文档类型提取的字段。agents/orchestratorgraph/doc_schema/purchase_order_schema.json 中的示例采购订单 schema 提供了一个参考。您的 schema 应指定字段名称、数据类型,以及每个字段是在文档中明确说明的还是从上下文中推断的。

构建您的验证流程

包含的验证器会根据 Aurora DSQL 中的合成供应商和产品表检查采购订单数据。您的生产实现需要一套根据您的业务规则量身定制的验证流程。例如:

  • 发票验证器可能会根据您的应付账款系统检查供应商 ID,并验证行项目总额与发票总额是否匹配。
  • 合同验证器可能会验证文档是否包含必需条款,以及日期和当事方名称是否与您的记录匹配。
  • 索赔验证器可能会根据您的保单管理系统检查保单编号、承保限额和索赔人信息。

要添加新的验证器,请创建一个 Lambda 函数,该函数接受提取的 JSON 并返回带有详细错误消息的通过/失败结果,然后将其注册为 AgentCore Gateway 中的工具。有关实现模式,请参阅 gateway/tools/po_validator_tool/。

更新代理提示词

agents/orchestratorgraph/prompts/ 中的代理提示词引用了采购订单术语。请更新这些提示词,以反映您的文档类型和提取要求。Orchestrator 代理、Validator 代理和 Instructions 代理各自包含特定于文档类型的语言,您应加以调整。

最佳实践

在训练和运行您的代理式 IDP 系统时,请牢记以下建议。

  • 从具有代表性的样本开始:在训练期间为每种类型上传 5–10 份文档,包括具有格式变体的边缘案例,以构建可靠的提取指令。
  • 使用业务规则验证:将验证器连接到 Aurora DSQL 中的参考数据(供应商列表、产品目录),以便及早发现提取错误。
  • 监控代理性能:使用 AgentCore Observability 和 CloudWatch 跟踪执行路径、识别瓶颈,并随时间衡量提取准确性。
  • 逐步添加文档类型:为每种新文档类型创建一个 JSON schema 和一个相应的验证 Lambda 函数。其余工作由代理处理。
  • 为生产环境添加护栏:应用 Amazon Bedrock Guardrails 对代理输出强制执行内容过滤和接地检查。当您处理敏感文档类型(如保险理赔或贷款申请)时,这一点尤为重要。
  • 查阅 OWASP LLM 十大风险:在构建使用大型语言模型(LLM)的应用程序时,请参阅 OWASP LLM 与生成式 AI 应用十大风险 了解安全注意事项。

清理

重要: 在运行清理之前,请导出您想要保留的数据。destroy.py 脚本会永久删除已处理的文档(S3)、作业历史记录(DynamoDB)、验证数据(Aurora DSQL)以及学习到的提取指令(向量存储)。

为避免持续产生费用,请移除已部署的资源:

uv run destroy.py

在控制台上确认六个 CloudFormation 堆栈已删除:AgenticIDP-Core-Dev、AgenticIDP-Gateway-Dev、AgenticIDP-Aurora-Dev、AgenticIDP-Agent-Dev、AgenticIDP-UIOrchestr-Dev 和 AgenticIDP-ModernUI-Dev。

结论

在本文中,您学习了如何使用 Amazon Bedrock AgentCore 构建一个自我改进的文档处理系统,其中专门的 AI 代理协作对业务文档进行分类、提取、验证和学习。这种代理式方法能够自动适应新的文档格式,并通过反馈循环随着时间的推移提高准确性,以自主学习取代手动模板配置。

后续步骤:

  1. 部署示例解决方案并使用随附的采购订单样本进行测试。
  2. 通过创建 JSON 架构和验证规则来添加您自己的文档类型。
  3. 探索如何将提取的数据与 ERP、CRM 或内容管理工具等下游系统集成。

要了解有关本文所用服务和模式的更多信息,请参阅以下资源:

如需构建文档处理解决方案方面的专家指导,AWS Professional Services 和 AWS 合作伙伴可以为您提供帮助。


关于作者

Erik Cordsen

Erik Cordsen

Erik 是 AWS 的一名解决方案架构师,为佐治亚州的客户提供服务。他热衷于应用云技术和机器学习来解决现实生活中的问题。在不设计云解决方案时,Erik 喜欢旅行、烹饪和骑行。

Vivek Mittal

Vivek Mittal

Vivek 是 Amazon Web Services 的解决方案架构师,帮助组织设计和实施前沿的云解决方案。他对生成式 AI、机器学习和无服务器技术怀有深厚热情,专长于帮助客户利用这些创新推动业务转型。他尤其乐于与客户合作,将他们雄心勃勃的技术愿景变为现实。

Sourabh Jain

Sourabh Jain

Sourabh 是一位高级解决方案架构师,拥有超过 8 年开发云解决方案的经验,帮助全球组织实现更好的业务成果。他专长于设计和实施稳健的云软件解决方案,拥有与全球财富 500 强团队跨不同时区和文化广泛合作的经验。

来源:AWS Machine Learning Blog · aws.amazon.com