使用深度學習打造智能聊天機器人

作者:張俊林,中科院軟體所博士,技術書籍《這就是搜尋引擎:核心技術詳解》、《大數據日知錄:架構與算法》作者。曾擔任阿里巴巴、百度、新浪微博資深技術專家,目前是用友暢捷通工智能相關業務負責人,關注深度學習在自然語言處理方面的應用。 
責編:周建丁([email protected]) 

本文為《工程師》原創文章,未經允許不得轉載,更多內容請訂閱2016年《工程師》

聊天機器人(也可以稱為語音助手、聊天助手、對話機器人等)是目前非常熱的一個人工智能研發與產品方向。很多大型互聯網公司投入重金研發相關技術,並陸續推出了相關產品,比如蘋果Siri、微軟Cortana與小冰、Google Now、百度的「度秘」、亞馬遜的藍牙音箱Echo內置的語音助手Alexa、Facebook推出的語音助手M、Siri創始人新推出的Viv……
究其原因在於大家都將聊天機器人定位為未來各種服務的入口,尤其是移動端App及可穿戴設備場景下提供各種服務的入口。

聊天機器人的類型
目前市場上有各種類型的聊天機器人,比如有京東JIMI客服機器人,兒童教育機器人,小冰娛樂聊天機器人,Alexa家居控制、車載控制機器人,Viv全方位服務類型機器人等。這是從應用方向對聊天機器人的一種劃分。

如果對應用目的或者技術手段進行抽象,聊天機器人可以有以下兩種劃分方法。

  • 目標驅動(Goal Driven) VS 無目標驅動(Non-Goal Driven)聊天機器人

目標驅動的聊天機器人指的是聊天機器人有明確的服務目標或者服務對象,比如客服機器人、兒童教育機器人、類似Viv的提供天氣/訂票/訂餐等服務的服務機器人等,這種目標驅動的聊天機器人也可以稱作特定領域的聊天機器人。

無目標驅動聊天機器人指的是聊天機器人並非為特定領域服務目的而開發,比如純粹聊天或者出於娛樂聊天目的以及計算機遊戲中的虛擬人物聊天機器人都屬於此類。這種無明確任務目標的聊天機器人也可以稱作為開放領域的聊天機器人。

  • 檢索式 VS 生成式聊天機器人

檢索式聊天機器人指的是事先存在一個對話庫,聊天系統接收到用戶輸入句子後,通過在對話庫中以搜尋匹配的方式進行應答內容提取。很明顯,這種方式對對話庫要求很高,需要對話庫足夠大,能夠盡量多地匹配用戶問句,否則會經常出現找不到合適回答內容的情形(因為在真實場景下用戶說什麼都是可能的),但它的好處是回答質量高,因為對話庫中的內容都是真實的對話數據,表達比較自然。

生成式聊天機器人則採取不同的技術思路,在接收到用戶輸入句子後,採用一定技術手段自動生成一句話作為應答,這個路線機器人的好處是可能覆蓋任意話題的用戶問句,但是缺點是生成應答句子質量很可能會存在問題,比如語句不通順、句法錯誤等看上去比較低級的錯誤。

本文重點介紹開放領域、生成式的聊天機器人如何通過深度學習技術來構建,很明顯這是最難處理的一種情況。

好聊天機器人應該具備的特點
一般而言,一個優秀的開放領域聊天機器人應該具備如下特點:

  • 首先,針對用戶的回答或者聊天內容,機器人產生的應答句應該和用戶的問句語義一致並邏輯正確,如果聊天機器人答非所問或者不知所雲,或者總是回答說「對不起,我不理解您的意思」,無疑是毀滅性的用戶體驗。

  • 其次,回答應該語法正確。這個看似是基本要求,但是對於採用生成式對話技術的機器人來說其實有一定困難,因為機器人的回答是一個字一個字生成,要保證這種生成的若干個字句法正確,並不容易做得那麼完美。

  • 再次,應答應該是有趣、多樣而非沉悶無聊的。盡管有些應答看上去語義沒什麼問題,但目前技術訓練出的聊天機器人很容易產生「安全回答」的問題,就是說,不論用戶輸入什麼句子,聊天機器人總是回答「好啊」、「是嗎」等諸如此類,看上去語義說得過去,但是這給人很無聊的感覺。


  • 此外,聊天機器人應該給人「個性表達一致」的感覺。因為人們和聊天機器人交流,從內心習慣還是將溝通對象想像成一個人,而一個人應該有相對一致的個性特徵,如果用戶連續問兩次「你多大了」,而聊天機器人分別給出不同的歲數,那麼會給人交流對象精神分裂的印象,這即是典型的個性表達不一致。而好的聊天機器人應該對外體現出各種基本背景信息以及愛好、語言風格等方面一致的回答。

幾種主流技術思路
當前聊天機器人的幾種主流技術包括:基於人工模板、基於檢索、基於機器翻譯技術,以及基於深度學習的聊天機器人。

  • 基於人工模板的技術通過人工設定對話場景,並對每個場景編寫針對性的對話模板,模板描述了用戶可能的問題以及對應的答案。這個技術路線的好處是精準,缺點是需要大量人工工作,而且可擴展性差,需要一個場景一個場景去擴展。目前市場上各種類似於Siri的對話機器人中都大量使用了人工模板的技術,但其精準性是其他方法還無法比擬的。

  • 基於檢索技術的聊天機器人則走的是類似搜尋引擎的路線,事先存儲好對話庫並建立索引,根據用戶問句,在對話庫中進行模糊匹配找到最合適的應答內容。

  • 基於機器翻譯技術的聊天機器人把聊天過程比擬成機器翻譯過程,就是說將用戶輸入聊天信息Message,翻譯成聊天機器人應答Response的過程類似於把英語翻譯成漢語。基於這種假設,就完全可以將統計機器翻譯領域相對成熟的技術直接應用到聊天機器人開發中。

  • 基於深度學習的聊天機器人技術是本文後續內容主要介紹的技術路線,總體而言,絕大多數技術都是在Encoder-Decoder(或者稱作Sequence to Sequence)深度學習技術框架下改進的。使用深度學習技術來開發聊天機器人相對傳統方法來說,整體思路非常簡單並可擴展。

利用深度學習構建聊天機器人
如上所述,目前對於開放領域生成式聊天機器人技術而言,多數採用了Encoder-Decoder框架,所以這裡首先描述Encoder-Decoder框架技術原理。然後分別針對聊天機器人研究領域需要特殊考慮的主要問題及其對應的解決方案進行講解,這些主要問題分別是:多輪會話中的上下文機制、「安全回答」以及個性信息一致性問題。

Encoder-Decoder框架
Encoder-Decoder框架可以看作一種文本處理領域的研究模式,應用場景異常廣泛,不僅可用在對話機器人領域,還可以應用在機器翻譯、文本摘要、句法分析等各種場合。圖1是文本處理領域裡常用的Encoder-Decoder框架最抽象的一種表示。Encoder-Decoder框架可以直觀地理解為適合處理由一個句子(或篇章)生成另外一個句子(或篇章)的通用處理模型。對於句子對(X,Y),我們的目標是給定輸入句子X,期待通過Encoder-Decoder框架來生成目標句子Y。X和Y可以是同一種語言,也可以是兩種不同的語言。而X和Y分別由各自的單詞序列構成:

Encoder顧名思義就是對輸入句子X進行編碼,將輸入句子通過非線性變換轉化為中間語義表示C:

對於解碼器Decoder來說,其任務是根據句子X的中間語義表示C和之前已經生成的歷史信息y1,y2……yi-1來生成i時刻要生成的單詞yi:




圖1 抽象的Encoder-Decoder框架
每個yi都依次這麼產生,那麼看起來就是整個系統根據輸入句子X生成了目標句子Y。

對於聊天機器人來說,完全可以使用上述的Encoder-Decoder框架來解決技術問題。

多輪會話中的上下文問題
利用上述Encoder-Decoder框架,聊天機器人可以根據用戶當前輸入Message自動生成應答Response,形成了一個有效的對話系統。但是一般人們聊天並不是單純的一問一答,回答的內容常常要參考上下文信息Context,也就是在用戶當前輸入問句Message之前兩者的對話信息。因為存在多輪的一問一答,這種情形一般稱為多輪會話。

深度學習解決多輪會話的關鍵是如何將上下文聊天信息Context引入到Encoder-Decoder模型中。Context應該引入到Encoder中,因為這是除了當前輸入Message的額外信息,有助於Decoder生成更好的應答Response。目前不同的研究主體思路都是這樣,無非如何將Context信息在Encoder端建立模型或者說具體的融入模型有些不同。

表1 聊天機器人聊天效果示例 

在上文所述的Encoder-Decoder框架中,很容易想到一種直觀地將Context信息融入Encoder的思路:無上下文信息的Encoder-Decoder模型的輸入僅僅包含Message,只需要把上下文信息Context和信息Message拼接形成一個長的輸入提供給Encoder,這樣就把上下文信息融入模型中了。這個直覺本身沒有什麼問題,但是對於採用RNN模型的Encoder來說,這種方式使得有時候輸入非常長,而對於RNN模型來說,輸入的線型序列長度越長,模型效果越差。所以簡單地拼接Context和Message的策略不會產生太好的聊天效果。

考慮到RNN對長度敏感的問題,文獻3提出了針對聊天機器人場景優化的Encoder-Decoder模型,核心思想是將Encoder用多層前向神經網路來代替RNN模型,神經網路的輸出代表上下文信息Context和當前輸入Message的中間語義表示,而Decoder依據這個中間表示來生成對話Response。這樣做既能夠將上下文信息Context和當前輸入語句Message通過多層前向神經網路編碼成Encoder-Decoder模型的中間語義表達,又避免了RNN對於過長輸入敏感的問題。圖2和圖3是論文中提出的兩種不同的融合方法,方法1對Context和Message不做明顯區分,直接拼接成一個輸入;而方法2則明確區分了Context和Message,在前向神經網路的第一層分別對其進行編碼,拼接結果作為深層網路後續隱層的輸入,核心思想是強調Message的作用,因為畢竟Response是針對Message的應答,Context只是提供了背景信息,所以應該突出Message的作用。

當然,除了Encoder從RNN替換為深層前向神經網路外,文獻3與傳統Encoder-Decoder還有一個顯著區別,就是Decoder的RNN模型每個時刻t在輸出當前字符的時候,不僅僅依賴t-1時刻的隱層狀態和當前輸入,還顯示地將Encoder的中間語義編碼直接作為t時刻RNN節點的輸入,而不是像經典Encoder-Decoder模型那樣把中間語義編碼當做Decoder中RNN的最初輸入。其出發點也很直觀,就是在生成每個輸出字符時反復強化中間語義編碼的作用,這對於輸出應答Response較長的情況是有幫助的。
文獻4給出了解決多輪會話上下文問題的另外一種思路(如圖4所示),稱作層級神經網路(Hierarchical Neural Network,簡稱HNN)。HNN本質上也是Encoder-Decoder框架,主要區別在於Encoder採用了二級結構,上下文Context中每個句子首先用「句子RNN(Sentence RNN)」對每個單詞進行編碼形成每個句子的中間表示,而第二級的RNN則將第一級句子RNN的中間表示結果按照上下文中句子出現先後順序序列進行編碼,這級RNN模型可稱作「上下文RNN(Context RNN)」,其尾節點處隱層節點狀態信息就是所有上下文Context以及當前輸入Message的語義編碼,以這個信息作為Decoder產生每個單詞的輸入之一,這樣就可以在生成應答Response時把上下文信息考慮進來。

綜上所述,深度學習解決多輪會話的上下文信息問題時大致思路相同,都是在Encoder階段把上下文信息Context及當前輸入Message同時編碼,從而可以參考上下文信息生成應答Response。

解決「安全回答」(Safe Response)問題
如果採用經典的Encoder-Decoder模型構建開放領域生成式聊天機器人系統,一個比較容易產生的嚴重問題就是「安全回答」。就是說不論用戶說什麼內容,聊天機器人都用少數非常常見的句子進行應答,比如英文的「I don’t know」、「Come on」、「I’ m OK」,中文的「是嗎」、「呵呵」等。雖然很多種情況下這麼回答也不能說是錯誤的,但可以想像,如果用戶遇到這樣一位聊天對象會有多抓狂。

這個現象產生的主要原因是聊天訓練數據中確實有很多這種寬泛而無意義的應答,所以機器人通過Encoder-Decoder模型學會這種常見應答模式。如何解決聊天機器人「安全回答」問題,讓機器產生多樣化的應答是個重要的課題。

圖2 融合方法1



圖3 融合方法2



圖4 層級神經網路

文獻5即在Sequence-to-Sequence框架下來解決「安全回答」問題。在聊天場景下,使用Sequence-to-Sequence框架來進行模型訓練時,傳統的優化目標基本上是最大似然法(MLE),就是說給定用戶輸入Message,通過訓練來最大化生成應答Response的概率:


其中M代表message,R代表Response。

文獻X提出了改進的優化目標函數:最大化互信息(MMI),其目標函數如下:



可以從公式差異中看出,MMI的優化目標除了最大化從Message生成應答Response的概率,同時加入了反向優化目標,即最大化應答Response產生Message的概率(即log p(M|R)部分),是控制兩者哪個更重要的調節超參數。通過其名稱「互信息」以及具體公式可以看出,這個優化目標函數要求應答Response和Message內容密切相關而不僅僅是考慮哪個Response以更高概率出現,從而降低了那些非常常見的回答的生成概率,使得應答Response更多樣化且跟Message語義更相關。

採用MMI作為目標函數明顯解決了很多「安全回答」問題,表2是兩個不同優化目標函數產生的應答Response的示例,其中Message列代表用戶輸入語句Message,S2S Response代表MLE優化目標產生的應答,MMI Response代表MMI優化目標產生的應答。

表2 S2S與MMI產生的應答



個性信息一致性問題
對於聊天助手等應用來說,聊天機器人往往會被用戶當做一個具有個性的虛擬人,比如經常會問「你多大了」、「你的愛好是什麼」、「你是哪裡人啊」等問題。如果將聊天助手當做一個虛擬人,那麼這位虛擬人相關的年齡、性別、愛好、語言風格等個性特徵信息應該維護回答的一致性。利用經典的Sequence-to-Sequence模型訓練出的聊天助手往往很難保持這種個性信息的一致性(不一致的例子請參考圖5),這是因為Sequence-to-Sequence模型訓練的都是單句Message對單句Response的映射關係,內在並沒有統一維護聊天助手個性信息的場所,所以並不能保證相同的問題每次能夠產生完全相同的應答。另外,對於海量用戶來說,可能不同的用戶會喜歡不同聊天風格或者不同身份的聊天助手,所以聊天機器人應該能夠提供不同身份和個性信息的聊天助手,不同類型用戶可以採用相應類型的聊天助手來聊天,當然,在聊天過程中要盡量保持身份和個性信息的一致性。

那麼如何在Sequence-to-Sequence框架下採用技術手段維護聊天助手的個性信息一致性呢?文獻6給出了一種比較典型的解決方案,我們可以改造出一個能夠做到不同身份個性特徵的聊天助手思路。圖6是其示意圖(注意:本文敘述的並非文獻6中的原始場景,而是本文作者參照文獻稍作修正的技術方案)。

其基本思路如下:聊天機器人系統可以定義不同身份、個性及語言風格的聊天助理,個性化信息通過Word Embedding的表達方式來體現,在維護聊天助手個性或身份一致性的時候,可以根據聊天對象選擇某種風格、身份的聊天助手。整體技術框架仍然採用Sequence-to-Sequence架構,其做到思路是把聊天助手的個性信息導入到Decoder的輸出過程中,就是說在採用RNN的Decoder生成應答Response的時候,每個t時刻,神經網路節點除了RNN標準的輸入外,也將選定身份的個性化Word Embedding信息一並作為輸入。這樣就可以引導系統在輸出時傾向於輸出符合身份特徵的個性化信息。

上述是一種深度學習框架下維護聊天助手個性一致的技術框架,很明顯還可以衍生出很多種其他方案,但是技術思路應該是類似的,核心思想是把聊天助手的個性信息在Decoder階段能夠體現出來,以達到維護個性一致的目的。

小結
上述內容介紹了使用深度學習構建聊天機器人採用的主體技術框架以及面臨的一些獨特問題及相應的解決方案。此外,還有一些問題值得探討,比如如何使得聊天機器人有主動引導話題的能力,因為一般聊天機器人都比較被動,話題往往都是由用戶發起和引導,聊天機器人只是作為應答方,很少主動引導新話題,而這很容易導致聊天冷場,所以如何主動引導話題也是聊天機器人應該具備的能力之一,文獻7提出了一種技術方案,此處不贅述,感興趣的讀者可自行參考。


圖5 個性信息不一致問題
(這是利用Twitter2500萬訓練數據經過Sequence-to-Sequence模型訓練後的結果)



圖6 一種Sequence-to-Sequence框架下維護聊天助手個性信息一致性的方案

深度學習聊天機器人的優點與需要改進的方向

相對基於檢索類或者機器翻譯類傳統技術而言,基於Encoder-Decoder深度學習框架的聊天機器人具有如下明顯優點

  • 構建過程是端到端(End-to-End)數據驅動的,只要給定訓練數據即可訓練出效果還不錯的聊天系統,省去了很多特徵抽取以及各種複雜中間步驟的處理,比如省去句法分析與語義分析等傳統NLP繞不開的工作,使得系統開發效率大幅提高。

  • 語言無關,可擴展性強。對於開發不同語言的聊天機器人來說,如果採用Encoder-Decoder技術框架,只需要使用不同語言的聊天數據進行訓練即可,不需要專門針對某種語言做相關的特定優化措施,這使得系統可擴展性大大加強。

  • 訓練數據擴大有助於持續提升系統效果。對於Encoder-Decoder深度學習模型來說,一般通過不斷增加訓練數據就能夠帶來持續的效果提升。

當然,開發出具備像人一樣能夠自然交流的聊天機器人目前還面臨著各種技術難題,具體到使用深度學習技術來構建聊天機器人來說,目前在以下幾個方面還需大力加強

  • 聊天機器人的評價標準。聊天機器人效果質量的評價標準對於持續提升系統是至關重要的,因為只有這樣才能有針對性地設計技術方案進行改進。聊天機器人在評價標準方面還有待深入研究,目前常用的標準包括機器翻譯的評價指標BLEU、語言模型評價標準困惑度等,還有很多工作是通過人工來進行效果評價,還沒有特別合適的專用於聊天機器人的評價標準,這是阻礙聊天機器人技術持續發展的一個障礙。

  • 缺乏標準化的大規模訓練數據。就像上述深度學習模型優點所述,訓練數據的不斷增加一般能夠帶來性能的持續提升。但是目前來說,標準化的特大規模人與人對話數據相對缺乏,很多研究都是通過Twitter或者微博評論等高成本的采集方式來收集對話訓練數據,或者使用電影字幕等比較間接的方式來積累訓練數據。如果能夠有大規模的標準聊天數據,很明顯將能夠極大促進技術進步。

  • 技術仍處於發展初期。很明顯採用深度學習來構建聊天機器人的技術研發還處於非常初期的階段,技術手段也好,實際系統效果也好,都有非常大的進步空間。



訂閱2016年工程師(含iOS、Android及印刷版)請訪問 http://dingyue.programmer.com.cn


訂閱咨詢:

  • 在線咨詢(QQ):2251809102

  • 電話咨詢:010-64351436

  • 更多消息,歡迎關注工程師編輯部



想了解更多內容,請掃描微信 知識庫


閱讀原文


關於作者:
CSDN精彩內容每日推薦。我們關注IT產品研發背後的那些人、技術和故事。

微信號:CSDNnews