對話機器人70年:科幻與現實的交融
摘要:本文將圍繞對話機器人相關技術及其在行業中應用實踐展開,同時介紹華為雲對話機器人在多模態、小樣本、預訓練方向上的最新進展。
從 1950 年圖靈測試的提出到現在,對話系統已經走過了將近 70 年的時間,在這期間對話系統技術得到了快速的發展。方法也從當初的規則演變成如今的深度學習方法,對話系統的魯棒性和準確性都得到了大幅提升。2020 年,自然語言處理頂級會議 ACL 被接收論文中,對話系統相關工作論文數量達到歷史之最,這也進一步驗證了對話系統最近幾年得到了非常大的關注。
本文將圍繞對話機器人相關技術及其在行業中應用實踐展開,同時介紹華為雲對話機器人在多模態、小樣本、預訓練方向上的最新進展。將按照以下 5 部分展開:
1. 對話機器人介紹以及歷史簡單回顧
2. 對話機器人中的自然語言理解
3. 對話機器人中的對話管理
4. 多模態對話機器人進展
5. 對話機器人未來方向以及總結
一、對話機器人介紹以及歷史簡單回顧
回顧對話機器人的發展歷史,首先要提及的就是著名的圖靈測試。1950 年圖靈發表了一篇論文《計算機器與智慧》,首次提出了對人工智慧的評價準則,也就是圖靈測試。其含義是指測試者和被測試者,通常是一個人和一臺機器,在彼此分隔的情況下,由測試者通過一些裝置向被測試者隨意提問。如果經過一段時間的交流後,有超過 30% 的測試者不能區分出哪些問題是由人或機器回答的,那麼就證明這臺機器通過測試,並且認為機器具有了一定的人類智慧。雖然說用圖靈測試來評測對話系統目前存在很多的爭議,但不妨礙圖靈測試的思路引領了幾十年間對話系統的發展。
圖靈測試誕生後第一個人機對話系統是 ELIZA,由 Weizenbaum 於 1964 年到 1966 年間在 MIT 編碼完成。ELIZA 主要是用在臨床治療中去,來模仿心理醫生對患者提供諮詢服務。當時只是用一些關鍵字的識別,但反響還是比較大的。時間跨越到 1995 年,業界誕生了一個非常聰明的,而且很有大眾知名度的對話機器人 Alice。Alice 三次獲得了羅伯納獎。羅伯納獎是重要的人工智慧的競賽,採用的是標準化的圖靈測試,評審會選出參賽程式中最像人類的。Alice 的成績為什麼如此驚人?主要原因在於其使用了 AIML 語言,在當年和同類產品相比具有很大的的競爭優勢。
總結這時期對話機器人的功能,基本都是基於關鍵字的識別,或者是通過專家系統的規則來構建的對話系統。但是,隨著專家系統規則的演變,逐漸地出現了瓶頸。而基於資料驅動方法就得到很廣泛的研究,並且慢慢地應用到了對話系統中。這一時期的對話系統主要是由自然語言理解這個模組來驅動,同時會結合基於強化學習的對話管理。為了解釋它為什麼是由自然語言理解和對話管理來驅動這個問題,研究者們做過兩個典型的工作:在 2005 年到 2013 年,劍橋大學的 Steve Young 教授提出了基於 POMDP 的對話管理,以及一個基於管道 Pipeline 方式的對話系統。
這一時期,基於機器學習自然語言理解方法百花齊放,出現了很多經典的機器學習模型。上文提及的劍橋大學 Steve Young,就是現在蘋果手機裡面後臺的 Siri 之父,為後續的深度學習的方法的對話系統研究,包括應用落地,打下了非常堅實的基礎。基本上形式化了很多對話系統的經典的問題。但是隨著後面的發展,基於傳統的機器學習也很快遇到了瓶頸,特別是在語音識別和影象分類方面,準確率無法得到很大的提升。所以在第三代的研究中,這些系統基本上轉向了基於大資料和深度學習的技術。比如現在大家熟知的,Amazon Alex、Google Home、Siri 這些助手類機器人。它們其實主要是以深度學習方法,即意圖的識別、語言理解的方式。基於深度學習技術,使得端到端的對話系統變得可行。
最近的幾年的研究中,端到端的對話系統得到了越來越多的關注和投入。2017 年開始,對話系統已經開始大規模在行業落地應用了,也有人稱 2017 年是對話機器人的元年。
那麼,為什麼需要對話系統、對話機器人呢?對話機器人到底有什麼用?我們為什麼要研究它?這點要從對話機器人巨大的需求背景講起。
需求主要是在兩個方向,一個是 to B,另一個是 to C。to B 場景比如企業客服,客服人員的勞動是簡單重複的,可以用對話機器人自動客服取代人類客服。其二是辦公助手,像華為 Welink,即類似釘釘、微信、WeChat 一樣的辦公類軟體,其實也有一部分可以去輔助人觸達一些應用。這種辦公類的助手,可以幫助訂機票,新建日程。還有一個方向是市場銷售,機器人也可以幫助企業做一些推銷、銷售、介紹產品。
對於 toC 來說,一個典型的應用是個人助理,特別像家裡會涉及到音箱等,這些個人助理現在有很大的應用背景。包括針對老人、小孩等特定人群的情感陪護需求,相對應的可以開發情感陪護的機器人。甚至有些機器人可以與小孩進行同步學習,教小孩一些課程,做一些娛樂的活動。
那麼什麼是對話機器人?首先通過最後三個字 “機器人”,第一個想到可能是一個實體機器人。確實,實體機器人可以做人機對話互動,特別像科大可佳機器人,能夠做一些多模態互動,給人類情感上一些陪護,甚至機器人它可以根據人的指令去做一些家居的控制,科大的可佳機器人可以去操作冰箱、微波爐, 可以聽懂人的指令去操作環境上的一些物體,另外類似日本的阿森姆機器人,這一類機器人就是實體類的硬體機器。還有一類是虛擬的軟體機器人,它可以部署在我們的作業系統裡面,像微軟的 Cortana。也可以部署到硬體裡面,甚至是手機裡面,像 Siri、Amazon Alex。
總結一下,對話機器人主要的目的是希望能夠通過多輪對話的方式幫助使用者完成任務,或者是保持使用者持續的一個有效的交流,並且可以部署到大量的硬體裝置裡面去。
這裡將對話機器人做兩個分類,第一類是任務完成型的對話機器人,第二是閒聊型對話機器人。上圖表格是兩種機器人的對比,我們可以稱之為一個是理性機器人,一個是感性機器人。
任務完成型對話機器人它可以偏理性一點,它需要去做一些任務。通常它可能需要呼叫一些知識庫,或者一些服務後臺的 API。但感性機器人即閒聊對話機器人,對產品層級來說,它可能會更偏向於感性一點,需要理解使用者的一些情感。任務完成型對話機器人它一般都有特定的目標,因為它確實需要完成一些具體的任務。閒聊對話機器人它通常是沒有特定的目標的,它會跟你一直持續的聊下去。而且從對話輪數控制來說,任務完成型對話機器人它希望是對話輪數越少越好,因為越少越好,能更快地達到目標。閒聊對話機器人它可能希望能夠跟人對話次數越來越多,而且能夠持續的交流下去。
任務完成型對話機器人它通常包含多個模組,而且可以採用規則或者統計學習的方法。但閒聊對話機器人它通常採用一些檢索,或者是 sequence to sequence 的生成方法,這是這兩類方法的不同點。下文將重點在任務完成型這一類機器人上展開內容。
從歷史角度看,從圖靈測試到現在已經 70 年過去了,對話機器人這一領域目前還是存在非常大的挑戰。大體總結為以下幾點:
首先,語言的多樣性非常複雜,一個含義可能有各種各樣的表達。同樣,同一個表達,在不同的語境下代表的含義可能不一樣,也就是語言的歧義性。
語言的多樣性和歧義性會給對話機器人的進展帶來非常大的挑戰。
此外還有語義的表示,首先需要讓機器去理解語言,而語言本身的符號是無法被機器所理解的,需要把符號轉換成機器的內部表示。那麼內部表示怎麼定義呢,什麼樣的內部表示才是豐富的呢。但是表示越豐富,對應的學習能力可能越弱,反之表示越弱,可能學習得越快,這需要如何權衡呢?
再者是系統的魯棒性,關於精度和召回的平衡。對話機器人也面臨著一個問題,特別是在 to B 場景裡面資料是極度匱乏的,在沒有資料情況下,如何去進行訓練,如何去做模型的調優,如何保證它的魯棒性?還包括現在深度學習的可解釋性,面對符號和環境知識的橋接。當機器人跟人對話時,它一般會建立在共同的知識基礎上,大家都知道中國的首都是北京,但如果機器人不知道這個知識,那它怎麼跟人繼續交流呢?
上圖是一個對話機器人常用的框架流程,主要分三個模組。第一塊是自然語言理解,自然語言理解的目的就是將自然語言文字轉成機器內部語義表示。任務型對話它通常有個假設。假設語義表示,它是由三個語義元素來組成的,一個是領域、一個意圖、一個槽。一個領域通常是包含多個意圖,比如天氣這個領域,有可能查天氣,有可能查溫度,有可能是查風向,這些不同的意圖,通常一個意圖上可能有多個槽,我說查天氣它查的是什麼呢?可能有時間、可能有地點,槽可能是任務型對話裡面的概念,大家可以認為槽是一個關鍵字的這樣一個關鍵資訊的概念,類似於時間、地點,也可以是使用者定義的任何的一個詞條型別。
這裡舉個例子,當用戶說:“今天深圳天氣怎麼樣”,自然語言理解的任務就是需要識別出來這句話裡面領域和意圖是什麼。所以輸出領域為天氣,意圖是查天氣。句子中提取到時間和地點槽位,時間是今天,地點是深圳。通常在實際落地應用裡,還需要把時間今天翻譯成一個真正的一個時間表達,比如說 2020 年 8 月 26 號。讓後臺系統方便對接。
自然語言理解模組之後,進入對話管理的模組,其中包含兩個子模組,對話狀態跟蹤和對話策略。從對話管理職責來看,這一步的輸入就是自然語言理解模組的輸出,輸出是一個 action,action 表明系統應該去做什麼,應該回復給使用者什麼東西,而且這個生成的 action 一般是一個形式化的、結構化的內容,所以說它一般會再經過一個自然語言生成的模組。
自然語言生成模組的目的就是把對話管理的輸出,轉成一個使用者能夠理解的自然語言描述,這個時候它會生成一個回覆就是:“好的,今天深圳的天氣是晴,溫度 20~30 度。”這麼一條自然語言描述。這就構成了非常典型的對話機器人的常用框架。
重點來看,對話管理又可細分對話狀態跟蹤和對話策略模組。對話狀態跟蹤的意思就是需要輸入自然語言理解的結果,同時需要去更新機器裡面內部維持的狀態,它狀態跳轉到什麼地方了,而且每一個槽的值發生了什麼變化。比如說像這裡面已經知道時間是今天,地點是深圳,當沒有獲取到這個資訊的時候,它之前的時間、地點肯定是空的、未知的,當接受到這個資訊,需要去更新它,時間,原來是今天,地點是深圳,這就是對話狀態跟蹤需要做的。對話策略就是需要根據這些機器人裡面的狀態,去選擇一個行動,這個行動就需要去反饋給使用者,圖上所示就是通過狀態的結果,去生成一個 inform動作。
二、對話機器人中的自然語言理解
那麼,華為雲在自然語言理解方面有哪些實踐、進展?首先來講講對話機器人中的自然語言理解模組。
自然語言理解模組任務包含三個任務,一個是領域識別,一個意圖識別,一個槽填充。
領域識別、意圖識別其實它任務是一樣的,都是一個分類任務。在上圖的圓圈裡,是我們涉及到的一些典型的演算法,在領域、意圖識別裡面。左下角就是一些規則的方法,前面對話機器人的歷史介紹的時候有提到過,主要包括一些關鍵字的識別,正則規則,然後上下文無關文法。這一塊其實工業界機器人平臺也有在使用。
上圖左上角是傳統的機器學習方法,像傳統的 SVM、決策樹,甚至 LR 的一些方法。到後面深度學習裡面用的比較多了,像 TextCNN,Fasttext,包括 R-CNN。從最近幾年趨勢來看,其實預訓練已經開始流行了,甚至分類識別的一個任務的正規化其實已經發生改變了。像基於BERT,華為的 NEZHA 這樣的預訓練的模型加微調方式,都可以很好的去做這類任務。
針對一些平臺級的,特別是 to B 的場景,有很多不同型別的場景,因為有些企業可能沒有資料,有些企業資料量不多,而有些企業確實隨著日誌的產生,它有很多資料。針對不同的資料,不可能一上來就套用BERT或一個預訓練模型,這種方法是不太可行的。
針對這些不同情況我們做了一些探索。先看如果在無樣本情況下,如何做這樣的領域一種識別,所以說華為雲的一些對話機器人技術平臺上,其提供了一些規則的方式定製,因為規則的話,一旦配置一條規則,其實它能泛化識別出大量的文字,在規則裡面提供適配的一些萬用字元,包括它可以配置一些槽位的欄位,甚至一些普通的欄位,普通欄位可能是一些 word,包括使用者自己的字典,這些都可以配置。右邊是給的一些示例,通過這些規則配置,我就可以做一些冷啟動的方式。即使在這個使用者沒有訓練資料的情況下,也有很大的幫助。
第二種情況,有很多資料時如何選擇最好的方法呢?這就要用到最近幾年眾人熟知的,通過預訓練加微調的方式,像上圖右邊這種方式,基本的結構是 transformer,transformer 之後輸出了一個CLS標籤的 Logits,後面接個全連線層,來預測做分類。
這種任務通過大量的實驗後發現確實效果比較好,比如雲上辦公軟體華為 Welink。Welink 有一些助手的意圖,在 80 多家意圖裡面,每個意圖給它分配 10 條語料、50 條語料、100 條語料,然後把所有語料放進去,它的效果確實不斷遞增,而且最終效果基本上可以達到 95% 以上的效果。如果你資料越多,它效果確實會答的非常好。不過存在一個問題,即部署成本較高。因為如果每個使用者都上一個 BERT,成本上的壓力是很大的。雖然說它是通過預訓練的方式加微調,但仍然需要交大量的資料。
我們有沒有其他方法去解決呢?有的,可以使用一些模型蒸餾的方法來解決,例如上圖 Tiny-NEZHA 這樣一個蒸餾的方式去把大模型去蒸餾到小模型裡。NEZHA 其實跟 BERT 本身模型上其實差距不是很大,都是基於 transformer的結構,但它有一些細微上的結構上的不同,一是可能採用一些相對位置編碼放,第二個就是字掩碼,因為字掩碼可能是字,或是基於詞級別的掩碼,和增大 batch size 可能會用一些混合精度訓練,包括 LAMB 優化器,這四點可能會有點不一樣。
第二塊就是我們的蒸餾技術 Tiny-BERT,會在兩個地方都做蒸餾,一個是在預訓練中的通用蒸餾,通用蒸餾即在訓練裡面也可以做蒸餾。第二個就是在任務相關的其實也可以做蒸餾,也做了一些資料增強的工作,中文系列模型 NEZHA 的話已經也開源了,程式碼和模型可以公開下載。
蒸餾方法如何實現呢?首先要想清楚學什麼,其次知道怎麼學。因為大模型 teacher 和 Student 原本就可以學很多向量的表示了,向量生成的一個表示,包括本身的隱藏 State 等都可以去學。每個層學的方向不一樣,在輸出層,可以通過傳統的 logits 學生模型的預測層的 logits 上去擬合 logits,在中間層,就是一個 Embedding 層的一個蒸餾,可以去用 MSE 去不斷的去逼近中間層的表達。
通過這幾種方式,其實在NLPCC任務裡面其實也做了很多這樣的蒸餾實驗,包括大小模型、高瘦模型、矮胖模型等,還包括如下面表格裡面,在 4 層在 6 層在 8 層裡面它的一個對應的效果。最終結果還是看上圖的右上角,在 ChineseProve 這樣一個小模型任務,我們最後 score 達到 77.7 分,拿到第一位。
假如需要再輕量級的模型,是否還有其他方法?對工業界來說,可以結合一些傳統的特徵,也可以結合一些深度的特徵。傳統的特徵例如語言模型、詞性、實體,包括同義詞、停用詞這些都可以利用上,而深度特徵像 word2vec,包括結合一些淺層的深度學習的編碼器等都可以實現。
第二個問題,在沒有大量的資料前提下,也就是小樣本場景下的領域意圖識別如何處理。這種情況下,隨時會加一些新的類別,而且新的類別下可能幾條資料,無法跟之前的資料一起訓練。
這種情況下學界提出小樣本學習的概念,其目標是隻需提供你若干個樣本(可能是 1~5 個樣本),根據這 1~5 個樣本去學習,來判斷這個類別是什麼。
小樣本學習的思路分兩個過程,一個是元訓練的階段,這一步非常簡單。有一個基本的訓練資料後,把這個基本的資料劃分成兩個集合,一個是支撐集,一個是詢問集,支撐集裡可能是每個類別是非常有限的,只能 sample 句子,k 通常很少很少可能 1~5 個, Query 可以自己選。最後元測試的階段就隨機去採 1 到 5 個樣本,再輸入一個 Query,通過這批小樣本是不是能夠預測正確。
小樣本學習有三種不同型別的方法,像剛見過的基於模型的,還有基於 optimize的優化的方式,此外還有基於度量的方式。我們在度量方式做了一些探索。
度量方式分很多種,比如 MatchingNet 是匹配的網路;原型網路 protoNet,唯一的不同就是 distance 計算不太一樣,此外還有 relationnet。我們在小樣本上跟傳統的 BERT預訓練加微調的方式確實做了對比。在十個類別、五個樣本都做了一些對比的實驗。BERT傳統分類有 83.2% 準確率,但小樣本學習的方法可能達到 93% 的準確率,提高確實比較大。最終十個類別十個樣本最終能達到準確率 96% 的效果。
同樣,在實驗的過程中也發現了一個問題,為什麼它能達到準確率 96%?這背後有個取巧方法,目前小樣本學習也存在這樣的現象。在已有框架下是每個 Epoch 的訓練測試資料其實是隨機取樣的,當有 2000 個類別時,隨機採 5 個,而資料本身包含大量簡單樣本時,這樣的取樣方式很難涵蓋到其中的困難樣本,所以實際效果十分存疑。為此,我們也做了實驗,提出了一個結合小樣本學習和課程學習的方法。方法分為幾部分,一部分先做難度的評估。我們可以採用 BM25 或 TFIDF計算一下每個樣本之間的差距,專挑那些難的樣本放在一起來學習。另一部分做資料劃分,可以把相似難度的資料劃分到一起。
在之前的實驗裡面,直接用難的樣本去訓練效果如上圖所示是非常非常差的。換一個思路,在能夠保證測試級別比較難的基礎上完成學習訓練,但發現效果還是會下降得很快。而前文講過測出來可能會達到準確率 96% 的效果,但這樣分析和實驗後,會發現真實的小樣本學習其實沒有這麼好的效果。為了解決這種情況,就要結合課程學習,不斷從易到難。
最終如上圖,提高三到六個點的準確率,目前工作也在也在持續地進行中。可以得到的結論是,在簡單資料上,課程學習雖然不能顯著提升效果,能提高 3 到 6 個點的準確率,但確實可以降低方差(方差就是說原本我隨著訓練的難度,測試難度越大,好跟不好差距特別大),而且直接使用傳統的小樣本學習的方法,在難的樣本里其實並不能取得很好的效果,之前能達到準確率 95% 這樣的效果其實是不可信的。同時加入小樣本加課程學習,在難樣本上提升效果比較明顯。
再來看槽填充方法。比如說使用者想要預定明天去北京的機票,機器人需要提取出來 time 是明天,而 destination 是北京,通常在實際使用中明天可能會需要轉成一個具體的時間表達,這樣一個任務可以轉換成一個序列標註任務
在線上場景中除了可以採用 CRF、LSTM-CRF、BERT 這些模型,一般情況下有一套完整流程,通常對話前會內建一些實體,首先會做自定義的實體識別,其目的在於作為一個實體的歸一化和做細度的特徵提取,之後才會輸入到模型裡,來提高模型的泛化能力。同時還會結合槽填充的規則做融合,得到輸出結果。
應用場景中,槽填充會有哪些問題呢?首先是時間歸一化,時間表達會比較多。另外不同的客戶人名可能不太一樣,人名錶達也具有多樣化,不同使用者人名的識別也會帶來一些難度。同時模型和規則的融合方法也存在挑戰。最後就是多輪中可能會有一些槽填充的問題。新平臺裡面需要內建一些槽位,這樣使用者用起來可能會比較方便、簡單。
從上文可以看出,將領域識別、意圖識別槽填充拆開出來當多個任務會帶來一些問題:
領域識別和意圖識別會產生錯誤,槽填充也會產生錯誤,經過一層一層 pipeline 可能會疊加一些誤差。這個時候可以採用多工模型的方式,即把這三個標籤資訊、三個語料同時去放到一個模型裡面去學習;
如上圖模型,融合bert和crf對領域、意圖、槽聯合建模,實驗結果也證明確實會帶來較大的提高。傳統的 CRF 模型可能效果確實不是很好,最後的 ChunkF1 可能只能達到 0.79 的準確率。通過 BERT 它可能達到 0.87 的準確率。加入領域識別槽填充這一系列後,最後的 ChunkF1 大約能提高大概兩個點。
三、對話機器人中的對話管理
為什麼對話機器人需要對話管理模組呢?為什麼不直接用自然語言理解直接對接服務 API?對話管理模組存在很有必要,而且是對話系統的核心,其原因在於使用者很多情況下不會一次性表達完意圖,同時系統各個模組的準確率,也並不一定能達到 100% 的準確。不管是語音識別或者自然語言理解本身解析都可能產生錯誤,導致反饋不正確的回覆,或者根本就不知道怎麼回覆。這兩種情況都需要機器人跟使用者進行多次的交流確認,才能獲取使用者的完整的意圖,也就是需要對話管理模組來完成這部分工作。
對話管理一般分為狀態跟蹤和對話策略的學習兩部分。狀態跟蹤就是用來跟蹤使用者的目標,比如使用者當前說了什麼、之前說了什麼。上圖左邊是一個簡單的狀態集合,包括可能有一些相關的狀態之間跳轉,可以看到通常會有狀態如何跳轉的先驗知識。右邊的結構是隨著使用者跟機器人的對話同時進行的。使用者說 “我要預定明天去北京的機票”,這時使用者狀態從空就跳到了目的地出發地這樣一個狀態,並隨著問題互動的進行,直到填充所有的槽位。這樣一個過程是通過狀態跟蹤來做的。
再來看對話策略,對話策略的目的是告訴機器人應該說什麼。看一個例子,按照上圖紅色框所示,根據輸入的當前狀態的資訊,使用者已經輸入目的地了並告知了出發時間,系統應該去判斷,發現出發地是未知的,這時的策略也很簡單,提問 “請問從哪裡出發?” 而不是 “請問去哪裡?”。
對話管理任務到底存在哪些問題和困難呢?
首先,是使用者的意圖是無法事先知道的,使用者隨時可能會說任何其他的話,甚至調戲機器人。所以機器人很難捕捉到使用者真實的意圖,甚至要面對使用者可能會隨時切換意圖的可能。
第二,真實環境中噪音比較大,導致對話管理獲取到的資訊並不是使用者真實表達的含義。
第三,絕大部分領域的意圖槽位內容會很多,比如時間或者其他數字資訊是連續的。如果要用模型真實建模來跟蹤所有可能的狀態,傳統的方法基本上不可用。要建模所有可能的狀態,並在狀態之間跳轉,需要列舉所有可能的語料,這本身是一個統計學問題。
對話管理本身方法也有很多。從上文講過的歷史來看,首先想到的是狀態機的方法,像比如說上圖左邊的 S1,使用者從 S1 狀態下定義我在 S1 狀態下它應該做什麼行動,可以 forward,可以 backward,可以 left,可以 right。當執行了 forward,就會到達 S3 狀態,這個時候就完成了一輪的互動,這就是一個通過狀態機的方式去實現的對話管理。對於狀態怎麼跳轉,包括狀態下應該做什麼行為,都定義得非常清楚。第二種,假設有 10 個槽,那個槽裡面很多值,一一列舉兩種組合或者幾種可能,其空間是非常大的,導致維護起來很困難。解決這一問題的思路之一是基於槽的框架的方法。我們來看看大致思路,首先對模型做簡單的形式化,認為槽跟槽之間是獨立的,與所填的值無關,在沒有填槽情況下,就進行提問,填充後就不問,多輪互動之後提問結束,目前很多企業,包括成熟的大企業和創業公司,很多都會採用槽的框架的方式。
不管是基於狀態機還是槽框架,本質上都是一套規則,而歷史上後續 Steve young教授提出一個基於資料驅動的對話管理方法,本質上來說就是把對話管理當做一個部分馬可夫決策過程,POMDP。如果大家感興趣可以看一下 Steve Young 於 2013 年發表的非常經典的綜述論文,主題就是 POMDP 的對話管理。
沿著歷史的脈絡梳理,這之後開始深度學習的方法就比較多了。目前效果最好的、比較經典的是trade模型,該模型獲得了ACL2019 的 outstanding paper,作者把對話狀態跟蹤的任務建模成生成任務,首先把歷史資訊編碼成向量,同時會把領域槽進行編碼,最後融合生成對應槽的值。當年這篇論文獲得很大的成功,效果確實比較好。另一個典型的例子是上圖右邊基於強化學習的對話管理,把對話策略建模成深度強化學習的問題。
隨著預訓練火熱之後,用 BERT 也能夠解決對話狀態跟蹤的問題。可以通過 Bert 閱讀理解技術,預測使用者所說的話裡面每個槽位的 Start pos 和 end pos,最終提取槽的值,同時它會再聯合一個分類的任務去做聯合模型。但是在真實場景中是沒有標註資料的,所以我們一般會通過模擬器和一個機器人進行互動,這種互動的方式可以生成大量對話資料,同時也建立了一個訪模擬器。通過這個模擬器,可以生成很多對話樣本。現在根據我們的意圖和槽位,生成大概有 7000 多個對話樣本,訓練集裡面大概有 3000 多個對話樣本,最後通過 Bert 閱讀理解分類聯合方式,它的跟蹤準確率可以達到 90% 左右。但這也存在一個問題 —— 生成的資料可能無法很好地模擬真實的情況。
針對對話策略來說,現在工業界絕大部分用的都是這種對話邏輯、對話流程的方式。因為在 toB 場景中,它的對話選擇很豐富,剛開始在某個狀態下,使用者說任何一個意圖,它可能會跳轉到任何一個狀態,它的行為會很多。如果把它建模成一個真實的強化學習問題,第一對資料量要求很大,雖然也可以通過模擬生成資料,但它也需要很大的資料量。其次真實場景的一個行為空間是很大的,所以很難通過一個強化學的方式去模擬它。
但是在對這種對話流程方案進行設計的時候,也要解決很多實際上的問題。一個是槽位記憶的問題,它需要支援不同意圖槽位之間的關聯,例如在訂票時,已經說了時間地點,那麼在說查天氣的時候它不應該反問你要查什麼地方的天氣。第二個是意圖記憶的問題,它需要支援多輪的意圖識別。例如使用者在問天氣時,問 “那上海的呢?” 就會利用多輪的資訊識別成天氣意圖。
對話系統可以拆成語言理解、狀態跟蹤,和對話策略。其實自然語言理解也能夠融入到對話管理裡,深度學習已經允許把對話系統建模成端到端的方式。有兩個經典的工作,一個是 HRED,它把對話系統建立成雙層的端到端的網路,第一層用來編碼對話文字歷史,第二層用來編碼對話狀態。這種方法比較粗暴,來了文字就直接編碼,然後歷史資訊傳遞下去。還有一個比較經典的工作是 Steve young教授團隊的,它看起來是端到端,還是分區域性的模組,特別像 pipeline 的方式,它先做一個意圖的檢測,也就是意圖的網路,再做一個叫做 brief checker 的槽填充,最後再從 database 裡面去做一個搜尋,最後這三個資訊融入到 policy network ,policy network 可以認為是對話策略網路,最後去生成它的一個回覆,這樣一個區域性的端到端的任務型對話系統,比前面一種方法更好理解,而且解釋性更強。
這就是兩個比較經典的端到端的對話管理,那麼針對未來的人機對話方式,怎麼去設計一個更好的端到端對話系統架構呢?是不是仍然採用之前這兩種方式?未來的人機對話的方式到底是什麼呢?
四、多模態對話機器人進展
多模態自然人機互動系統是下一代人機互動系統的一個發展趨勢,它可以融合視覺、聽覺、觸覺、嗅覺甚至味覺,表達的效率比單一的視覺甚至單一的文字豐富性更強。多模態自然語言人機互動的對話模式,是目前最為自然而且最理想的人際互動方式。之所以研究多模態對話系統,是因為真實環境裡的語音識別引擎帶來的錯誤很難避免,同時它帶來的語義歧義性也特別大。那是不是能夠在理解語言的基礎上,融合其他模組的資訊,比如視訊圖片,引入一種多模態資訊融合就能夠提升計算機對使用者意圖的理解的準確性呢?
多模態對話的應用目前不是很多,但也有文章對此進行了研究,一個是情感感知對話系統,在駕駛時,駕駛員需要集中精力去關注路況,但是他很難騰出手去操作一個介面,這是一個很經典的多模態問題,它可以通過駕駛員,可以通過口頭或者是視覺的提示,甚至是語音文字,駕駛時語音識別效果可能會更差,那麼能不能通過視覺的資訊,手勢的資訊去理解,這是一個非常典型的場景。
中科院自動化研究出了一個多模態自然語言口語對話系統,它可以結合人的一些表情手勢姿態去進行對話,但本質上這幾個應用場景還是一個模態之間的串聯,它其實沒有做到很好的模態之間的融合。所以我們一直在調查研究是不是可以做模態的融合。通過調查,發現電子商務其實有這樣一個場景:使用者說 “我要買褲子,我要買衣服”,他還會發送一些樣本圖片,然後機器人也同時會反饋一些圖片給他,這就是天生的一個文字加圖片的方式,它可以構成一個多模態對話的流程。
多模態的簡單定義是,給定多模態對話上下文,包括使用者的詢問,目標是生成對應的系統的文本回復。針對上文電商的場景,提供的可能只有文字跟圖片,當然後面都可以擴充,還可以加語音甚至其他某些資訊,那麼這裡面可能不含圖片。它形式上就是你只需要輸入一個歷史上下文,再加上使用者的 query,需要生成的是系統的回覆。
對於端到端的對話管理,也可以使用 HRED 模型,該模型非常簡單,但是它僅支援單模態。在 HRED 裡面,只需要把圖片資訊加入,把圖片編碼,編碼之後再融合文字,文字通過 RNN 得到向量,把這兩個拼接在一起,再通過一層上面的 RNN,這就是現在用的比較多的基於 HRED 構造的多模態的 HRED 模型。
後面對模型進行了改進,第一使它可以在生成裡面進行控制,經過意圖的理解,去控制生成一個簡單、通用的回覆,也可以去生成一個多模態的、知識相關的回覆。第二個改進點,可以在生成過程中融合一些知識進來,比如說三元組這些資訊或者屬性表格,會比較好地控制生成的質量。但這幾個模型,也存在比較大的問題。
這裡列舉的兩個經典論文提及的這些方法都是基於層級迴圈的神經網路。這個方法的模態融合很弱,是把句子編碼成一個向量,其實這會損失句子裡面的細度資訊,比如說關鍵字實體。另外一方面雖然使用了屬性三元組,但其實並不能很好地有效利用這些知識,即知識的利用率比較低,所以華為採用了一種叫做 MATE 的模型,它是基於語義元素集的、上下文依賴的一個多模態對話系統。將模型拆開來看,左邊是一個多模態元素集的編碼器,用來編碼來自對話歷史的記錄,包括使用者查詢的所有影象,都儲存在對話記憶模組。為什麼存在影象記憶模組?因為有些當前的文字看不到前面的圖片,所以說這裡面會做一個 attention 操作。通過注意力機制或者影象的一些文字的嵌入,有選擇性的是否加入一些圖片。
最後所有嵌入都會拼接成多模態的語義元素集。這樣每個元素跟圖片裡面的元素都可以進行一個很好的互動。第二塊是右半部分,它是一個解碼過程,解碼過程可以分兩步。第一步先關注在編碼器裡面輸出,它只關注前面生成的注意力操作。第二階段,解碼之後再結合領域知識,再做一個 attention 操作,這樣能夠進一步很好地去利用這樣的知識,而且同時會利用好前面的一個編碼器的輸出,這樣能夠進一步地優化系統回覆的質量。
上圖是我們論文的一個實驗結果,實驗發現如果使用第一種解碼器和第二個解碼器,確實有一些提高。同時我們第一階段的編碼器,相對於前面所有方法中最好的方法,在 BLEU-1 上能提高 6 個點,在 BLEU-4 上能提高 9 個點,而且是絕對值的提升,這個提升是非常大的。同時下面的表格,把不同的模組進行替換,進行進一步的分析,包括在去掉 image position,previous image,knowledge 的情況下進行的對比。
上圖是展示的一個樣例。它關注了語義元素集的資訊,左下部分、右下部分, formal shoes 能關注到更上層的比較關鍵更元素集的一些資訊,包括 star。
五、對話機器人未來方向以及總結
以上就是我們在對話機器人上的一些進展和工作。針對機器人的這個行業來說,我們是希望每個人都能享受到對話人機互動的樂趣。即使跨洋彼岸,機器人也能夠跟使用者更好地進行交流,甚至機器人能夠服務好使用者。上圖是一張圖片,顯示器裡面是凱文・凱利,右邊是科大的佳佳機器人,當時是做了一個跨洋跨語種的對話。但要把這樣的事做好,其實是一個很大的挑戰。
首先,機器要理解使用者,甚至能夠理解使用者很多開放性的問題,這需要很大量的常識知識,例如上文提及:中國的首都是北京,機器人怎麼會知道這樣一個知識?真實世界知識太多,如果它能夠理解使用者各種各樣的問題,需要具備大量的常識知識去豐富它的能力。
再者同樣比較重要的。也是現在比較流行的個性化需求。每個人的特性不一樣,甚至機器人的特性也不一樣,如何去依照每一個使用者的個性去做不同的、基於個性化的回覆,也是目前相對來說研究得比較多,且前景比較好的方向。另外,對於小樣本學習需要解決的問題,特別是 toB 的場景企業的問題,挑戰是比較嚴峻的,真實的場景裡面企業其實沒有太多資料,甚至是沒有資料,小樣本學習是企業會重點關注的一個問題。
多模態、多領域,預訓練,預訓練在相對未來一段時間內還是會成為主流。從目前實踐證明,預訓練加微調的方式效果確實會比傳統的深度學習的重新訓練效果好很多。再結合現在深度學習的可解釋性,有一部分人在研究神經網路與符號類進行結合去解釋深度學習,更好地去建模真實的 AI 問題。
然後是無監督學習,無監督學習和小樣本學習面對的同樣還是企業場景的問題,客戶可能沒有標註資料,也許會有一些非結構化資料,這些資料怎麼用,怎麼去學習,也是對話機器人從業者面臨的挑戰。最後,現在的一些語料,甚至是對話機器人的語料,絕大部分是 2014 年之前的,還是單語種的資料,到最近才開放了多語種的資料集,所以多語種對話機器人也將會是比較好的方向。
本文分享自華為雲社群《圖靈測試70載,回顧對話機器人的經典實踐和最新進展 | 以華為雲對話機器人為例》,原文作者:listen2Bot 。
點選關注,第一時間瞭解華為雲新鮮技