跳轉到

開發語音應用的挑戰

封面

在打造語音應用的時候，最常見的挑戰，來自於模型的能力，環境噪音，還有延遲的問題。

模型的能力

在我們前面的示範中，我們大量使用系統所提供的 ASR、TTS 的能力，在 NLU 與 NLG 方面，則大量使用 LLM 的能力，在這裡使用的是 Gemini。而我們的語音助理最終的使用體驗，就大量取決於這些元件、模型的表現—如果辨識錯誤，或是無法辨識，使用者體驗就會大打折扣。而通常最大的問題是 ASR。

對於使用者來說，NLU 引擎辨識意圖的過程，其實是不可見的，所以，就算辨識出對開發者而言錯誤的意圖，我們還是有辦法可以對應到指定的對話流程上。如果我們發現某套 TTS 引擎，會把某個句子中的某個詞唸錯，我們也可以把這個句子換掉，換成某個其實寫起來不對，但是發音正確的句子到 TTS 引擎上，然後在 GUI 畫面與 TTS 引擎其實拿到不同的句子。這些問題大概都可以用障眼法解決。但如果是 ASR 辨識錯誤，那就沒有什麼障眼法可以用了。

假設我們有一套手搖飲料的的語音點餐系統，裡頭有一項叫做「好的噗咩茶」這樣的產品，這並不是常見的詞彙，各平台上的 ASR 引擎大概就不認得，可能會辨識成「普洱茶」。我們可以做個選擇，當 ASR 引擎完整辨識出了「普洱茶」時，我們假設這是「噗咩茶」的錯誤結果，把要訂購的產品強制指定到噗咩茶上，但，如果店家同時有噗咩茶與普洱茶，這樣就很有問題。還有一種可能是，ASR 引擎根本沒辦法把「噗咩茶」辨識出來，

一個方向是，這個模型需要加強分辨「噗咩茶」或「普洱茶」的訓練，但使用既有模型的我們並沒有這個能力，我們或許要求助有自家 ASR 模型的公司，在我的職業生涯中，也看到一些公司曾經嘗試透過 Open Source 的元件打造語音應用，但最後還是因為 ASR 的能力，而去尋找可以客製 ASR 模型的公司。

或著，可以選擇在產品設計上避開，比方說，我們的店家是否應該要有「噗咩茶」這個產品，我們是否可以把「噗咩茶」換成「檸檬茶」，這樣就可以避開這個問題。這邊能做的選擇，就會依賴商業上的判斷，像是使用「噗咩茶」這個名稱能帶來的收益，與找人訂製 ASR 模型的成本相比，是否更值得。

而在一些時候，我們還會遇到完全無法適用 ASR 功能的情境，比方說，我們想透過語音功能，傳訊息給指定的聯絡人，但他的名稱可能充滿了罕見字，像是「龘䶛䨻䎱㸞蚮䡶䴞䴝䯬䬛䰕㹚」1，或是充滿了一堆想唸都唸不出來的符號，像是「▄▃▂z★nble▁▂▃▄」。那就完全無能為力了。

環境噪音

如果使用者處在一個吵雜的環境中，那麼環境的噪音一定大大影響 ASR 的辨識結果。我們可以在產品設計上提出一些對使用者的要求，例如要使用指定型號的耳機或麥克風，甚至是特定的指向性麥克風陣列。

或著，在一些系統中，我們可以透過設定一些系統消除噪音，以 iOS 為例，我們可以對 AVAudioSession 設定不同的 mode，iOS 會在設定不同的 mode 之後，套用不同的消噪的演算法，而所謂的 mode 就是不同的情境，比方說，如果選擇了 videoRecording，用手機拍片的模式，那就會變成盡可能要把什麼聲音（包括噪音）都錄進來，顯然就不是我們想要的錄音模式。比較適合像是 voiceChat 或是 videoChat 這種假設使用者是手持手機，跟使用者保持一個距離的錄音模式，而在 iOS 12 之後，蘋果特定針對語音識別的情境，加上了 voicePrompt mode。

而如果需要更進接的消噪，那大概得具有消噪技術的供應商了。

延遲

在我們這次的示範中，使用的 ASR 引擎會用到網路識別，像是，speech_to_text 在 iOS 上用到了蘋果的 API，而蘋果的實作是用到了他們的網路服務，而 NLU、NLG 引擎，則是用到了 Gemini API。只要是透過網路傳輸資料，自然就會有延遲（Latency），這個延遲會影響到使用者的體驗—使用者會因為等待而煩躁，像是使用者只需要說一聲「對」或「好」，之後卻需要好幾秒的等待，才會進入下一步。

針對一些短句，我們或許需要做一些最佳化，消除使用者的等待時間。比方說，在收到 ASR 結果之後，我們先用一個簡單的字串表格，與 ASR 結果比對一輪，如果發現是一些明確的短句，那也就不用去使用線上的 NLU 分析功能。另外，ASR 引擎通常會在使用者講完話之後，大概等待幾秒鐘，確定使用者真的講完了，但是，如果我們一開始就知道，語音引擎現在期待的就是講一些「好」、「是」、「確定」或「取消」等短句，我們可以不用做這樣的等待，只要收到了符合的辨識結果，就馬上進入下一步對話流程。

另外，您也可能會有在完全不連網的狀況下，需要一套語音助理。那麼，這裡所打造出的方案，就完全不適用了。

其他

其他挑戰像是：我們需要開發特定語言的語音應用，但是我們自己並不會講這種語言，身邊也沒有會講這種語言的人，一來不知道怎麼不知道怎麼發音，讓我們有辦法測試開發出的系統，也不確定在特定文化中，我們的流程是否符合當地習慣，甚至會不會冒犯使用者。我們或許要找更多的合作夥伴，不是單純可以從技術的方向解決。

而說到國際化的問題，想要讓語音助理同時處理多國語文，也是一項挑戰。在 NLU 的部分，基於文字的語言模型，通常比較能夠分辨出一段文字屬於哪一種語言，而且根據傳入的語言給予相同語言的回應，比較大的問題還是出在 ASR 上，目前常見的 ASR 引擎通常還是以一個語言為主，突然講另外一個語言，大概都會得到預期以外的回應。但目前 ASR 技術也在飛速進步，我們期待不久就能夠方便使用可以同時正確辨識多國語文的 ASR 引擎。

  1. 出自「龘䶛䨻䆉」這首歌，https://zh-yue.wikipedia.org/wiki/龘䶛䨻䆉 ↩