GPT-4 有 99.4% 的機率會出錯——於是我們不再讓它做決定
已經接近午夜，而我正看著我們的代理連續第三次把一班航班訂到了錯誤的城市。
而且每次還不是不同的錯誤城市——是同一個錯誤城市。是德里（Delhi），而不是德拉敦（Dehradun）。使用者清楚地輸入了「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 呼叫。它是一台有限狀態機，帶有一組精確的操作序列，不能重新排序、不能跳過、也不能近似。
你先驗證身分並取得一個工作階段權杖（session token）。這個權杖必須在後續每一個標頭中傳遞——如果 LLM「忘了」它或幻覺出一個新的，整個交易的情境就會遺失。接著你搜尋航班，GDS 會回傳龐大的巢狀 JSON 負載——通常超過 50KB——其中包含票價基礎代碼（fare basis codes）、行李模型、航段參照。LLM 需要從那個負載中擷取出一個特定的offerId才能繼續。但 LLM 是有損壓縮器。它們會摘要。它們會截斷。它們會「好心地」把 GDS 要求必須精確到位元組的資料格式加以正規化。
有一晚，我們花了四個小時除錯一次訂位失敗。LLM「更正」了一個票價基礎代碼——把一個小寫字母改成了大寫，因為對一個以英文文本訓練出來的模型來說，那看起來更「正確」。GDS 用一個晦澀的錯誤拒絕了它：ERR 1209 - SEQUENCE ERROR。沒有解釋。沒有建議。就只是一堵牆。
LLM 是有損壓縮器。當它們在 API 呼叫之間傳遞資料時，會以破壞企業系統所要求之密碼學完整性的方式「自動更正」和「正規化」。
而當 GDS 回傳一個像UC（Unable to Confirm，無法確認）這樣的錯誤時，LLM 完全不知道該怎麼辦。它被訓練成要樂於助人，所以它把這個錯誤解讀成一次小故障，然後重試一模一樣的請求。一次又一次。我們看著代理燒掉數千個 token 並撞上 API 速率限制，卡在我們開始稱之為「死亡迴圈」的狀態裡——不斷地撞向一堵它們無法理解的牆。
我們翻轉架構的那一晚
轉捩點出現在一場爭論之中。
我們進行這個專案已經三個月了。我的工程主管想繼續改進提示詞——更長的系統訊息、更多範例、思維鏈指令。「我們就快成功了，」他不停地說。「只要我們把 PNR 建立步驟的提示詞結構弄得更好一點……」
我調出我們的日誌。在上一週，我們在測試環境中有 47 次失敗的訂位嘗試。其中 11 次是死亡迴圈。9 次是幻覺出來的機場代碼。6 次是 LLM 試圖在加入必填的「Received From」欄位之前就提交 PNR——這是一種序列錯誤，無論怎麼調整提示詞似乎都無法修正，因為模型除了從訓練資料中吸收到的之外，對時間排序並沒有任何內在的概念。
「我們並不接近，」我說。「我們已經到了上限。問題出在架構。」
那一週，我們把一切都重寫了。我們不再要求 LLM 去做編排。我們不再讓它決定下一步該做什麼。我們不再把原始的 GDS 回應餵給它、然後指望它能擷取出正確的欄位。
取而代之的是，我們建了一張圖（graph）。
關於我們打造了什麼以及為什麼這麼做的完整技術剖析，我寫了一篇詳盡的研究論文，深入探討了這套架構。
神經符號 AI 究竟是如何運作的？
核心概念看似簡單得令人意外：控制流不是一項語言任務。
在一個嚴格的商業流程中決定下一步要做什麼，不應該是 token 預測的問題。它應該是條件邏輯的問題。「要求付款」這個決定，只有在「已選定航班」且「已確認價格」時才應該觸發。這是一個布林條件，而不是一個機率性的建議。
我們把系統拆成了兩層：
而LLM 成為了介面層——翻譯者。它把使用者的自然語言（「我想要一班早上飛往德拉敦的航班，別太貴」）解析成結構化資料：{origin: "DEL", destination: "DED", date: "2024-03-15", time_preference: "morning", budget: "economy"}。這正是 LLM 真正擅長的事：理解雜亂的人類意圖。
而那張圖成為了執行層——管理者。它接收那些結構化資料，並使用決定論式的程式碼執行商業邏輯。寫死的節點。有型別的狀態綱要（state schemas）。檢查變數（而非感覺）的條件邊。
我們用 LangGraph 來打造這套系統，因為它提供了你需要的原語：一個共享的狀態綱要（由資料庫而非聊天記錄支撐）、只是 Python 函式的節點，以及根據實際變數值來路由的條件邊。
LLM 應該是工人——擷取資料、摘要文字、格式化 JSON——而管理者則應該是寫死的軟體。這種控制權的反轉，正是穩健的代理式系統的決定性特徵。
在我們的架構中，LLM 真的無法跳過步驟。系統要在selected_offer_id 變數於狀態中被填入之前就嘗試訂位，這在實體上是不可能的。這不是因為我們在提示詞裡告訴 LLM「別那樣做」，而是因為那條圖的邊根本不會觸發。這就像試圖開車穿牆——程式碼就是不允許。
實際的系統長什麼樣子？
讓我帶你走一遍，當有人說「幫我訂一班下週二從孟買飛倫敦的航班」時會發生什麼事。
首先，一個Collector 節點（收集器節點）——由 LLM 驅動——把那句話解析成結構化欄位。它使用引導式生成（JSON 模式）來輸出一個特定的綱要。一個 Python 驗證器會檢查那些機場代碼是否真實存在。「倫敦」是有歧義的——是希斯洛（Heathrow）還是蓋威克（Gatwick）？——所以圖會路由到一個消歧節點。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 產業正開始覺醒。問題正從「誰擁有最聰明的模型？」轉向「誰擁有最穩健的系統？」那些在研討會演講中令人驚豔的示範——代理在受控環境中完美無瑕地訂下一班航班的那種——是廉價的。真正昂貴、也真正重要的，是打造出在第一萬次請求時，能像第一次一樣可靠運作的東西。
我們正邁入一個時代，在這個時代裡，差異化的關鍵不再是模型。而會是那張圖。是狀態綱要。是那些錯誤處理器。是那些條件邊。是那些枯燥、嚴謹、決定論式的軟體工程，包裹在機率性的魔法周圍，防止它把整棟房子燒掉。
魔法從來不在提示詞裡。它一直都在架構裡。