8900 万美元的 bug:Apple 和高盛在金融 AI 上究竟错在了哪里

去年十月的一个周二傍晚,我正坐在家里的办公室,CFPB 的新闻稿出现在我的信息流里。Apple 和高盛(Goldman Sachs)被勒令支付超过 8900 万美元,原因是他们处理 Apple Card 争议的方式存在系统性失败。我把那份同意令(consent order)读了两遍。然后又读了第三遍,因为我不敢相信自己看到的东西。

核心的失败并不是什么复杂新奇的金融工程出了岔子,也不是某个失控的算法做出了歧视性的信贷决策。问题出在一个按钮。Apple Wallet 应用里的一个二级表单——消费者一旦没有填完,他们的账单争议就会消失进数字的虚空。数以万计的人报告了未经授权的扣款,而系统就这么……把它们吃掉了。没有调查。没有确认。没有解决。账单最后还是消费者自己扛。

我以构建 AI 系统为生。我的公司 Veriprajna 专注于我们所说的深度 AI(deep AI)——一种神经符号架构,把大语言模型的灵活性与形式化验证的数学严谨性结合起来。读那份同意令时,我并没有感到“我早就说过”的快意。我感到的是反胃。因为 Apple Card 上出的每一个问题都是可以预防的。不是靠更好的测试。不是靠更多的工程师。而是靠一种根本不同的思路,去思考面向受监管行业的 AI 系统究竟应该怎么建。

你的 Apple Card 争议究竟发生了什么?

让我带你走一遍这次失败的过程,因为细节比那个登上头条的数字更重要。

Apple 和高盛在 2017 年签署了合作协议。Apple 负责消费者体验——精致的 Wallet 界面、消息系统,整个前端。高盛则是幕后的那家银行,负责授信、处理交易,并在出问题时调查争议。

2020 年 6 月,Apple 对“Report an Issue”(报告问题)流程推送了一次更新。更新之前,你点一笔可疑交易,按下“Report an Issue”,就会被引导到与高盛的一段基于 Messages 的对话。简单直接。更新之后,Apple 加了一个二级表单——消费者在发出初始消息之后本应完成的额外一步。

问题就出在这里:当人们通过 Messages 提交了争议、却没有填完那个二级表单时,系统就把这项争议视为不完整。它从未把投诉传送给高盛。从监管的角度看,这些消息中有许多都构成《诚实信贷法》(Truth in Lending Act,TILA)下有效的账单错误通知(Billing Error Notice)。依法,它们本应在特定时限内触发调查。结果,它们消失了。

数以万计在法律上有效的消费者争议,被一台从未经过形式化验证的状态机吞掉了。

我记得读到这个细节时,想起了我和金融服务高管们的每一次对话——他们告诉我,他们的系统是“久经沙场”的。久经沙场,是对着什么?是对着“一次 UI 改动在分布式工作流中引入了一个死状态”这种具体场景吗?这可不是靠单元测试和 QA 冲刺能抓出来的东西。

那条毁掉一切的 2500 万美元条款

同意令里埋着一个细节,我一次次回到它。Apple 与高盛的合同中有一条约定:高盛每导致 Apple Card 发布延期 90 天,就要支付 2500 万美元的违约金。

两千五百万美元。每个季度。就因为迟到。

我待过那样的房间,商业压力会扭曲工程决策。我见过团队明知东西没准备好还是发了出去,因为延期的代价比失败的代价更具体可感。但我从没见过哪份激励结构被写得这么直白。高盛实际上是为“谨慎”预先挨了罚。

Apple Card 于 2019 年 8 月 20 日上线。高盛内部团队曾就系统的就绪程度提出过担忧。Wallet 应用与高盛后端之间的消息队列测试不足。同步协议很脆弱。但这笔账很简单:现在就发、以后再修,或者先付 2500 万美元、把问题先修好。

他们发了。而在之后一年多的时间里,这套系统带着一个从外部谁也看不见的窟窿在运行。

每当有人问我 Veriprajna 为什么坚持在部署之前做形式化验证,我就会想到这件事。“那不是很慢吗?”他们问。“不能直接在生产环境里做监控、发现问题再说吗?”当然可以。你也可以不装刹车就上路,打算靠打方向盘绕开障碍。这法子一直管用,直到它不管用为止。而在金融服务里,当它不管用的时候,真实的人会受到伤害。

为什么没有人发现这个问题?

这个问题一直缠着我。地球上技术最精深的两家公司——拥有传奇工程文化的 Apple,和拥有强大量化火力的高盛——竟然谁也没注意到数千件争议正掉进一个黑洞?

我认为,答案在架构上。这套系统被设计成一场接力:Apple 管前端,高盛管后端,消息在两者之间流动。但没有人负责那片地带——它夹在两个系统之间。没有人建立过形式化模型,来描述当一项争议进入状态 A(“消息已提交”)却从未到达状态 B(“表单已完成”)时应该发生什么。在一台设计良好的状态机里,那是你会明确处理的一个转移。在 Apple Card 的系统里,它是一个没人写进规格的缺口,所以也就没人监控。

大约一年前的一个深夜——我和团队正在为一位客户搭建合规工作流,我们的一位工程师 Priya 发现了类似的东西。她当时在为一套文档审查流程建模状态转移,结果找到了一条路径:如果第三方 API 超时,一份提交就会无限期地卡在“待数据补全”(pending enrichment)状态。这不是代码里的 bug。代码完全按照指令执行了。问题出在设计上——一个规格说明从未考虑到的状态。

我们之所以能抓到它,是因为我们使用形式化验证工具——具体来说,我们把工作流建模成状态机,再交给 SMT 求解器穷尽地检查每一条可能的路径。求解器几秒钟就找出了 Priya 那个死状态。而在 Apple Card 的系统里,那个死状态在生产环境中跑了好几个月。

Apple Card 的失败不是代码里的 bug。代码完全按照指令执行了。它是设计里的 bug——一个没人写进规格的状态,所以也就没人监控。

为什么不能直接用 GPT 来做这件事?

这个问题我一直被问到。一位投资人在一次路演会上几乎一字不差地这样问我:“你们为什么不能直接拿 TILA 法规去微调 GPT-4,让它来处理争议?”

我吸了口气。然后我反问他:“如果 GPT-4 告诉一位消费者他的争议已经解决,但那项争议其实根本没有传送到银行,谁来承担责任?”

他答不上来。其他任何人也答不上来,因为这个问题暴露了我称之为“超级提示词”(mega-prompt)式做法——即受监管行业中使用 AI 的那种做法——的根本问题。你拿来一个大语言模型,把相关法规塞进它的上下文窗口,然后指望它把一切都处理对。没有治理层。没有形式化验证。没有任何数学上的保证,能确保系统的输出与法律一致。

在 Apple Card 这件事上,失败是一个分布式状态机里的逻辑错误。一层 LLM 套壳不会修好它——反而可能让它更糟。想象一下,一个 LLM 信心十足地告诉消费者“您的争议已提交,正在调查中”,而实际上这项争议从未离开过 Apple 的服务器。这不是假设。这就是幻觉在金融语境中的样子,而它令人恐惧。

那些流行的金融科普网站,以及关于银行业 AI 的广为流传的内容,几乎无一例外地忽略了这个区别。他们谈论 AI 如何“自动化”合规,好像难的部分是读懂法规。难的部分不是读懂它们。难的部分是证明你的系统在每一种可能的场景下都遵守了它们,包括那些你还没想到的场景。

如果想更深入地了解 Apple 与高盛的这次失败如何对应到具体的监管违规与架构缺口,我写了一份交互式分析,逐条梳理了这份同意令。

“可证明正确”究竟意味着什么

当我说 Veriprajna 构建“可证明正确”的合规系统时,我指的不是“测试得非常充分”。我指的是经过数学证明。这两者不同,而且这个差别至关重要。

测试检查的是特定场景。你写一个测试:“如果用户提交了争议并填完了表单,就验证它到达了高盛。”这个测试通过了。很好。但你没有测试过这样的场景:用户提交了争议,却没有填完表单。或者他们填完了,但网络把数据包丢了。又或者两项争议同时到达,其中一项覆盖了另一项。

形式化验证不检查场景。它检查的是性质。你定义一条性质——“每一项已提交的争议最终都必须进入调查状态”——然后由数学求解器穷尽地证明:这条性质在系统的每一次可能执行中都成立。每一条路径。每一个边界情形。每一种竞态条件。只要存在哪怕一个反例,求解器就会找到它,并准确地告诉你系统会怎样失败。

我们使用像 Imandra 这样的工具,它让我们能够构建出本质上是合规逻辑数字孪生的东西。这个孪生体与生产系统并行运行,一旦生产代码试图执行任何偏离已验证模型的动作——比如因为某个 UI 步骤没完成就丢弃一项争议——系统会实时抓住它。

正是这样的方法,本可以在任何一位消费者受到影响之前就抓住 Apple Card 的这个 bug。在设计阶段,一个 SMT 求解器会立刻识别出:“CompletedFormB”这个变量在 TILA 下并不是必填项。传输逻辑要求它,但法律并不要求。这个不匹配是一个可证明的缺陷,它本会在部署之前就被标记出来。

我们真正构建的架构

我想具体说说“深度 AI”合规系统在实践中是什么样子,因为那些关于“AI 驱动的合规”的含糊说辞本身就是问题的一部分。

Veriprajna 采用多智能体架构。我们不是让一个单体式的 AI 试图包揽一切,而是部署职责与边界都有明确定义的专用智能体。与其把它想成雇了一个天才,不如想成组建了一支团队:每个人都有具体的分工,还有一位主管在检查他们的工作。

受理智能体(Intake Agent)负责处理混乱的、属于人的那一部分——解析自然语言表述的争议。当有人写下“我从没在西雅图买过这杯咖啡,那天我人在伦敦”时,该智能体会抽取出关键实体:这笔交易、商户、日期,以及主张的性质。这正是 LLM 真正出彩的地方。

但接下来——这也正是我们与我见过的所有套壳式方案分道扬镳之处——被抽取出的信息会被交给一个符号化策略引擎,它不做预测,也不靠猜测。它依据联邦法律的一阶逻辑编码来评估这项争议。这条消息是否包含足够的信息,足以构成 TILA 下有效的账单错误通知?这个引擎不做估计。它做证明。

工作流智能体(Workflow Agent)强制执行操作的先后顺序。验证智能体(Verification Agent)进行实时的数学检查。审计智能体(Audit Agent)把每一次交互都记录进我们所说的“玻璃盒”——对监管机构完全透明。

而最关键的是,哨兵智能体(Sentinel Agent)专门监测的,正是那种搞垮了 Apple Card 系统的死状态。如果一项争议停留在“已提交但未传送”的状态超过某个设定的阈值,哨兵不会等着某个人去发现。它会自主判断现有信息是否足以继续推进,把信息打包,并通过一条经过验证的通道传送出去。

在一套为绝对合规而建的系统里,决定一项争议是否有效的是法律,而不是 UI。如果一位消费者已经告诉你有一笔未经授权的扣款,那么表单没填完是你的问题,不是他的问题。

为什么时效是一项法律要求,而不是一个性能指标

这里还有一个维度,是大多数技术讨论完全忽略的。在金融合规中,时间就是法律。Regulation Z 不只是说你必须调查争议。它规定你必须在特定期限内予以确认,并在 60 天内解决。高盛被罚款,部分原因就是他们未能在这些时限内发出确认通知。

我的团队花了好几个月开发我们所说的符号化延迟(Symbolic Latency)分析——一种从数学上证明分布式系统在最坏情况下仍能在监管期限内完成工作的方法。不是平均情况。不是“第 95 百分位”。是最坏情况。

传统监控告诉你,你的系统是否曾经很慢。符号化延迟告诉你,你的系统是否可能很慢。如果对 UI 代码的一次改动使最坏情况下的处理时间超出了 60 天的监管窗口,该部署就会被自动拒绝。你不是在事后才发现问题。你是在上线之前就发现。

我记得我们内部争论过这种程度的严谨是否必要。我的一位工程师——一个在某家大型云厂商干了多年的聪明人——强烈反对。“你为了一个可能永远不会发生的场景,给部署周期多加了好几周,”他说。我指了指 Apple Card 的同意令。“它发生了,”我说。“发生在 Apple 身上。发生在高盛身上。发生在数以万计什么错都没犯的消费者身上。”

在那之后,他没有再争。

想了解我们形式化验证方法的完整技术拆解,包括用于延迟边界的 Performal 方法论,请参阅我们的研究论文。

“可这建起来也太久了”

人们总在这一点上反驳我,我也理解为什么。Apple Card 几个月就上线了。而一套经过形式化验证的合规架构,在遗留系统繁重的环境里要花 18 到 36 个月才能完全优化到位。在一个竞争对手每周都在发版的世界里,那感觉漫长得没有尽头。

但让我换个方式来算这笔账。Apple 和高盛花了好几年构建并发布 Apple Card。然后他们又花了好几年处理后果——内部调查、监管检查、法律成本、声誉受损,以及最终 8980 万美元的罚款与消费者赔付。那条“快”的路线并不快。它只是把速度前置,把灾难后置。

我们分阶段的部署方法承认现实。你没法把一家银行的核心系统连根拔掉。那些从 1980 年代就一直在跑的 COBOL 主机不会一夜之间消失。所以我们分层集成:审计现有架构,构建一个智能 API 网关,让 AI 系统以影子模式运行以校验遗留系统的输出,再随着形式化证明的积累逐步移交决策权。

第一阶段——评估与形式化建模——需要 14 到 20 周。到这一阶段结束时,你就拥有了自己合规逻辑的数学模型,它能抓出困扰 Apple Card 的那类死状态 bug。那不是 36 个月。那是不到五个月,就能得到一套从根本上更安全的系统。

那个改变了我对这件事看法的瞬间

有一个具体的瞬间,我一次次回到它。那大约是八个月前,我们正在为一家金融服务客户做概念验证。我们把他们的争议解决工作流建模成了一台分布式状态机,并运行了整套形式化验证。

求解器找到了十一个死状态。

十一条贯穿系统的路径,消费者的投诉可能卡在上面,既得不到解决,也不会触发任何告警。这家客户的工程团队已经运行这套系统三年了。他们处理过数百万笔交易。他们有监控看板、告警系统、季度审计。而这一切都没能抓住这十一个窟窿。

当我把结果给他们看时,整个房间安静了下来。他们的合规负责人——一位在银行监管领域干了二十年的女性——看着屏幕说:“有多少消费者掉进了那些状态里?”

我们不知道。他们也不知道。这就是分布式系统中死状态的特点:如果没人盯着它们,它们就是隐形的。受影响的消费者可能打过客服电话,被踢了皮球,最后放弃了。也可能他们至今还在为并非自己发生的扣款付钱。

从内部看,Apple Card 的失败就是这个样子。不是一场戏剧性的爆炸。而是一种缓慢、无声的伤害累积,在监管者强行撬开那个黑盒子之前,谁也看不见。

未来五年会是什么样

CFPB 对 Apple 和高盛的执法并不是一个孤立事件。它是一场监管清算的开端——针对科技公司如何处理金融基础设施。随着银行业变得越来越“嵌入式”——嵌入手机、嵌入应用、嵌入那些最初根本不是为金融服务而设计的平台——“大多数时候能用”与“可证明始终能用”之间的差距,会变成一笔以数亿美元计的责任。

我常想起我听到最多的那句质疑:“对大多数金融系统来说,形式化验证是不是杀鸡用牛刀?”而随着时间推移,我的回答变得越来越简单。Apple Card 是全世界最引人注目的消费金融产品之一,由两家工程资源近乎无限的公司打造。如果连他们都无法通过传统的测试与监控发现争议工作流中的一个死状态,凭什么认为你的系统会不一样?

整个行业正在走向我所说的绝对合规(Absolute Compliance)——合规不再是打勾走过场的动作,而是一种架构性质。在这样的系统里,对法律的遵守不是你事后去核验的东西,而是你在部署之前就加以证明的东西。在这里,UI 与法规之间的鸿沟,不是靠人的警觉来弥合,而是靠数学上的确定性。

“先发布、后修补”的时代,与全球金融“搬运资金、保护民众”的要求是不相容的。Apple Card 证明了这一点。问题在于,这个行业是在下一笔 8900 万美元罚款之前学会这一课,还是之后。

我们正在 Veriprajna 构建那个未来。不是因为它容易——对分布式金融系统做形式化验证是真的难,谁要是告诉你不难,那他一定是在推销什么。而是因为另一条路的结局,就是我们在 2024 年 10 月看到的那样:世界上最有实力的两家公司,一个坏掉的按钮,以及数以万计的人替自己根本没有过的消费买单。

那不是一个技术问题。那是一个工程伦理问题。而解法不是更好的监控或更快的补丁。解法是构建“构造即正确”的系统——在这样的系统里,数学保证不会有任何一位消费者的争议消失进虚空。

那 8900 万美元的罚款已经付清了。真正的代价是被打破的信任。重建它需要的不只是承诺。它需要的是证明。