18,000 杯水：得來速語音 AI 一再犯下的錯

2025 年 8 月，一位顧客把車停在 Taco Bell 的點餐機前，點了 18,000 杯水。AI 完全聽懂了他的話，把全部 18,000 杯都加進了訂單。那段影片的觀看次數突破 2,150 萬次，Taco Bell 也因此暫停了 AI 的擴張，好弄清楚到底哪裡出了問題。

令人不安的地方在於：人工智慧本身並沒有出任何差錯。語音辨識完美無瑕，語言模型也一字不差地解析了顧客所說的內容。真正缺少的，是一小段無趣的、以規則為基礎的軟體，它應該位於 AI 與收銀機之間——那種本該看著「18,000 杯水」然後說不，這不是一筆真實的訂單。只是沒有人把它打造出來。

我職業生涯近期都投身在得來速語音 AI 之中——也就是在你把車停在點餐機前點餐、而店員站在取餐窗口的那套系統——我想告訴你，為什麼這些失敗會一再發生，因為它給我們的教訓，並不是那些新聞標題所暗示的那樣。問題幾乎從來都不在模型本身，而在於模型周圍的架構。

AI 正確地聽到了訂單，只是系統裡根本沒有任何一個環節，被允許說出「這不可能是對的」。

這句話，就道盡了得來速語音 AI 為何不斷讓部署它的連鎖品牌難堪。而這是可以修正的——靠的不是更聰明的模型，而是在趕著做出展示樣品的路上，被所有人略過的那些不起眼的工程。

沒有人願意談的三年瓶頸

當我最初認真研究這個領域時，人人都拿來當作前車之鑑的，是麥當勞。他們與 IBM 合作的得來速語音專案花了三年，訂單準確率卡在 80–85% 左右，最後在 2024 年 7 月悄悄終止了整件事。過程中，這套系統曾在一輛車的訂單裡加了 260 塊麥克雞塊，還在某人的香草冰淇淋上點綴了培根。如今它已被列入「失敗博物館」的收藏。

我的第一直覺，和大多數工程師的一樣：他們一定是用了很弱的模型。於是我們從所有人都會起步的地方開始——拿一個強大的語音轉文字引擎，把它接進一個能力出色的語言模型，再把輸出串接到銷售點（POS）系統，然後讓它跑起來。在會議室裡，它確實令人印象深刻，能處理複雜的訂單、各種加料與替換。我當時深信，我們在幾週內就攻克了這個問題。

然後，我們在一個寒冷、颳風的傍晚，把它搬到真正的得來速車道上，它幾乎立刻就崩潰了。

一輛卡車在相隔兩個車位處怠速運轉，系統就開始把它的引擎聲轉錄成文字。一陣強風被判讀成一連串的說話聲。當顧客車上的收音機開著時，AI 還興高采烈地把電台 DJ 的聲音混進了訂單裡。那個在室內表現出色的東西，到了戶外幾乎無法使用，而我當初可是親自把早期的產品藍圖，押在「模型才是難題」這個假設上。它並不是。真正的難題，是在模型聽到聲音之前，聲音所經歷的一切。

停車場裡的那一晚，徹底改變了我看待整個問題的方式，也正是我們後來之所以打造出我們在Veriprajna所做之物的原因——那並不是一個更好的模型，而是圍繞在它周圍、原本缺失的那些層。

為什麼點餐機是地球上最難聆聽的地方

得來速的點餐機，是你能要求一台機器去聆聽的、在聲學上最惡劣的環境之一。我這麼說並不是在打比方。

引擎的低頻轟鳴集中在 200–400Hz 的頻段——而這恰好正落在典型男性嗓音基頻的正上方。所以這種噪音並不會客氣地待在旁邊、讓你可以把它濾掉；它與承載話語的那些頻率纏繞在一起。風會產生非穩態的壓力波，以無法預測的陣陣衝擊拍打麥克風。雨則在整個語音頻率範圍內加上寬頻的嘶嘶聲。而一個相互競爭的聲音——一名乘客、一台收音機、隔壁的車道——所產生的聲音，是標準的語音活動偵測根本無法從顧客聲音中分離出來的。

麥當勞與 IBM 的系統應付這一切的方式，是把原始、未經過濾的音訊直接送進語言理解層。這就是為什麼它會「聽到」隔壁車道的訂單、把引擎的瞬態聲響誤讀成有人開始說話，並從語音片段中憑空捏造出菜單品項。當音訊品質劣化時，模型做了模型在不確定時會做的事：它把這些雜訊比對到機率最高的相近詞元，然後產出一個自信卻錯誤的結果。

你無法靠提示工程來擺脫糟糕的音訊。如果訊號在模型看到它之前就已經被破壞，那麼更聰明的模型只會給你一個更流暢的錯誤。

解法是一條多階段的音訊處理流程，而各步驟的先後順序至關重要。我們把以能量為基礎的語音偵測——它會把任何大聲的聲音都當成說話——換成一個神經網路偵測器（Silero 這一類的模型），它在判定真的有人在說話之前，會維持一個 400 毫秒的連續機率門檻。光是這一項改動，就消除了大部分「引擎在點雞塊」這類的失敗。在此之上，我們還執行頻譜閘控，在語音辨識器收到訊號之前，先剝除大約 75% 的背景噪音；並透過麥克風陣列——Andrea DA-252 或 Veovox AudioBox——進行波束成形，在空間上把駕駛的聲音從車子周圍的一切其他聲音中隔離出來。

問題在於——而這正是供應商討厭的部分——這一層必須針對每一種點餐機型號、每一種聲學環境分別調校。那些以整潔辦公室音訊訓練出來的現成降噪方案，到了停車場就派不上用場。這裡沒有捷徑，而這正是為什麼真正這麼做的人少之又少。

那 18,000 杯水是軟體錯誤，不是 AI 錯誤

讓我回頭談談 Taco Bell，因為它是第二種失敗模式最清楚的例證。

那段影片瘋傳的那天早上，一位我一直有在往來的連鎖品牌營運者把它轉發給我，並直截了當地問，我們的系統會不會也做出同樣的事。這是個合理的問題，而誠實的答案是，大多數已部署的系統都會，因為它們有著同樣的架構漏洞。

AI 正確地理解了「18,000 杯水」。這一點從來沒有疑問。問題在於，系統沒有數量驗證、沒有異常偵測，也沒有針對每一次點餐的速率限制。模型的輸出直接流向了銷售點系統，因為根本沒有人打造出那個中介軟體，去在訂單送進廚房之前，先問一問這筆訂單在現實中是否合理。正是同一個缺失的層，讓麥當勞在一張帳單上加了 260 塊雞塊、在冰淇淋上加了培根。在這每一個案例裡，語言理解都是正確的，缺的只是商業邏輯。

令人抓狂的是，這個修正有多麼廉價。一個確定性的驗證引擎——我指的是真正以規則為基礎的程式碼，而不是更多的 AI——為每個連鎖品牌打造只需要兩到三週。它會執行由真實訂單分布推導出來的數量上限（在速食餐廳裡，單筆水的訂單，實際上限大約是八杯左右，而不是一萬八千杯）。它會檢查品項組合的邏輯，而在訂單資料中，「冰淇淋加培根」的歷史機率實際上等於零。它會為每一筆交易設定價格門檻，並強制在任何超出這些界限的情況下，由人工介入。

得來速語音 AI 中最便宜、最快速的修正，也正是能防止那些獲得 2,100 萬次觀看的災難的修正。靠的是規則，而不是智慧。

這正是讓人們感到意外的顛倒之處。那個華麗的部分——對話模型——如今大多已是被解決、且商品化的能力。真正保護品牌的，是那個確定性的防護欄層，而沒有人會把它放進展示裡，因為它看起來並不吸睛。

當一位口吃的人把車開來時，會發生什麼事？

第三種失敗模式，是那個讓我夜不能寐的問題，一部分是因為它是個道德問題，一部分則是因為它即將變成一個法律問題。

Wendy's 的 FreshAI 曾被口吃的顧客形容為「無法使用」，而一旦你理解了其中的機制，原因就顯而易見。我們自己的早期版本也有同樣的缺陷，而我之所以會發現，只是因為我坐下來，一遍又一遍地重播一段某人點「b-b-baconator」的錄音。我們的系統每一次都把他們的話打斷。

不流暢的言語會以三種截然不同的方式讓語音 AI 失效。當一個人重複某個音——「b-b-baconator」——辨識器會產生重複的詞元，打亂訂單邏輯。當他們出現卡頓，也就是在一個詞的中間出現無聲的停頓時，語音偵測器會把這段沉默判讀成他們發言的結束，於是在點餐途中就停止聆聽。當他們把某個音拉長——「Mmmmilk」——這個音素被延展得夠長，系統就會聽成一個完全不同的詞（「Silk」）。這些現象一點也不罕見。它影響著全球大約 8,000 萬名口吃者，以及更多帶有濃厚口音、年長者說話方式或非母語發音的人。這些系統是以流暢、標準的美式英語訓練出來的，而它們辜負了其他所有人。

我以前總把無障礙歸類為「有最好，以後再說」。我錯了，而讓我改變想法的，是法規的走向。在《美國身心障礙者法案》之下，食品與飲料如今是數位無障礙訴訟第二大被鎖定的產業，約占所有申訴案件的 21%，而這些申訴案件在 2025 年比前一年成長了 40%。加拿大於 2025 年 12 月發布了 CAN-ASC-6.2:2025——全球第一個無障礙 AI 的國家標準——它要求不論身心障礙與否都能有公平的表現，並提供一個有意義的選項，讓人可以拒絕 AI、改由真人服務。歐盟《AI 法案》的透明度義務將於 2026 年 8 月生效，要求必須告知顧客他們正在與一台機器對話。

目前還沒有任何一宗得來速語音 AI 的無障礙訴訟成案。但麥當勞的生物辨識隱私案——一宗指控其未經同意就收集聲紋的集體訴訟——已經顯示，得來速 AI 正牢牢處在訴訟的瞄準線上，即便那樁特定案件最後被駁回。這裡的成本算式，往錯誤的方向殘酷地傾斜：在一套已經部署的系統中事後加裝無障礙功能，花費大約是一開始就把它做進去的五倍。從第一天起就為不流暢的言語進行設計，並不是做慈善，而是那個更便宜的版本。

這一切真的行得通嗎？行——只要架構做對了

讀到這裡，很容易會下結論說得來速語音 AI 是個壞主意。它並不是。那些把各個層次工程做得妥當的連鎖品牌，正繳出失敗部署從未達到的數字，而兩者之間的落差，正是重點所在。

Hi Auto 在 Bojangles 大約 500 個據點運行，回報 93% 的訂單完成率與 96% 的準確率，其投資組合每年有超過 1 億筆訂單流經。SoundHound 在 White Castle 的系統，訂單完成率超過 90%，並宣稱每個據點每年約可節省 58,000 美元。2025 年的 Intouch Insight 得來速研究發現，採用 AI 的車道總服務時間平均為 3 分 53 秒，相對於整體的 4 分 15 秒——每筆訂單大約快了 22 秒——並且每小時能處理 17 到 18 輛車，相對於沒有 AI 時的 16 輛。採用 AI 的據點滿意度約為 97%，比傳統車道高出好幾個百分點。

看看這個差距。麥當勞與 IBM 停滯在 80–85%。Hi Auto 與 Bojangles 則達到 96%。這並不是弱模型與強模型之間的差別——到了 2026 年，底層的模型大致上已相差無幾。這是「把原始音訊直接送給模型」與「把訊號處理、確定性驗證，以及圍繞其周圍的整合都做好工程」之間的差別。

最後那個詞——整合——正是許多美好意圖夭折的地方。一個大型連鎖品牌大約 75 到 80% 的營收，都來自得來速這個通路，而那筆訂單必須乾淨俐落地落進連鎖品牌既有的任何一套銷售點系統裡。NCR Aloha、Toast 與 Oracle Simphony 各自提供不同的 API，對於加料如何串流、以及多車道連線如何保持彼此隔離，也各有不同的限制。菜單同樣不會安分：限時優惠、分時段供餐與地區限定品項，每週會變動兩到四次，而任何一套需要重新訓練模型才能學會新品項的系統，都跟不上這個節奏。我們的做法，是把語言理解建立在一份即時的菜單資料流之上，如此一來，新品項在幾分鐘內、而不是幾天內就能上線。

營運者真正會問我的問題

當我和這些連鎖品牌負責技術的人交談時，同樣的質疑總會出現，所以讓我用在會議室裡回答他們的方式，來回答這些問題。

我們是不是乾脆選 Google 或 NVIDIA，然後就了事？你可以，而且已經有很多人這麼做了——Wendy's 跑在 Google Cloud 上，Taco Bell 透過 Yum! 跑在 NVIDIA 的基礎設施上，Burger King 面向員工的「Patty」助手則跑在 OpenAI 上。代價是平台依賴。如果 API 有所變動、或定價出現變化，你的整套部署都會暴露在風險中，而且你拿到的是通用型的模型，而不是專為你那些特定車道的聲學條件所打造的東西。供應商市場既擁擠又有實力——Presto 在 2026 年 1 月募得 1,000 萬美元，並延攬了 FreshAI 最初的創辦人；SoundHound、Hi Auto、ConverseNow 與 Vox AI 也都已在真實規模下部署——但他們每一家交給你的，都是他們自己的技術堆疊，而不是一條客製化的訊號處理流程。我們的立場是供應商中立：稽核你手上既有的東西，在任何平台之上打造出缺失的那些層，而且不把你綁死。

驗證層與無障礙層難道不會把一切都拖慢嗎？這是真正的工程張力所在。低於 300 毫秒的回應是及格線，而你每加一層，都要付出延遲的代價。光是雲端處理，就會增加 100 到 500 毫秒的網路來回時間；把推論移到邊緣設備上，可以把這降到 5 到 10 毫秒，但每個據點要多花 500 到 1,500 美元的硬體。這份工作，是在不讓每小時處理車輛數掉到人工基準線以下的前提下，加上防護欄，因為一套系統一旦拖慢了排隊速度，不論它有多準確，都會被撤下來。那個平衡是一個有已知答案的工程問題，而不是略過防護欄的理由。

這到底是一筆真正的預算項目，還是一個科學實驗？每個據點的語音 AI，軟體每月花費 200 到 500 美元，連同硬體全部算進去則是 400 到 980 美元。相對於此，連鎖品牌回報每個據點每月額外增加 3,000 到 18,000 美元的營收，以及每月四位數的人力成本節省。這筆經濟帳算得過來。算不過來的，是把那筆預算花在對話層上，卻略過了那三個真正能讓你不上頭條的層。

那些瘋傳失敗案例真正的教訓

把每一樁登上新聞的得來速語音 AI 災難再回顧一遍——那 260 塊雞塊、那份培根聖代、那 18,000 杯水、那位口吃卻被掛斷的顧客——你不會找到任何一樁，是由一個聽不懂英語的模型所造成的。它們每一樁都是架構的失敗：從未被清理的音訊、從未被合理性檢查的訂單、一種系統從未被打造來聆聽的聲音。

在這件事上勝出的連鎖品牌，並不是買了一顆更好的大腦。他們打造的是圍繞著它的身體——在停車場裡也管用的耳朵、能在一筆荒謬訂單送進廚房之前就攔下它的反射神經，以及知道一筆真實訂單長什麼樣子的判斷力。那正是我們在Veriprajna所做的工作，而它遠不如那些展示所暗示的那般光鮮亮麗。

用機器來接得來速訂單的技術，其實已經行之有效一段時間了。在大多數搶著部署它的連鎖品牌那裡，仍舊缺少的，是沒有人會為上市發表拍進去的那個部分：清理乾淨的音訊、那條能攔下第 18,000 杯水的規則、讓口吃的人把一個詞說完的耐心。把這些做出來，模型就從來都不是難題。略過它們，你也已經知道那段影片會怎麼收場。