用示例文档几分钟内优化 Amazon Bedrock Data Automation 的蓝图提取精度

预计阅读时间：11 分钟

从非结构化文档中提取字段，蓝图（Blueprint）是核心配置——它告诉 BDA 你要抽什么、怎么抽。但写好蓝图指令并不容易：一条模糊的指令可能导致字段漏抽、值偏移、格式混乱。过去要修正这些问题，往往需要反复调整指令文本、跑测试集、人工比对，周期以周计。

Amazon BDA 现在提供了 蓝图指令优化（Blueprint Instruction Optimization） 功能，把这件事压缩到几分钟。你只需要提供 3–10 个标注了期望输出值的示例文档，BDA 自动改写蓝图指令，让提取结果更贴近你的预期。不需要单独微调模型，不需要写额外代码——整个优化流程在 BDA 服务内部完成。

下面拆解这个功能的工作方式、操作路径和选例策略。

优化流程怎么运转

核心逻辑很简单：你给示例 + 期望值，BDA 反推更精准的指令。

具体步骤：

你已有一个蓝图，定义了要提取的字段（比如 invoice_number、total_amount）。
你准备 3–10 份真实文档，每份文档都标注了每个字段的"正确答案"（ground truth）。
把这些示例提交给 BDA 的优化流程。
BDA 内部会用当前蓝图先跑一遍提取，对比提取结果和你的 ground truth，找出偏差点。
根据偏差，BDA 自动改写蓝图中的指令文本——比如把"提取发票号"改成"提取页面顶部标注为 Invoice No. 或 Inv # 的编号，忽略页脚重复出现的同值"。
优化完成，你拿到一份改写后的蓝图，直接用于后续提取任务。

整个过程不需要你手动改指令，也不需要调模型参数。BDA 在服务端完成指令推理和改写。

通过控制台跑一次优化

在 Amazon Bedrock 控制台中的操作路径：

进入 Bedrock Data Automation → Blueprints。
选择你要优化的蓝图，点击 Optimize。
上传 3–10 份示例文档（支持 PDF、图片等 BDA 支持的输入格式）。
为每个示例填写 ground truth——每个字段的期望输出值。可以逐个手动填，也可以批量导入 JSON 格式的标注文件。
点击 Start optimization，等待几分钟。
优化完成后，查看改写后的指令，对比优化前后的提取结果差异。
确认后，将优化后的蓝图应用到你的提取项目中。

控制台适合首次体验和小批量优化。生产环境中的持续优化更适合用 API。

用 API 触发优化：可复制的完整示例

下面是一个用 Python + boto3 调用 BDA 优化 API 的完整流程。假设你已有蓝图和示例文档，ground truth 以 JSON 文件提供。

import boto3
import json
import time
from pathlib import Path

bda_client = boto3.client("bedrock-data-automation", region_name="us-east-1")

BLUEPRINT_ID = "arn:aws:bedrock:us-east-1:123456789012:blueprint/my-invoice-blueprint"
PROJECT_ID   = "arn:aws:bedrock:us-east-1:123456789012:data-automation-project/my-project"

# ---- Step 1: 准备示例文档和 ground truth ----
# 示例文档已上传到 S3，ground truth 存在本地 JSON 文件中
examples = [
    {
        "input_s3_uri": "s3://my-bda-examples/invoice_sample_01.pdf",
        "ground_truth": {
            "invoice_number": "INV-2024-00871",
            "total_amount":   "$1,245.00",
            "vendor_name":    "Acme Supplies Inc.",
            "due_date":       "2024-07-15"
        }
    },
    {
        "input_s3_uri": "s3://my-bda-examples/invoice_sample_02.pdf",
        "ground_truth": {
            "invoice_number": "88042",
            "total_amount":   "3,780.50 USD",
            "vendor_name":    "Global Logistics Co.",
            "due_date":       "August 30, 2024"
        }
    },
    # ... 最少 3 个，最多 10 个示例
]

# ---- Step 2: 创建优化任务 ----
response = bda_client.create_blueprint_optimization_job(
    blueprintIdentifier=BLUEPRINT_ID,
    dataAutomationProjectIdentifier=PROJECT_ID,
    inputConfig={
        "documents": [
            {
                "s3Uri": ex["input_s3_uri"],
                "groundTruth": ex["ground_truth"]
            }
            for ex in examples
        ]
    },
    outputConfig={
        "s3Uri": "s3://my-bda-output/optimized-blueprints/"
    }
)

job_id = response["jobId"]
print(f"优化任务已创建，jobId: {job_id}")

# ---- Step 3: 等待优化完成 ----
while True:
    status_resp = bda_client.get_blueprint_optimization_job(
        blueprintIdentifier=BLUEPRINT_ID,
        jobId=job_id
    )
    status = status_resp["status"]
    print(f"当前状态: {status}")
    if status in ("COMPLETED", "FAILED"):
        break
    time.sleep(30)

if status == "COMPLETED":
    optimized_blueprint = status_resp["optimizedBlueprint"]
    print("优化完成！改写后的指令：")
    print(json.dumps(optimized_blueprint, indent=2, ensure_ascii=False))
else:
    print(f"优化失败，原因: {status_resp.get('failureReason', '未知')}")

运行前需要修改的地方：

BLUEPRINT_ID 和 PROJECT_ID：替换为你自己的 ARN。
input_s3_uri：替换为你示例文档的实际 S3 路径。
ground_truth：每个字段填入你手工标注的正确值，格式要和期望输出一致（包括货币符号、日期格式等细节）。
outputConfig.s3Uri：替换为你存放优化结果的 S3 路径。
确保 IAM 角色有 bedrock-data-automation:* 和相关 S3 读写权限。

选例策略：3–10 个文档怎么挑

优化效果直接取决于你选的示例质量。几个实操原则：

覆盖变异，而非堆叠重复。 如果你的发票号有时是 INV-2024-xxx 格式、有时是纯数字、有时带前缀 PO#，那示例里每种格式至少出现一次。三个格式各一个，比十个同格式文档效果好得多。

ground truth 要精确到格式。 你期望 total_amount 输出带 $ 符号还是不带？日期是 YYYY-MM-DD 还是 Month DD, YYYY？ground truth 里写清楚，优化后的指令才会明确约束格式。模糊的标注产出模糊的指令。

优先选 BDA 当前提取最差的文档。 先用现有蓝图跑一批提取，挑出偏差最大的几份作为优化示例。这比随机选例更高效——优化机制会集中修正这些痛点。

数量不是越多越好。 3–10 是有效区间。少于 3 个，BDA 无法启动优化；超过 10 个，边际收益递减且耗时增加。5–6 个覆盖主要变异的示例通常是最佳平衡点。

避免极端边缘案例。 如果某份文档的字段排版和 99% 的生产文档都不同，把它放进示例可能让优化后的指令过度适配边缘情况，反而拉低整体准确率。边缘案例留在后处理逻辑里处理。

优化前后该做什么验证

拿到优化后的蓝图，不要直接上线。建议走一轮对比验证：

用优化前的蓝图跑一批生产文档（20–50 份），记录每个字段的提取结果。
用优化后的蓝图跑同一批文档，对比结果差异。
重点看三类变化：
之前漏抽、现在能抽到的字段——这是优化带来的正面收益。
之前抽对、现在抽错的字段——过度修正的风险信号。
格式变化——比如金额从 1245 变成 $1,245.00，确认是否符合下游系统的期望格式。

如果优化后整体准确率提升且没有新的错误类型，可以替换蓝图。如果出现新的偏差，考虑调整示例组合重新跑优化，而不是手动改指令——手动改指令容易和优化机制冲突。

什么时候该用、什么时候不该用

适合用的场景：

蓝图刚创建，提取结果和预期差距明显，需要快速校准。
文档格式发生变异（比如新增了一种发票模板），现有蓝图开始漏抽。
多字段蓝图中某些字段一直不稳定，需要针对性修正。

不适合或需要谨慎的场景：

文档极度非结构化、字段位置完全不固定——优化能改善指令措辞，但无法弥补文档本身的无规律性，这类问题更适合加预处理步骤。
只有 1–2 份文档可用作示例——低于 3 个无法启动优化，此时只能手动调指令。
优化后蓝图已稳定运行、准确率满足需求——没必要反复优化，每次优化都有成本。

上线 Checklist

把优化流程纳入日常运维前，确认以下事项：

✅ IAM 权限已配置：BDA 优化 API + 示例文档 S3 读取 + 结果 S3 写入。
✅ 示例文档已上传 S3，ground truth JSON 已逐字段标注且格式与期望输出一致。
✅ 示例数量在 3–10 之间，覆盖了主要格式变异。
✅ 优化前已跑基线提取，有准确率数据可供对比。
✅ 优化后蓝图已通过对比验证，整体准确率提升且无新增错误类型。
✅ 下游系统对字段格式的期望已和 ground truth 标注格式对齐。

蓝图指令优化把"调指令"从手工试错变成了数据驱动的一步操作。关键是选好示例、标好 ground truth、跑好验证——这三步做到位，几分钟就能拿到一份更精准的蓝图。