932
人類與機器人，如何能像朋友一樣愉快聊天？
縱觀傳統互聯網時代，如果用一個詞來總結和概括的話，“連接”這詞再合適不過了，傳統互聯網時代，我認為主要建立了三種連接：第一，人和信息的連接；第二，人和人的連接；第三，人與商品服務的連接。第一種連接成就了Google和百度這樣的互聯網巨頭；人和人的連接成就了Facebook和騰訊這樣的互聯網公司，人和商品服務的連接，成就了Amazon、阿裏巴巴、京東這樣的巨頭。所以，從這個意義上看，傳統互聯網最典型的特征就是連接。
過去3-4年，我們可以看到，連接互聯網的設備發生了很大變化，設備已經從PC和智能手機延伸到更廣泛的智能設備，比如智能音箱、智能電視、機器人、智能汽車等設備。智能設備的快速發展正在改變著人和設備之間的交互方式。
我們梳理一下智能設備，大致可以分成三類：
第一，可穿戴設備，比如說智能眼鏡、智能手表。 第二，智能家居，比如我們熟知的智能電視、智能音箱、智能機器人、智能玩具。 第三，智能出行，比如智能汽車、智能後視鏡、智能行車記錄儀等。
我們從以下的一些數據來看智能設備的發展，這是美國市場做的調查：2015年的時候，美國市場上語音設備的出貨量是170萬台，到2016年的時候這個數據上升到了650萬台，大概是3-4倍的增速。專家預估，在2017年，這個數據將會上升到2450萬台。
我們再來看用戶，美國這邊對使用智能助理的用戶做了分析，把用戶分成了三類：第一類，嬰兒潮出生的用戶，即1945-1964年出生的；第二類，1965-1980年出生的；第三，80後、90後這批用戶。這個調查發現，80後、90後對於智能助理產品的接受度，遠遠高於其他兩類用戶，比如說，2016年，80後90後的用戶數大概在2300萬，其他兩個加到一起是2000萬多一點。2017年，預估的話大概是3000萬，2018年大概是3500萬，到2019年是4000萬。
所以，無論是用戶的接受度，還是智能設備的快速發展和普及，都在促使人和設備之間交互方式的巨大改變，我稱之為交互的時代。
今天的分享主要聚焦人和設備如何通過自然語言對話來展開對話交互的。
對話交互的特點，我認為主要有以下四點：
第一，人和智能設備和機器對話的交互一定是自然語言，因為對於人來說，自然語言是最自然的方式，也是門檻最低的方式。
第二，人和設備的對話交互應該是雙向的。即不僅是人和設備說話，而且設備也可以和人對話，甚至在某些特定條件下機器人可以主動發起對話。
第三，人和設備的對話交互是多輪的，為了完成一個任務，比如定機票，這裏會涉及多輪交互。
第四，上下文的理解，這是對話交互和傳統的搜索引擎最大的不同之處，傳統搜索是關鍵詞，前後的關鍵詞是沒有任何關係的。對話交互實際上是要考慮到上下文，在當前的上下文理解這句話什麼意思。
從連接到對話交互，一個本質的改變是什麼？舉個例子，比如淘寶網首頁，拋開內容，其本質就是鏈接和按鈕。對於用戶來說，無論是點擊鏈接還是按鈕，他的行為完全是由產品經理定義好的，他的行為是完全確定的，所以，我認為它是一種受控、受限的行為，這種方式才能確保比較好的用戶體驗。再來看這種對話交互，用戶可以說任何內容，天文、地理，包羅萬象，這樣一個完全開放的場景，機器人對自然語言的理解和把握對機器人來說是非常非常大的挑戰，從而帶來機器人回答的不確定性。
所以我認為從連接到對話交互這背後的本質改變是從確定性變為不確定性。那麼後麵無論是算法還是交互設計，基本上都要想辦法提高語言理解的確定性或者是降低交互的不確定性。
下麵分享阿裏巴巴在智能對話交互方向的進展和實踐。先看對話交互邏輯的概況，傳統的對話交互，大概會分以下幾個模塊：語音識別子係統會把語音自動轉成文字；語言理解就是把用戶說的文字轉化成一種結構化的語義表示；對話管理就是根據剛才的語義理解的結果來決定采取什麼樣的動作action，比如說定機票，或者設置鬧鍾。在語言生成這一塊，就是根據action以及參數生成一段話，並通過一種比較自然的方式把它讀出來。
對話係統架構簡圖
我認為現在人機交互和傳統的人機交互一個不同點就是在數據和服務這一塊，因為隨著互聯網的發展，數據和服務越來越豐富，那人機交互的目的是什麼？歸根到底還是想獲取互聯網的信息和各種各樣的服務，所以，在現在的這種人機交互的場景中，數據和服務起的作用會越來越重要。
語言理解簡單來說就是把用戶說的話，轉換為一種結構化的語義表示，從方法上會分成兩個模塊：用戶意圖的判定和屬性的結構化抽取。來看一個例子，比如用戶說，我要買一張下周去上海的飛機票，國航的。第一個模塊要理解用戶的意圖是要買飛機票，第二，使用抽取模塊，要把這些關鍵的信息出處理出來，出發時間、目的地、航空公司，從而得到一個比較完整的結構化的表示。
自然語言理解
人機對話中的語言理解麵臨哪些挑戰呢？我總結為四類：
第一，表達的多樣性。同樣一個意圖，比如用戶說，我要聽《大王叫我來巡山》，但是，不同的用戶有太多太多不同的表達方式，我要聽歌，給我放一首音樂等等。那對於機器來說，雖然表達方式不一樣，但是意圖是一樣的，機器要能夠理解這件事情。
第二，語言的歧義性。比如說，我要去拉薩，它是一首歌的名字，挺好聽的歌。當用戶說，我要去拉薩的時候，他也可能是聽歌，也可能是買一張去拉薩的機票，也可能是買火車票，或者旅遊。 第三，語言理解的魯棒性，因為用戶說話過程當中，比較自然隨意，語言理解要能夠捕獲住或者理解用戶的意圖。 第四，上下文的理解。這是人機對話交互與傳統的keyword搜索一個非常大的不同，它的理解要基於上下文。
在語言理解這一塊，我們把用戶語言的意圖理解抽象為一個分類問題，把它抽象為分類問題之後，就有一套相對標準的方法解決，比如CNN神經網絡、SVM分類器等等。阿裏巴巴現在就是采用CNN神經網絡方法，並在詞的表示層麵做了針對性的改進。機器要理解用戶的話的意思，背後一定要依賴於大量的知識。比如說，“大王叫我來巡山”是一首歌的名字，“愛探險的朵拉”是一個視頻，互聯網上百萬量級這樣開放領域的實體知識並且每天都會有新的歌曲/視頻出現，如果沒有這樣大量的知識，我覺得機器是很難真的理解用戶的意圖的。那麼在詞的語義表示這塊，除了word embedding，還引入了基於知識的語義表示向量。
剛才提到了，用戶的話實際上是比較隨意和自然的。那我們怎麼樣讓這個模型有比較好的魯棒性來解決口語語言的隨意性問題呢？我們針對用戶標注的數據，通過算法自動加一些噪音，加了噪音之後(當然前提是不改變語義)，然後基於這樣的數據再training模型，模型會有比較好的魯棒性。
第二個模塊是屬性抽取，在這一塊，我們把它抽象為一個序列標注問題。這個問題，神經網絡也有比較成型的方法，我們現在也是用這種雙向LSTM，在上麵有一層CRF解碼器，取得了不錯的效果。當然其實在方法論上還是在神經網絡框架下還是比較常見的或者說是標準的，但是這背後更大的功夫來自於對數據的分析和數據的加工。
以上所述的人機對話語言理解最大的特色就是基於上下文的理解，什麼是上下文？我們看一個例子，用戶說“北京天氣怎麼樣？”，機器回答說“北京的天氣今天溫度34度”。接著用戶說“上海”呢？在這裏的理解一定是理解他指的是上海的天氣，所以是要能夠理解用戶說的話，是和上文有關係的，所以我們再對問題做了一個抽象，在上下文的情況下，這句話和上文有關還是無關，把它抽象為二分的分類問題。這麼做了抽象和簡化以後，這個事情就有相對成型的方法。
剛才介紹的是語言理解。
對話引擎：就是根據語言理解的這種結構化的語義表示以及上下文，來決定采取什麼樣的動作。這個動作我們把它分成幾類。第一，用於語言生成的動作。 第二，服務動作。 第三，指導客戶端做操作的動作。
我們來看一個簡單的對話例子。用戶說我要去杭州，幫我訂一張火車票，這個時候機器首先要理解用戶的意圖是買火車票，之後就要查知識庫，要買火車票依賴於時間和目的地，但是現在用戶隻說目的地沒說時間，所以它就要發起一個詢問時間的動作，機器問了時間之後，用戶回答說“明天上午”。這個時候機器要理解用戶說的明天上午正好是在回答剛才用戶問的問題，這樣匹配了之後，基本上這個機器就把這個最關鍵的信息都收集回來了：時間和目的地。之後，機器就可以發起另外一個請求服務指令，然後把火車票的list給出來。這個時候用戶接著說，“我要第二個”。機器還要理解用戶說的第二個，就是指的要打開第二個鏈接，之後用戶說“我要購買”，這個時候機器要發起一個指令去支付。
綜上，對話交互，我會把它分成兩個階段：
第一階段，通過多輪對話交互，把用戶的需求表達完整，因為用戶信息很多，不可能一次表達完整，所以要通過對話搜集完整，第一階段得到結構化的信息（出發地、目的地、時間等）；有了這些信息之後，第二階段就是請求服務，接著還要去做選擇、確定、支付、購買等等後麵一係列的步驟。
其實，傳統的人機對話，包括現在市麵上常見的人機對話，一般都是隻在做第一階段的對話，包括像大家熟知的亞馬遜Alexa，也隻是在解決第一階段的對話，第二階段的對話做得不多。
我們在這個對話交互這塊，在這方麵還是做了一些有特色的東西。
第一，我們設計了一套麵向Task Flow的對話描述語言。剛才說了，對話其實是分兩個階段的。傳統的對話隻是解決了第一階段，我們設計的語言能夠把整個對話任務流完整地表達出來，這個任務流就是類似於咱們程序設計的流程圖。對話描述語言帶來的好處是它能夠讓對話引擎和業務邏輯實現分離，分離之後業務方可以開發腳本語言，不需要修改背後的引擎。
第二，由於有了Task Flow的機製，我們在對話引擎方帶來的收益是能夠實現對話的中斷和返回機製。在人機對話當中有兩類中斷，一類是用戶主動選擇到另外一個意圖，更多是由於機器沒有理解用戶話的意思，導致這個意圖跳走了。由於我們維護了對話完整的任務流，知道當前這個對話處在一個什麼狀態，是在中間狀態還是成功結束了，如果在中間狀態，我們有機會讓它回來，剛才講過的話不需要從頭講，可以接著對話。
第三，我們設計了對話麵向開發者的方案，稱之為Open Dialog，背後有一個語言理解引擎和一個對話引擎。麵向開發者的語言理解引擎是基於規則辦法，能夠比較好的解決冷啟動的問題，開發者隻需要寫語言理解的Grammar、基於對話描述語言開發一個對話過程，並且還有對數據的處理操作。這樣，一個基本的人機對話就可以完成了。
問答引擎：其實人和機器對話過程中，不僅僅是有task的對話，還有問答和聊天，我們在問答引擎這塊，目前還是著力於基於知識圖譜的問答，因為基於知識圖譜的問答能夠比較精準地回答用戶的問題，所以我們在這方麵下的力氣會多一點。
聊天引擎：在聊天這塊，我們設計了兩類聊天引擎。
第一是基於對的聊天引擎，它能夠實現讓業務方定製，為什麼要定製呢？舉個例子，在不同的場景下，機器的名字可能是不一樣的，用戶A和用戶B給機器的名字是不一樣的，我們有了這個機製之後，可以去定製機器的名字。但是這一方法的覆蓋率是比較受限的。為了解決覆蓋率的問題，我們又設計了基於seq2seq的生成式聊天引擎，這種生成式聊天，能夠對開放的用戶說的問題給出一個相對通順並且符合邏輯的回答。當然這兩類聊天引擎會有一個協同的策略在裏麵。
剛才語言理解引擎、對話引擎、聊天引擎再加上語音識別合成，形成了完整的一套係統平台，我們稱之為自然交互平台。在這套平台上，一端是連接著各種各樣的設備，另外一端是連接了各種各樣的服務，這樣的話，用戶和設備的交互就能夠用比較自然的方式進行下去了。
值得一提的是，這樣的自然交互平台在阿裏巴巴已經有比較多的應用了。無論是在汽車、電視、音箱、機器人中，比如說在互聯網汽車對話交互，我們和合作夥伴設計開發了汽車前裝和汽車後裝場景的對話交互。前裝指的是我這個汽車在出廠的時候就有了對話交互能力，後裝是指買了車之後再買一個設備，比如說行車記錄儀、導航儀之類的。
在功能上，比如說像地圖、導航、路況，還有圍繞著娛樂類的音樂、有聲讀物，還有實現對車的控製，在車的控製這塊當然是受限的，現在能實現對車窗玻璃的控製。 在汽車場景下的對話交互，還和其他場景有非常多的不同。因為產品方希望當這個車在郊區網絡不好的時候，最需要導航的時候，你要能夠工作，所以我們的語音識別還有語言理解、對話引擎，就是在沒有網絡的情況下，要在端上能夠完全工作，這裏麵的挑戰也非常大。
有了這樣一個對話交互平台，我們正在把這樣的平台開放出來，讓合作夥伴去開發自己場景的對話交互，所以我們正在開發麵向開發者的平台，這個平台背後有端上的解決方案和雲上的解決方案，端上包括聲音的采集、VAD、端上無網情況下完整的對話方案，服務端的能力更強大一些。
在合作夥伴這塊有兩類。一類是麵向設備的，比如說汽車、電視、音箱、機器人、智能玩具。 另外一類就是類似於行業應用，比如說智能客服這樣的一個場景。
考察一個對話交互平台的能力，主要看它背後的沉澱和積累的核心能力，我們在這方麵花了三年的時間去沉澱了一些公共場景的對話交互能力。比如像娛樂、出行、理財、美食，有了這樣的能力之後，當一個新的業務方接入的時候，就不需要再去開發了，直接調用就好。他隻需要開發業務場景中特定的一些場景就可以，能夠大大地加快業務方開發對話交互的速度。
其實對話交互平台背後第二個能力，就是提供足夠強的定製能力，這種能力我們在語言理解，用戶可以定製自己的時點、對話邏輯、聊天引擎、問答引擎，可以把自己積累的數據上傳上來，以及對語音識別的詞語定製，包括TTS聲音的定製等等。
過去3-4年，在人機對話領域，應該是說還是取得了長足的進步，這樣的進步來自於以深度學習為為代表的算法突破。這個算法的突破帶來語音識別大的改進。同時，另一方麵我們認為對話交互和真正的用戶期望還是有明顯的距離的，我認為有兩點：第一，對話交互能覆蓋的領域還是比較受限的，大家如果是用智能語音交互的產品，你就發現翻來覆去就是那幾類，音樂、地圖、導航、講笑話等等。第二，有的能力體現得還不夠好，所以我們想未來怎麼辦呢？
我們先看看現在的模式，有幾種模式，我把它總結為兩類模式。第一類，自主研發。很多的創業公司或者是團隊基本上都是自主研發的，像蘋果它基本上是自主研發的模式。第二類，平台模式，比如說典型代表就是亞馬遜的Alexa，這個平台的一個好處，它能夠發動開發者的力量快速地去擴展領域。但是你會發現現在在亞馬遜Alexa上有8000多個這種能力，但是很多領域的體驗都不夠好，根本原因在於開放平台上開發的這些skill沒有很好的評測手段和質量控製機製。
自主研發的好處是體驗相對較好，平台模式的好處是能夠快速擴展。所以如何把這兩者結合在一起，有沒有第三種模式。
如果有，第三種模式應該有以下幾個特點。
第一，由於自然語言理解的門檻還是比較高的，門檻高指的是對於開發者來說，它比開發一個APP難多了，從無到有開發出來不難，但要做到效果好是非常難的。所以，語言理解引擎最好能夠自研；
第二，對話邏輯要平台化。對於對話交互因為它和業務比較緊，每個業務方有自己特殊的邏輯，通過平台化比較合適，讓平台上的開發者針對各自場景的需求和交互過程來開發對話；
第三，需要建立一套評測體係，隻有符合這個評測體係的，才能引入平台當中；
第四，需要商業化的機製，能夠讓開發者有動力去開發更多的以及體驗更好的交互能力。
如果這幾點能夠做到，我們稱之為第三種範式，基於這個範式的平台能夠相對快速地並且開發的能力體驗是有效果保證的。這樣它開放給用戶的時候，無論是對B用戶還是C用戶，可以有更多的用戶價值。
最後，總結下我們對於研發對話交互機器人的幾點思考和體會：
第一，堅持用戶體驗為先。這個話說起來很容易，但是我們也知道，很多團隊不是以用戶為先的，是以投資者為先的，投資者喜歡什麼樣的東西，他們就開發什麼樣的東西。堅持用戶體驗為先，就是產品要為用戶提供核心價值。
第二，降低產品和交互設計的不確定性。剛才也提到了，對話交互實際上最大的問題是不確定性，在產品的交互上我們要想辦法把這種不確定性盡量降得低一點，惟有通過設備設計的時候降低，或者是交互界麵的降低，或者是通過對話引導的方式，把這種不確定性盡量降低。
第三，打造語言理解的魯棒性和領域擴展性。語言的理解能力盡量做到魯棒性，能夠比較好的可擴展。
第四，打造讓機器持續學習能力。對話交互我認為非常非常重要的一點，就是怎麼樣能夠讓機器持續不斷地學習。現在的這種對話交互基本上還都是有產品經理或者是人工定的，定好之後這個能力是固化的，所以怎麼樣能夠把算法（策劃學習）能力打造出來，就像小朋友學語言一樣，隨著年齡的增長，能力會持續不斷地增強。
第五是打造數據閉環。要能夠快速地達到數字閉環，當然這個閉環當中要把數據的效能充分調動起來，結合更多數據的服務。
本文根據千訣（博士，阿裏巴巴資深專家） 2017年5月18在中國雲計算技術大會上的演講整理。
原文鏈接
最後更新：2017-07-12 09:32:37