<b>摘要：</b>随着語音互動、自然語言處理、多模态等技術的發展，人機互動方式已經變得越來越簡單，目前人機互動已經成為行業最熱的研究方向之一。那麼，未來人機互動的發展趨勢什麼呢？阿裡巴巴智能語音互動專家高傑在《雲栖大講堂第三期|未來人機互動技術沙龍》上為大家分享了在阿裡巴巴智能個人助理建構過程中所積累的經驗和教訓。
<b>演講嘉賓簡介：</b>
<b>高傑，</b>智能語音互動專家，博士畢業于中國科學院聲學研究所，現任職于阿裡巴巴機器智能技術實驗室語音互動組，有十多年的語音互動和機器學習的研發經驗。現任職于阿裡巴巴機器智能部語音互動組。緻力于自然互動界面 (Natural User Interface) 的普适應用，主導多種裝置 (汽車、電視、手機等) 的人機互動界面系統的架構和實施。
<b>以下内容根據演講嘉賓PPT以及視訊整理而成（雲栖社群做了不修改原意的編輯）。</b>
首先簡單介紹阿裡巴巴機器智能實驗室語音互動組的概況：阿裡巴巴機器智能實驗室語音互動組大概是在3年前正式成立的，語音互動組自成立開始就帶有兩個使命，第一個使命就是緻力于将人工智能中基本的語音能力，包括語音合成、語音識别以及其他基礎的自然語言處理能力特别是語音互動技術相關的能力，沉澱到阿裡雲中作為普适的計算能力，提供給所有的開發者，并且使這樣的技術成為廉價的、大家都能夠用得起的雲計算能力。語音互動組還與ISV一同建構了很多垂直領域的解決方案，包括法庭庭審、客戶質檢以及視訊直播等。語音互動組的另一個使命則是緻力于讓每一台裝置都能夠具備人機互動的語音能力。本文也将主要為大家分享關于人機智能互動的部分，而這部分的主要載體就是NUI (Natural User Interface) 平台。
<b>緣起-智能個人助理</b>
至于阿裡巴巴語音互動組做NUI平台的初衷是非常簡單的，就是實作智能個人助理。其實真正引爆智能個人助理市場的是蘋果公司，2011年蘋果正式釋出了Siri，全世界群眾第一次對于智能助理開始關注起來。當到了2014和2015年時，亞馬遜和微軟又分别釋出了Alexa和Cortana，這就意味着語音助理開始從手機向其他裝置遷移。2015年，阿裡巴巴建立了現在的智能實驗室語音互動組，也就開始跟随之前的企業建構類似的東西。
在2018深圳雲栖大會上，阿裡巴巴宣布開始全面進軍IoT。IoT或者說基于裝置的方向也成為了阿裡巴巴的一個主要發展方向。其實NUI平台的想法和願景也和整個阿裡巴巴集團的戰略是一緻的，NUI平台的想法就是讓每個裝置都具有基于語音甚至是基于多模态的自然互動能力。
<b>NUI曾經支援的裝置和智能助理</b>
上圖展現的是在過去三年左右的時間内，NUI平台曾經支援的裝置，包括了手機、電視、天貓盒子以及機器人和汽車等。這裡有幾個比較有趣，比如阿裡巴巴與上汽榮威合作的斑馬智行系統，這個系統目前已經随着汽車在市場上大規模發售了；另外一個就是上圖中右上角的多模态地鐵售票機，這個項目中不僅包括語音模态，還包括視訊模态等；最近的還有阿裡巴巴與海爾合作的遠場語音識别系統，其語音識别是基于麥克風陣列的，這個系統也将會在2018年5月份的時候在市場中大規模發售。
語音互動組在做了這麼多的東西之後，也沉澱了很多的想法，是以本文的題目就叫做經驗和教訓，因為這麼多的項目做下來發現有一些東西大家會很喜歡，可以在市場上進行發售，但是有些也就默默無聞，然後最終消失了。這是為什麼呢？如何去思考語音互動？又應該如何使用語音互動建構出使用者願意使用的東西？這也是本文将與大家探讨的兩個主要話題。
<b>當談論智能個人助理時，在談論什麼?</b>
當大家都在談論智能個人助理的時候，到底在談論些什麼呢？用真實客戶的話來講就是“我希望給我的裝置加上AI”，可以看出在大衆眼中的個人智能助理實際上就是AI。而智能個人助理到底是什麼呢？其實智能個人助理是基于服務和自然互動的方式，為人提供資訊、操控裝置或者完成其他任務的産品形态，是以最終而言，智能個人助理是一款産品。
上圖就展現了智能個人助理的三個環節，最核心的大家所謂的“AI”部分就是中間的環節，其實際上就是一種自然互動的方式，這裡所展現的就是非常典型的互動系統的流程圖。智能個人助理的核心價值不在于它會為大家提供互動方式，而在于它會為大家提供互動的内容和服務，并且最終會落地到某一種裝置上，以一種具體的産品形象來展示。
<b>如何建構智能個人助理産品？</b>
那麼究竟應該如何去建構智能個人助理産品呢？下圖展示了對于NUI的三種觀點，其實應該從這三個角度來看智能個人助理。首先，最典型的角度就是将NUI看做機器學習系統，特别是一種統計機器學習的系統；第二個角度就是将其視作傳統的軟體系統，是以在建構智能個人系統的時候還需要關注軟體工程的部分；而最後落腳到使用者是否喜歡這個東西上，就需要将其視作一款産品，更準确地說就是網際網路産品。
<b>NUI-機器學習系統</b>
NUI是一個基于資料統計的機器學習系統。當使用統計知識解決具體任務的時候，首先要收集一部分任務相關的資料來訓練出模型，之後将模型部署上去，最重要的是從整個部署過程中擷取資料，進而去更新和疊代整個系統，這就是建構NUI平台的核心想法。這裡首先需要注意資料任務的相關性。其次，需要從一開始建構系統的時候就要思考需要努力的方向、團隊的能力分布，并思考如何建構這樣的回報閉環。
<b>NUI-軟體系統</b>
NUI也是一個傳統的軟體系統，需要經曆從産品需求分析、系統設計，到編碼實作、軟體測試，再到系統維護的整個流程。首先需要将一個天馬行空的想法變成一個現有技術可實施的設計，而現有技術本身會有很多限制，是以在這部分會産生很多的讨論。後面則是具體的編碼實作，以及為了保證軟體品質的測試和系統維護工作等。這些雖然是老生常談的工作，但是這些都是在建構實際系統中必不可少的環節。而NUI系統的建構實際上也會與傳統軟體系統的建構有些許不同。
<b>NUI-(網際網路)産品</b>
最後，NUI也是網際網路産品，而作為産品則需要去考慮其核心價值是什麼。NUI作為一款産品的核心價值就是幫人類完成任務，查詢資訊，操作裝置。如果一款智能個人助理産品不能提供這樣的核心價值，那麼就難以被使用者接受。在有了落地場景和核心價值之後，還需要标準來衡量産品優劣，因為NUI的核心訴求是幫助人類完成任務，是以最終的衡量标準就是任務完成率和互動的速度。最終NUI還是一款産品，對于産品，特别是網際網路産品而言，産品經理們經常向其中添加新的特性，下圖中就已經展現了市面上語音互動系統中經常定義的産品特性，而具體如何實作這些特性都是開放性的。
<b>NUI的設計與實作</b>
前面分享了NUI的三個觀點和其核心訴求，接下來分享究竟應該如何實作NUI。
<b>NUI: 架構Quick Recap</b>
在NUI架構設計中，首先需要有裝置，因為NUI的核心是需要人通過語音與裝置進行互動，比如面對一台海爾電視，使用者的一個樣例指令就是“你好電視，我想看烈火如歌”，然後電視就會回答“為你找到烈火如歌，請觀看”，這樣一個短短的對話中其實就完成了使用者與電視語音互動的過程。首先通過麥克風陣列收取使用者語音，其次通過信号收集的算法來降低周圍的噪聲對其的幹擾，“你好電視”就是一句所謂的通用喚醒詞，就如同“Hi Siri”一樣會喚起裝置。之後使用者所發出的任何語音就會經過語音識别轉化成文字，并且通過自然語言了解來分析出使用者的意圖，最後查詢服務并且給出提示，并在電視上面播放節目，這就是比較簡單的人機互動流程。
<b>子產品：拾音技術</b>
在音頻采集或者音頻收集部分會需要用到拾音技術，這是因為在人和裝置互動的過程中往往會受到各種各樣的噪聲幹擾，比如在和裝置講話時正好旁邊有其他人在講話，也可能會是因為房間布局造成的一些反射聲，此外還會有一些其他的幹擾聲，比如在看電視的時候旁邊的空調聲音以及冰箱聲音等，這些噪聲都會對于裝置收集人的指令聲音造成一定的幹擾。
在拾音技術部分，通過阿裡巴巴近幾年的技術積累，語音互動團隊已經具備了自主設計拾音硬體的能力，包括目前非常流行的線性陣和環形陣的硬體設計能力，以及配套的前端處理算法。
<b>子產品：信号處理</b>
對于信号處理算法而言，可以通過舉例來說明。通過這裡的例子可以為大家解釋在語音互動中使用最多的拾音算法。
第一個算法叫做固定波束形成技術，這個算法很簡單，如上圖左側所示，裝置将會在固定方向劃出一個拾音區域，人站在區域中所發出的聲音指令才能喚醒裝置，其他地方的聲音則不能影響，也就是說其他的幹擾源就會被屏蔽掉，用術語來講就是空間濾波技術。另外一個比較有趣的算法就是聲學聚焦技術，相比于空間濾波技術會劃分出一個區域，聲學聚焦技術則通過輔助定位裝置比如攝像頭或者麥克風本身的定位算法将人定位在如圖右側所示的某一區域，不僅僅可以測定方向，還可以測定距離，可以将收音區域限制在一個小範圍内。這個算法就應用于了地鐵售票機中，通常情況下大家需要排隊購買地鐵票，一個人在買票時，其他人都會排在其後面，那麼這種情況下空間濾波技術所劃分的固定方向區域就完全沒用了，而使用聲學聚焦技術則可以有所幫助。
<b>子產品：喚醒技術</b>
語音喚醒其實就是上述所提到的像“你好，電視”或者“Hi Siri”這樣的語句，關于語音喚醒已經有很多的文章在讨論技術細節，本文不再展開詳細的讨論，隻是去分享語音互動組所做的一些東西。首先，語音互動組在模組化算法中使用了自己所實作的聲學模組化算法cFSMN with MFP。除了複雜的算法，喚醒技術另外一個大的挑戰就是需要運作在裝置本身上面，而裝置本身的計算能力是非常有限的，那麼就需要降低計算量，是以還實作了基于算法的低bit壓縮技術以及晶片級的計算優化。除了端上算法之外，還需要特别關注準确率，是以還在雲端實作了二次确認，這也是目前主流廠商的做法。
<b>子產品：語音識别技術</b>
阿裡巴巴在語音識别方面的積累也更多一些。目前已經實作了幾代的模型疊代，從最開始标準的深度神經網絡，到Latency-Controlled BLSTM (LC-BLSTM)，到最近提出的第三代:Lower Frame Rate (LFR) Model。Lower Frame Rate Model實際上是對于第二代技術的改進，第二代技術會帶來很好的準确率的提升，而在第三代模型中則更關注計算量以及資源消耗。而在第四代則是将Lower Frame Rate Model和更好的模組化技術融合到一起，結合Multiple Frame Prediction技術進一步降低計算量。大家也可以從語音識别技術模型的演變中發現其中的關注點，一方面就是在準确率本身，會使用更加準确的序列模型；另一方面則更加關注計算量和資源消耗，這會和某些産商或者公司的想法不一緻，很多公司的想法就是使用更加昂貴的機器來支撐服務，而阿裡巴巴的想法則是既需要考慮準确率又需要考慮低計算量。這與語音互動組的使命是一緻的，需要做到準确率比較高并且成本很低，讓大家都能用得起。
<b>子產品：自然語言了解</b>
下圖所展現的是阿裡巴巴NUI平台的自然語言處理框圖，基本上是規則系統和統計系統的串行系統。這裡關于使用規則系統還是統計系統存在很多争執，而阿裡巴巴實踐後總結出的經驗卻表示兩種系統都不可少。規則系統一般比較準确，特别是系統剛剛開始運作，也就是冷啟動什麼資料都沒有的時候，可以迅速地編寫一些規則使其快速上線，這是一個非常好的做法。而當資料積累比較多的時候，可能就會傾向于使用統計系統完成任務。
自然語言處理的核心任務就是抽取分類，抽取使用者所發出的語音指令到底出于什麼樣的意圖，比如“我要看烈火如歌”這句話的意圖就是去看視訊，另外會有一些命名實體或者核心的屬性需要将其抽取出來，比如上述語音指令中的視訊片名就叫做“烈火如歌”，這就是如今比較常用的做法。圖中最右邊的部分叫做Systematic Frame，也是目前最主流的語義表示方案。
<b>子產品：對話引擎</b>
最後，在對話引擎部分，實作了對話的邏輯和引擎的分離。首先會有一個對話解釋器，其次對于每個任務會有自己的腳本，此外還會通過外在的方式與服務打交道，因為所有的和服務、資源以及内容打交道的都在對話這部分中完成。阿裡巴巴會将對話引擎這部分做的比較靈活，友善于第三方開發者以及合作方在其上進行自定義，當然為了使得合作方完成的工作更加符合預期，這裡也會給一定的監督。
對于前面所論述的單點語音技術，阿裡巴巴智能實驗室語音互動組發表了很多文章，這裡給出部分論文清單。
<b>關鍵字1：打通</b>
前面簡單介紹了NUI平台各個的子產品。那麼是不是将這些子產品進行簡單的插拔就可以了呢？當然不是，是以在本文中所分享的經驗和教訓中的第一個關鍵詞就是“打通”。
打通的原因大緻有兩個，一個是技術是有限的，在設計産品特性的時候必須要考慮技術的有限性。技術子產品不夠成熟，很多時候子產品的準确率都不夠高。其次還會受到各種各樣的限制，比如在裝置端上面，依然有一些低計算量的裝置，而業務方卻希望在裝置之上實作更多的功能，那麼如何在功能和計算量之間進行平衡也是需要考慮的内容，需要多個子產品互相配合才能解決。其次就是産品經理會提出各種奇怪的需求，比如快捷喚醒、Oneshot識别、智能定向、聲紋支付等。但是想要完成這些都是比較困難的。
<b>打通：算法子產品的邊界</b>
接下來分享車載智能定向的例子。阿裡巴巴的車載智能定向功能是裝載在榮威的實體車裡面的，斑馬是阿裡巴巴投資的一個方案提供商，斑馬為榮威汽車提供了車載智能系統解決方案。其車載智能系統的喚醒詞是“你好，斑馬”，下圖中的草圖大概代表了汽車内的四個位置，當主駕駛說出喚醒詞之後，車載系統将會首先給出定位提示，當主駕駛喚醒了系統并發出打開車窗的指令，那麼則需要打開主駕駛位旁的車窗，而副駕駛說打開車窗，則會打開副駕駛位置的車窗。
這部分所使用的技術就像之前所提到的固定波束算法，但是僅憑該算法卻無法完成這樣的任務。這裡基本的算法就是通過麥克風陣列的收音基本确定喚醒的方向，基本處理就是固定波束加上人聲檢測以及喚醒三個子產品的打通，而資訊流也不是單向的，可能需要傳回來。而且需要經過大量的調試工作才能實作這樣的功能，但是這樣的功能在裝載到實體車上之後，大家覺得是最有趣的并且感覺度最高的特性。這裡就是打通算法子產品的邊界，在例子中必須打通信号、人聲檢測以及喚醒子產品之間的邊界，互相融合才能完成這樣的小功能。
<b>打通：算法和産品的邊界</b>
另外一個案例就是電視“免喚醒”，當然這裡的“免喚醒”并不是真正的不需要喚醒，而需要使用字首“我要看”。從技術的角度而言，“我要看”可以視作一個喚醒詞，但是因為太短了，是以不敢用，可能會導緻誤喚醒率太高，但是産品經理還是要求實作，是以經過了技術與産品之間的讨論和妥協，最終設計出的技術方案就是打通整個鍊路，當發出“我要看XXXX”的時候會在界面上有所提示，也就是預喚醒階段，同時會走完整個互動的流程，一直到确定收到确切的結果時才會進行展示。通過加上預喚醒階段，不僅可以有效地降低誤喚醒率，并且不會讓響應時間延長太多。這就是打通算法和産品的邊界。
<b>打通：科學家和汽修工的邊界</b>
最後，也是最重要的就是在建構系統時需要打通科學家和汽修工的邊界。其實在建構實際産品的時候，僅僅依靠很牛的技術和子產品是不夠的，必須放下科學家的架子，跑到場景中解決各種各樣的實際問題。
<b>關鍵字2：測試</b>
<b>測試：工程品質</b>
系統傳遞也是軟體工程中的概念，而這裡的關鍵詞就是測試，對于測試而言，有一些比較傳統和經典的名額是大家所比較關注的，比如系統的穩定性、記憶體以及CPU的耗費以及移動裝置的流量耗費，包括伺服器的可能承受能力、并發度等。而人機互動是為了幫助人類完成任務，是以整個互動的延遲也是非常重要的。此外，一個比較有趣的就是異常的調用序列，調用任何一個比較長的鍊路就會有一系列的事件發生，如何保證序列的有效性，将事件串起來是互動裝置端上需要注意的部分。
<b>測試：機率(不确定)系統的确定性</b>
NUI平台的測試與傳統軟體系統中不太一樣的地方就是互動系統是機器學習系統、機率系統的串聯，每個子產品都是具有不确定性的系統，都可能是不靠譜的東西。那麼如何在這一堆不靠譜的東西中做出一個看似靠譜的系統呢？這就需要做更多的測試來保證。首先，需要對于各個子產品需要設定嚴格的準确率測試名額。僅有子產品準确率名額還不夠，需要打通來看，需要實作端到端的測試，模拟人機互動的過程，如果能夠建構一個自動化測試的工具就比較好，如果不能則需要投入更多的人力進行主觀的測試，找到現有系統中的問題，才能保證整個系統的可用性。關于測試的第三點就是比對産品特性的測試，這部分與NUI産品本身相關，因為産品經理會有很多想法，為了如何保證每個産品特性都被實施下來，需要根據産品本身思考很多的測試方法來保證品質。比如對于喚醒詞而言，就需要做安靜測試、有音樂回放的測試以及有外界噪聲的測試，以及在汽車中需要進行定向測試，保證一個方向發出語音指令，另一個方向的語音不能進來，包括之前提到的免喚醒詞，這每一項都需要詳細地測試才能保證整個系統傳遞出去才是正确的。
<b>關鍵字3：FBL (FeedBack Loop)</b>
在這部分的關鍵字就是FBL (FeedBack Loop) 回報閉環，這個與之前提到的NUI平台的三個觀點是相符的。第一個觀點就是NUI平台是一個機器學習系統，這個機器學習系統是一個非常典型的有監督的回報閉環，必須進行訓練、上線、拿到資料标注，再去重新訓練。每個子產品都需要思考如何去建構回報閉環，包括語音識别是否需要标注語音資料來更新聲學模型，是否分析線上Query情況爬取更多的語料來更新語言模型。對于自然語言了解，現在最大的問題就是覆寫度不夠，使用者會有很多奇怪的說法以及正确的意圖，并不能被捕獲到，而需要從日志中挖取這些，如何建構回報閉環都是開放性的問題，也是非常困難的。對于語言合成而言，為了使得語音更加好聽，比如天貓精靈會拉去實際的資料進行分析，針對資料進行特殊的優化使得語音更加好聽。喚醒以及後面的資料源都在跟随整個流程，分析線上的資料并進行相應的疊代。
那麼究竟應該如何實作FBL呢？其實在開始設計系統時就必須要有這樣的想法，在裝置上做足夠的埋點，這些埋點不僅是傳統的關于裝置的，比如每天有多少激活，裝置的資訊是什麼，還需要對于互動的過程做一些設計，比如什麼時候進行喚醒，喚醒詞是什麼，語音識别的結果是什麼，自然語言了解的結果是什麼以及使用者後期做了什麼樣的行為都需要被記錄下來送到雲端的日志系統中。在雲端需要基于這些資料建構足夠好的查詢與分析工具找到問題所在。對于自動化的訓練平台而言，首先橫向的項目很多，另外作為網際網路公司，疊代率非常快，快速地生成并且疊代自己的模型是非常重要的，語音互動組幾乎在每個子產品上都花費了很大的精力來建構自動化的訓練平台，有了資料之後能夠實作迅速疊代，越來越快地進行疊代，疊代到足夠好。另外一方面就是部署，部署上因為背靠阿裡雲，是以會有很多好用的工具，可以利用這些工具實作快速部署。
前面與大家分享了如何建構一個NUI平台，總結而言就是首先需要有一個基礎子產品，其次需要将子產品打通，打通子產品之間，打通子產品與産品，打通高大上的人與實際問題的邊界。其次，在整個實施過程中需要思考各種各樣的方法來保證工程品質以及準确率。第三點，如果做出的系統受到大家的追捧，就必須持續地進行疊代，在開始設計時就需要思考如何建構系統回報閉環，包括埋點、查詢以及模型疊代的過程，這些都是實施一個好的NUI産品或者智能助理産品的必要步驟。
<b>NUI的未來</b>
目前NUI的主流廠商都在将平台變得更加開放。阿裡巴巴也希望将自己的NUI平台做成一個普世的、完全開放的平台，這也是接下來需要努力的方向。首先就是将NUI平台在各種各樣的裝置上都實作可複制并且具有落地的能力。其次，因為現在的全鍊路都可以定制，那麼目标就是實作完全開放，包括硬體設計都可以開源；喚醒詞現在可以定制，未來則可以自由設定；而在語音識别部分，阿裡巴巴是走在最前沿的，現在對于阿裡巴巴的語音識别子產品而言，除了必須要使用雲服務之外，聲學模型和語言模型都可以自己定制，這也是其他廠商難以實作的，而至于其他子產品在未來也希望能夠做到像語音識别這樣的程度，這樣整個鍊路都可以被第三方把控，極大地提升平台的開放性。并且還需要将子產品融合在一起，将這些産品的優秀特性都做成一個完整的解決方案，當開發者裝上SDK之後就可以享受到全部的特性，同時可以在其上進行自由修改。
<b>NUI-更加自然的互動</b>
NUI未來會具有更加自然的互動能力，大緻會有三個方向，第一個就是多模态，目前阿裡巴巴也已經做出了一個嘗試，就是最近在上海釋出的地鐵售票機，這個是真的免喚醒的，因為其上有攝像頭，使用者可以直接走到售票機前說所需要購買的票即可；另外一個自然互動的方向就是個性化和場景化的方式，目前阿裡巴巴也做了一些比較好玩的嘗試，比如在打開車窗是車控裡面常用的操作，而在整個的對話系統中，不僅需要考慮車控本身，而需要根據所在的位置以及外面天氣的情形等資訊來提示使用者是否應該打開車窗；最後一點就是主動互動，其實主動互動目前并不成形，大家的手機每天彈出很多彈窗的時候雖然也叫作主動互動，但是卻是很惱人的主動互動，究竟應該在哪些裝置上做有用的主動互動也是極具挑戰的問題，需要小心地嘗試産品的特性，看看是否真的被大家接受了。而除了産品設計方面，主動互動還存在一些技術難點，這部分可以視為更自然互動的下一步。
<b>本文由雲栖志願小組賈子甲整理，編輯程弢</b>