AI 語音客服聽起來卡頓，原因不一定在模型。電話網路、語音活動偵測、輪次判斷、模型推理、企業 API 和語音合成都會累積等待；調快其中一段，也可能把使用者尚未說完的內容截斷。正確測法不是只記一個「回覆幾秒」，而是把延遲、插話與任務結果一起觀察。
來電先經過電信與 SIP／PBX 路由，音訊送進語音處理後，系統要判斷使用者是否說完，再由模型理解、呼叫企業工具，最後把回覆轉成語音送回電話。若查詢 CRM 或建立工單需要等待，工具時間也會進入體感延遲。只量模型首 token，會忽略來電者真正感受到的整條路徑。
| 階段 | 量測起訖 | 常見風險 |
|---|---|---|
| 電話傳輸 | 來電音訊進入與離開語音平台 | 電信路由、編解碼、網路抖動與封包遺失 |
| 輪次判斷 | 使用者停止說話到系統確認結束 | 等待過久或太早截斷 |
| 模型回應 | 送出有效輸入到產生可播放內容 | 上下文過長、模型選擇與複雜推理 |
| 工具呼叫 | 發出 API 到取得可用結果 | 企業系統逾時、重試與排隊 |
| 語音播放 | 文字或音訊產生到電話端開始播放 | 合成緩衝、首包等待與播放取消 |
Server VAD 通常依音量與沉默時間判斷語音開始及停止；Semantic VAD 會進一步估計語意是否尚未完成。等待較久可降低截斷，卻會增加停頓；反應太快則可能把「嗯……我想改成」切成兩輪。參數不能全站共用一個答案，姓名、長地址、代碼與開放式描述需要的停頓容忍度不同。
Barge-in 讓來電者在 AI 播放期間插話並停止原本回覆，適合更正資訊、跳過已知內容與縮短選單。它和系統因沉默判斷使用者已說完是兩件事。一般對話通常應允許插話；錄音告知、必要揭露或重要欄位確認是否允許打斷，則要依企業流程與法務要求個別決定。把 Barge-in 全域關閉會讓對話遲鈍，把它全域開啟也可能讓必要內容沒播完。
平均值容易被少數極慢或大量極快樣本扭曲。p50 用來看一般通話體感，p95 用來看較差但仍常遇到的尾端；另外記錄使用者停止說話到首段回覆、工具完成時間、錯誤截斷、錯誤等待及插話未生效。每筆樣本還要標記任務、網路、語言和是否呼叫企業 API，否則不同情境混在一起無法定位問題。
| 觀察項目 | 事件定義 | 判讀用途 |
|---|---|---|
| 首段回應延遲 | 確認輪次結束到使用者聽見回覆 | 區分輪次、模型與合成等待 |
| 工具等待 | API 發出到結果可用 | 找出企業系統或第三方瓶頸 |
| 錯誤截斷 | 使用者未說完就開始回覆 | 調整 VAD、輪次與欄位策略 |
| 錯誤等待 | 使用者已說完但系統持續沉默 | 檢查結束判斷、逾時與工具狀態 |
| 插話成功 | 使用者開口後原回覆停止並保留新輸入 | 驗證取消播放與上下文一致性 |
網頁麥克風在安靜辦公室的結果，不能代表手機、車內、免持、藍牙耳機或市話。測試至少要涵蓋背景人聲、回音、訊號不穩、快慢語速、常見口音、數字、英數代碼與長地址。對重要欄位，目標不只是逐字正確，而是系統能否重述、讓使用者修正，並在仍不確定時停止執行。
CRM、ERP 或派單 API 可能需要數秒甚至進入非同步流程。系統可以用簡短進度語句降低死寂，但不能在結果返回前說「已完成」。超過通話內可接受時間時，應建立待確認狀態、人工待辦或後續通知，並用唯一識別避免重複執行。延遲優化若犧牲結果真實性，只是把錯誤更快地說出口。
GoGoCha 的公開案例證明電話入口與即時派單工作流，但沒有公開端到端延遲分布、電信環境、通話樣本或 SLA。未經相同事件定義與真實量測，不應把產品設計目標寫成已達成服務水準。企業專案要在自己的 PBX／SIP、API 與尖峰條件下重新建立 p50、p95 和失敗樣本。
公開案例與可驗證證據
GoGoCha AI 電話與即時派單技術案例