人機對話技術研究進展與思考

嘉賓：袁彩霞 博士 北京郵電大學 副教授

整理：Hoh Xil

來源：阿里小蜜 & DataFun AI Talk

出品：DataFun

注：歡迎轉載，轉載請在留言區內留言。

導讀：本次分享的主題爲人機對話技術研究進展與思考。主要梳理了咱們團隊近兩年的工做，渴望能夠經過這樣的介紹，能給你們一個關於人機對話 ( 包括它的科學問題和應用技術 ) 方面的啓示，幫助咱們進行更深刻的研究和討論。主要包括：

1. Spoken dialogue system：a bird view ( 首先咱們來看什麼是人機對話，尤爲是 Spoken dialogue。其實說 Spoken 的時候，有兩層含義：第一個 spoken 就是 speech，第二個咱們處理的語言自己具備 spoken 的特性。可是，稍後會講的 spoken 是指咱們已經進行語音識別以後，轉換爲文本的一個特殊的天然語言，後面討論的口語對話不過多地討論它的口語特性，主要是講人和機器之間的天然語言對話。)

2. X-driven dialogue system：緊接着來說解咱們近些年的研究主線 X-driven dialogue syatem，X 指構建一個對話系統時，所採用的數據是什麼，從最先的 dialogue -> FAQ -> KB -> KG -> document 以及咱們一直在嘗試的圖文多模態數據。

3. Concluding remarks ( 結束語 )

01

Spoken dialogue system：a bird view

學術界關於對話系統有着不一樣的劃分，這種劃分目前看來不是很是準確，也不是特別標準的劃分了。可是，接下來的內容，主要是圍繞着這兩個主線：

限定領域，專門指任務型對話 ( 圍繞某一特定用戶對話目標而展開的 ）。對於任務型對話，對話系統的優化目標就是如何以一個特別高的回報、特別少的對話輪次、特別高的成功率來達成用戶的對話目標。因此即使是限定領域，咱們這裏討論的也是特別限定的、專門有明確的用戶對話目標的一種對話。

開放領域，not purely task-oriented， 已經再也不是純粹的對話目標驅動的對話，包括：閒聊、推薦、信息服務等等，後面逐步展開介紹。

咱們在研究一個問題或者作論文答辯和開題報告時，常常討論研究對象的意義在哪裏。圖中，前面講的是應用意義，後面是理論意義。咱們實驗室在北京郵電大學叫智能科學與技術實驗室，其實她的前身叫人工智能實驗室。因此從名字來看，咱們作了很是多的 AI 基礎理論的研究，咱們在研究這些理論的時候，也會講 AI 的終極目的是研製一種可以從事人類思惟活動的計算機系統。人類思惟活動創建在獲取到的信號的基礎上。人類獲取信號的方式大致有五類，包括視覺、聽覺、觸覺、味覺、嗅覺等，其中視覺和聽覺是兩個比較高級的傳感器通道，尤爲是視覺通道，佔據了人類得到信息的80%以上。因此咱們從這兩個角度，設立了兩個研究對象：第一個是語言，第二個是圖像。而咱們在研究語言的時候，發現語言有一個重要的屬性，叫交互性，交互性最典型的一個體現就是對話；同時，語言不是一個獨立的模態，語言的處理離不開跟它相關的另外一個通道，就是視覺通道。因此咱們早期更可能是爲了把交互和多模態這樣的屬性歸入到語言建模的範圍，以其提高其它天然語言處理系統的性能，這就是咱們研究的一個動機。

1. Block diagram

上圖爲 CMU 等在1997年提出來的人機對話框架，基於這個框架人們開發出了很是多優秀的應用系統，好比應用天氣領域的 "Jupiter"。這個框架從提出到商業化應用，一直到今天，咱們都還沿着這樣的一個系統架構在進行開發，尤爲是任務驅動的對話。

這就是具體的對話系統的技術架構。

1. Specific domain

這個架構發展到如今，在功能模塊上，已經有了一個很清晰的劃分：

首先進行語音識別，而後天然語言理解，緊接着作對話管理，將對話管理的輸出交給天然語言生成模塊，最後造成天然語言應答返回給用戶。這就是一個最典型的 specific domain 的架構。早期 task 限定的 dialogue，基本上都是按照這個架構來作的。這個架構雖然是一個 Pipeline，可是從研究的角度來說，每個模塊和其它模塊之間都會存在依賴關係。所以，咱們試圖從研究的角度把不一樣的功能模塊進行統一建模。在這個建模過程當中，又會產生新的學術性問題，咱們旨在在這樣的問題上能夠產生驅動性的技術。

1. Open domain

Open domain，也就是「閒聊」，實現上主要分爲途徑：

第一個是基於匹配/規則的閒聊系統；第二個是基於檢索的閒聊系統；第三個是基於編解碼結構的端到端對話系統。固然，實際情境中，這幾個途徑每每結合在一塊兒使用。

02

X-Driven dialogue system

目前不管是任務型對話仍是閒聊式對話，都採用數據驅動的方法，所以依據在構建人機對話系統時所用到的數據不一樣，建模技術和系統特性也就體現出巨大的不一樣。咱們把使用的數據記爲 X，因而就有了不一樣的 X 驅動的對話。

1. Our roadmap

若是想讓機器學會像人同樣對話，咱們能夠提供的最天然的數據就是 dialogue。咱們從2003年開始作對話驅動的對話；2012年開始作 FAQ 驅動的對話；2015年開始作知識庫 ( KB ) 驅動的對話；2016年開始作知識圖譜 ( KG ) 驅動的對話，相比於 KB，KG 中的知識點產生了關聯，有了這種關聯人們就能夠在大規模的圖譜上作知識推理；2017年開始作文檔驅動的對話。這就是咱們研究的大體脈絡。

1. Dialogue-driven dialogue

早期在作 Dialogue driven 的時候，多依賴人工採集數據，可是，從2013年以來，逐步開放了豐富的涵蓋多領域多場景的公開數據集。好比最近的 MultiWOZ，從 task specific 角度講，數據質量足夠好、數據規模足夠大，同時涵蓋的對話情景也很是豐富。可是，目前公開的中文數據集還不是不少。

這個是和任務型對話無關的數據集，也就是採集的人與人對話的數據集。尤爲以 Ubuntu 爲例，從15年更新至今，已經積累了很是大規模的數據。

以 Dialogue 爲輸入，咱們開展了任務型和非任務型兩個方向的工做。先來看下任務型對話：

2.1 NLU

當一個用戶輸入過來，第一個要作的就是天然語言理解 ( NLU )，NLU 要作的三件事爲：Domain 識別；Intent 識別；信息槽識別或叫槽填充。這三個任務能夠分別獨立地或採用管道式方法作，也能夠聯合起來進行建模。在聯合建模之外，咱們還作了一些特別的研究。好比咱們在槽識別的時候，老是有新槽，再好比有些槽值很是奇怪，例如 "XX手機能夠一邊打電話一邊視頻嗎？"，對應着槽值 "視頻電話"，採用序列標註的方式，很難識別它，由於這個槽值很是不規範。用戶輸入可能像這樣語義很是鬆散，不連續，也可能存在很是多噪音，在進行聯合建模時，傳統的序列標註或分類爲思想，在實際應用中已經不足以解決問題了。

咱們針對這個問題作了比較多的探討，右圖爲咱們2015年的一個工做：在這三個任務聯合建模的同時，在槽填充這個任務上將序列標註和分類進行同時建模，來更好地完成 NLU。

在 NLU 領域還有一個很是重要的問題，隨着開發的業務領域愈來愈多，咱們發現多領域對話產生了諸多很是重要的問題，例如在數據層有些 domain 數據可能不少，有些 domain 數據可能不多，甚至沒有，因而就遇到冷啓動的問題。所以，咱們作了很是多的 domain transfer 的工做。上圖爲咱們2016年的一個工做，咱們會把數據比較多的當作源領域，數據比較少的當作目標領域。因而，嘗試了基於多種遷移學習的 NLU，有的是在特徵層進行遷移，有的是在數據層遷移，有的是在模型層進行遷移。圖中是兩個典型的在特徵層進行遷移的例子，不只關注領域通常特徵，並且關注領域專門特徵，同時採用了對抗網絡來生成一個虛擬的特徵集的模型。

2.2 NLU+DM

緊接着，咱們研究了 NLU 和對話管理 ( DM ) 進行聯合建模，由於咱們發現人人對話的時候，不見得是聽完對方說完話，理解了對方的意圖，而後才造成對話策略，有可能這兩個過程是同時發生的。甚或 DM 還能夠副作用於 NLU。早期咱們基於的一個假設是， NLU 可能不須要一個顯式的過程，甚至不須要一個顯式的 NLU 的功能，咱們認爲 NLU 最終是服務於對話管理 ( DM )，甚至就是對話管理 ( DM ) 的一部分。因此，2013年的時候，咱們開始了探索，有兩位特別優秀的畢業生在這兩個方面作了特別多的工做。好比，如何更好地聯合建模語言理解的輸出和對話管理的策略優化。這是咱們在 NLU 和 DM 聯合建模的工做，同時提高了 NLU 和 DM 的性能。

在聯合模型中，咱們發現，DM 的建模涉及到很是多的 DRL ( 深度強化學習 ) 的工做，訓練起來很是困難，好比如何設計一個好的用戶模擬器，基於規則的，基於統計的，基於語言模型的，基於 RL 的等等咱們嘗試了很是多的辦法，也取得了一系列有趣的發現。2018年時咱們研究一種不依賴於規則的用戶模擬器，業界管這個問題叫作 "Self"-play，雖然咱們和 "Self"-play 在網絡結構上差別挺大的，可是咱們仍是借鑑了 "Self"-play 訓練的特性，把咱們本身的系統叫作 "Self"-play。在這樣的機制引導下，咱們研究了不依賴於規則，不依賴於有標記數據的用戶模擬器，使得這個用戶模擬器能夠像 Agent 同樣，和咱們所構造的對話的 Agent 進行交互，在交互的過程當中完成對用戶的模擬。

在訓練過程當中還有一個重要的問題，就是 reward 怎麼來，咱們知道在 task oriented 時，reward 一般是人類專家根據業務邏輯/規範制定出來的。事實上，當咱們在和環境交互的時候不知道 reward 有多大，可是環境會隱式地告訴咱們 reward 是多大，因此咱們作了很是多的臨接對和 reward reshaping 的工做。

2.3 小結

Dialogue-driven dialogue 這種形式的對話系統，總結來看：

優勢：

定義很是好，邏輯清晰，每個模塊的輸入輸出也很是清晰，同時有特別堅實的數學模型能夠對它進行建模。

缺點：

因爲很是依賴數據，同時，不管是在 NLU 仍是 NLG 時，咱們都是採用有監督的模型來作的，因此它依賴於大量的、精細的標註數據。

而 DM 每每採用 DRL 來作。NIPS2018 時的一個 talk，直接指出：任何一個 RL 都存在的問題，就是糟糕的重現性、複用性、魯棒性。

1. FAQ-driven dialogue

FAQ 是工業界很是常見的一種情景：有大量的標準問，以及這個標準問的答案是什麼。基於這個標準問，一個用戶的問題來了，如何找到和它類似的問題，進而把答案返回給用戶，因而這個 Service 就結束了。

實際中，咱們如何建 FAQ？更多的時候，我會把這個問題和咱們庫的標準問題作一個類似度的計算或者作一個分類。

咱們在作這個工做的時候發現一個特別大的問題，就是 Unbalanced Data 問題。好比，咱們有5000個問題，每一個問題都有標準答案，有些問題可能對應的用戶問題特別多，好比 "屏幕碎了" 可能會有1000多種不一樣的問法，還有些問題，可能在幾年的時間裏都沒有人問到過。因此，面對數據不均衡的問題，咱們從2016年開始作了 Data transfer 的工做。

大體的思路是：我有一個標準問題，可是很糟糕，這個標準問題沒有用戶問題，也就是沒有訓練語料。接下來發現另一個和這個標準問很類似的其它標準問有不少的訓練語料，因而藉助這個標準問，來生成虛擬樣本，進而削弱了 Unbalance。

具體的方法：咱們把目標領域的標準問當作 Query，把和它類似的標準問題及其對應的用戶問題當作 Context，採用了 MRC 機器閱讀理解的架構來生成一個答案，做爲目標問題的虛擬的用戶問題，取得了很是好的效果，而且嘗試了三種不一樣的生成用戶問題的方法。

實際項目中，FAQ 中的 Q 可能有很是多的問題，例如3000多個類，須要作極限分類，這就致使性能低下，且很是耗時，不能快速響應用戶的問題。因而咱們作了一個匹配和分類進行交互的 model，取得了不錯的效果。

目前，大部分人都認爲 FAQ 驅動的 dialogue 不叫 dialogue，由於咱們一般說的 dialogue 輪次是大於兩輪的。而 FAQ 就是一個 QA 系統，沒有交互性。有時候帶來的用戶體驗很是不友好，好比當答案很是長的時候，系統要把長長的答案返回，就會一直講，致使用戶比較差的體驗。因而，咱們基於 FAQ 發展出了一個多輪對話的數據，如右圖，這是咱們正在開展的一個工做。

1. KB-driven dialogue

KB 最先人們認爲它就是一個結構化的數據庫，一般存儲在關係型數據庫中。好比要訂一個酒店，這個酒店有各類屬性，如位置、名稱、戶型、價格、面積等等。早期 CMU 的對話系統，全部的模塊都要和 Hub 進行交互，最後 Hub 和後端的數據庫進行交互。數據庫的價值很是大，可是早期人們在建模人機對話的時候，都忽視了數據庫。這裏就會存在一個問題：機器和用戶交互了好久，而在檢索數據庫時發現沒有答案，或者答案很是多，形成用戶體驗很是糟糕。

從2012年開始，咱們開始把 KB 引入咱們的對話系統。圖中的對話系統叫作 "teach-and-learn" bot，這是一個多模態的對話，可是每一個涉及到的 object，咱們都會把它放到 DB 中。和用戶交互過程當中，不光看用戶的對話狀態，還要看數據庫狀態。這個想法把工做往前推動了一些。

直到2016年，MSR 提出的 KB-InfoBot，第一次提出了進行數據庫操做時，要考慮它的可導性，不然，就沒辦法在 RL 網絡中像其它的 Agent action 同樣進行求導。具體的思路：把數據庫的查詢和 Belief State 一塊兒總結起來作同一個 belief，進而在這樣的 belief 基礎上作各類對話策略的優化。

在上述方法的基礎上，咱們作了有效的改良，包括 entropy regularities 工做。是每次和用戶進行交互時，數據庫的 entropy 會發生變化。好比當機器問 "你想訂哪裏的酒店？"，用戶答 "阿里中心附近的。"，因而數據庫馬上進行了一次 entropy 計算進行更新，接着繼續問 "你想訂哪一天的？"，用戶答 "訂7月28號的"，因而又進行了一次 entropy 計算進行更新。這樣在和用戶進行交互的時候，不光看用戶的 dialogue 輸入，還看 DB 的 entropy 輸入，以這兩項共同驅動 Agent action 進行優化。

這裏咱們作了特別多的工做，信息槽從1個到5個，數據庫的規模從大到小，都作了特別多的嘗試，這樣在和用戶交互的時候，agent 能夠自主的查詢檢索，甚至能夠填充和修改數據庫。

這是咱們2017發佈的一個工做，KB driven-dialogue，其優勢：

控制萬能高頻回覆 ( 提升答應包含的有用信息 )

賦予 agent 對話主動性

1. KG-driven dialogue

剛剛講的基於 KB 的 dialogue 任務，基本都認爲對話任務就是在進行槽填充的任務，若是一個 agent 是主動性的，經過不停的和用戶進行交互來採集槽信息，因此叫槽填充，當槽填完了，就至關於對話任務成功了。可是，當咱們在定義槽的時候，咱們認爲槽是互相獨立的，而且是扁平的。然而，實際中許多任務的槽之間存在相關性，有的是上下位關係，有的是約束關係，有的是遞進關係等等。這樣天然的就引出了知識圖譜，知識圖譜能夠較好地描述上述的相關性。因而，產生了兩個新問題：

知識圖譜驅動的對話理解：實體連接

知識圖譜驅動的對話管理：圖路徑規劃

這裏主要講下第二個問題。

舉個例子，咱們在辦理電信業務，開通一個家庭寬帶，須要提供相關的證件，是本身去辦，仍是委託人去辦，是房東仍是租戶等等，須要提供各類不一樣的材料。因而這個情景就產生了條件的約束，某一個 node 和其它 node 是上下位的關係，好比證件能夠是身份證，也能夠是護照或者戶口簿等等。因此咱們能夠經過知識圖譜來進行處理。

當一個用戶的對話過來，首先會連接到不一樣的 node，再基於 node 和對話歷史構造一個對話的 state，咱們會維持一個全局的 state 和一個活躍的 state，同時活躍的 state 會定義三種不一樣的操做動做，一個是祖先節點，一個是兄弟節點，還有一個是孩子節點。因此，在這樣的知識圖譜上如何尋優，好比當經過某種計算獲得，它應該在某個節點上進行交互的時候，咱們就應該輸出一個 action，這個 action 要和用戶確認他是一個租戶，仍是自有住房等等。因此，這個 action 是有區別於此前所提到的在特定的、扁平的 slot 槽上和用戶進行信息的確認、修改等仍是有很大不一樣的。解決這樣的問題，一個很是巨大的挑戰就是狀態空間很是大。好比圖中的節點大概有120個，每一個節點有3個不一樣的狀態，知識從節點的狀態來看就有3的120次冪種可能。這也是咱們正在開展的待解決的一個問題。

在端到端的對話模型 ( 閒聊 ) 中，也開始逐步地引入知識圖譜。下面介紹兩個比較具備表明性的引入知識圖譜後的人機對話。其中右邊是2018年 IJCAI 的傑出論文，清華大學黃民烈老師團隊的工做，引入了經過 KG 來表示的 Commonsense，同時到底在編碼器端仍是在解碼器端引入知識，以及如何排序，排序的時候如何結合對話的 history 作知識的推理等等，都作了特別全面的研究。

另外一個比較有表明性的工做是在 ICLR2019 提出的，在架構中引入了 Local Memory 和 Global Memory 相融合的技術，經過這種融合，在編碼器端和解碼器端同時加入了知識的推理。

總結下 KB/KG-driven dialogue：

優勢：

已經有大規模公開的數據 ( e.g.，InCar Assistant，MMD，M2M )。

訓練過程可控&穩定，由於這裏多數都是有監督學習。

缺點：

由於採用有監督的方式進行訓練，因此存在以下問題：

① 環境肯定性假設
② 缺乏對動做的建模
③ 缺乏全局的動做規劃
Agent 被動，徹底依賴於訓練數據，因此模型是不賦予 Agent 主動性的。

構建 KB 和 KG 成本昂貴！

1. Document-driven dialogue

Document 驅動的對話，具備以下優勢：

① 應用場景真實豐富：

情景對話 ( conversation )，好比針對某個熱門事件在微博會產生不少對話，這就是一個情景式的對話。

電信業務辦理 ( service )，好比10086有很是多的套餐，如何從中選擇一個用戶心儀的套餐？每一個套餐都有說明書，咱們能夠圍繞套餐的說明書和用戶進行交互，如 "您但願流量多、仍是語音多"，若是用戶回答 "流量多"，就能夠基於文本知道給用戶推薦流量多的套餐，若是有三個候選，機器就能夠基於這三個候選和用戶繼續進行交互，縮小候選套餐範圍，直到用戶選出心儀的套餐。

電商產品推薦 ( recommendation )，能夠根據商品的描述，進行各類各樣的對話。這裏的輸入不是一個 dialogue，也不是一個 KB，甚至結構化的內容很是少，徹底是一個 free document，如何基於這些 document 進行推薦，是一個很好的應用場景。

交互式信息查詢 ( retrieval )，不少時候，一次查詢的結果可能不能用戶的需求，如何基於非結構化的查詢結果和用戶進行交互，來更好地達成用戶的查詢目的。

......

② 數據獲取直接便捷：

相比於 dialogue、FAQ、KB、KQ 等，Document 充斥着互聯網的各類各樣的文本，均可以當作是文本的數據，獲取方便，成本很是低。

③ 領域移植性強：

基於文本，再也不基於專家定義的 slot，也再也不基於受限的 KB/KG，從技術上講，所構造的 model 自己是和領域無關的，因此它賦予了 model 很強的領域移植性。

這是咱們正在進行的工做，情景對話偏向於閒聊，沒有一個用戶目標。這裏須要解決的問題有兩個：

如何引入文檔：編碼端引入文檔、解碼端引入文檔

如何編碼文檔：文檔過長、冗餘信息過多

數據：

咱們在 DoG 數據的基礎上模擬了一些數據，造成了如上圖所示的數據集，分 Blind 和 Non-blind 兩種情形構造了不一樣的數據集。

咱們發現，基於文本的端到端的聊天，有些是基於內容的閒聊，有些還須要回答特定的問題。因此，評價的時候，能夠直接用 F1 評價回答特定問題，用閒聊通用的評價來評價基於內容的聊天。

剛剛講的是偏閒聊式的對話，接下來說下任務型對話。

這裏的動機分爲兩種狀況：單文檔和多文檔，咱們目前在挑戰多文檔的狀況，單文檔則採用簡單的多輪閱讀理解來作。

多文檔要解決的問題：

如何定義對話動做：由於是基於Document進行交互，而再也不是基於slot進行交互，因此須要從新定義對話動做。

如何建模文檔差別：以剛剛10086的例子爲例，總共有10個業務，經過一輪對話，挑選出3個，這3個業務每一個業務可能都有10種屬性，那麼其中一些屬性值相同的屬性，不必再和用戶進行交互，只須要交互它們之間不一樣的點，因此交互的角度須要隨對話進行動態地變化。

數據：

這裏採用的數據是 WikiMovies 和模擬數據，具體見上圖。

1. A very simple sketch of dialogue

上圖爲任務型對話和非任務型對話的幾個重要節點，你們能夠了解下。

03

Concluding remarks

任務型對話具備最豐富的落地場景。

純閒聊型對話系統的學術價值尚不清楚。

任務型和非任務型邊界越發模糊，一個典型的人人對話既包括閒聊，又包括信息獲取、推薦、服務。

引入外部知識十分必要，外部知識形態萬千，建模方法也於是千差萬別。

Uncertainty 和 few-shot 問題，是幾乎全部的對話系統最大的 "卡脖子" 問題。

X-driven dialogue 中的 X 還有哪些可能？剛剛提到的 X 都仍是基於文本的。事實上，從2005年開始，咱們已經開始作 image 和文本數據融合的對話；從2013年開始作 Visual QA/Dialogue，挑戰了 GuessWhat 和 GuessWhich 任務。

X=multi media ( MM Dialogue )，X 還能夠很寬泛的就是指多媒體，不光有 image 還可能有 text，2018年已經有了相關的任務，而且開源了很是多的電商業務。這是一個很是有挑戰性的工做，也令人機對話自己更加擬人化。

04

Reference

這是部分的參考文獻，有些是咱們本身的工做，有些是特別傑出的別人的工做。

今天的分享就到這裏，感謝你們的聆聽，也感謝咱們的團隊。

歡迎關注DataFunTalk同名公衆號，收看第一手原創技術文章。