# Serverless 文档处理流水线（ADE + Lambda + S3） 把 ADE 提取能力装进 Lambda 容器，由 S3 上传事件触发——上传即处理，不传即沉默，纯 AWS 原生设施。 架构三...

- 来源：Meng Shao
- 发布时间：2026-07-08 09:13
- AIWatch 分数：60
- AIWatch 标记：未精选
- AIWatch 链接：https://aiwatch.icu/events/evt_01kwzpvwxfkp0pwbrxgvh1s174
- 原文链接：https://x.com/shao__meng/status/2074663123739713790

## 精选理由

高信息密度，值得细读

## AI 摘要

本文介绍了一套基于 AWS 原生设施构建的 Serverless 文档处理流水线，核心是将 Amazon Textract（ADE）的文档提取能力封装进 Lambda 容器，由 S3 上传事件触发。架构分为镜像构建、ECR 存储和 Lambda 部署三段，支持 Parse（返回层级 JSON 供 RAG/检索）和 Extract（Pydantic schema 绑定后直接落库）两种模式。关键设计是 Schema Registry，通过字典映射类型名到 Pydantic 类，新增文档类型只需添加一个类和一个字典项，无需重建容器。审计方案将提取值回指产生它的 chunk，元数据与字段同落一份 JSON。对开发者而言，该方案提供了低延迟、可伸缩的文档处理参考，尤其 Schema Registry 设计降低了维护成本。
核心观点：
1. Schema Registry 通过 EXTRACTION_SCHEMAS 字典将类型名映射到 Pydantic 类，新增文档类型只需添加一个类和一个字典项，handler 零改动。
2. 审计方案将每个提取值回指产生它的 chunk，元数据与字段同落一份 JSON，不依赖外部日志拼接。
3. Batch 模式基准测试显示单次调用处理 11 份文档耗时 119 秒（约 10.8 秒/份），15 分钟超时内可处理约 80 份。

## 正文

把 ADE 提取能力装进 Lambda 容器，由 S3 上传事件触发——上传即处理，不传即沉默，纯 AWS 原生设施。

架构三段
· 镜像：lambda/python:3.11 基底 + 依赖 + handler. py + config. py。
· ECR：build 脚本构建 arm64 → 登录 → 建 repo → tag → push。同账号存镜像，IAM 窄、延迟低、生命周期托管。
· Lambda：deploy 脚本建 role → 挂 CloudWatch 写权限 → 创建/更新函数（容器 URI、300s 超时、1024MB、API key 与 bucket 名入环境变量）。
· 配置收敛到单个 .env，冷启动经 config. py 加载。

两模式（payload 切换）
· Parse：返回层级 JSON，喂 RAG/检索。
· Extract：Pydantic schema 绑定解析后的 Markdown，返回校验字段，直接落库。

Batch 一等公民：单次调用处理整 prefix，带进度条与逐文档计时。基准 11 份/119s（10.8s/份），15 分钟超时内约 80 份/调用，更大按 prefix 拆。

两触发方式
· S3 事件：ObjectCreated → handler 取 key → 下载 → 处理 → 结果 JSON 写回输出前缀。覆盖被动到达常态。
· 直接调用：notebook 演示回填/批跑，含统计与 CSV 导出。

Schema Registry——关键伸缩点
EXTRACTION_SCHEMAS 字典：类型名 → Pydantic 类。新增文档类型 = 一个类 + 一条字典项，handler 零改动。对比硬编码要重建容器+全量重部署，registry 把变更降到单文件级。Field(description=...) 作为提取提示传给 ADE——schema 即规格说明。

审计
每个提取值回指产生它的 chunk，元数据与字段同落一份 JSON——审计随数据走，不靠外部日志拼接。CloudWatch 兜底运营侧调试。