用 Amazon Bedrock Data Automation 自动化提取金融文档数据。

Blueprint

Blueprint 蓝图，是把金融文档提取变成稳定工作流的配置地图。

BDA 的核心配置单元是蓝图 Blueprint。它不是普通提示词，而是一份定义数据提取方式的配置模板：说明正在处理哪类文档，需要提取哪些字段，字段属于什么类型，如何组织数组或自定义对象，以及输出应该如何进入下游系统。

可以把蓝图理解为一张“提取地图”：它精确告诉 BDA 需要从哪里找什么信息，以什么类型表达，如何把多行表格、多组税务字段和自由文本条款变成结构化结果。BDA 提供内置目录蓝图，也支持自定义蓝图；在金融生产场景里，自定义蓝图尤其重要，因为字段口径和下游流程往往因企业而异。

Four document families

四类文档，分别验证交易明细、税务字段、上下文一致性和合同条款提取。

Scenario 01

银行对账单：核心任务是把跨页交易明细稳定送入会计工作流。

银行对账单记录账户在特定周期内的全部金融活动，包括存款、取款和手续费。它的挑战在于交易记录数量大、经常跨越多页、格式和描述方式因银行而异。对财务团队而言，核心不是“读完整份 PDF”，而是精确捕获每笔交易的日期、金额、描述和参考编号，再输入自动化会计分类或对账流程。

主字段：
- transactions: [TRANSACTION_DETAILS]

TRANSACTION_DETAILS：
  - date（日期）
  - description（描述）
  - debit（借方）: number
  - credit（贷方）: number

提取结果能够以 CSV、JSON 和原始数据格式输出，便于对接下游会计系统。对企业来说，这类场景的收益最直接：减少人工录入错误、缩短对账周期，并把异常交易留给人工重点复核。

Scenario 02

W-2 表格：标准表格不等于简单表格，关键在字段分组和代码配对。

W-2 表格用于报告收入和已预扣税款。它的结构看似标准，但信息维度复杂：联邦税和州税信息在表格上不一定以业务系统需要的方式分组；Box 12 可能包含多个代码，每个代码都对应不同薪酬或福利类型；Box 14 是自由填写项，雇主可以写入不属于其他专属格的信息，必须单独归类，不能污染结构化字段。

主字段：
- employer_info: EmployerInfo
- employee_general_info: EmployeeInfo
- federal_tax_info: FederalTaxInfo
- federal_wage_info: FederalWageInfo
- filing_info: FilingInfo
- state_taxes_table: [StateTaxInfo]
- codes: [CodeAmount]
- nonqualified_plans_income: number
- other

自定义类型：
1. EmployerInfo：ein、雇主名称、地址、邮编、控制编号
2. EmployeeInfo：社安号、姓名、地址、邮编
3. FederalWageInfo：应税工资、社保工资、医保工资、社保小费
4. FederalTaxInfo：联邦所得税、社保税、医保税、分配小费
5. StateTaxInfo：州名、雇主州税 ID、州应税工资、州所得税、地方工资、地方所得税、地方名称
6. CodeAmount：code、amount: number
7. FilingInfo：OMB 编号、验证码

提取结果重点解决三类复杂场景：联邦税和州税信息被正确关联分组；Box 12 的多个代码-金额对被准确配对；Box 14 的自由填写内容被单独归类。这样输出才能进入税务处理，而不是让人工重新拆字段。

Scenario 03

1099-B：真正考验的是跨交易记录的上下文一致性。

IRS 1099-B 用于追踪证券交易活动、经纪商促成的交易以及易货交易。它的复杂性在于，同一证券的多笔交易记录可能使用不同描述方式出现，系统需要在整个文档处理过程中保持上下文一致性，正确识别并关联同一证券的不同交易。

TRANSACTION_DETAILS：
  - security_description（证券描述）
  - quantity_sold（卖出数量）: number
  - date_acquired（取得日期）
  - date_sold_or_disposed（卖出或处置日期）
  - proceeds（所得金额）: number
  - cost_or_other_basis（成本或其他基础）: number
  - gainloss_amount（盈亏金额）: number
  - additional_information（附加信息）

在该场景中，系统需要统一识别同一证券描述符，即使它以不同方式出现在不同交易记录中。这验证的是 BDA 的文档级上下文理解能力，而不是逐行孤立解析能力。对税务和投资运营团队来说，这类一致性直接影响成本基础、盈亏计算和后续申报质量。

Scenario 04

供应商合同：没有标准模板时，自定义蓝图就是业务规则的载体。

供应商合同没有统一行业模板，每家企业都需要根据自身运营工作流和法务审查需求定义字段。这是典型的“无内置蓝图”场景，完全依赖自定义蓝图把非标准文本转换为结构化条款。

主字段：
- PARTICIPANT_DETAILS: PARTICIPANT_DETAILS
- effective_date（生效日期）
- time_period（时间周期）
- participant_requirements: PARTICIPANT_REQUIREMENTS
- confidentiality_obligations（保密义务）
- TERM_AND_TERMINATION: TERM_AND_TERMINATION

自定义类型：
1. PARTICIPANT_DETAILS：参与方名称、授权代表
2. PARTICIPANT_REQUIREMENTS：分配资源、参与方义务、参与方限制
3. TERM_AND_TERMINATION：合同期限、终止条件

提取结果输出为结构化 JSON，可对接合同管理系统或法务审查工作流。对合同场景来说，不能只看字段是否提取出来，还要看低置信度条款、缺失条款、异常终止条件和高风险义务是否能进入人工复核队列。

Blueprint strategy

一份蓝图还是多份蓝图，取决于工作流差异和文档版式差异。

通常情况下，针对特定文档类型创建一份自定义蓝图即可满足提取需求。但如果同类文档服务于不同工作流，或者不同来源文档版式差异显著，就应考虑创建多份蓝图。

蓝图创建完成后，可以作为工作流标准组件复用。对于同一蓝图，如果输入文档包含不同数据字段，BDA 可能返回略有差异的结构化输出。由于输出是 JSON，下游规则可以处理可选字段、缺失字段和低置信度字段；关键是提前定义哪些字段可以为空，哪些字段必须触发人工复核。

Production workflow

生产环境里的文档 AI，必须同时考虑准确性、可解释性、成本和合规。

金融文档处理的终点不是“模型回答正确”，而是“字段进入系统后不会制造新的运营风险”。因此，生产化需要把确定性规则与 AI 提取结合起来：标准格式字段可以用规则和类型约束处理；需要上下文理解的内容，例如合同义务、1099-B 证券描述、自由填写项归类，则交给模型理解，再通过置信度、视觉定位和人工复核闭环控制风险。

1. 01

   文档分类与蓝图匹配

   先判断文档类型，再使用对应自定义 Blueprint，避免用一个泛化提示词处理所有格式。

2. 02

   字段提取与类型约束

   金额、日期、代码、数组和对象都要按业务系统需要输出，而不是只返回自然语言摘要。

3. 03

   置信度与视觉定位复核

   低置信度字段、高金额字段、关键合同条款和税务代码进入人工复核队列。

4. 04

   下游系统集成

   JSON / CSV 输出进入会计、税务、合同管理和风控系统，异常项保留可追溯记录。

Technical context

BDA 的价值，是让文档理解能力成为可配置、可复用、可审计的工作流组件。

在企业项目中，BDA 适合承担“从非结构化/半结构化金融文档到结构化字段”的入口层；后续仍需要结合企业自己的数据治理、权限体系、复核机制和系统集成来完成闭环。