本文內容整理自 PaperWeekly 和 biendata 在 B 站組織的直播回顧，點擊文末閱讀原文即可跳轉至 B 站收看本次分享完整視頻錄像，如需嘉賓課件，請在?PaperWeekly?公眾號回復關鍵詞課件下載獲取下載鏈接。

作者介紹：盧棟才，來自華為云語音語義創新 Lab，博士學位，畢業于中國科技大學，曾獲世界機器人大賽冠軍，所負責的家庭服務機器人可佳和佳佳機器人在國內外有較高的影響力。曾研發的知識圖譜問答技術，獲得 CCKS2019 的技術創新獎，2020 年聯合組織了一個 CCKS 相關的評測任務。同時，在一些機器人相關的會議和期刊上發表過一些論文。從 2012 年開始從事人機交互系統的算法，包括系統的研發，目前致力于華為云對話機器人平臺相關工作。

從 1950 年圖靈測試的提出到現在，對話系統已經走過了將近 70 年的時間，在這期間對話系統技術得到了快速的發展。方法也從當初的規則演變成如今的深度學習方法，對話系統的魯棒性和準確性都得到了大幅提升。

2020 年，自然語言處理頂級會議 ACL 被接收論文中，對話系統相關工作論文數量達到歷史之最，這也進一步驗證了對話系統最近幾年得到了非常大的關注。

本文將圍繞對話機器人相關技術及其在行業中應用實踐展開，同時介紹華為云對話機器人在多模態、小樣本、預訓練方向上的最新進展。將按照以下 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 年之前的，還是單語種的數據，到最近才開放了多語種的數據集，所以多語種對話機器人也將會是比較好的方向。

關于數據實戰派

數據實戰派希望用真實數據和行業實戰案例，幫助讀者提升業務能力，共建有趣的大數據社區。

更多閱讀

#投 稿?通 道#

?讓你的論文被更多人看到?

如何才能讓更多的優質內容以更短路徑到達讀者群體，縮短讀者尋找優質內容的成本呢？答案就是：你不認識的人。

總有一些你不認識的人，知道你想知道的東西。PaperWeekly 或許可以成為一座橋梁，促使不同背景、不同方向的學者和學術靈感相互碰撞，迸發出更多的可能性。?

PaperWeekly 鼓勵高校實驗室或個人，在我們的平臺上分享各類優質內容，可以是最新論文解讀，也可以是學習心得或技術干貨。我們的目的只有一個，讓知識真正流動起來。

?????來稿標準：

? 稿件確系個人原創作品，來稿需注明作者個人信息（姓名+學校/工作單位+學歷/職位+研究方向）?

? 如果文章并非首發，請在投稿時提醒并附上所有已發布鏈接?

? PaperWeekly 默認每篇文章都是首發，均會添加“原創”標志

?????投稿郵箱：

? 投稿郵箱：hr@paperweekly.site?

? 所有文章配圖，請單獨在附件中發送?

? 請留下即時聯系方式（微信或手機），以便我們在編輯發布時和作者溝通

????

現在，在「知乎」也能找到我們了

進入知乎首頁搜索「PaperWeekly」

點擊「關注」訂閱我們的專欄吧

關于PaperWeekly

PaperWeekly 是一個推薦、解讀、討論、報道人工智能前沿論文成果的學術平臺。如果你研究或從事 AI 領域，歡迎在公眾號后臺點擊「交流群」，小助手將把你帶入 PaperWeekly 的交流群里。

總結

以上是生活随笔為你收集整理的图灵测试70载，回顾对话机器人的经典实践和最新进展的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。