用戶插嘴（barge-in）：粵語語音 Agent 點樣接得住打斷

一句答你： 插嘴（barge-in）唔係一個「開關功能」，而係一個狀態機。系統喺度出聲嗰陣，要同時做三件事：判斷呢個聲係咪插嘴、即刻收手、仲要等客戶講完先答。淨係做到第一件，客人一樣會覺得你唔聽講嘢。

「我等一下——」呢句一講出嚟，系統仲照講落去，係語音客服最傷嘅體驗之一。客人唔會再講第二次。

但barge-in做得好唔容易，因為大部分聲音都唔係插嘴：咳嗽、打鍵盤、同事行過講嘢，全部似插嘴。判斷錯咗，客人只會覺得系統神經病。

重點摘要

• 插嘴處理係一個狀態機，唔係一個門檻值。判斷、收手、等客戶講完，三個動作缺一不可。
• 判斷唔可以只靠音量。要同時睇音量、持續時間、語意同講者身份。
• 「等一下」「停」「唔係」呢類打斷用語，應該即刻收手，唔使等語意判斷完成。
• 停生成係唔夠嘅。要同時停播放、清走未播嘅緩衝，客人先唔會聽到殘留嘅半句。
• 停咗之後唔好即刻答。客戶可能仲有下半句。
• 台詞越短，插嘴嘅成本越平。講咗一半被切走嘅合成成本係真金白銀。
• 驗收要分兩個數：真插嘴嘅收手延遲，同埋假插嘴率。

插嘴唔係一個功能，係一個狀態機

Barge-in 係指用戶喺系統講緊嘅時候插嘴，系統要即刻收手。

半雙工（half-duplex） 係指講完先輪到另一方講，兩邊唔可以同時出聲。全雙工（full-duplex） 係指兩邊可以同時出聲，用戶可以隨時插入。

大部分客服系統由半雙工起步，因為容錯高得多：唔使判斷，就唔會判斷錯。但代價係客戶一定要等系統講完先可以講。

上面呢張圖有兩個位係最多團隊寫錯嘅：

1. ④ 收到疑似插嘴 — 觸發點要喺「收到第一段語音」嗰刻，唔可以等系統生成完先處理。
2. ⑥ 真插嘴：即刻收手 — 要同時停生成同清緩衝，淨係停生成係唔夠嘅。

公開嘅全雙工語音評測跑過 293 段模擬對話、1,200 次插嘴、超過 40 小時生成語音，結論係現有模型面對插嘴仍然有明顯問題，尤其喺噪音環境同頻繁打斷嘅情況（見 FD-Bench，arXiv:2507.19040，2025 年 7 月）。另一份工作提出用個人化嘅語音活動偵測去壓低噪音同非主要講者造成嘅誤判，並且用三個系統層指標評估互動質素：barge-in、句尾判定準確率、端到端延遲（見 FireRedChat，arXiv:2509.06502，2025 年 9 月）。

點解香港客服一定要支援插嘴

同一個問題，粵語客嘅反應會比英文客強。

第一，粵語嘅打斷用語好短。 「停」「唔係」「等陣」三個字就係一個完整嘅打斷指令。英文客通常會講 "wait, actually..."，語意機會有足夠時間反應。

第二，港式英文夾雜令語意判斷難做。 「唔係，我要 cancel」呢類句子，語意模型要先處理語言切換先判斷到係咪打斷。

第三，街頭同商場嘅收音環境雜。 背景人聲、隔音唔好嘅電話線，會製造大量似插嘴嘅訊號。

第四，粤语嘅停頓長。 客戶停頓唔講，唔等於佢講完。半雙工系統如果照英文嘅停頓門檻處理，會喺客戶只係思考嘅時候插嘴，結果係客戶要重講。

五類「似插嘴但其實唔係」嘅聲音

判斷錯嘅代價，比漏接插嘴更大：漏接只係客人喊多句，誤判就係系統成句講落去。

其中「系統自己嘅回聲」係最陰險嗰類。耳返式電話或者外放嘅環境，系統嘅聲音會被麥克風收返入去，如果唔做回聲取消，系統會不停嘅自己打斷自己。公開研究亦提到，語音系統最常見嘅三個問題係：唔知幾時應該開口、打斷得太急、極少做自然嘅附和聲（見 Talking Turns，arXiv:2503.01174，2025 年 3 月）。

同客服團隊對齊定義。 工程團隊同客服主管對「插嘴」嘅定義好易唔一致：工程睇訊號，客服睇體感。落報告之前，應該一齊寫低三件事：邊啲算插嘴、邊啲當背景噪音、收手幾快先算合格。例如「等一下」係插嘴，「咳一聲」係噪音——呢個定義唔寫落去，評分就會變成各自話各自。

判斷矩陣：幾時當真插嘴

用四個訊號一齊判斷，唔好用單一門檻。

打斷用語要行捷徑。 當辨識結果係「等一下」「停」「唔係」「等陣」呢類短指令，直接收手，唔好等語意判斷完成。客戶講咗「唔係」，你仲要等佢講埋三個字先停，體感上就係「唔聽講嘢」。

時間門檻要當作可調參數。 唔好喺規格書寫死一個毫秒數——咁做只會製造一個冇人喺你條線量過嘅數。做法係先喺你自己嘅真實錄音上面量，再定值。

中英夾雜嘅場景特別要小心，因為「cancel」呢類英文詞好短，一個唔夠長嘅門檻會令正常嘅查詢被當成插嘴。盲測方法可以參考中英夾雜 IVR 實測。

收到插嘴之後要做嘅三個動作

判定咗係真插嘴之後，仲有 三個動作要做，漏咗任何一個都會出事。

第一，即刻收手。 停止合成，亦要停止播放已經送到嘅音頻。只停生成唔夠 —— 客戶仲會聽到殘留嘅半句。

第二，丟棄未完成嘅部分稿。 客戶插嘴嗰陣，辨識可能只出咗半句，呢半句唔應該入對話歷史，否則下一輪會拎住一個錯誤嘅上下文去答。

第三，唔好即刻答。 停低之後，應該等客戶講完。好多系統一停就即刻出聲，結果客戶講「等一下，其實我想問……」時，系統已經開始答第一部分。呢度要有第二個狀態：等待客戶講完。

成個流程點樣影響延遲，睇語音 Agent 延遲預算嗰篇 —— 插嘴收手延遲係要獨立監察嘅一個指標。

半雙工定全雙工：揀邊個

建議做法：先做半雙工，但預留位。 即係話，話音通道、播放控制同埋句尾判定嘅接線要一開始就做好，判斷邏輯可以後加。咁樣第二期開全雙工，唔使推翻第一期。

台詞設計：畀用戶插嘴嘅空間

呢部分睇落唔似工程，但直接決定插嘴體驗。

短句。 一句講一件事，唔好將三個資訊塞入一句。短句亦都令語音合成更快，客戶可以更早插嘴。具體幾長最啱，要喺你條線耳聽完先知。

【原創數據】 用港嘢現行公開費率自己就算（2026-10-25 查閱）：入門方案 HK$128 每月 200,000 字符，即每字符大約 HK$0.00064。一句 25 字嘅回覆成本大約 HK$0.016。

【獨家觀察】 呢個數字嘅真正意義喺度：每次插嘴，講咗一半嘅嗰句合成就作廢。如果系統平均每通講三句、被打斷一次，你起碼浪費咗 HK$0.016。寫得短，唔止平，仲令「插嘴 → 重新答」嘅循環短啲。逐項成本同攤分例子，睇AI 客服每通話成本。

留白。 句子中間加停頓位（例如標點同換行），畀客人物理上有空間插嘴。

唔好問引導式問題。 「您想知道保單、地址，定係……」呢種句子，客戶一開始答就已經被切斷。

點樣驗收：barge-in 測試五步

1. 收 5 類真實插嘴音檔。 咳嗽、環境聲、旁人、客戶打斷用語、系統回聲。一定要用真實錄音，唔好用合成音。
2. 揀 3 句會俾人切嘅回覆。 揀最長嗰啲。
3. 量兩個數。 真插嘴嘅收手延遲（報 p95），同埋假插嘴率。
4. 人手評分。 收手時間、誤判次數、對話有冇斷。
5. 每次改動之後跑返同一批音檔。 呢個係回歸測試，唔跑就等於無驗過。

每一回合最少要記低呢幾欄，先有得比較同埋追問題：

公開研究做語音代理測試時，用咗 500 句真實查詢做語料，並且逐段記錄耗時（見 arXiv:2508.04721，2025 年 8 月）。同一方向嘅工具亦可以逐回合顯示每個模組嘅延遲指標（ESPnet-SDS，NAACL 2025 demo）。你唔需要做到咁大，但記錄欄位嘅設計可以直接照抄。

完整嘅粵語語音 agent 測試語料點砌，睇粵語語音 Agent 測試指南。台詞長度、語速同重聽設計，睇廣東話 IVR 電話錄音指南。

常見問題

插嘴一定唔好過唔支援？

唔一定。答案穩定、客人唔急嘅查詢，半雙工完全夠。反而如果系統判斷錯一次，客人對整個系統嘅信任會跌。寧願慢少少先假插嘴。

客戶講「等一下」，應該即刻停定等佢講完？

即刻停。等佢講完係下一步嘅事——停低之後要等，唔係停之前等。

停咗之後點樣知道客戶講完？

用句尾判定：停頓加語意一齊判。呢個位要獨立調優，唔好同收音延遲混埋。

插嘴會唔會增加成本？

會，但主要係「講咗一半作廢」嗰部分。所以解法係寫短啲，唔係減少插嘴功能。

轉真人同插嘴有咩關？

有。客戶插嘴話「我想搵人」，就係轉真人嘅訊號。呢類情況應該即刻轉，唔好再答多一句。轉接時要帶咩脈絡，睇AI＋真人混合客服。

想試下你嘅場景？

整套工程脈絡，我哋喺廣東話 AI 客服點樣砌嗺篇講得更完整；產品面睇廣東話 AI 客服。想了解我哋背景，可以喺「關於港嘢」一頁睇；有技術問題歡迎聯絡我哋。

---

本文由港嘢內容團隊編輯審閱（editorial review，2026-10-25）。文中引用嘅第三方研究已標明出處同日期；門檻數值係建議起始值，未喺你嘅線路易實測，本文唔會當成保證值。