AWS发布合同智能平台架构：双模型验证提取字段，接入Amazon Quick查询
AWS机器学习博客介绍了一套在AWS上运行的合同智能平台：AI代理从合同PDF中提取并交叉验证 8 个关键字段，再由Amazon Quick的仪表盘和自然语言聊天回答组合级与单文档问题。
AI解读：这份方案要解决的不是"读合同"，而是"算合同"。RAG聊天工具按块检索，只能取回最相关的几段文本，无法对 250 份合同做求和、计数和比较，问合同总价值往往得到自信但错误的答案。
AWS的思路是先把非结构化PDF转成结构化数据库，再用数据库做数学：提取代理逐份读取PDF输出字段和置信度，验证代理用另一款模型独立复核，两者在"是否已签署"上分歧时由Amazon Textract用计算机视觉裁决。
对处理大批量合同、采购、合规文档的团队来说，这套架构把原来靠人工逐份翻PDF的活变成可聚合查询的数据，但博客明确说明验证只是 20 份合同的方向性测试，团队仍需拿自己的数据重新评测。
AWS机器学习博客发布了一套在AWS上构建合同智能平台的参考架构，用于把成百上千份供应商合同PDF转成可查询的结构化数据。文章作者Konala McGrath描述的场景是：合同总监面对数百甚至数千份合同，合同金额、到期日、签署状态、关键联系人都锁在PDF里，人工逐份提取并维护表格需要一周以上。
该方案的核心判断是：当问题跨越整个合同组合（总金额、即将到期、最贵协议）时，RAG的top-k语义检索无法胜任，因为系统只会取回最相关的几段文本，无法对全部合同求和或比较。文章称，这不是某款工具的缺陷，而是RAG本身的工作方式决定的。方案转向"结构化提取"：用AI代理把关键字段抽进数据库，再用为聚合而生的分析工具查询，同时保留知识库处理单份合同的精确查找。
提取代理读取PDF，验证代理用另一款模型复核
提取和验证代理基于Strands Agent SDK构建，部署在Amazon Bedrock AgentCore运行时上。文章称AgentCore负责无服务器托管、自动扩缩容和会话隔离，Policy in Amazon Bedrock AgentCore可用基于Cedar的策略在代理代码之外定义并强制执行安全控制，并可在执行前用自动推理验证，确保代理和用户只能访问被授权的合同。
提取代理使用Claude Sonnet系列模型，原生读取完整PDF，无需OCR预处理，输出带每个字段置信度的结构化JSON，共提取 8 个关键字段。验证代理使用更轻量的Claude Haiku模型，独立读取同一份PDF复核。文章指出，两款模型训练不同，能发现重复运行同一模型会漏掉的错误；单一模型可能以高置信度幻觉出一个值，两个独立模型出现分歧则是需要人工复核的信号。
- 提取代理：Claude Sonnet系列，原生读取PDF，输出 8 个字段及各自置信度
- 验证代理：Claude Haiku模型，独立复核同一份PDF
- 安全控制：Policy in Amazon Bedrock AgentCore提供Cedar策略边界
- 文章提示：文中引用的是方案构建时的可用模型，模型选项变化很快，应使用当前可用模型并在依赖结果前重新测试
签名识别分歧交给Amazon Textract裁决
测试中出现了一个具体的失败模式：验证模型有时在合同并不存在签名时，以 95%–100% 置信度标记为"已签署"，与正确读取为未签署的提取代理产生分歧。文章解释，模型误读了空白签名栏，把签名字段（"Signature: __________"）的存在当成了签名的证据。
团队没有接受这个幻觉，也没有写更复杂的提示词绕过，而是加入Amazon Textract的计算机视觉签名检测作为架构级裁决：它用视觉分析而非语言理解来识别页面上真实的手写或数字签名。该服务只在两个模型对is_signed字段有分歧时运行，以控制成本并捕捉误报。文章由此总结：让大语言模型做文档理解、字段提取和上下文理解，让确定性服务处理视觉元素检测、精确计数和数学运算。
20 份合同测试：提取模型比验证模型更影响准确率
团队用 20 份合同的样本数据集手工标注全部 8 个字段（共 160 个值）作为基准，测试多种提取与验证模型组合的匹配程度。结论有两条：提取是影响更大的环节，更强的提取模型即使搭配较轻的验证模型也能维持准确率，而较弱的提取模型无论配什么验证模型都会拉低准确率；能力更强并不总是值得多花钱，在测试数据上最强的模型并没有明显超过一款能力足够、成本更低的验证模型。
文章强调这是针对 20 份合同的小规模方向性测试，不是全面评估，结果会随合同格式和字段复杂度变化，并强烈建议用户用自己构建时可用模型、按自身基准和成功标准重新评测。
Amazon Quick同时接数据库和原文知识库
提取并验证后的数据存入Amazon Aurora PostgreSQL。平台把它接入Amazon Quick，用Amazon Quick Sight能力驱动的仪表盘做结构化查询，用自然语言查询和聊天回答普通语言问题。文章称，这一界面同时覆盖两类问题：通过结构化数据和Topic回答聚合问题，例如"合同总价值是多少"返回"20 份合同共 5000 万美元"；通过知识库回答文档级问题，例如"AnyCompany合同的付款条款是什么"，直接返回源PDF中的原始条款。
仪表盘通过Amazon Quick Sight Embedding SDK直接嵌在React应用内，用户不需要导出或另开BI工具。团队没有把数据缓存进SPICE以避免额外成本，而是直接查询数据，因此仪表盘始终是实时的，合同处理完成的瞬间就会出现在里面。仪表盘包含概览（合同总数、总价值等KPI，已签署与未签署饼图，带筛选的完整提取表）、详情（提取和验证代理双方的置信度，以及逐字段匹配状态）和成本（凸显无服务器架构的服务级成本拆分）等视图。
聊天代理同时连接Topic（结构化数据库查询）和知识库（文档级搜索）。文章给出的示例包括：20 份合同、总价值 5000 万美元；3 份过期、合计 370 万美元；17 份已签、3 份未签；优先处理的 3 份合同是接近到期且未签署的合同，按价值排序。
实时状态、成本与人工兜底
方案加入基于WebSocket的实时状态更新，React前端显示合同进入流水线后的每个处理阶段，把不透明的上传等待变成可见流程。存储合同PDF的Amazon S3桶触发自动处理流水线，流水线在典型条件下可在数秒内处理完一份合同，无服务器架构设计用于并行处理大量合同。
成本方面，按每月 1000 份合同计算，Amazon Quick（1 个企业用户加基础设施费）约 290 美元，Aurora Serverless v2约 44 美元，Amazon Bedrock（Sonnet提取加Haiku验证）约 12 美元，Amazon Textract签名裁决约 2 美元，AWS Lambda、API Gateway、S3和CloudFront合计低于 1 美元，总计约 349 美元/月。文章注明价格基于博客发布之日，并给出AI推理成本为每份合同 0.014 美元（Bedrock加Textract），可变成本随规模线性增长，相对固定的分析许可费用可以忽略。
文章最后给出边界：当两个模型出现确定性服务也无法裁决的分歧时，下一步应把合同转给人工审核，而不是自动解决。该模式也被认为适用于采购、法律合规、保险理赔、HR入职文档和房地产租约等需要组合级查询的大量非结构化文档场景。