使用 AWS 构建智能文档处理流水线：从概念到生产的旅程

Source: Dev.to

请提供您希望翻译的正文内容，我将为您翻译成简体中文并保留原有的格式、Markdown 语法以及技术术语。

TL;DR – 想跳过故事吗？

Fork the repo, deploy in 10 minutes, start processing documents:

git clone https://github.com/Tetianamost/aws-intelligent-document-processing.git
cd aws-intelligent-document-processing
sam build && sam deploy --guided

一切已准备好投入生产。只需添加你的 AWS 凭证和电子邮件。如果想了解它是如何工作的以及我在构建过程中学到了什么，请继续阅读。

为什么我构建它（以及你可能也需要它的原因）

想象一下：你被发票、收据、税表和合同淹没。你的团队正在手动将 PDF 中的数据输入到电子表格里。耗时数小时，错误频出。听起来熟悉吗？

我使用 AWS 服务构建了一个自动化文档处理系统，该系统能够：

• 自动提取任何文档中的文本、表格和表单数据
• 实时处理文档，一上传即开始
• 存储结构化数据，便于分析或集成
• 在处理完成（或失败）时发送通知
• 轻松扩展，从 10 份文档到 10 000 份文档皆可自如应对

最棒的是？部署后每份文档的成本只有几分钱，且无需任何维护。你也不必从头开始构建——只需 fork、部署并使用即可。

架构：简洁而强大

Document Upload (S3)
    ↓
Automatic Trigger (S3 Event)
    ↓
AI Processing (Lambda + Textract)
    ↓
Structured Storage (DynamoDB)
    ↓
Notification (SNS Email)

魔法在几秒内完成

1. 将文档放入 S3
2. Lambda 自动唤醒
3. Textract 提取所有内容（文本、表格、表单）
4. 数据落入 DynamoDB，结构完美
5. 您收到电子邮件通知

无需管理服务器。无需维护基础设施。纯粹的无服务器优势。

什么让它这么酷？

1. 它真的能理解你的文档

这不仅仅是 OCR。Amazon Textract 使用机器学习来理解文档结构：

• 表格 – 提取行列并保持关系完整
• 表单 – 识别键‑值对（例如 Invoice #: 12345、Date: Dec 23）
• 文本 – 获取每个单词并附带置信度分数

我用一张包含 4 项明细、计算和公司信息的业务发票进行测试。Textract 提取了 155 个文本块，并完美重建了整个表格结构。示例输出：

{
  "fields": {
    "Invoice #": "INV-2024-001234",
    "Date": "December 23, 2024",
    "Total": "$30,922.50"
  },
  "tables": [
    {
      "rows": 8,
      "columns": 4,
      "data": [
        ["Description", "Quantity", "Price", "Total"],
        ["AWS Cloud Setup", "1", "$5,000", "$5,000"],
        ["DevOps Consulting (80 hrs)", "80", "$175/hr", "$14,000"],
        ...
      ]
    }
  ]
}

2. 零基础设施管理

还记得那段时间需要配置服务器、负载均衡器和自动伸缩吗？我也不记得了。使用这种无服务器架构：

• Lambda – 负责计算（仅在需要时运行）
• S3 – 自动触发事件
• DynamoDB – 无限扩展
• CloudWatch – 监控所有内容

我真的部署了它，上传了一份文档，然后就走开了。它就是这么好用。

3. 任意规模下的成本效益

真实案例： 每月处理 1 000 张发票的费用约为 $1.50。就这么简单。

4. 生产就绪的错误处理

事情会出错。网络会卡顿。文档会损坏。我在系统中加入了：

• 死信队列 处理失败的任务
• CloudWatch 警报 监控错误
• SNS 通知 同时发送成功和失败信息
• 带指数退避的自动重试
• 在 DynamoDB 中的状态跟踪

一旦出现问题，你会立刻知道。

挑战（以及我如何解决）

挑战 #1 – CloudFormation 中的循环依赖

我的第一次 SAM 部署失败，报错如下：

Circular dependency between resources: [DocumentBucket, DocumentProcessorFunction, DocumentProcessorFunctionPermission]

问题： S3 存储桶需要 Lambda 权限，Lambda 需要存储桶名称，而权限又需要两者——典型的先有鸡还是先有蛋。

解决方案：

1. 先 部署基础设施，不 包含 S3 事件通知。
2. 之后使用 AWS CLI 添加 S3 通知。
3. 为 Lambda 权限显式添加 DependsOn。

经验教训： 有时必须将 CloudFormation 拆分为多个步骤来打破循环依赖。

挑战 #2 – PDF 格式兼容性噩梦

我使用 Python 的 reportlab 库生成了精美的 PDF。它们看起来完美，但 Textract 把每一个都拒绝：

UnsupportedDocumentException: Request has unsupported document format

甚至官方的 IRS Form 1040 PDF 也失败了！

调查过程：

• Textract 支持 PDF（参考 AWS 文档）✅
• 我的 PDF 在 Preview 中可以正常打开✅
• 文件大小小于 5 MB✅
• 仍然被拒绝❌

突破点： 并非所有 PDF 都一样。Textract 对内部 PDF 结构非常挑剔。reportlab、fpdf 以及某些政府表单生成的 PDF 使用了 Textract 不支持的格式。

解决方案： 先将 PDF 转换为 PNG/JPG 图像。

# 使用 poppler 的 pdftoppm
pdftoppm -png -singlefile document.pdf output

结果

将 PDF 转为图像格式可以规避 PDF 结构问题，让 Textract 正常工作。

挑战 #3 – IAM 权限迷宫

SAM 部署需要大量 AWS 权限：

• CloudFormation – 创建堆栈
• Lambda – 部署函数
• IAM – 创建执行角色
• S3 – 存储制品和文档
• DynamoDB – 创建表
• SNS – 创建主题
• CloudWatch – 创建日志组和告警
• X‑Ray – 进行追踪

最佳实践： 为所有必需的托管策略创建一个 IAM 用户组，然后将部署用户加入该组。这样可以让权限管理更简洁、可复用。

实际结果：它实际提取了什么

测试 1：商务发票

输入： 带公司抬头、收票信息、4 行项目和计算的 PNG 图像

提取：

• 8 对键值（发票号、日期、地址等）
• 完整的 8 × 4 表格，包含所有项目
• 小计、税额和总额计算
• 155 个文本块

处理时间： 大约 2 秒

测试 2：IRS 表格 1040（税表）

输入： 转换为 PNG 的官方 IRS 表格

提取：

• 1,412 个文本块
• 所有表单字段标签
• 表单结构和布局
• 表单上的每一段文字

处理时间： 大约 3 秒

部署：从零到生产仅需 10 分钟

# 1. Build the application
sam build

# 2. Deploy to AWS
sam deploy --stack-name doc-processing-dev \
  --region us-east-1 \
  --capabilities CAPABILITY_IAM \
  --parameter-overrides NotificationEmail=your@email.com \
  --resolve-s3 \
  --no-confirm-changeset

# 3. Configure S3 event notifications
aws s3api put-bucket-notification-configuration \
  --bucket your-bucket-name \
  --notification-configuration file://s3-notification-config.json

# Done!

CloudFormation created:

• 1 S3 bucket → 1 个 S3 存储桶
• 1 Lambda function → 1 个 Lambda 函数
• 1 DynamoDB table → 1 个 DynamoDB 表
• 1 SNS topic with email subscription → 1 个带电子邮件订阅的 SNS 主题
• 2 CloudWatch alarms → 2 个 CloudWatch 警报
• 1 SQS dead‑letter queue → 1 个 SQS 死信队列
• All IAM roles and permissions → 所有 IAM 角色和权限

Total deployment time: 3 minutes → 总部署时间： 3 分钟

我会不同的做法

• 从第一天起就使用 PNG/JPG – 本可以节省数小时的 PDF 调试
• 更早加入异步处理 – 对于多页文档，异步 Textract 任务更好
• 加入费用警报 – 在部署前设置计费告警
• 添加 API Gateway – 通过 HTTP 触发处理变得容易
• 实现文档版本控制 – 跟踪已处理文档的更改

---

底线

构建这个项目让我明白，Serverless 不仅是一个流行词——它真正改变了文档处理工作流。

您将获得

• 自动化文档处理，秒级完成
• AI 驱动的数据提取（不仅仅是 OCR）
• 零服务器管理
• 按使用付费
• 生产级错误处理
• 无限可扩展性

成本

• ≈ 每千份文档 $1.50
• 几小时即可完成设置
• 零持续维护

节省

• 数百小时的手动数据录入
• 无数的转录错误
• 服务器基础设施成本
• DevOps 开销

---

准备好使用了吗？

整个项目 已具备生产环境可用性，并在 GitHub 上开源：
aws‑intelligent‑document‑processing

快速开始

# 1. 克隆仓库
git clone https://github.com/Tetianamost/aws-intelligent-document-processing.git
cd aws-intelligent-document-processing

# 2. 部署到 AWS（约 3 分钟）
sam build
sam deploy --guided

# 3. 上传文档
aws s3 cp your-document.png s3://your-bucket-name/incoming/

# 4. 在 DynamoDB 中查看提取的数据

所有必需的内容都已包含：

• ✅ Lambda 函数代码
• ✅ CloudFormation 模板
• ✅ 示例文档（发票 + 税表）
• ✅ IAM 权限模板
• ✅ 步骤详尽的部署指南

专业提示： 请先使用 PNG 图像，而不是 PDF。相信我，这样更好。

有问题或已经实现类似功能？欢迎留言或联系我！