GPT-4 有 99.4% 的情况都会出错——于是我们不再让它做决策
快到午夜了,我眼睁睁看着我们的智能体连续第三次把机票订到了错误的城市。
而且每次都不是订到不同的错误城市——是同一个错误城市。德里而非德拉敦。用户清清楚楚地输入了“Dehradun”。LLM 在思维链推理中已正确解析了它。然后,当它生成 API 调用时,却换成了德里的机场代码。信心满满。悄无声息。三次。
我的联合创始人也在通话中。他说:“它知道正确答案。看看推理轨迹。上面明明写着 Dehradun。然后它却做了别的事。”
就是那一夜,我不再相信更好的提示词能拯救我们。
我们一直在开发一个用于旅行预订的 AI 智能体——那种会与 Amadeus、Sabre 这类全球分销系统(Global Distribution Systems)对话的智能体,而这些古老的大型机时代后端系统,支撑着地球上每一笔航空订座。而我们当时做的,和 2023 年其他所有人做的一样:把 GPT-4 包在一层薄薄的编排层里,给它一些工具,然后祈祷。
祈祷并不管用。
那个改变一切的数字
在德拉敦那次事件几周之后,我偶然看到了TravelPlanner 基准测试——这是一项严谨的学术评估,用真实的约束条件来测试 LLM 的多日行程规划能力:预算、交通、餐饮、住宿。这种事情,一个称职的旅行社顾问二十分钟就能搞定。
GPT-4 的总体成功率:0.6%。
不是 60%。不是 6%。是百分之零点六。
我读了三遍。然后我调出方法论部分,想确认他们没有搞错。他们没搞错。当你要求世界上最先进的语言模型去规划一趟既要守住预算、又要把航班、酒店、餐厅串联起来、还不能违反基本时间逻辑的旅行时——它有 99.4% 的概率会失败。
当 GPT-4 被要求在真实世界约束下规划旅行时,它的成功率是 0.6%。而一个解决同样问题的神经符号智能体拿到了 97%。
那个拿到 97% 的系统并没有用更聪明的模型。它用的是一种根本不同的架构——在这种架构里,LLM 把用户请求翻译成结构化数据,然后由一个确定性求解器去做真正的规划。LLM 是翻译官。代码才是大脑。
那个基准测试不只是印证了我们的挫败感。它还给了我们一张蓝图。
你的 AI 智能体为什么总是失败?
有一件事,“AI 智能体”淘金热中没人愿意谈:LLM 不会推理。它们只会预测。
当 GPT-4“决定”调用一个搜索 API 时,它并不是在执行逻辑。它是在根据训练数据中的模式,预测统计上最可能出现的下一个 token。在对话中,这种预测通常已经够好了。但在一个十步的 API 工作流中,每一步都依赖上一步的精确输出?那就是一场灾难。
我开始把这称为概率链问题。假设你的 LLM 每一步都有 90% 的正确率——对于复杂的工具调用来说,这已是慷慨的估计。来算一下:
- 1 步: 90% 成功率
- 5 步: ~59% 成功率
- 10 步: ~34% 成功率
一个订机票的工作流——搜索、筛选、选择、定价、收集乘客信息、创建 PNR、校验、支付、出票——动辄超过十步。在 34% 的理论成功率下,你造的不是软件。你造的是一台老虎机。
而 34% 还只是上限。真实世界的表现更糟,因为我们在生产环境中反复撞上两个现象。
幻觉级联
第一个,我称之为幻觉级联。在链式架构中,第 2 步的输出会成为第 3 步的输入。如果 LLM 在早期犯下一个细微错误——把航班到达时间误读成下午 2:00 而非凌晨 2:00——这个错误不会被捕捉到。它会传播下去。智能体会根据那个被幻觉出的时间,把酒店入住订到错误的日期。GDS API 并不知道智能体的意图,只知道它的输入,因此它会成功处理这个请求。智能体看到一个 200 OK 响应,于是更加坚信自己的错误。
最终你得到的是一条“成功”的执行轨迹,却造成了灾难性的现实后果。智能体以为自己完美搞定了。而客户到了机场才发现根本不是那么回事。
第二个现象是上下文漂移。随着智能体推进一个多步骤计划,上下文窗口被中间数据填满——搜索结果、API 响应、用户消息。模型的注意力机制在所有这些 token 上摊得越来越薄。到第 10 步时,它实际上已经“忘记”了自己在第 2 步正确识别出的预算约束。由 softmax 函数支配的注意力分数,被稀释到太多无关的 token 上。
我在一次给潜在合作伙伴做的演示中亲眼看到了这一幕。智能体在第 3 步找到了一家预算之内的酒店。到第 8 步选餐厅时,它已经完全记不清剩余预算了。它推荐了一家会让用户支出上限超支 40% 的餐厅。那位合作伙伴转过头对我说:“所以它就……忘了?”
是的。它就是会忘。
当 AI 遇上大型机会发生什么?
要真正理解我们为什么需要一种不同的方法,你必须先理解与全球分销系统打交道是种什么体验。
Amadeus、Sabre、Travelport——它们是全球航空旅行的骨干。它们诞生于大型机时代,行事方式也一如那个时代。订一张机票不是一次单独的 API 调用。它是一台有限状态机,带有一套精确的操作序列,不能重新排序、跳过或近似处理。
你先认证,拿到一个会话令牌。这个令牌必须在之后每一个请求头中传递——如果 LLM“忘了”它,或者幻觉出一个新的,整个交易上下文就丢失了。接着你搜索航班,GDS 返回体量庞大的嵌套 JSON 负载——常常超过 50KB——里面包含票价基础代码、行李规则、航段引用。LLM 需要从这个负载中提取一个特定的offerId才能继续。但 LLM 是有损压缩器。它们会做摘要。它们会截断。它们会“热心地”把 GDS 要求精确到字节的数据格式给规范化掉。
一天晚上,我们花了四个小时调试一次预订失败。LLM“纠正”了一个票价基础代码——把一个小写字母改成了大写,因为对一个用英文文本训练出来的模型来说,那样看起来更“正确”。GDS 用一个晦涩的错误拒绝了它:ERR 1209 - SEQUENCE ERROR。没有解释。没有建议。就是一堵墙。
LLM 是有损压缩器。当它们在 API 调用之间传递数据时,会以破坏企业系统所要求的加密完整性的方式进行“自动纠正”和“规范化”。
而当 GDS 返回一个诸如UC(无法确认)这样的错误时,LLM 根本不知道该怎么办。它被训练得乐于助人,于是把这个错误当成一次小故障,然后重试完全相同的请求。一次。又一次。我们眼看着智能体烧掉成千上万的 token、撞上 API 速率限制,卡在我们开始称之为“死亡循环”的状态里——一遍遍地撞向一堵它们无法理解的墙。
我们翻转架构的那一夜
转折点出现在一场争论中。
那时项目已经进行了三个月。我的工程负责人想继续改进提示词——更长的系统消息、更多的示例、思维链指令。“我们已经非常接近了,”他不停地说。“只要我们把 PNR 创建那一步的提示词结构再优化一下……”
我调出了我们的日志。就在上一周,我们在测试环境里有 47 次预订失败。其中 11 次是死亡循环。9 次是幻觉出的机场代码。6 次是 LLM 在添加必填的“Received From”字段之前就试图提交 PNR——这是一种再多提示词似乎也修不好的序列错误,因为除了从训练数据中吸收到的东西之外,这个模型本身对时间先后顺序没有任何内在概念。
“我们并不接近,”我说。“我们已经到了上限。问题出在架构上。”
那一周,我们把一切都重写了。我们不再让 LLM 去做编排。我们不再让它决定下一步该做什么。我们不再把原始的 GDS 响应喂给它,寄望它能提取出正确的字段。
取而代之,我们构建了一张图。
关于我们构建了什么、以及为什么这样构建的完整技术剖析,我写了一篇详尽的研究论文,深入探讨了这套架构。
神经符号 AI 究竟是如何运作的?
核心思想简单得有些出人意料:控制流不是一个语言任务。
在一个严格的业务流程中决定下一步做什么,不应取决于 token 预测。它应取决于条件逻辑。“请求付款”这个决定,只应在“已选定航班”并且“价格已确认”时才触发。那是一个布尔条件,而不是一个概率性的建议。
我们把系统拆成两层:
而LLM成了接口层——翻译官。它把用户的自然语言(“我想要一趟去德拉敦的早班航班,不要太贵”)解析成结构化数据:{origin: "DEL", destination: "DED", date: "2024-03-15", time_preference: "morning", budget: "economy"}。这正是 LLM 真正擅长的:理解人类杂乱的意图。
而图成了执行层——管理者。它接收那些结构化数据,用确定性代码执行业务逻辑。硬编码的节点。带类型的状态模式(state schema)。检查变量而非“感觉”的条件边。
我们用 LangGraph 来构建它,因为它提供了你所需要的基本组件:一个共享的状态模式(由数据库支撑,而不是聊天记录)、只是 Python 函数的节点,以及根据实际变量值来路由的条件边。
LLM 应该是工人——提取数据、总结文本、格式化 JSON——而管理者应该是硬编码的软件。这种控制反转,正是健壮的代理式系统(agentic system)的决定性特征。
在我们的架构里,LLM 是真的无法跳过步骤。系统要在selected_offer_id变量被填充进状态之前就尝试预订,这在物理上是不可能的。这并不是因为我们在提示词里告诉 LLM“别那么做”,而是因为那条图的边根本不会触发。这就像想开车穿墙而过——代码根本不允许。
实际的系统长什么样?
让我带你看看,当有人说“帮我订一张下周二从孟买到伦敦的机票”时会发生什么。
首先,一个Collector 节点——由 LLM 驱动——把那句话解析成结构化字段。它使用引导式生成(JSON 模式)来输出一个特定的模式。一个 Python 校验器检查这些机场代码是否真实存在。“伦敦”是有歧义的——是希思罗还是盖特威克?——于是图路由到一个消歧节点。LLM 不会猜。它会问。
一旦我们有了经过校验的搜索条件,一个Retriever 节点就会调用 Amadeus API。这是纯代码。没有 LLM 参与。响应返回后,被缓存进状态,只有到那时,一个Summarizer 节点——一个 LLM——才会把前五个结果转换成一条人类可读的消息。但它受到严格约束:它只能显示缓存 JSON 中存在的数据。它不能捏造额外权益,也不能更改价格。
用户挑选一个选项。一个Selector 节点把“第二个”解析成具体的offer_id哈希值。一个Gatekeeper 节点检查业务规则——这是否符合公司政策?承运商是否在黑名单上?如果存在违规,图就会挂起。它把自己的状态持久化到数据库,向管理者发送一个审批请求,然后等待。几个小时后,当管理者点击“批准”时,图会重新加载完全相同的状态,并从预订节点恢复。
最后,一个Transactor 节点会按照 GDS 要求的精确顺序,执行 PNR 创建序列——航段、乘客信息、定价、提交。如果 GDS 返回一个价格变动警告(在旅行中很常见),该节点会停下来,请用户确认。它不会自动以更高的价格下单。
每一次节点转移都会被记录。每一个决定都可追溯。审计人员可以阅读执行日志,准确理解为什么系统预订了某一趟特定的航班——不是靠解读一堆乱糟糟的 token,而是靠阅读一条结构化的记录:Node:Gatekeeper | Input: Price=1200 | Rule: Policy_Limit=1000 | Output: REJECT_NEED_APPROVAL。
我把完整的架构,包括那些交互式图表,都写在了白皮书的交互式版本中。
这不就是……普通的软件工程吗?
人们不停地问我这个问题。“所以你是说我们应该写代码,而不是用 AI?真是‘革命性’啊。”
不。我是说,AI 行业太沉醉于语言模型的魔力,以至于忘掉了过去六十年的计算机科学。状态机、带类型的模式、条件分支、事务完整性——这些并不是过时的概念。它们正是你的银行不会不小心把钱汇到错误账户的原因。
神经符号方法并不反 AI。它拥护架构。我们大量使用 LLM——用于意图解析、用于消歧、用于摘要、用于处理那个真正困难的问题——理解一个人究竟意指着什么:当他们输入某种含糊表述时。但当车子行驶在高速公路上时,我们不会让 LLM 去碰方向盘。
你可以造一个只会大谈做事的聊天机器人,也可以架构一个真正做事的智能体。区别就在那张图。
还有一个成本方面的论点让我颇感意外。纯 LLM 智能体很昂贵——不是因为单次推理调用成本高,而是因为那些失败循环。当一个智能体靠幻觉出新参数来反复重试一个 GDS 错误、直到超时,它会烧掉成千上万的 token。单单一次卡死的会话就可能消耗 5 到 10 美元的 API 额度。我们硬编码的错误处理程序以零 token 成本捕捉这些失败。而且,因为我们只把一个 50KB 的 GDS 响应中 5 个相关字段发给 LLM,而不是整个响应,我们把上下文窗口的用量削减了大约 90%。
但模型最终不会变得足够好吗?
也许吧。我真的不知道 GPT-6 或 GPT-7 会不会可靠到足以在没有护栏的情况下编排十步的 API 工作流。但有两件事我是知道的。
第一,即便模型有了戏剧性的提升,那个概率链问题是数学层面的,不是技术层面的。如果你的模型每一步都有 99% 的可靠性——这是了不起的成就——一个十步的工作流仍然有 10% 的概率会失败。对企业级交易来说,这依然无法接受。而图彻底消除了这个问题,因为路由并不是概率性的。
第二,等待模型变得更好,是大多数企业负担不起的奢侈。它们需要的是能够工作的智能体——就现在;需要可审计——就现在;需要符合欧盟《AI 法案》透明度要求——就现在。神经符号方法不押注于未来。它建立在经过验证的工程原则之上,同时使用当今可用的最佳 AI 能力。
架构就是产品
我和投资人以及企业买家同处一室的次数已经足够多,足以知道 AI 行业正开始觉醒。问题正在从“谁拥有最聪明的模型?”转向“谁拥有最健壮的系统?”那些在会议演讲中令人眼花缭乱的演示——那种智能体在受控环境里完美订好一张机票的演示——是廉价的。真正昂贵、也真正重要的,是构建一种在第一万次请求时,能像第一次一样可靠运行的东西。
我们正在进入一个差异化不再取决于模型的时代。它将取决于图。取决于状态模式。取决于错误处理程序。取决于条件边。取决于那种枯燥、严谨、确定性的软件工程——它包裹住那份概率性的魔力,不让它把整栋房子烧塌。
魔力从来都不在提示词里。它一直都在架构中。