摘要：接下來，由會通過上傳音頻數據，云端通過一系列算法最終將語音數據轉換為兩部分結果純文本，表示這段音頻數據中用戶所說的話，比如若琪今天的天氣。

本文是面向 Web 開發者所寫，介紹關于“語音交互”的一篇科普性質的文章，希望借助這篇文章，讓開發者了解到什么是語音交互，以及在 YodaOS 中的技術實現。不了解YodaOS是什么？點擊這里回顧。

作為 Web 開發者，相信在面試時常會被問到“瀏覽器輸入 URL 后發生了什么”這樣的經典問題，這可以很好地幫助工程師理解整個 Web 的技術棧。因此，本文將從“若琪，今天杭州的天氣”這一句話開始，盡量讓大家了解到語音交互的技術全貌。

以下章節涉及到的知識點包括（可以先自行查閱之）：
語音激活（VT）
語音識別（ASR）
語義理解（NLP）
語音合成（TTS）
技能（Skill）——語音交互時代的應用
如下是一次語音交互的流程：

從上圖可以看出：

首先，用戶（人類）通過智能設備上的麥克風獲取音頻信號數據（PCM），通過“語音激活”模塊，它能正確地將帶有激活詞的數據轉換成云端可以識別的音頻數據（如 opus）。

接下來，由 VUI Client 會通過 WebSocket 上傳音頻數據，云端通過一系列算法最終將語音數據轉換為兩部分結果：

ASR：純文本，表示這段音頻數據中用戶所說的話，比如“若琪今天的天氣”。
NLP：JSON 格式的數據，NLP 也叫語義理解，通常會把每句話解析成兩個重要的信息：

一部分叫意圖（Intent），表示用戶說這句話的目的，比如“今天的天氣”，那我們可以獲得這句話的意圖是 query_weather，表示在查詢天氣；

另一部分是具體信息（Slots），一般在 JSON 中是一個對象，比如“今天的天氣”會在 slots.date 中為 today，表示這句話詢問的是“今天”的天氣，類似也可以有像 slots.location 用于表示詢問的是“哪兒”的天氣；

ASR 和 NLP 會由 VUI Runtime 下發到具體的技能（Skill），每個技能通過解析 Intent 和 Slots 來做對應的處理，最終生成為一段文本，由 TTS 回復給用戶。

以上其實就是一次語音交互的基本流程，接下來會按照不同的模塊分別介紹。

語音激活流程

在說明這個流程之前，先來看看為什么需要它。當用戶與一個智能設備交互時，由于媒介是語音（空氣），所以不像傳統的 GUI（PC、平板、手機）設備，它們擁有一個獨自的媒介平臺（如屏幕、按鍵等），所以交互目標是明確的。而生活中空氣是共享的，這意味著在交互之前，首先要判斷用戶是不是想要跟你說話，比如你說“幫我開下燈”，可能是讓你老婆去開燈，而不是若琪。

無論 Alexa、若琪、小愛同學，還是天貓精靈，首先需要給設備取一個悅耳的名字，這樣設備才能知道你是否在跟他/她說話，這——便是語音激活模塊要做的事兒。

然而要做好這么一件簡單的事兒，可不容易。

首先我們先了解下什么是 PCM，維基百科上中文名稱叫：脈沖編碼調制。很難理解對吧？如果要把整個概念說清楚，可能需要涉及到很多聲學和信號學的知識，這里就不拓展了。簡單來說，你可以把它理解為，就是你說了一段話（語音），然后被麥克風記錄成了二進制數據，這個原始數據就叫 PCM。

了解了 PCM 后，再來了解2個概念：

AEC，自音源消除。在智能音響上，通常都有麥克風和揚聲器，麥克風在收音時，會把當前設備通過揚聲器播放的聲音也記錄下來，因此 AEC 所做的就是從 PCM 數據中將設備本身播放的音頻消除，減少干擾。
VT，激活算法模塊。將 AEC 后的音頻數據輸入到 VT 算法/模型中，他會給出激活分數，最后通過分數判斷是否激活。

在激活模塊內部，從麥克風獲取到語音數據后，會經過 AEC 處理，將揚聲器的聲音消除，接著會通過其他降噪算法去除一些額外的噪音，然后將最終處理過后的音頻數據輸入 VT，若模型判斷是激活的話，就會把后面的（音頻）數據通過 VUI Client 上傳到云端 ASR，直到云端判斷用戶說完了并結束本次交互。

NLP 下發流程

前面講到從云端會下發兩種類型的數據：ASR 與 NLP，然而對于云端是如何生成這些數據并沒有提及，這里我們先稍微講解一些 NLP 的部分。

在 ASR 將音頻數據轉成文本后，會輸入給 NLP 服務（云端），那么云端是怎么把一段簡單的文本解析成本地想要的 JSON 格式呢？NLP 引入了領域（Domain）概念，比如“若琪，今天的天氣”會被劃分為天氣領域，“我要開燈”是 IoT 領域，“我要聽歌”則是音樂領域，類似的領域還有故事、時間、百科、導航和聊天等。

可以簡單理解為領域是一個大的范圍，表示用戶想要跟設備交流的主題，而意圖則是在這個主題下一個個需要設備幫助完成的任務。比如“今天的天氣”，主題是天氣，而意圖則是問詢。

有了“領域”的概念后，當我們獲取到一串文本后，會經過預先訓練好的模型以及預先定義好的規則和說法，就能判斷出這段文本命中了什么領域和意圖，然后再從文本中抽出相關的信息。最后將所有信息組合成一個完整的 JSON 下發至設備端。設備通過每條 NLP 命中領域或技能的不同，下發給對應的技能進行處理。

CloudApp

語音交互的輸出相對比較單一，基本上是：TTS、音效以及多媒體音樂，因此這里有一個 VUI Rendering 的概念。

在 GUI 時代，渲染的輸出是屏幕的可交互的控件、聲音以及視頻。而 VUI 就是 TTS、音效和多媒體音樂，相對于 GUI 來說，已經相當簡單了。因此與 Web 一樣，VUI 渲染也分為服務端渲染和本地渲染：

本地渲染：本地應用直接處理 NLP 數據，在本地執行業務邏輯，并最終播放 TTS、音效以及多媒體音樂。
服務端渲染：NLP 服務會將數據先發送到預先配置好的一臺服務器，在服務器上執行業務邏輯，并分別將 TTS、音效和多媒體音樂轉換為一條條指令（Directive），返回給 NLP 服務，最后設備端收到后，只需按照指令執行對應的操作即可。

一般把在服務端渲染的應用稱作 CloudApp，其優點當然是實時更新，開發快捷簡便，與 Web 的運行機制類似，缺點則是能力受限，拓展依賴于協議本身的能力（類似于瀏覽器沙箱）。

技能生命周期

無論是本地還是云端，技能跟我們所熟知的頁面一樣具有其生命周期，VUI Runtime 會對其進行管理。在 YodaOS 中，每個技能可以由兩種方式啟動：

用戶通過語音 NLP 下發命令并啟動。
用戶通過設備按鍵觸發啟動。

每個技能在啟動后，就會處于技能棧棧頂，表示當前技能正在運行，此時可以控制設備的輸出內容（TTS、音效與多媒體）。與此同時，若之前有技能已經在運行，則會將之前的技能銷毀或暫停，這取決于他是即時（CUT）還是場景（SCENE）技能：

CUT：用于單次會話的技能，因此有新的技能命中時，會毫不猶豫地結束（銷毀）該技能。
SCENE：用于長時間需要交互的技能，如音樂播放、游戲或有聲故事。若新請求的技能是 CUT，會先暫停上一個技能，待 CUT 結束后恢復；若新請求的技能是 SCENE，則會替換掉之前的技能。

總結

其實一次語音交互遠不止上文所提到的這些流程，這里也僅僅希望拋磚引玉，以及給對于語音交互感興趣的工程師分享出我們在做 YodaOS 的一些心得，最后歡迎大家關注我們的 VUI Runtime：https://github.com/yodaos-pro...。