如何打造「被打斷也不崩潰」的語音代理——LiveKit 的 Jesse Hall 現身說法

LiveKit 這家即時基礎設施公司的開發者推廣者 Jesse Hall 主張，語音代理在正式環境中失效，問題不在於模型在排行榜上分數難看，而在於團隊優化了錯的指標，而且從來沒有測試過完整的對話。這場演講大部分時間花在拆解這種失效的機制——首位元組延遲（time-to-first-byte）與首段音訊延遲（time-to-first-audio）的差別、Token 速度與句子速度的差別、輪次偵測（turn detection），以及讓工具呼叫與對話並行執行——另外還介紹一套評測方法：把模型堆疊換掉，對上模擬的來電者反覆測試。標題所講的「在代理講到一半時插話」只是其中一條線索；這一集的核心是延遲預算與端到端評估，並以金融服務作為高風險的 motivating 案例。

Hall 是以 LiveKit 的立場發言——它是 OpenAI ChatGPT 進階語音模式背後的開源即時框架，他在臺上也引用了這個選用事實。讀者讀完應該帶走三樣東西：一個具體的延遲目標（大約 500–600 毫秒才有人味，1.5 秒是上限）、一組測量方式的修正，以及一套可重複的迴圈：用完整對話而非個別元件來挑選模型堆疊。

排行榜評的是元件，你交付的是一場對話

Hall 的核心論點是：對即時代理來說，照排行榜挑模型根本行不通，因為排行榜是在乾淨音訊上替個別元件打分，但真正送到來電者耳裡的是一整場對話。他舉的例項：來電者說想在三號付款，語音轉文字模型聽成三十號，LLM 就照三十號去規劃，錯誤一路往下傳，因為 LLM 根本無從得知轉錄錯了。沒有任何元件分數會浮現這種失效。他指出，真實的來電者是在車陣中開著擴音、後座還有小孩，不是在乾淨音訊的評測環境裡。

他推動的重新框架是：別再問「我該挑哪個模型」，改問「針對我的使用情境，我該交付哪一套堆疊」。他把架構選項描述成兩類：一是由三個模型串成的串接式管線（cascaded pipeline）——語音轉文字、LLM、文字轉語音——協同運作；二是較新的語音轉語音模型，直接取代整條管線。他說後者持續進步，但「還沒到每個使用情境都能用的程度」。市面上有數百個模型、數十家供應商，選擇問題確實存在，而他主張唯一站得住腳的答案，是為你自己的代理量身打造一套評測。

量來電者聽到的東西，不是儀錶板回報的東西

Hall 點出兩個測量陷阱，會讓堆疊看起來比實際更快。文字轉語音方面，供應商回報的是首位元組延遲；他說 LiveKit 測過幾家熱門供應商，首位元組之後最多還會送出四分之三秒的靜音。真正該看的是首段音訊延遲。LLM 方面，回報的指標是首個 Token 延遲，但 TTS 模型沒辦法只憑一個 Token 就開口——它需要一整個句子。真正該看的是首句延遲，而且產生 Token 最快的 LLM，不見得是最快講完第一句的那一個。

他直接把利害關係扣到金融場景：付款完成後，來電者問「我的付款進去了嗎」，卻聽到兩秒靜音，這樣安撫不了人。

延遲預算是固定的，所謂像人就是塞得進這個預算

Hall 把延遲看成一份有限的預算，而不是一場比誰更快的競賽。這份預算就是來電者最後一個音節到代理第一段聽得見的回應之間的落差，所有東西——輪次偵測、LLM 依暫定轉錄稿準備回應、TTS 生成、每一次函式呼叫與轉接——都得塞進這個視窗。他給的數字：大約 1.5 秒是外緣，通話還撐得住但開始覺得怪；輪次之間 500–600 毫秒才有人味。該問的不是「我能跑多快」，而是「在這個視窗內，我能塞進多像人的代理」。

flowchart TD
    A["來電者的最後一個音節"] --> B["輪次偵測器判定來電者講完了"]
    B --> C["LLM 依暫定轉錄稿準備回應"]
    C --> D["TTS 生成音訊"]
    D --> E["代理第一段聽得見的回應"]
    E --> F{"落差在預算內嗎？"}
    F -->|"500-600 毫秒"| G["有人味"]
    F -->|"約 1.5 秒"| H["撐得住，但感覺不對"]
    F -->|"超過 1.5 秒"| I["對話崩掉"]

耗時的工具呼叫該跟對話並行，而不是擋住它

後端動作——查交易、確認付款狀態、送出爭議申請——都要時間，從毫秒到數十秒不等。Hall 對隱藏這種延遲的答案很直白：四十秒是藏不住的。反過來問，真人會怎麼做？真人不會悶不吭聲，他會說「稍等我一下，我幫你查」，或「系統現在有點慢，快好了」，或者一邊查一邊先聊下一個問題。代理也能這樣做，他示範了開啟這件事的那一行程式碼：在工具呼叫上做 async await，把麥克風交還給代理，對話和工具就不再共用同一條執行緒。

他的示範是一個開源的飯店接待代理，服務虛構的 Gilded Rose Hotel，透過多輪往返訂一間房——日期、人數、房型、景觀、姓名、電子郵件、電話——工具呼叫在背景跑，每一筆資訊都存下來。對話從不為了等存檔確認而停頓，而是立刻進到下一個問題。他指出，如果工具呼叫回傳錯誤，代理會自行修正，最糟的情況是把來電者轉給真人。示範過程中他打斷代理，代理照樣講下去。

輪次偵測需要音訊，不能只看轉錄稿

Hall 說明 LiveKit 內建的輪次偵測器除了轉錄稿，還會聽節奏、音高和語調。他引用公開資料：領先的替代方案有 9.9% 的機率打斷、把使用者截斷，而 LiveKit 的偵測器在自家針對飯店代理及其他代理的測試中是 4.5%。他說這些評測是開源的，團隊可以拿自己的資料來跑。他舉了一個只看轉錄稿會出錯的例子：來電者說「五百五十五塊兩毛三」，卻在「五百」就被截斷，因為偵測器只看到一個數字加上兩秒停頓；而聽得到音訊的偵測器會聽出語調，知道要等。

用模擬來電者輪換堆疊，打造專屬評測

Hall 提出的評估方法，起點是一個接上真實後端、完整可運作的代理——那個飯店接待代理是開源的——然後對它跑模擬來電者。這些來電者會追求目標、改變主意、插話、含糊其詞，還可以加入背景噪音。模擬可以是文字形式，測商業邏輯；也可以是音訊形式，測語音辨識、輪流發言和整條語音管線。情境會指定來電者要什麼，以及代理應該產生哪些動作與結果。

評分看結果——正確的訂房有沒有進資料庫、正確的授權金額有沒有扣款——再加上流程檢查，因為代理會鑽完成度的漏洞：兩步就能做完的事，它有沒有拖到十步？有沒有幻覺出不存在的函式呼叫？接著團隊換掉模型堆疊，代理和情境維持不變，再跑一次同樣的迴圈，每個模型吃到的輸入位元組完全相同，而且持續不斷地跑。結果就是一套專屬於單一代理的評測；Hall 的說法是，現在有多少個代理，就有多少套評測。

「能最快幫你拿到答案的模型，就是適合你的模型……而且出乎意料的是，那個模型未必是排行榜最頂端的那一個。」

在飯店評測中，排名第一的 LLM 是在 LiveKit Inference 上跑的 Gemma 3 31B；同一個模型換到另一家供應商就比較慢，Hall 把這歸因於 LiveKit 針對語音工作負載優化了自家的推論服務。他強調 LiveKit 不繫結特定模型。

上線檢查清單

Hall 最後給了一份清單，還請聽眾直接拍照：

• 設定來電者實際聽得到的延遲預算。
• 量首段音訊延遲與首句延遲。
• 行動之前，先確認關鍵日期與任何金額。
• 存取帳戶之前，先驗證身分。
• 慢速工具在跑的時候繼續聽；讓對話繼續進行。
• 用模擬反覆跑完整對話。
• 測試最終狀態、隱私防護、多餘的工具呼叫，以及輪流發言。
• 把每一次失敗都變成回歸情境，持續測試。

他為整場演講下的定調是：語音代理不是裝了喇叭的聊天機器人，而是一個必須像人一樣回應的即時系統。他開場講的是大家都熟悉的經驗——你搶話，代理就崩掉，對真人來說等於零分；結尾則希望不久的將來，來電者打斷這些代理時，它們就是能順順地接下去。

尚未解決的張力在於：這套方法要靠團隊自己打造並維護模擬測試框架與回歸測試套件——這是實打實的工程工作，Hall 說它是開源的，但沒有量化成本。4.5% 對 9.9% 的打斷資料，來自 LiveKit 對自家代理做的自家測試；Gemma 3 31B 的結果也只針對那一套飯店流程；兩者在當成通則之前，都值得在金融服務代理上重跑一次。至於語音轉語音這條替代路線——它會讓 Hall 花了整場演講最佳化的三模型管線整個消失——只被一句「還沒到那個程度」帶過，沒有給時間表。