Amazon 合同智能平台直面 RAG 的组合盲区

Amazon 发布了一套围绕八个提取字段构建的合同智能架构，为仅依赖 RAG 的聊天系统难以处理的问题打造了 Amazon 合同智能平台。

这套参考设计针对的是企业中一个棘手的问题。聊天机器人通常可以从单份协议中检索出一项付款条款；但当被要求在数百份合同中汇总金额、比较日期或统计未签署文件时，其可靠性就会下降。

Amazon 的答案不是更大的提示词或更长的上下文窗口，而是将文档理解与合同组合分析分离。AI 智能体负责提取和验证字段，数据库负责计算，Amazon Quick 则为用户提供统一入口来处理两类工作流。

这种区分正让仅依赖检索的合同助手面临压力。该系统将检索增强生成（RAG）视为一个组件，而非回答所有问题的数据库。这也为企业智能体应在何处发挥作用、传统数据系统又在哪些环节仍不可或缺，提供了一个有价值的检验案例。

Amazon 实际构建了什么

该设计将每份上传的合同同时转化为可搜索文档和结构化数据库记录。

AWS 于 2026 年 9 月 29 日发布了这套合同智能架构。这是一项参考实现，并非自主法律服务或客户部署的发布公告。

一个 React 应用提供用户界面。合同 PDF 被上传至 Amazon Simple Storage Service 存储桶后，会触发自动化处理管道。

第一个智能体会读取每份 PDF 并提取八个字段。AWS 表示，该实现采用 Anthropic 的 Claude Sonnet 4.6，并为每个字段返回附带置信度评分的结构化 JSON。

第二个智能体会独立读取同一份文档。AWS 称，这一验证器采用 Claude Haiku 4.5，并将其发现与提取器的输出进行比较。

这两个智能体通过 Amazon Bedrock AgentCore 上的开源 Strands Agents SDK 运行。AgentCore 提供托管运行时，用于执行和扩展智能体代码。

出现分歧并不自动意味着验证器获胜。对于签署状态，系统会调用 Amazon Textract 作为视觉裁决工具。经过验证的记录随后被写入 Amazon Aurora PostgreSQL。

原始 PDF 则走另一条路径。它会保留在知识库中，用于针对文档的检索，包括有关付款条款或具体条款的问题。

Amazon Quick 横跨这两类来源。其 Quick Sight 功能可显示基于数据库记录构建的仪表盘；其对话界面则可以将问题路由至结构化分析或文档检索。

这种区分之所以重要，是因为这些来源回答的是不同类型的问题。查找某项条款需要相关文本；计算整个组合的总额则需要覆盖所有适用记录，并进行可靠计算。

该设计还通过 WebSocket 连接将管道状态流式传输至浏览器。用户可以看到文件目前处于提取、验证、检查还是存储阶段。

这种可见性不只是界面上的润色。当用户能够看到是哪个处理阶段造成延迟或分歧时，企业工作流会更容易审查。

AWS 表示，在典型条件下，一份合同可在数秒内通过该处理管道。这仍是一项设计层面的说法，实际性能将取决于文档长度、并发量、模型可用性和区域配置。

此次发布延续了 AWS 在 2026 年 1 月推出的早期合同管理设计。此前的版本强调使用多个专业智能体处理法律、风险、合规和工作流任务。

新架构更聚焦，也更具启发性。它将重点放在提取准确性和合同组合分析上，而这两项能力恰恰暴露了对话式演示经常掩盖的弱点。

为什么 RAG 无法汇总合同组合

RAG 负责筛选相关段落，而合同组合分析需要完整记录和可控计算。

最初的 RAG 研究将语言模型与检索到的外部知识结合起来。这一模式让模型无需将整个来源集合置入提示词中，也能回答问题。

典型系统会将文档切分为多个片段，并为其创建向量表示。当用户提交问题时，语义搜索会检索数量有限、关联度最高的片段。

当答案存在于少数几个段落中时，这种机制运行良好。关于终止条款措辞的问题，可以在无需重新阅读每一页的情况下检索到相关条款。

但当问题覆盖整个集合时，这一机制就会成为负担。设想一位采购负责人询问所有有效协议的承诺总价值。

检索器仍只会挑选看起来最相关的片段，无法保证每一份有效协议都贡献了一项完整、且经过正确标准化的金额。

增加检索片段数量也无法彻底解决问题。合同中包含重复标签、修订、表格、脚注和相互冲突的日期；相关段落数量也可能超过模型可用的上下文容量。

缺失的能力并非对话流畅度，而是覆盖完整性。

AWS 以一个假设的 250 份合同组合说明这一问题。若每份合同有 10 至 20 页，该组合最多可包含 5,000 页内容。

人工最终可以审阅每份文件并维护电子表格，但每新增一份协议或修订案，都可能让电子表格过时。

RAG 助手可以更快给出答案，却仍可能遗漏检索窗口之外的记录。即使计算仅覆盖一个子集，答案听起来也可能十分完整。

这正是 Amazon 合同智能平台背后的核心较量：仅依赖 RAG 的聊天系统，对阵先提取再查询数据库的方式。

在提取方式下，每份合同都会经过同一套模式。金额、日期、交易对手方、签署状态和其他选定字段将转化为行和列。

随后，数据库可以筛选有效记录、按供应商分组并计算总额，也可返回结果背后的记录以供进一步审查。

这种架构并未让 RAG 过时，而是赋予它更契合其优势的职责。

对于难以标准化的问题，文档检索依然很有价值。付款措辞、责任条款、例外情形和特殊义务通常需要结合周边文本理解。

结构化分析则服务于不同层次的问题。它可支持诸如有多少协议已到期、哪些未签署合同金额最高，或哪些续约临近指定日期等问题。

两条路径可以相互补充。结构化查询可识别需要关注的合同，而检索则可找回作为依据的相关条款。

这种划分也带来了更清晰的失效模型。检索错误会影响某个文档答案；提取错误则可能影响仪表盘及基于已存储字段建立的所有汇总结果。

这使得数据摄入管道比聊天界面更具决定性。对话层的可信度，取决于其背后的记录和检索来源。

Amazon 合同智能平台如何改变数据路径

该架构将最困难的工作从提问时转移到数据摄入时。

仅依赖 RAG 的助手会将解释工作推迟到有人提问时进行。Amazon 合同智能平台则在每份文档进入系统时，就对选定的合同字段进行解释。

这一改变创建了可复用的分析层。一旦续约日期被提取、验证并存储，多个仪表盘和问题便可使用同一经过标准化的数值。

第一步是通过 Amazon S3 摄入文档。上传操作会启动处理流程，无需分析师手动打开文件。

AWS 表示，提取智能体随后会原生读取 PDF，生成预期的八个字段，并附加供下游组件审查的置信度评分。

置信度评分是信号，而非保证。它们可以帮助确定审查工作的优先级，但不能证明提取的数值符合条款的法律含义。

独立验证器引入了第二次读取。使用同一模型系列的不同成员，旨在降低重复同一提取过程所产生的相关性错误。

这一思路类似于由两人复核，但这种类比存在局限。同一提供商的两个模型仍可能共享训练模式、盲点和文档处理弱点。

AWS 使用 20 份合同评估了提取器和验证器的组合。团队为每份合同手工标注了八个字段，共产生 160 个真实值。

该评估显示，提取器的重要性高于验证器。作者称，当更强的提取模型搭配较轻量的验证器时，结果依然能够保持。

AWS 还表示，在该数据集上，更强的模型并不总能带来有意义的改进。该公司建议根据各组织自身的合同和验收标准测试可用模型。

这一限定很重要。20 份合同只能构成方向性测试，并不能证明选定组合可泛化至不同行业、语言或起草风格。

完成验证后，数据库便成为回答汇总问题的系统。Amazon Quick 可连接 Aurora PostgreSQL，并查询实时数据，而无需等待单独导出。

Amazon Quick 还会连接保存源文档的知识库。因此，其聊天智能体可在同一界面内支持结构化问题和单份文档查询。

这种路由机制正是 Amazon 合同智能如何运作的架构基础。模型并非在每次对话中都通过阅读合同文本来完成全部计算。

对于汇总请求，结构化来源会提供筛选后的记录和计算结果；对于特定文档请求，知识库则检索相关合同文本。

AWS 展示了基于一个包含 20 份合同的样本组合的示例输出。其中包括合同组合价值、到期合同总额，以及已签署和未签署协议的数量。

这些数字用于说明界面功能，并非来自已披露客户合同组合的运营结果，也不应被视为性能证据。

嵌入式仪表盘提供了审查同一数据的另一种方式。用户无需离开应用，即可查看合同组合总额、签署状态、提取结果和置信度对比。

这一共享基础可减少仪表盘与聊天输出之间的分歧。对于分析性问题，两个界面都可引用同一批经过验证的数据库记录。

该设计也保留了对源材料的访问能力。当合同决策需要阅读具体条款时，分析师不必将数据库数值视为最终结论。

这种混合模式的适用范围不止合同。保险理赔、合规申报、租赁文件和入职记录，都可能同时包含可重复处理的字段与文档特有的语言。

它也符合更广泛的知识融合原则。结构化事实与来源上下文服务于不同目的，而有用的系统需要在两者之间建立受治理的桥梁。

验证比再调用一次模型更重要

该设计中最具启发性的部分，是它拒绝让语言模型裁决每一项争议。

在测试期间，AWS 发现验证器有时会将空白签名栏判定为已签署。在一些误报案例中，报告的置信度达到 95% 至 100%。

模型识别出了与签署相关的文字和版式，随后将签名字段的存在视为有人已经签字的证据。

这一失败暴露了生成式 AI 的一个反复出现的问题：置信度评分可以描述模型内部的确定程度，却无法证明其底层结论正确。

AWS 的应对方式是，仅在两个模型对签名状态存在分歧时才加入 Textract。Textract 通过检查视觉特征来识别手写或数字签名。

这一选择形成了三层控制机制：一个模型负责提取，另一个模型负责核验，而专门的计算机视觉服务则解决一类被明确定义的分歧。

这比让第三个语言模型参与投票更合适。第三个模型可能会重复同样的语义混淆，将签名线误认为实际签名。

这一模式还将专门检查限定在存在争议的案例中。在保留主流程的同时，它会在模型表现出不确定性时采用不同的技术方法。

不过，Textract 只是判断签名是否存在的裁决工具，而不是每个字段的仲裁者。合同金额、续约规则、日期和当事方身份都可能产生不同类型的歧义。

补充协议可能会替换此前的数值。自动续约条款可能需要结合上下文解读。即使存在签名，协议也可能因其他原因而尚未完整生效。

这些情况需要明确的升级处理规则。AWS 的文章称，当确定性服务无法解决未决分歧时，应将其交由人工审核。

这条人工路径是负责任采用的核心。它决定了自动化是在减少日常工作，还是仅仅把不确定的记录隐藏在数据库中。

系统应保留每项提取值、其来源位置、两个模型的输出以及最终处理结果。否则，审核人员无法还原仪表盘为何会包含某个特定数字。

组织还需要针对不同字段设定阈值。错误的联系人姓名与错误的终止日期，带来的运营风险并不相同。

NIST AI framework 强调对 AI 系统进行测试、评估、验证和确认。合同工作流需要在数据字段层面落实这些实践。

团队应按字段衡量精确率、召回率和完全匹配表现，同时跟踪分歧率、审核人员覆盖修改的情况，以及审批后发现的错误。

准确率还应按文档类型细分。原生 PDF、扫描页面、表格、补充协议、手写标注和多语言协议的表现可能各不相同。

AWS 对 20 份合同的评估提供了一种起步方法，但其多样性不足以证明对其他组织合同组合的生产环境可靠性。

一项有价值的试点应抽样那些风险最高的文件，包括非标准模板和低质量文件，而不能只选用来自标准表单的清晰协议。

该设计的双模型验证依然很有价值，因为它让分歧变得可观察。它创造了一个可衡量的事件，可触发确定性检查或人工审核。

但模型之间的一致不能被视为事实依据。两个代理可能产出同一个错误值，尤其是在源文本存在歧义时。

关键控制措施是可追溯性。每一个结构化值都应能让审核人员回溯到产生它的页面、条款和提取决策。

准确性、访问控制与经济性仍未得到验证

这套参考架构提出了可信的机制，但并未证明它已适用于所有合同组合的生产环境。

第一项不确定性是评估规模。AWS 在比较模型组合时使用了 20 份合同和 160 个已标注值。

这一样本可以揭示不同配置之间的明显差异，但无法代表企业协议中全部的格式、起草、扫描、语言和补充协议模式。

第二项不确定性是模式覆盖范围。八个字段可以支撑有用的仪表盘，但合同运营往往依赖更复杂的义务和条件性日期。

续约日期可能取决于通知期限。一个金额可能同时包含承诺费用、按使用量计费、抵扣额度或指数化上调。

将这些条款扁平化为一条记录，可能制造一种确定性的假象。当某字段无法表示为简单数字或日期时，模式必须保留其限定条件。

第三项不确定性涉及模型变更。AWS 指出模型可用性会持续演进，并建议开发者在依赖新选项之前重新测试系统。

即使周边应用保持不变，替换模型也可能改变提取行为。因此，生产团队需要固定的评估集和发布门槛。

第四项不确定性是授权。合同可能包含机密定价、员工信息、安全义务和战略供应商条款。

AWS 表示，AgentCore 支持会话隔离，策略控制可以置于代理代码之外。AgentCore documentation 描述了用户会话的独立执行环境。

然而，基础设施隔离并不会自动形成正确的业务权限。AWS 文档指出，客户端后端必须维护用户与会话标识符之间的关联关系。

开发者还必须在文档、数据库、仪表盘和代理工具层面实施访问控制。聊天界面不应泄露同一用户无法在其他位置打开的记录。

第五项不确定性是运营经济性。AWS 的文章提供了一个成本模型示例，但商业条款会变化，合同组合的工作负载也各不相同。

处理成本取决于页数、模型调用、重试、存储、数据库容量、并发量和用户查询频率。人工审核可能成为最大的变量。

可信的商业论证应衡量每条被接受记录的成本，而不是每次模型调用的成本。若廉价提取造成大量审核工作，它在经济上并不廉价。

竞争格局同样提供了多种实施路径。Microsoft 的合同提取模型可通过 Document Intelligence 从合同中返回结构化字段。

Google 的 Document AI 同样能够将非结构化文档转换为供下游处理使用的结构化数据。

这些产品在模式、自定义、编排、分析和云集成方面各有不同。采购方应比较完整的控制闭环，而非单一的提取基准。

Amazon 在该设计中的差异化优势，在于将代理、验证、关系型数据库、嵌入式分析和文档问答连接起来。

这种集成可能吸引已经在 AWS 上运营的组织，但也可能加深其在存储、模型、数据库、分析和身份控制上的架构绑定。

团队应在投入生产前测试可移植性。提取记录和溯源数据应使用有文档说明的模式，并且在单一对话界面之外仍可访问。

他们还应明确失败责任归属。采购、法务运营、数据工程和安全团队可能都会以为由其他团队负责验证输出。

工作流需要一名对模式变更、评估阈值、异常队列和访问审查负责的明确责任人。没有这种责任归属，系统可能只是将不一致自动化。

更大的教训是，合同智能是一个带有 AI 数据摄取层的数据治理项目。将其视为聊天机器人部署，会低估所需工作。

采购方接下来应关注什么

三个信号将表明，这套架构是会成为合同数据可靠的操作系统，还是仍只是一场有说服力的参考演示。

第一个信号是来自更大、更多样化合同集合的评估证据。采购方需要看到扫描件、补充协议、表格、多种语言和少见起草模式下的字段级结果。

仅公布准确率还不够。有价值的证据应披露数据集构成、错误类别、审核政策，以及两个模型同时同意错误值的频率。

更好的证据将强化 Amazon 的核心主张，即独立验证能够提高可靠性。若持续存在相关性错误，则会削弱双模型设计的论据。

第二个信号是生产级异常处理。平台需要可配置的审核队列、来源引用、审批历史，以及处理未解决分歧的清晰路径。

Amazon Quick 包含人在回路中的能力，但组织必须展示这些控制如何融入日常合同运营。审核人员需要上下文，而不是又一个无法解释的置信度评分。

成熟的工作流应允许人员更正字段、记录原因，并在不丢失原始输出的前提下更新下游分析。

成功的部署还会将低风险自动化与高风险决策区分开来。合同组合计数所能接受的控制措施，与终止通知或财务承诺并不相同。

第三个信号是超越演示工作负载的采用情况。应关注已披露的客户部署案例，看其是否将提取质量与可量化的运营结果联系起来。

相关指标包括审核时间、更正率、过期记录频率，以及无需升级处理的合同占比。这些指标比聊天机器人响应速度更重要。

竞争也将影响采用情况。Microsoft 和 Google 已支持结构化文档提取，而合同生命周期平台则提供面向领域的工作流。

Amazon 必须证明 Quick 和 AgentCore 能减少集成工作，同时不限制模式灵活性或治理能力。竞争对手则必须证明，它们也能提供从文档到已验证合同组合分析的同样连贯路径。

Amazon 合同智能平台最有力的论点在于架构，而非模型的新颖性。它认识到，检索、提取、验证和计算是不同的工作。

这一认识为企业团队提供了一条实用决策准则：使用 RAG 定位和解释源文本段落；使用结构化记录进行计数、排序、比较和汇总。

然后，在错误答案会改变法律或财务决策的地方设置审核控制。任何模型置信度评分都不应自动绕过这一判断。

对于评估合同 AI 的团队，下一步是开展具有代表性的试点。选择困难文件，标注所需字段，定义验收阈值，并衡量审核人员的工作量。

询问每个答案能否追溯至其来源。跨用户、合同、仪表盘和聊天会话测试权限。更正和补充协议后重新计算汇总结果。

最重要的是，将混合架构与它所替代的流程进行比较。它是否以更少的隐性错误和可辩护的审计线索，生成更及时的合同组合数据？

这才是重要的检验。Amazon 合同智能平台的成功，不在于单份合同能否给出令人信服的答案，而在于它是否让整个合同组合能够被可靠地查询。