AWS发布基于Bedrock Data Automation的无服务器PII脱敏流水线
AWS官方博客展示了一套用自定义blueprint加Step Functions批量并行调用的方案：12 份文档（47 页）测试中，仅靠blueprint提取的精确率 97.0%、召回率 89.3%；叠加标准输出与token匹配后召回率升至 95.2%，精确率降至 96.5%。
AI解读：AWS机器学习博客给出了一套可直接照搬的批量文档脱敏架构：先用Amazon Bedrock Data Automation（BDA）的自定义blueprint声明哪些字段需要脱敏，再由Step Functions加 5 个Lambda函数把检测、打黑框、重组PDF串起来。它解决的不是“能不能识别PII”，而是“一页纸上同时出现患者姓名和医生姓名时，只遮前者”——这种字段级业务逻辑过去要靠OCR加自写ML模型，格式一变就得重训。
真正值得留意的是它承认了自己的短板：单独用blueprint跑，12 份文档、47 页的样本里召回率只有 89.3%，原因集中出现在自由文本段落和手写医生笔记中的重复姓名。AWS的补法是同一次API调用返回两份结果——custom output给出PII字段的边界框，standard output给出每个词的边界框——再用token匹配把漏掉的重复实例补上，召回率提到 95.2%，代价是精确率从 97.0% 掉到 96.5%，也就是多了少量误遮。
对处理医疗理赔、保险单据这类每天上万页扫描件的团队来说，这套架构的参考价值在工程细节：每个PDF页单独发一次BDA调用以控制上下文范围；脱敏是把像素直接涂黑，而非叠一层注释，原文不可从输出文件中还原；文档级失败不阻断其他文档，持续限流则可借Step Functions的redrive从断点续跑。
需要划清边界的是，95.2% 的召回率来自 12 份文档的小样本测试，覆盖六档画质（从清晰打印件到 100 DPI低分辨率扫描），并不等于生产环境的稳定表现；AWS也明确写了一条“设计blueprint依赖反复实验，进一步自动化实验属于未来工作”。另外整个方案没有公布成本对比，是否比人工复核更省，得按自己的文档量算。
AWS在机器学习博客中发布了一套无服务器PII脱敏流水线的构建方案，用Amazon Bedrock Data Automation（BDA）的自定义blueprint定义需要遮蔽的字段，由AWS Step Functions状态机编排五个Lambda函数完成批量处理，作者为Samantha Stuart。
方案针对的是医疗表单、保险理赔、财务记录等每天需要处理数千份扫描件的场景，在这些文档交给第三方或进入下游流程前完成个人信息脱敏。AWS称典型生产负载可以覆盖每晚约 25,000 页的医生诊疗声明（Attending Physician Statement）。
AWS给出的评估结果是：仅用blueprint提取时，12 份文档（47 页）样本上的精确率 97.0%、召回率 89.3%；叠加BDA标准输出和token匹配后，召回率升至 95.2%，精确率降至 96.5%。
为什么需要字段级精度：患者姓名要遮，医生姓名不遮
AWS把脱敏描述为不只是检测问题，也是精度问题：同一页纸上可能出现多个姓名、日期和地址，但只有一部分对当前用例是敏感的。传统做法是OCR加模式匹配或自建ML模型，局限在于文本质量差时失效、难以表达字段级业务逻辑，且文档格式变化时需要ML专业能力重新训练模型。
博客以医生诊疗声明在下游理赔处理前的脱敏为例，列出四项界定问题：什么是敏感信息（患者姓名、出生日期、家庭住址、联系方式）；什么不是（医生姓名、检查日期、诊所地址、诊所联系方式、症状和医疗记录）；分布在页面的什么位置（结构化表单字段、非结构化手写内容、跨文档多处出现）；以及如何移除（拿到边界框坐标，把PDF转成PNG，在后处理阶段按坐标打黑框）。
blueprint在控制台、AWS CLI或开发SDK中创建，控制台提供基于样本文档生成schema的引导选项。最终schema需要枚举可脱敏字段、数据类型、简短的自然语言描述，以及适用的转换规则。
以患者出生日期为例，该字段是日期类型，但文档中并非所有日期都需要脱敏，比如就诊日期和签名日期。blueprint指令会告诉BDA提取哪种日期子类型，把提取范围限制在目标字段上；同样的设计把主治医生的打印姓名和签名排除在脱敏集合之外。出处：AWS Machine Learning博客，作者Samantha Stuart。
- 示例blueprint为医生诊疗声明定义了 9 个字段组、共 37 个字段
- 字段组（field group）用于把相关结果组织到提取结果的同一位置
- 字段使用inferenceType: "explicit" 表示不做转换直接提取，配合自然语言指令限定检测范围
- BDA为每个实例返回字段内容、置信度分数和边界框坐标，供下游后处理使用
两次检测如何做：一次API调用返回custom与standard两份输出
初始测试显示，blueprint在 12 份文档（47 页）样本中至少识别出了每个PII实例一次，但偶尔会漏掉叙述性文本和手写医生笔记中的重复实例。为提高召回率并尽量少损失精确率，AWS引入了第二次检测：使用BDA的标准输出，并通过后处理中的token匹配步骤合并结果。
单次API调用返回两份输出：custom output是blueprint检测到的带边界框的PII字段；standard output是完整提取结果，包含每一个词的边界框。token匹配把每个检测到的PII值规范化为词级token，再扫描该页standard output中的词，把规范化形式与PII token匹配的新词、非重叠匹配加入最终需要脱敏的坐标集合。
由于两次检测共用一次API调用，质量检查增加了覆盖范围，但没有第二次调用带来的延迟。AWS用覆盖六个画质档位的 12 份文档（47 页）做了评估，对照人工脱敏的基准真值。
评估表显示：仅blueprint提取的精确率 97.0%、召回率 89.3%，对显式声明的字段精确率高，但漏掉自由文本叙述块中的PII；blueprint加standard output加匹配逻辑的精确率 96.5%、召回率 95.2%，token匹配补充了叙述文本中重复PII的覆盖，代价是轻微的过度遮蔽。
AWS补充说，把blueprint表现和BDA置信度分数一起评估，可以按用例需要把边界情况路由给人工复核。
- 评估覆盖六档画质：清晰打印件、打印并传真件、打印机质量差的传真件、手写件、手写加打印并重扫件、100 DPI低分辨率扫描件
- 调用方式为invoke_data_automation_async，传inputConfiguration、outputConfiguration、dataAutomationProfileArn、dataAutomationConfiguration（含dataAutomationProjectArn和stage）
- blueprint阶段遮住表单标注字段中的患者姓名，standard output的token匹配则捕获同一姓名在页面下方叙述段落中的出现
- blueprint的定制依赖反复实验结果，进一步自动化实验被列为未来工作
- 最终部署时把目标blueprint的ARN作为输入参数，同一套批处理基础设施可编排并部署到多个脱敏用例
流水线怎么搭：五函数、两层分布式map、像素级涂黑
生产环境中医生诊疗声明的脱敏量可达每晚约 25,000 页，在保持成本效率的同时最大化脱敏并发是重要设计考量。流水线由AWS Step Functions状态机编排五个顺序执行的Lambda函数：Initialize、Preprocessing、Redaction、Reassembly和Reporting。
Step Functions提供两个输入源前缀、输出前缀，以及已通过验证的BDA blueprint ARN。两级嵌套的分布式map处理并行：外层map遍历文档，内层map遍历每份文档中的页。AWS提醒文档级和页级并发设置需要匹配账户对InvokeDataAutomationAsync的服务配额。
各步骤分工：Initialize校验输入、解析blueprint、从Amazon S3列出源文档并写出供文档级分布式map使用的清单；Preprocess把每个PDF转成逐页PNG图片，图片文档作为单页PNG直接通过；Detect and redact把每页图片发给BDA做PII检测，再在检测到的区域坐标上打黑框；Reassemble把脱敏后的页图片合并为每份文档一个脱敏PDF，并生成文档级元数据；Report把文档摘要聚合为任务级报告并执行对账检查。
Redaction函数对每页做四件事：调用BDA、解析结果、脱敏图片、上传S3。BDA返回的边界框是归一化坐标（左、上、宽、高为 0 到 1 之间的小数），函数将其转换为像素坐标，略微扩大每个框以应对偏差，再在区域上绘制实心黑色矩形。
AWS特别说明，这种脱敏直接覆盖图片本身的像素数据，被覆盖的内容不存在于输出文件中；这与基于注释的方式不同——后者在叠加层之下原文仍可恢复。
- 外层map遍历文档、内层map遍历页面，构成两级嵌套并行
- 页面图片逐个发给BDA以把生成式AI请求范围限制在一页上下文内
- BDA处理完整页面以理解版式、字段标签和上下文，不依赖字符级OCR，因而能定位OCR引擎可能难以转写的手写患者姓名，并对输入质量差的边界情况处理更有效
- documents_submitted 12、documents_output 12、documents_failed 0、fully_reconciled true、total_pages 47、total_pii_fields 331、total_pii_blueprint_count 294、total_pii_match_count 37、average_confidence 0.8079、pipeline_duration_seconds 290.7
失败恢复、限流与安全控制
流水线采用分层失败恢复。第一层用Step Functions原生的指数退避重试和抖动处理限流峰值；第二层在暴露损坏输入文档错误的同时允许其他成功文档继续；若中断持续，运维人员可以使用Step Functions的redrive能力，无需重新处理已完成的工作。
隔离策略分两类：文档级失败（如PDF损坏或重组错误），流水线在任务报告中记录失败，其他文档继续处理，输出包含成功执行的脱敏PDF和逐项失败记录；页级失败（如持续限流耗尽重试），恢复依赖Step Functions内置的redrive，运维人员可以先看到哪些页失败再决定是否恢复。
最终任务报告聚合每份文档的明细、耗时数据和对账摘要。当fully_reconciled为true时，每一份提交的文档都产出了脱敏PDF；如果所有文档都失败，执行会以专门的PipelineNoOutput失败结束。
安全方面，流水线沿用所用AWS服务的安全控制：每个Lambda函数有专用的最小权限IAM角色，范围限定在流水线存储桶和所需操作；Amazon S3默认加密以AES-256保护每份文档和Lambda制品，对S3、Step Functions和Amazon Bedrock的访问走TLS；Lambda支持通过基础设施即代码变量部署到VPC，启用后对这些服务的流量通过VPC终端节点而不经过公共互联网；AWS CloudTrail记录流水线中的API活动，可用于支持合规审查。
- AWS列举该方案的适用场景：文档质量差或格式混合、需要字段级业务逻辑（例如遮患者姓名但不遮医生姓名）、需要像素级边界框坐标用于图像脱敏
- 博客称该方案基于其所用AWS服务的安全控制构建
- 若限流失败影响工作流，可使用Step Functions原生redrive能力继续处理