用 Bedrock+Textract 把抵押文档处理提速15倍

手工处理抵押贷款与产权文件，慢的不是“打字速度”，而是人在一堆不一致的扫描件里找信息：先判断这页是什么文件，再定位关键字段，再把它们抄进系统。Rocket Close 给了一个很现实的数字：他们每天处理约 2,000 份 abstract package（产权/抵押相关“打包文件”），平均 75 页。在高峰期，一份包的端到端提取平均要 10 小时——其中真正人工操作大约 30 分钟，剩下的时间被排队、分配、复核、返工和沟通吃掉。

这件事之所以值得金融科技团队、银行运营团队、以及中小型贷款服务商关注，是因为它揭示了一个常被低估的事实：流程瓶颈往往不在模型，而在工作流。Rocket Close 通过 Amazon Textract（OCR）+ Amazon Bedrock（大模型推理）做了两段式智能文档处理，把人工每包 30 分钟压到 2 分钟以内，整体约 15 倍提速，并在分割、分类、字段抽取上做到约 90% 准确率。

我更想强调的是：这不是“大公司才玩得起”的 AI。只要你的业务存在“重复、规则多、文档杂”的工作（贷款、保理、保险理赔、对公开户、票据、合同审核），你就能把这套方法迁移到自己的自动化工作流里，甚至可以进一步接上AI 语音助手，让一线同事用“说的”而不是“点的”去驱动流程。

抵押/产权文档为什么特别难自动化？

答案很直接：文档类型多、版式乱、证据链长。 abstract package 往往 50–100 页混在一起，里面可能有打字文本、表格、手写批注、盖章、签名、扫描噪点，顺序还不固定。单一 OCR 或单一规则引擎很容易在这里失效。

Rocket Close 需要处理 60+ 文档类别，大致包括：

• 抵押类文件：抵押合同、deed of trust、安全协议等（牵涉贷款金额、利率、期限）
• 产权链文件：warranty deed、quitclaim deed 等（证明所有权转移链条）
• 判决与留置权：judgment、lien notices（影响产权清洁度）
• 税务留置：联邦/州税务留置通知
• 其他法律文件：诉讼、止赎相关材料、继承宣誓书等

对“人工团队”来说，这些文件靠经验能做；对“自动化系统”来说，难点在于：

1. 先分段、再分类：你得知道每一段从哪页到哪页属于同一份文件
2. 按文档类型抽字段：不同文件抽取的字段完全不同
3. 容错与评估：姓名、地址、地块号、州代码、日期格式都有大量变体

这也是为什么 Rocket Close 采用“两段式管线”而不是让大模型直接读 PDF：先把文档结构化，再让大模型做理解与抽取。

Rocket Close 的两段式架构：先 OCR，再让大模型“按规矩办事”

核心思路：把“看清楚”交给 OCR，把“看懂并输出结构化结果”交给大模型。 这套分工清晰，成本和性能也更可控。

第 1 段：Amazon Textract 把 PDF 变成可计算的文档

Textract 负责把扫描 PDF/影像转换成机器可读文本，并尽量保留版式结构（段落层级、表格、表单、签名等）。Rocket Close 把输出进一步整理成 markdown，既方便人读，也方便后续模型处理，并存储到 Amazon S3 等位置，作为后续推理的输入。

这里的关键不是“有没有 OCR”，而是：

• 能否识别表格、表单字段的关系
• 能否在质量不稳定的扫描件上保持鲁棒
• 能否保留足够结构信息，让后续分割/分类更可靠

第 2 段：Amazon Bedrock 负责分割、分类与字段抽取

Bedrock 提供统一 API 调用不同基础模型（文中提到使用 Anthropic Claude），Rocket Close 用它完成两步：

1. 文档分割与分类：基于内容生成“目录/TOC”，把混装的包拆成一份份具体文档，并标注类别
2. 按类别抽字段：对每个类别使用专门的提示词（prompt）与领域知识，输出标准化 JSON，便于对接核心业务系统

这段的重点在于“让模型守规则”。Rocket Close 不是把几百页丢给模型让它自由发挥，而是：

• 给出明确的分类指南与输出格式
• 按类别提供字段定义与示例
• 用领域知识缩小模型的自由度（这会显著提升一致性）

一句好用的判断标准：如果你的输出不能稳定地变成 JSON 并进入下游系统，那它就还停留在“演示级 AI”。

真正拉开差距的三件事：Prompt、领域知识、评估

很多团队做智能文档处理，卡在“模型看起来能用，但上线后到处翻车”。Rocket Close 的经验很有代表性：把工程化三件套做好，比换更大的模型更重要。

1) Prompt 不是文案，是“流程控制”

他们为不同任务设计了专门提示词：分割分类用一套，字段抽取用另一套，并带有示例与严格格式要求。

我自己的观点更激进一点：在金融服务场景，prompt 应该被当作可审计的业务规则来管理（版本号、变更记录、回滚机制），而不是“某个同事调出来的一段文字”。

2) 领域知识要“可注入”，别写死在模型里

Rocket Close 把领域知识做成可组合资源：

• 字段与文档类别的映射（哪些字段应该去哪些文档找）
• 数据字典（字段定义、格式、约束）
• 抵押/产权术语表（缩写、同义词、常见表述）

这类知识动态拼装进 prompt，会比“微调一个模型然后祈祷它记住”更稳，也更符合金融机构的合规习惯（规则可审计、可更新）。

3) 评估体系要贴合金融字段的“真实世界”

他们做了领域感知的评估：不仅是简单准确率，还包含模糊匹配、数值容差、州代码/契据类型/交易类型等专用指标。

这一步经常被省略，但上线后最致命。因为金融业务里，很多字段的错误不是“完全错”，而是：

• 日期格式不一致（03/04/2026 vs 2026-03-04）
• 人名顺序颠倒、包含中间名
• 地址缩写差异（St. vs Street）
• 金额小数点或千分位问题

没有“贴近业务”的评估，你就无法稳定地把准确率从演示的 80% 拉到可运营的 90%+。

结果到底意味着什么？把“人力成本”变成“系统吞吐”

Rocket Close 的公开结果很清晰：

• 速度：人工每包约 30 分钟 → 自动化 2 分钟以内，约 15x
• 准确率：整体约 90%（不同轮次测试约 89.71%–91.28%）
• 规模：设计支持 50 万份/年 的弹性处理

更值得运营负责人关注的是：他们最初的问题是“10 小时/包”。这说明痛点并不只是“录入慢”，而是整个流程的排队与返工。当抽取变成稳定的机器输出，后面的流程会发生连锁变化：

• SLA 更好控制（批量处理、峰值自动扩缩）
• 复核从“全量检查”变为“抽样 + 例外处理”
• 下游系统拿到标准 JSON，减少二次加工

对中小型机构来说，这种改变往往比“省了几个录入员”更重要：你获得的是可增长的运营能力。

把案例迁移到你的业务：一套可复制的自动化路线图

如果你在做金融服务与金融科技（本系列的主题），可以把 Rocket Close 的方法抽象成 6 个步骤，基本适用于贷款、保单、理赔、合同、KYC、对账单等场景。

1) 先选对“高频且格式混乱”的流程

优先选这种：

• 每天/每周量大（否则 ROI 不明显）
• 文档来源多、格式不统一
• 抽取字段明确，且能直接驱动后续动作（入库、核验、风控规则、放款条件检查）

2) 设计两段式管线（OCR → LLM）

别急着“端到端大模型”。先把输入稳定成文本+结构，再让模型做语义理解与抽取。这样你能单独优化 Textract 与 Bedrock 的成本、并发与错误处理。

3) 做一个“字段字典 + 证据定位”标准

字段字典至少包含：字段定义、允许格式、示例、常见异常。再加一个我强烈建议的项：证据定位（字段来自哪页哪段）。这能大幅降低人工复核成本，也更容易通过合规审查。

4) 把“例外处理”写进流程，而不是写进 PRD

90% 准确率意味着 10% 需要处理。成熟做法是：

• 自动抽取 + 置信度/规则校验
• 低置信度进入人工队列（只看证据片段，不看全包）
• 人工改正会回流为评估样本与提示词改进素材

5) 接上自动化工作流，最后再接语音助手

这里和本次活动主题（AI 语音助手与自动化工作流）就真正连上了：

• 文档抽取的 JSON 进入工作流引擎（审批、核验、通知、归档）
• 语音助手用于“触发与查询”：例如“帮我查这笔贷款的 lien 是否清洁”“把缺失文件清单发给经纪人”

我的经验是：语音助手放在最后接入，成功率更高。因为它依赖你已经有结构化数据与可执行动作。

6) 用领域评估指标盯住质量，而不是只看整体准确率

把指标拆开：

• 文档分割准确率（页码边界错了会毁掉后续一切）
• 文档分类准确率
• 字段抽取准确率（按字段类型定义比较方式）
• 例外队列占比与平均处理时长

当这些指标稳定，你就具备把能力扩展到更多流程的底座。

下一步：从 POC 到生产，上线要盯的不是模型，是“可运营性”

Rocket Close 在“下一步”里提到容器化生产部署、反馈闭环、模型版本更新策略，以及扩展到 payoff、purchase agreement、title clearance 等流程。

我赞同这种路线，因为生产系统最怕两件事：

1. 模型升级导致输出漂移：JSON 字段缺失/格式变动会直接打断下游
2. 数据分布变化：新州别、新模板、新扫描质量会让表现下滑

解决办法也很工程化：模型与 prompt 版本管理、回归测试集、灰度发布、以及明确的“降级策略”（比如模型不可用时如何处理）。

金融科技的现实是：能稳定跑 12 个月的系统，比一周内把准确率冲到 95% 更值钱。

你可以从今天就开始做的三件小事

如果你是小团队、预算有限，但想在 2026 年把 AI 自动化真正落地，我建议从这三件事起步：

1. 把一个流程的字段字典写清楚（含格式、示例、证据来源）
2. 做 50–100 份带 ground truth 的样本集（以后所有改进都靠它回归）
3. 先跑通“抽取 JSON → 进入工作流 → 例外队列”（这条链跑通了，语音助手只是锦上添花）

Rocket Close 的案例提醒我们：生成式 AI 在金融服务里最实际的价值，不是“回答问题”，而是把大量重复劳动变成可规模化的自动化工作流。

如果你的团队也被合同、票据、抵押/产权、理赔材料拖慢节奏，你更想先自动化哪一段——“分割分类”，还是“字段抽取 + 例外处理”？