你的 AI 旅遊助理正在騙你——直到你被困在異鄉，才會發現
去年有一位女士寄了一張截圖給我們。她用一款熱門的 AI 旅遊規劃工具，為家人安排了一趟哥斯大黎加之旅。那個 AI 推薦了一個地方，名字大概叫「Tabacon Springs Eco-Lodge」——描述得綠意盎然、一晚不到 200 美元、照片看起來也對得上。她替四個人訂了機票，租了車，還告訴孩子們他們要去樹屋上看猴子。
那間旅館根本不存在。
不是「它關門了」或「它在整修中」，而是它字面意義上根本不存在。這個 AI 把兩、三間真實的哥斯大黎加度假村的細節混在一起——用其中一間的名字、另一間的設施、再加上路邊某家青年旅館的價位——拼湊成一個描述得美輪美奐、卻從未被蓋出來的房產。那個訂房連結導向一個通用付款頁面，刷了她的卡，卻什麼都沒交付。
讀到那封信時，我感受到的不是意外，而是似曾相識。因為我在 Veriprajna 的團隊，已經花了好幾個月盯著這種一模一樣的失效模式，把它拆解開來，從架構層面理解它為什麼會發生。而答案既簡單，又讓任何在旅遊領域打造 AI 產品的人深感不安：業界最熱門的那些 AI 系統，被最佳化的目標是「聽起來對」，而不是「真的對」。在一個寫詩產生器裡，這個差別很微妙。但在旅遊物流中，它就是「一趟假期」和「一場災難」之間的差別。
為什麼你的 AI 會憑空捏造出不存在的飯店？
以下是大多數人不了解的、關於大型語言模型的事——GPT-4、Claude、Gemini，全都一樣。它們並不像資料庫那樣「知道」事情。飯店訂房系統知道 JW 萬豪酒店的 412 號房從 3 月 3 日到 3 月 7 日已被預訂。那是一個事實，存在某一列裡，可供查詢。
LLM 的運作方式並非如此。它是根據訓練資料中的統計模式，來預測序列中的下一個字。當你向它詢問「哥斯大黎加、每晚 200 美元以下的豪華生態旅館」時，它會啟動一堆聯想的叢集——「哥斯大黎加」會帶出「綠意盎然」、「雨林」、「生態旅館」。它開始產生統計上很可能接在這些字後面的文字。而當它需要替這個房產取名時呢？它就開始混合。它從自己看過的數千則評論中擷取片段，然後合成出某個聽起來合情合理的東西。
在創意寫作中，這種混合叫做想像力。在旅遊中，它叫做幻覺。而模型完全無從分辨兩者的差異。
模型最佳化的目標是連貫性，而不是正確性。它被設計來產生一個「看起來像有效答案」的回應，而不是一個「經過即時庫存驗證、真正有效」的答案。
讓情況更糟的，是這些模型的訓練方式。在基於人類回饋的強化學習（RLHF）過程中，人類評分者一貫地偏好那些內容全面、語氣自信的答案，而不是說「我不知道」的答案。於是模型在很深的層次學到：自信地猜測會得到獎勵，坦承無知則會受到懲罰。一個會胡亂猜測空房狀況的真人旅遊業務員會被開除；而一個猜測空房狀況的 AI，卻因為它的「流暢」而受到讚賞——直到顧客降落在異國他鄉、卻無處可睡為止。
我意識到「流暢正是問題所在」的那一夜
有一個時刻我一再回想。當時我們正在測試一個早期原型——不是我們推出的產品，而是一個內部實驗，用來了解 LLM 如何處理旅遊查詢。我請它幫我找一間紐約時裝週期間、中央公園附近、每晚 250 美元以下的飯店。
它回傳了三個選項。詳盡的描述、價格、設施。其中一個甚至提到有個可以眺望公園景色的頂樓酒吧。那個語言如此精緻、如此具體，以至於我的第一直覺就是點下「訂房」。
接著我的一位工程師——一個比較安靜、非常有條理的人——拿同一則查詢去跑 Amadeus 飯店搜尋 API。三間飯店裡有兩間確實存在，但在時裝週期間沒有空房。第三間飯店的名字很接近一間真實的房產，卻對不上系統中任何一個飯店 ID。至於那個頂樓酒吧？它其實屬於六個街區外一間完全不同的飯店。
就在那一夜，我明白了：危險的不是那種會明顯失敗的 AI。一個說「我聽不懂你的問題」的聊天機器人固然令人惱火，卻無害。真正危險的，是那種完全聽懂你的問題、卻用雄辯滔滔、極具說服力、事實上卻是錯的資訊來回應的 AI。我們開始把這稱為可靠度上的「恐怖谷」——系統的語言智慧太高，以至於使用者放下了對事實查證的戒心。
加拿大航空的聊天機器人案，讓這件事在法律層面上變得具體。一個聊天機器人捏造了一項退款政策。法院判定該航空公司須負責——而不是 AI 供應商，也不是把聊天機器人當成「測試版工具」來卸責。部署這個代理的公司，要為該代理的種種聲明負責。如果你的 AI 承諾一間 200 美元的海景套房，而 GDS 裡只有一間 400 美元的標準房，你可能就得為這中間的差額負責。更糟的是，得為毀掉的整趟行程負責。
當你把 LLM 當成「大腦」而不是「嘴巴」時，會發生什麼事？
那個測試之夜過後，我的團隊爭論了很久。就是那種大家在白板上塗塗畫畫、你一言我一語搶著說話的爭論。問題很簡單：我們是要設法讓 LLM 更準確，還是要徹底改變整個架構？
一派人想要更好的提示詞、更多護欄、檢索增強生成（RAG）；把模型用旅遊資料做微調。另一派人——也就是我最後加入的那一派——則主張問題不在於模型的知識，而在於模型的角色。我們是在要求一個文字產生器去做庫存管理員的工作。這就像要求一位小說家去經營一家航空公司。他能把飛行的體驗描寫得美不勝收，卻沒辦法告訴你早上 8 點飛往希斯洛的班機上還有沒有座位。
於是我們做了一個決定，它改變了我們之後所打造的一切：LLM 永遠不會是旅遊資訊的來源，它會是意圖的路由器。
使用者說「幫我找一間中央公園附近的飯店」。LLM 的工作是理解這個意圖，把它拆解成結構化參數——地點、日期範圍、預算、偏好——再把這些參數交給一個會去查詢真實庫存的工具。工具會帶著實際資料回來。LLM 的第二項工作，是用自然語言呈現那些資料。但它從不產生資料，它只是翻譯資料。
我們不再打造「談論」旅遊的 AI。我們開始打造「執行」旅遊的 AI——它查詢真實系統、解讀真實的狀態碼、且只確認它能夠驗證的事情。
這就是業界所謂從「LLM 包裝器」轉向代理型 AI 系統的轉變。而這個差異並非漸進式的，它是物種上的改變。我在我們研究的互動版本中深入探討了這個架構。
協調器—工作者模式：為什麼單一代理還不夠
一開始，我們試著讓所有事情都透過單一代理來處理。同一個提示詞要應付機票、飯店、租車、飲食限制、企業差旅政策。它在自身的重量下崩潰了。上下文視窗被塞滿，指令彼此衝突。這個代理會在還沒確認航班日期之前就先訂了飯店，然後又不得不把一切重新拆掉重來。
於是我們打造了我們所稱的協調器—工作者模式。你可以把它想成一位從不親自碰鍵盤的資深旅遊顧問，他管理著一支專家團隊，而每位專家都把某一件事做到極致。
協調器是一個高推理能力的模型——GPT-4o 或 Claude 3.5 Sonnet——它負責與使用者對話、維護對話歷史，並決定接下來需要發生什麼。它不會直接碰 GDS。在它之下是各個專門的工作者：一個會講 Amadeus 航空 API、懂 IATA 代碼的航班工作者；一個會講 Sabre 的住宿內容服務（Content Services for Lodging）、分得清「訂金」和「擔保」差別的飯店工作者；還有一個會在任何內容被呈現之前先檢查企業差旅規則的政策工作者。
當使用者說「幫我訂下週二飛紐約的班機，還有一間中央公園附近的飯店」時，協調器會把它拆解成兩項任務，判斷出飯店搜尋取決於航班的抵達時間，於是先啟動航班工作者，再帶著正確的日期啟動飯店工作者。如果飯店工作者失敗了，協調器仍會呈現航班選項，並詢問使用者是否想以不同的飯店條件重試。沒有任何東西當機，也沒有任何東西產生幻覺。
關鍵洞見在於把思考與執行分開。協調器負責思考，工作者負責執行。而兩者都不假裝自己是對方。
為什麼「200 OK」差點騙了我們
這裡有個故事，至今仍讓我皺眉。當時我們正深入進行與 Sabre 訂房 API 的整合測試。我們的飯店工作者會送出一個訂房請求，收到一個 HTTP 200 回應——在網頁開發中這代表「成功」——然後把它傳給協調器。協調器就會告訴使用者：「你訂好了！」
只不過，他們並沒有。至少不是每次都有。
我們花了長得令人尷尬的時間才抓到這一點。那個 HTTP 回應之所以是 200，是因為那則訊息被成功送達了。但在回應主體內部，GDS 的航段狀態碼卻是UC——Unable to Confirm（無法確認）。飯店已經拒絕了這個請求，通常是因為快取的空房資料已經過時。在搜尋與嘗試訂房之間的那幾毫秒內，房間就被賣掉了。
傳輸層與應用層之間的脫節，是一個經典的陷阱，而我們正好一腳踩了進去。HTTP 層級的 200 OK 說的是「你的訊息送到了」。而 GDS 層級的UC說的卻是「你的訂房失敗了」。我們的系統只讀了信封，卻忽略了裡面的信。
就是在那時候，我們實作了我如今認為是整個架構中最重要的一環：驗證迴圈。每一則訂房回應在任何確認訊息抵達使用者之前，都會經過一個獨立的驗證步驟——可能是一個決定性的程式碼檢查，也可能是一個扮演品質稽核員角色的專門提示詞。這條規則是絕對的：
AI 代理絕對不被允許輸出確認訊息，除非它已經剖析了那個特定的 GDS 航段狀態碼，並驗證其為 HK——Holding Confirmed（已確認保留）。無論 HTTP 標頭怎麼說，其他任何情況都算是失敗。
HK代表庫存已被鎖定。UC代表飯店拒絕了你。NN代表請求仍在等待處理中——先別承諾任何事。NO代表未採取任何動作。這些代碼，就是「訂到的房間」和「被困住的旅客」之間的差別，而大多數 AI 旅遊系統甚至根本不去剖析它們。
若想完整了解我們對狀態碼的處理方式以及驗證架構的技術細節，請參閱我們的研究論文。
AI 代理如何處理「這間房剛剛被賣掉了」？
這正是代理型系統展現其價值之處。「查詢與成交」（Look-to-Book）之間的落差是旅遊業的通病——你搜尋、看到有空房、按下訂房，房間卻已經沒了。在旺季期間這種事層出不窮。以包裝器為基礎的 AI 對這種情況毫無應對的詞彙。它要嘛說「我訂好了！」（錯的），要嘛說「訂房失敗」（沒幫助）。它沒辦法說「一秒鐘前它還在，但別人搶走了——這是你下一個最佳選擇」。
我們的代理做得到。當一筆訂房回傳UC時，系統會自動針對同一間飯店觸發一次新的空房搜尋。如果有其他房型或房價可訂，它就會提出這個選項：「先前那個房價已售完，但我找到一間類似的房間，只多 10 美元。」如果什麼都沒有，它就從原始搜尋結果中拉出下一個最佳飯店，改為提供那間。這需要代理維持狀態——一份記憶，記錄它已經搜尋過什麼、使用者已經拒絕過什麼、有哪些替代方案。包裝器是無狀態的，做不到這一點。它們每次都從零開始，否則就會憑空捏造出「連續性」。
沒有人談論的正規化問題
有一件事讓我很意外——是真的很意外——那就是 Amadeus 和 Sabre 之間的資料結構差異有多大。Amadeus 會以嚴謹的巢狀 JSON，把價格拆成基本價、總價和稅金。Sabre 則有時把稅金含進去、有時不含，端看房價方案而定。欄位名稱也不一樣。amount在一個系統裡，到了另一個系統就變成totalPrice。
如果你把兩邊的原始回應都餵給一個 LLM，要它去比較飯店，它就會被搞混。它可能引用 Amadeus 的稅前價格和 Sabre 的稅後價格，讓那間 Amadeus 飯店看起來便宜了 50 美元，但實際上它反而貴了 20 美元。我們在測試中親眼見過這種情況發生，而這正是那種使用者幾乎不可能察覺的錯誤。
於是我們打造了一個正規化工作者——一個決定性的程式碼層，它把來自兩個系統、彼此互異的 JSON，轉換成單一的標準化結構。協調器永遠不會看到原始的 GDS 資料。它看到的是乾淨、一致的欄位：名稱、含稅總價、星級、距離使用者興趣點的遠近。LLM 呈現的是這份已正規化的資料。它不去解讀原始的 API 回應，它翻譯的是已經整理好的事實。
「就直接用 GPT 啊」——以及投資人會說的其他話
人們不斷問我，為什麼我們不乾脆用檢索增強生成——把飯店資料拉進一個向量資料庫，讓 LLM 去搜尋它。或者用旅遊資料微調一個模型。又或者，只是加上一個更好的系統提示詞。
曾有一位投資人直截了當地對我說：「就用 GPT 配上一個好提示詞嘛。這模型夠聰明了。」我尊重這種直覺——它是最簡單的解法，而簡單的解法通常是對的。但在這裡不是。當失效模式是「一家人睡在機場」時，就不是。
RAG 有助於處理靜態知識——「泰國的簽證政策是什麼？」——但它沒辦法告訴你 AA123 航班此時此刻還有沒有空位。微調有助於掌握語氣和領域詞彙，但它無法把模型連上即時庫存。更好的系統提示詞有助於格式呈現，但它無法阻止模型產生一個在任何 GDS 裡都不存在的飯店名稱。
在旅遊領域，唯一能防止幻覺的方法，就是把 AI 的輸出錨定在來自記錄系統（system of record）的即時、經過驗證的資料上。那個系統就是 GDS。其餘一切都只是裝飾。
沒有約束的創造力就是混亂。在旅遊中，那份約束就是現實——那個存在或不存在的機位、那間有空或沒空的飯店房間。這中間沒有灰色地帶，而 AI 必須停止假裝有。
那「速度慢」的部分呢？
我不會假裝代理型系統很快。單一使用者的一次請求，可能會觸發四次工具呼叫——搜尋、價格查核、政策查核、回應合成。這可能要花上 10 到 15 秒。在電子商務裡，這簡直是永恆。
我們用三種方式來處理這一點。第一，我們把代理的推理過程即時串流給使用者：「正在 Amadeus 搜尋航班……」「正在查核企業差旅政策……」把過程展示出來，能大幅降低使用者感受到的延遲。第二，我們讓工作者平行運作——航班工作者和飯店工作者同時搜尋，而不是依序進行，把總等待時間大約砍掉一半。第三，我們把空房查詢結果在 Redis 中快取 15 分鐘。如果使用者說「再讓我看一次那第二間飯店」，我們就不會再次去打 GDS，而是從快取中拉出來。
它有像那種兩秒內就編出一個答案的包裝器那麼快嗎？沒有。但對一個想要真實答案的使用者來說，它有達到該有的速度嗎？有的。
這一段，我要坦承我們目前還做不到的事
沒有任何 AI 系統能處理每一種情況。牽涉簽證相依性的複雜多段行程、冷門的航空聯盟、需要協商費率的團體訂房——這些仍然會出問題。我們之所以知道，是因為我們替它建立了偵測機制。當代理陷入迴圈卻無法解決，或當情緒分析標記出使用者的不滿時，系統就會降級到我們所稱的「副駕駛模式」（Copilot mode）。它會通知一位真人旅遊業務員，交出這段對話完整的結構化脈絡，再由這位真人用代理已經準備好的工具，完成這筆訂房。
人們問我這算不算一種失敗。我認為恰恰相反。最危險的 AI，是那種不知道何時該停手的 AI。知道自己的極限、並優雅地交棒，是一項功能，而不是一個瑕疵。那個說「讓我幫你接一位專員」的代理，比那個一直自信滿滿地亂猜的代理更值得信賴。
接下來要往哪裡走
我們今天所打造的，是地基，而不是天花板。我們正處於我會稱之為「第 3 級自主」的階段——代理會執行特定任務，但在動用金錢之前由使用者確認。前方的道路包括：不只訂已列出的價格、還會去查詢飯店 API 尋求量大折扣的協商代理；把機票與飯店打包成具有可控利潤的客製化產品的動態組裝引擎；以及主動式的行程中斷管理——由代理全天候監控航班狀態，一旦發生取消，早在旅客甚至還不知道出了狀況之前，就已經在下一個最佳選項上先保住了一個機位。
這些沒有一項是能在包裝器上實現的。如果系統會產生幻覺，這些也沒有一項行得通。上述每一項能力，都需要我們一直在打造的那種「具狀態、經驗證、以工具為根基」的架構。
旅遊業正處於一個轉折點。第一波 AI 採用浪潮——那些包裝器、聊天機器人、以及「就加個 GPT」的實驗——創造出某種既誘人又危險的東西：那些聽起來像是你這輩子見過最厲害的旅遊業務員、實際上卻連一間房都訂不了的系統。而下一波浪潮，將由一個更艱難、也更不光鮮的問題來定義：不是「AI 能不能寫出一份美麗的行程？」而是「AI 能不能確認那份行程上的每一個項目，在此時此刻、以它所報的價格，都真的存在？」
哥斯大黎加的那家人，值得比一篇寫得再美的虛構故事更好的東西。每一位旅客都值得。那個「靠猜測」的 AI 時代已經結束。接下來登場的，是一個會去查核的 AI——而且只在它確知時才開口。