使用 Amazon Quick 与 Adjudicated Query 模式批量审查数千份租约的合规性

规模化合规挑战

一个投资组合运营商持有跨多个州的 5 万份租约，各州房东-租客法规（如滞纳金上限、通知期、押金限制）会按立法机构的时间表变化。当法规变化时，合规团队必须确定哪些租约不再合规。

小规模时可由律师人工审阅，答案可信；但超过一定阈值后必须转向软件，随之出现新问题：屏幕上的数字无人能独立验证。

• 可证明的完整性：声称“我们检查了所有 22,910 份德克萨斯州租约”必须真实且可证明，未评估的记录应报告为未评估而非静默省略。
• 可辩护性：数月后可能在诉讼、审计或监管检查中受到质疑，需要知道应用了哪个版本的哪条规则、针对哪段条款文本、用什么方法、在什么日期、由谁执行。
• RAG 解决了可访问性差距，但无法满足上述两个属性；相似性搜索没有能代表“全部”的阈值，排序样本永远不知道排除了什么。
• Text-to-SQL 缩小了差距，但存在类别级风险：幻觉谓词可能静默缩小总体，结果数字看似精确但范围错误。

Adjudicated Query 模式如何解决

该模式是在确定性规则引擎之上的有界对话层。模型只做两件事：将自然语言问题翻译为对固定类型操作的调用，并叙述返回的结果。它从不编写查询、从不固定总体、从不执行判定。

边界之后是规则引擎。规则是版本化数据而非代码，引擎知道通用比较运算符（gte、lte、equals、exists），不包含任何命名司法管辖区或主题的分支。法律变更只是规则手册行编辑，而非代码部署。

每次合规扫描都会生成完整性收据：断言的不变量，其中 compliant + in-breach + ambiguous + unreadable 必须等于 scanned。这在任何持久化之前根据计数计算并断言。无法解释其总体的运行永远不会完成，不存在记录被静默跳过的路径。

对话界面承载计数、收据和带标签的样本。完整结果集（可能数万行）位于读取同一数据存储的仪表板界面，可按记录下钻。这种分离意味着模型永远不会将保证总结掉。

• 模型仅翻译问题并叙述结果，不编写查询、不固定总体、不执行判定。
• 规则是版本化数据，法律变更只需编辑规则手册行。
• 完整性收据确保所有记录被计入，无法解释总体的运行不会完成。
• 对话界面承载计数和收据，完整结果集在仪表板中下钻查看。

为何不用 RAG 或 text-to-SQL

语义检索（RAG）只能提供排序样本，结构上无法保证总体完整性，可辩护性也仅部分满足。生成查询（text-to-SQL）声称可证明但实际无法证明，存在静默缩小风险，可辩护性取决于是否建模。

规则引擎加 BI（无聊天）可精确且可证明，满足完整性和可辩护性。Adjudicated Query 在规则引擎加 BI 方法之上增加了自然语言访问，而不牺牲保证。当责任用户需要对话式访问，且遗漏记录是责任而非轻微不便时，这是正确选择。

• RAG：排序样本，无法保证完整性，可辩护性部分。
• text-to-SQL：声称可证明但无法证明，有静默缩小风险。
• 规则引擎+BI：精确且可证明，满足两个属性。
• Adjudicated Query：在规则引擎+BI 上增加自然语言访问，不牺牲保证。

参考架构

合规官与 Amazon Quick 中的两个界面交互：用于提问的聊天代理和用于浏览完整结果集的 Amazon Quick Sight 仪表板。聊天代理首先从 Amazon Cognito 获取 OAuth 令牌，然后通过 Amazon API Gateway HTTP API 发送 Model Context Protocol (MCP) 请求，API Gateway 验证令牌后转发到 AWS Lambda 函数。

Lambda 函数托管 MCP 服务器和规则引擎，通过 RDS Data API 读写 Amazon Aurora Serverless v2，并仅对探索性条款搜索路径调用 Amazon Bedrock。Amazon Quick Sight 仪表板通过 VPC 连接直接读取同一 Aurora 存储。两个界面因此读取同一存储，使完整性收据成为单一事实来源。

聊天代理承载完整性收据和仪表板链接，仪表板承载大量数据（因为 10,800 行无法在聊天消息中渲染）。Amazon Bedrock 仅由探索性操作从 AWS Lambda 调用，合规扫描不涉及模型，Aurora Serverless v2 也不调用模型。

• 聊天代理通过 Cognito OAuth 和 API Gateway 调用 Lambda 中的 MCP 服务器。
• Lambda 托管 MCP 服务器和规则引擎，读写 Aurora Serverless v2，仅探索性操作调用 Bedrock。
• Quick Sight 仪表板通过 VPC 直接读取同一 Aurora 存储。
• 两个界面读取同一存储，完整性收据为单一事实来源。

有界操作面

MCP 服务器恰好暴露六个工具，每个都有不同的语义：sweep_compliance 对指定日期生效的规则执行穷尽式总体扫描，结果官方，每份租约都在计算的收据中说明，并写入发现；simulate_rule_change 针对批准基线测试一条规则在提议值下的表现，结果探索性，仅提供方向性计数，不记录任何内容；explore_clauses 在过滤后的总体中按语义相似度返回 Top K，结果解释性，是排序样本，无法回答“有多少”；get_finding 获取单个判定的完整证据链，用于下钻；list_rules 返回指定日期生效的规则手册，包含版本、引用、批准者，用于参考查询；check_connection 是活性检查，不接触数据，用于传输健康。

这个有界操作面消除了生成查询的静默缩小风险。因为模型只能从一组固定操作中选择，而这些操作的总体逻辑由人员编写、审查和测试，它无法组合出错误的总体。

• sweep_compliance：穷尽式总体扫描，官方结果，写入发现。
• simulate_rule_change：测试规则变更，探索性，不记录。
• explore_clauses：语义相似度 Top K，解释性，无法回答数量。
• get_finding：单个判定的完整证据链。
• list_rules：指定日期的规则手册及版本引用。
• check_connection：活性检查，不接触数据。

关键架构组件

Amazon Quick 对话界面和代理编排层允许用户提出自然语言合规问题，聊天代理将其翻译为对有界 MCP 操作面的调用。Amazon Quick 通过 Cognito 使用 OAuth 2LO 向 MCP 服务器认证，并处理工具发现和响应叙述。确定性引擎处理合规逻辑。

Amazon Aurora Serverless v2（Postgres + pgvector）在单一关系存储中存储规则手册、租约记录、提取状态、判定和运行。将所有内容放在一个数据库中使完整性收据成为 SQL 计数，这是一种使核心保证可检查的经济高效方式。

AWS Lambda 托管 MCP 服务器（JSON-RPC 2.0 over Streamable HTTP，使用 Server-Sent Events 帧格式响应，这是 Amazon Quick 客户端要求的）和规则引擎。有界操作通过将规则值绑定为参数转换为基于集合的 SQL。自然语言不会到达查询层。Amazon API Gateway HTTP API 提供前门，使用 JSON Web Token 验证。

• Amazon Quick 提供对话界面和代理编排，通过 Cognito OAuth 2LO 认证。
• Aurora Serverless v2 存储所有数据，完整性收据为 SQL 计数。
• Lambda 托管 MCP 服务器和规则引擎，有界操作转为参数化 SQL。
• API Gateway HTTP API 作为前门，验证 JWT。