租约合规检查做到 22,910 份全量覆盖还能自证，靠的是让 AI 只翻译问题不碰结论

合规团队最头疼的事，不是读不完租约，而是读完以后拿不出证据。50,000 份租约分散在多个州，每个州的房东-租客法（滞纳金上限、通知期限、押金限额）按立法机关的节奏改，不按运营商的节奏改。法规一变，就要找出哪些租约现在不合规了。量小的时候，法务助理一份份读，答案有人背书，可信。过了某个规模阈值，活儿交给软件，新问题就来了：屏幕上那个数字，没人能独立验证。
这个问题的本质不是检索，是两件事：可证明的完整性和可辩护性。

• 可证明的完整性： "我们检查了全部 22,910 份德州租约"这种说法，必须是真的，而且得能当场证明。任何一条没被评估过的记录，要明确报告为"未评估"，而不是悄悄漏掉。
• 可辩护性： 几个月后，某个结论可能在诉讼、审计或监管检查里被翻出来。要辩护，就得说清楚当时用的是哪个版本的哪条规则、套的是哪段条款原文、用什么方法、在哪天、由谁做的。

这两点把问题和企业搜索彻底区分开了。RAG 解决的是"能不能找到"的差距，但满足不了这两个性质。相似度搜索没有"全部"这个阈值——它返回的是一个排序后的样本，永远不会告诉你它排除了什么。Text-to-SQL 缩小了一点差距，但带着类别级的风险：一个幻觉出来的谓词可能悄悄缩小统计范围，数字看起来精确，范围实际是错的。

这个模式怎么绕开 AI 的"差不多"

Adjudicated Query 模式的做法，是把对话层和确定性规则引擎隔开，中间画一条硬边界。模型只干两件事：把自然语言问题翻译成对一组固定类型化操作的调用，然后把返回结果用自然语言复述出来。它不写查询、不定范围、不做判定。
边界后面是规则引擎。规则是版本化的数据，不是代码。引擎只知道通用比较运算符（gte、lte、equals、exists），里面没有任何一个分支写着具体州名或具体话题。法律改一条，就是改规则簿里的一行，不是重新部署一次代码。
每次合规扫描都会产出一张完整性收据：一个断言不变量，合规 + 违规 + 模糊 + 不可读 = 已扫描。这个等式用计数算出来，在任何数据落库之前就断言。跑一次扫描如果对不上总体数量，这次运行就永远不会结束。不存在一条记录被静默跳过的路径。
对话界面上显示计数、收据和标签，但判定本身不在那儿。

这套参考架构实际怎么落地

AWS 参考架构把整个流程拆成了可部署的组件，从自然语言问题到最终收据，每一步都有明确归属：

1. Amazon Quick 聊天界面：业务用户在这里用自然语言提问，比如"哪些德州租约的滞纳金超过法定上限"。模型在这里做翻译和复述。
2. 类型化操作层：把问题映射到固定操作集上，比如"过滤"、"计数"、"分组"。模型不生成自由 SQL，只选操作和参数。
3. 确定性规则引擎：执行实际判定。规则是版本化数据，比较运算符是固定的，不涉及任何州名或主题分支。
4. 完整性收据生成：每次扫描结束，计算不变量并断言。对不上就不算完成。
5. 审计追踪：每次判定都记录规则版本、条款文本、方法、日期和执行人——这是可辩护性的物理基础。

这套架构的关键判断是：把"语义理解"和"逻辑判定"彻底分开。语义理解可以模糊，可以用概率模型；逻辑判定必须确定，必须可复现。AI 的幻觉风险被限制在翻译这一步——翻译错了顶多是问题理解偏了，不会导致统计范围静默变化。

直接跑起来要留意什么

参考架构是能端到端跑的示例。实际部署时有两个容易踩的坑：
坑一：别让模型碰范围。 如果模型能自己决定"查哪些租约"，就回到了 Text-to-SQL 的老路。正确的做法是模型只负责把问题翻译成操作和参数，范围的确定完全由规则引擎接管。这样模型输出错，最多是参数错，不会出现"看起来查了全部，实际只查了一部分"的假象。
坑二：收据必须是硬约束，不是日志。 完整性收据不是事后记录，是运行时的断言。等式对不上，运行就要失败。这不是可选的，是架构的一部分。没有这个约束，就又回到了"数字在屏幕上没人能验证"的老问题。

这个模式能往哪儿搬

租约合规只是例子。作者明确点了另外几个高风险的合规场景：制裁筛查、保险理赔判定、出口管制。这些场景的共同特征是：判定标准会变、判定结果可能被挑战、必须能证明覆盖面是完整的。
底线很清楚：AI 负责把人的问题翻译成机器能执行的操作，机器负责执行确定的判定，两者之间的边界不能模糊。 想让 AI 做"全部检查"这件事，就得接受它只做翻译和复述，把"对不对"的最终决定权留在规则引擎手里。