語音對話平台海爾五代智能電視落地

智能語音互動(Intelligent Speech Interaction)是AI的入口，智能語音互動之于VUI，正如滑鼠鍵盤之于GUI。但什麼是智能語音互動呢？這個名詞并非每位同學都能望文生義，我試着給出個最簡練的解釋：讓機器能聽懂我們的話，并能給出相應的回報。

這其中包括了喚醒、聲紋、語音識别(ASR)、語義了解(NLU)、知識庫(QAS)、多輪對話(Dialog)、語音合成(TTS)等諸多端上和雲上的能力，這前面還包括了從麥克風整列、聲學信号處理到端上喚醒、免喚醒等能力。

為什麼會有這篇的分享呢？

先來聽聽"一小撮"客戶的聲音：A公司有ASR，B公司有NLU，C公司有TTS，他們看起來都不錯，我都想用，我來把這些攢起來，然後根據具體情況，選擇ASR用A家還是阿裡的、NLU用B家還是你們的……端上呢，向我的服務發起請求，我來做上帝。

是的，客戶永遠是上帝。隻要你喜歡，這種攢的方案總是可以搞出hello world的，這是事實。曾經，我們非常了解客戶的心情，也這樣提供給使用者這樣的單元件輸出的服務。但是，"智能"服務的核心是智能，也就是準——準确地被采集、被喚醒、被識别、被了解，并給出最佳的回報路徑和相關内容。單元件輸出的問題我不(YU)好(KU)亂(WU)講(LEI)，看完本篇你自然會懂。

為了秉承精品輸出理念，我們最終選擇了幾乎"偏執"的解決方案——整體能力的輸出。這是不斷被折磨、蹂躏、挑戰、逼迫，險些放棄并最終堅持的觀點。

海爾五代項目在阿裡巴巴大文娛的鼎力支援和合作下，我們共同貫徹了整體能力輸出的目标。有幸作為參與者，我将從語義了解和對話管理開發者的角度，與大家分享我在海爾五代項目上的觀察和思考。

1 聯合優化

一緻的資料

一切智能始于資料。沒有資料就沒有模型，而模型是智能的大腦。

從開始在阿裡雲大資料團隊到今天，我時常聽到的一句交流是"你是怎麼解決冷啟(Cold Start)的？"，也就是說，沒有資料就無法訓練出有效的模型，這是智能服務最不智能的階段。

日更

我們生活在資料大爆炸的時代，大文娛領域的影視作品、當紅藝人等；新零售領域的商品名稱、促銷别名等，大交通領域的車站名稱、路名等，這些資料的更新非常頻繁。為了滿足海爾五代項目的需求，我們确認了資料更新的頻率為日更。

為了滿足日更的目标，我們必須建立一套自動化pipeline基礎設施，以實作從資料到語言模型(LM)、實體(Entity/Tag)+詞典(Dict)、了解模型(model-based NLU)、了解規則(grammar-based NLU)的每日上線，否則從業者累死也跟不上這樣的節奏。(注意：并非全自動化、無人參與。由于智能行業的特殊性，依然需要人的參與，衆包和标注要靠人來最終确認。）

我們在原有自動化pipeline的輸入源上增加了大文娛的日更資料，輸出是上線的識别和了解的能力。因為我們為海爾五代輸出的是整體能力，是以ASR和NLU共享源頭資料，確定了更新的内容和處理時間一緻性、人工和處理程式的方式的一緻性，避免了人工标注的重複勞動，最終熱更新的詞典、規則、模型的上線時間也是一緻的(最矬也是精确到天啊，不要問我差多少個ms)。

使用者自定義詞典

通過我們的對話技能定制平台，使用者可以定制自己業務場景的對話技能，每個技能包括了細粒度的語義了解和對話管理的定制。其中，使用者自定義的詞典是解決使用者特定技能下的語義了解的。舉個例子，要了解"幫我訂下阿裡日全天的問天涯"，就要知道"阿裡日"是日期(5月10日)、"問天涯"是阿裡的會議室名稱。雖然系統詞典提供了日期和地理資訊的詞典，但無法支撐語義了解服務解這個特定業務的query。

使用者對自定義詞典的改動是随時随地的，而且預設期望是随即生效的。我們提供的技能建設能力會在使用者儲存修改後，自動處理相關資料并最終同時對ASR和NLU服務做熱更新。得到我們整體能力輸出的客戶，ASR會準确識别"阿裡日"和"問天涯"兩個詞，NLU會正确了解這兩個詞的含義。

注意，使用者改動自定義詞典的這一過程，無論ASR還是NLU都不需要我們人工介入。對海爾五代的産品經理來說，省去了與(平台和引擎的)研發同學的溝通成本和等待人工的時間成本。

資料閉環

整體能力輸出不止是引擎服務，還包括集團賦予我們的能力，比如全鍊路日志建設。

當客戶回報某個query沒有得到預期的結果時，我們通過全鍊路日志可以很快地定位和解決問題。但這還不是全鍊路日志最有價值的地方。

無論規則還是模型都無法覆寫全部場景(open dialog和open Q&A已經證明是行不通的)，服務會有矬的時候。當一個query的了解結果為unknown時，使用者得到的結果通常是"我沒懂"一類的話術。

通過全鍊路日志，我們可以得到unknown對應的query，通過周期性的人+自動化的pipeline修正能讓服務越來越懂，換句俗話就是讓機器通過學習變聰明。這個過程就是資料閉環。

資料閉環推動了服務能力的可持續改進，但這個改進很難通過單元件輸出展現出來。

• 隻輸出ASR，識别對了可能依然是unknown的了解結果；
• 隻輸出NLU，如果語音識别錯了NLU幾乎無法了解(後面會講到糾錯，但也是整體輸出才能展現效果)，NLU會很冤，通常在出現unknown時，NLU會首先背鍋，沒有強大的運維能力，這鍋就扣住了，最後定位到ASR的問題，還是解不了。

一緻的規則

如果模型是飯，那麼規則就是水。

"你是怎麼解決冷啟(Cold Start)的？"

"寫規則啊"

說者理直氣壯，問者會心一笑，不知者不屑一顧。

從業者都知道，在模型沒有被足夠的資料訓練好之前(可能就不存在這樣一個時間點)，基于規則的識别、基于規則的了解就如水一樣，是智能服務的生命之源。"工程"出身的人通常羨慕"算法"的是訓模型，覺得實作規則沒啥牛的，這感覺對錯并不重要，重要的是規則很重要。規則是啟動(boost)一個智能服務的源水。

任何同時擁有ASR和NLU的公司或者團隊，都不會同時使用兩套定義規則的文法，也就不會搞兩套規則解析器(grammar-based decoder)。

在海爾五代項目中，ASR和NLU的規則引擎和規則定義是一套，同步改進了解能力和解析速度。當請求遇到"準"相關的問題時，我們會去看基于同一文法的識别規則和了解規則，同步改進規則書寫的邏輯；當遇到"快"相關的問題時，我們會去看底層統一的規則解析器，改進算法或者實作；遇到"穩"相關的問題時，我們會去分析并改進統一的服務架構。

2 互相補位

阿裡巴巴機器智能技術實驗室的科學家說：智能服務引擎的輸入和輸出都應建立在基于機率的假定之上，健壯的引擎不能假設輸入是100%确定的。

我來個小白的解釋：ASR不是萬能的，NLU不要相信他；NLU不是萬能的，Dialog不要相信他。

2.1 NLU補位ASR

縱然前述講到資料的一緻更新，但由于兩者對細節的考慮和處理不同依然存在差異的。比如如下同音不同字的情況：

• 我想看熊出沒之雪嶺熊風
• 請播放變四

先從人類的角度看上面兩個用例。如果你家沒有熊孩子，那麼你不會看熊出沒，也應該沒聽過"雪嶺熊風"。那麼當你聽到這四個字時，最直覺的識别就該是"雪嶺雄風"。如果你不知道"變四"是指"變形金剛第四部"，你應該無法識别是哪兩個字；你知道這個詞也可以書寫成"變四"或者"變4"，兩者沒有錯對。

再從機器的角度說海爾五代項目中的真實案例。一開始，ASR對上面兩句的識别是"雪嶺雄風"和"變四"，而NLU的熱詞分别是"雪嶺熊風"和"變4"。從NLU的角度看，ASR都"錯"了。NLU引擎服務中實作了糾錯，自動将"雪嶺雄風"更正為"雪嶺熊風"，并将"變四""轉成了"變4"。在我們的整體輸出能力中，NLU的這一改變，ASR是可以通過對應的日志最終感覺的，反哺ASR的持續改進。ASR可以決定是否跟着NLU的糾錯進行修改，比如可以接收"雪嶺雄風"但堅持"變四"。

2.2 Dialog和NLU互補

一個query送給NLU，NLU不能保證每次都傳回最正确(N-Best)的結果。最正确的傳回應該是攜帶置信度的domain/intent/slot清單，而不是隻根據置信度打分傳回分數最高的值。因為，詞槽對應的實體标簽是和對話上下文強相關的。比如，"成都"可以是"城市名稱"也可以是"歌曲名稱"。如果目前query之前的意圖值是"旅行"，那麼"城市名稱"更接近使用者的意圖；如果是"音樂"，那麼使用者應該是想聽趙雷的歌。

依靠對話上下文來判斷的能力是對話管理的本職。但是，Dialog也不是萬能的，僅靠這一個因素是不夠的，還需要了解結果中的置信度。隻有了解和對話深度共建，在書寫對話邏輯的時候，才能盡量合理地使用了解結果中的置信度，否則你無法确認一個

0.9

的結果和另一個

0.8

的結果，哪個更值得相信。

Dialog的結果會根據具體業務以及端的類型傳回最佳回報或者最好的一組回報。對于音箱這類無屏的端，一般會傳回最佳回報，在海爾五代項目這類大屏業務中，可以傳回一組回報，便于使用者選擇和确認。這裡的核心技術點是，Dialog需要讓NLU知道，在上一輪、多輪的結果中，Dialog最終采用了哪個或者哪幾個了解結果，以便NLU對目前輪的query做出更合理的了解。

此外，在我們的整體解決方案中，客戶除了可以定制業務相關的對話技能和意圖，還可以定制問答對知識庫。對于閑聊、電視産品說明書、百科等業務來說，使用NLU不是正确的打開方式。此時，Dialog對NLU的補位是通過知識庫實作的。

NLU和Dialog一起負責智能服務中的"懂"和"做"。這一工作是非常艱苦和持續的。原因是AI技術遠未發展成熟，人類對此的共同探索在未來的很長一段時間恐怕都是孜孜以求卻求而不得的狀态。

但人類不會因為沒有發明出發動機而放棄馬車。隻有NLU和Dialog一起發展并不斷補位，才能在科技水準存在瓶頸的階段做出最好的回報。根據Conway定律，NLU和Dialog同宗同源才能更好地打造馬車時代的精品。

2.3 喚醒的端+雲補位

相信用過語音智能産品的同學都有體會，智障并不是智能産品最無法接受的，夜裡被誤喚醒并講出可怕的故事或者發出靈異的聲音才是天理難容的。

是以，喚醒成為了智能語音互動的雙刃劍。無喚醒意味着從麥克風到語音上雲的鍊路是從不關閉的，那麼智能産品除了費電、占帶寬，還會不斷地告訴你他聽不懂或者亂打岔。因為他不知道那句話是對他說的。是以，喚醒是必備功能。那麼，喚醒詞就是"芝麻開門"的作用，這個詞多家設計為以"小"字開頭。

被誤喚醒的根源是智能産品把請求query或者某種聽得見聽不見的音頻流當做了喚醒詞。相信是這個道理：如果一家能根治的問題，最終對其他家來說也不是問題。那麼說明，以現在的科技能力，沒有能真正解的技術。

于此同時，為了滿足海爾五代項目的業務需要，我們需要支援免喚醒功能——支援熱門影視作品的随說即達。比如我們直接對電視說"我要看羞羞的鐵拳"，電視會被自動點亮并直接播放該片。當然，"羞羞的鐵拳"必須是熱門影片并且你得有收看該片的權限。

這個對使用者來說很牛的功能把本就不成熟的喚醒功能逼上了絕路。于是，被逼的我們，為整體解決方案設計了端+雲的補位(詳情請付費收看，開個玩笑，這不是本篇重點)。有了雲+端的聯合判斷，不但有效降低了誤喚醒，還實作了上述的免喚醒影視直達的狠功能。

3 技能的完整性

通用技能的共享和建設是智能服務各個領域都非常看重的。一個技能包含了語義了解、對話管理和内容服務三部分的能力輸出。我們以海爾五代項目中的音樂技能為例：

• 語義了解：使用者的任何有關播放音樂的query都能被了解為音樂領域
• 對話管理：以最收斂的方式确認是音樂播放意圖并确認所需的全部參數，并從内容服務擷取資源傳回給端
• 内容服務：根據關鍵字或者标簽計算出相關資源并傳回給調用方

從這個例子可以看出，整體輸出能夠得到最完整和最流暢的服務能力。攢服務是無法做到通用技能聯合建設聯合打磨、調優的，更無法做到零開發成本的(與其他廠商之間的)技能共享。

對話管理是通用技能中最關鍵的環節。像講故事、播放内容這些技能，對話路徑比較容易設計，因為這些技能的業務相關性比較弱，無論業務方是全屋智能、智能電視還是智能汽車，我們都比較容易以相同的對話路徑實作統一的傳遞。但像旅遊、酒店等技能，我們無法預先想好一個泛領域的路徑，以适用各個業務方。

是以，我們的管理平台提供了預置了解能力和内容服務的能力，使用者隻需在管理平台上實作對話函數(fn-based dialog)或者對話任務(taskflow-based dialog)即可實作業務相關的技能建設，并且可以共享給業務類似且對話路徑相同的其他使用者。

整體輸出的另一個好處是内容聚合。舉個例子，由于資料安全和知識産權等原因，我們可以獲得大文娛的首屏熱門資源清單這種日更資料，外部的NLU或者Dialog服務無法享受這個自動化服務。那麼如果一個依賴大文娛優酷的電視廠商，不走我們整體輸出，他們的NLU和Dialog就缺少這塊的資料更新，勢必會影響其熱門影視作品的了解和對話管理能力。再舉個例子，如果使用者要看優酷、聽蝦米、上淘寶、走飛豬、吃盒馬，那麼集團裡誰有語音識别、語義了解、對話技能建設的整體輸出能力，誰就有資格代表阿裡輸出智能語音互動服務。

今年隻是AI一年(2017年被定義為AI元年)，人類在AI領域要走的路還很長，智能語音互動的整體能力輸出當然也在其中。最後，我純票友暢想一下語音互動持續的整體能力輸出黑科技：ASR+TTS的聯合能力、Dialog NLG+TTS的聯合能力、方言整體輸出能力。