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

如何用 Amazon Bedrock AgentCore 构建自我改进的智能文档处理系统

Build self-improving document processing using Amazon Bedrock AgentCore

AI 导读

基于 Amazon Bedrock AgentCore 构建的多智能体智能文档处理(IDP)系统,可自动完成业务文档的分类、提取、验证与学习。方案用 Strands Agents 编排 8 个专用 Agent,通过 Amazon Textract 提取文本、S3 Vectors 做向量匹配,新文档类型经训练工作流生成提取指令并保存复用,已知类型则直接走自动化流程。

正文 · 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 Simple Storage Service (Amazon S3) 的一项功能 Amazon S3 Vectors 中的向量相似性搜索类似的文档。
  • 训练工作流(新文档类型):当未找到匹配时,Instructions 智能体生成提取提示词,Extractor 智能体提取结构化数据,Validator 智能体在 Amazon Aurora DSQL 中根据架构和业务规则检查结果。如果验证失败,Instructions Fixer 智能体会优化提示词并重试。成功后,Save Instructions 智能体会持久化保存这些指令以供复用。
  • 自动化工作流(已知文档类型):当找到匹配时,Extractor 智能体使用现有指令。如果验证失败,Troubleshooter 智能体会直接修复提取的数据,而不修改指令。

工作原理

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

图 2:AWS 上的智能体式 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. 您的智能体通过由 AgentCore Identity(Amazon Bedrock AgentCore 的一项功能)和 Amazon Cognito 管理的机器对机器凭证安全地访问 AWS 资源。
  5. 您的 Lambda 函数通过 AgentCore Gateway(Amazon Bedrock AgentCore 的一项功能)的 Model Context Protocol(MCP)接口成为与智能体兼容的工具。
  6. 智能体使用 Amazon Textract 提取文本,使用 S3 Vectors 中的向量嵌入对文档进行分类,并在 Aurora DSQL 中根据业务规则验证数据。
  7. 智能体通过 MCP 服务器访问企业数据,以根据业务规则验证提取的内容。
  8. 您可以通过托管在 Amazon Elastic Container Service(Amazon ECS)上的支持聊天的仪表板监控状态并排查问题。
  9. 您可以通过 AgentCore Observability(Amazon Bedrock AgentCore 的一项功能)和 Amazon CloudWatch 遥测数据了解智能体的性能表现。

部署该解决方案

按照以下步骤将该解决方案的基础设施和 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 界面并选择 Process Document(处理文档)。
  2. 从 infrastructure/sample_data/purchase_orders/training/ 上传一份示例采购订单。
  3. The document enters the agent workflow:
    • Analyzer 智能体提取文本并识别发件人和文档类型。
    • Matcher 智能体在向量存储中搜索类似文档。
    • 对于新的文档类型,训练工作流会生成提取指令、提取数据、进行验证,并保存这些指令以供将来使用。
    • 对于已知的文档类型,自动化工作流使用现有指令提取数据并进行验证。
  4. 在 Review Jobs and Instructions(查看作业和指令)选项卡中查看结果,以验证提取的数据、验证结果和生成的指令。

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

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

Analyzer 智能体使用 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 智能体根据模式生成提取提示词,Extractor 智能体生成结构化的 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 智能体根据模式检查结果并失败:

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 智能体诊断出不匹配之处,并在提取提示词中添加了一条明确的 SKU 转换规则:为供应商 SKU 添加前缀 AB-。第二轮处理中,七个明细项全部验证成功,Save Instructions 智能体将优化后的提示词保存到向量存储中。此次首次运行的端到端耗时:3 分 49 秒。

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

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

  • Extractor 智能体直接应用存储的指令,因此编排器跳过提示词生成。训练期间学习到的 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 以查看可用的智能体功能。
  • 询问 list instructions 以查看存储的提取指令。
  • 询问 what is the status of job XXXX 以检查处理进度。
  • 询问 what went wrong with job XXXX, how can we update the instructions? 以诊断故障。

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

系统通过两个反馈环路不断提升:

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

在更换模型时,请使用 Amazon Bedrock AgentCore 的一项功能 AgentCore Evaluations 来确认提取质量仍保持可接受的水平。该解决方案已使用 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 Top 10 for LLMs and Generative AI Apps 以了解安全注意事项。

清理

重要提示:在运行清理之前,请导出您想保留的数据。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 合作伙伴可以提供帮助。


关于作者

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