雷鋒網(公衆号：雷鋒網)按：本文作者張俊，文章将會詳細解密1）聊天機器人所要解決的三個問題；2）以及它們所使用的模式。
引言：
chatbot是最近一段時間非常火的一個詞或者一個應用，不僅僅各大新聞媒體在熱炒bot的概念，各大巨頭也投入巨大的資源進行研發，arxiv上刷出bot相關的paper也更是家常便飯。炒作歸炒作，pr歸pr，不得不說一個尴尬的事實是市面上确實難以找到一個真正好用的bot。bot按照涉及的領域，分為開放域(open-domain)和面向具體任務(task-oriented)的bot。開放域要做的事情很大，更像是一個什麼都能搞的平台，不管你提什麼樣的需求，它都能夠解決，有點true ai的意思，而面向任務的bot則專注做好一件事情，訂機票，訂餐，辦護照等等。
說到開放域bot，大家接觸最多的也就是一些回答非常無厘頭的娛樂用bot，比如很多年前活躍在各大社交網站上的小黃雞，現在市面上活躍着很多号稱掌握了bot技術，在用深度學習解決bot技術的bot公司，都是這種，解決不了什麼實際問題，就是能和大家聊上兩句，而且很多時候回答都是牛頭不對馬嘴的，十分可笑。
再說task-oriented bot，市面上最多的就是客服機器人，銀行也好，電商也罷，不想重複性地回答使用者的問題，就用一個客服機器人來應對，且不說效果如何，開發一個具體task的bot需要費不少工夫，而且後期還要大量的維護，因為太多的hand crafted features被用到，整個bot的架構橫向擴充性相對來說較差，換一個場景基本上就需要重新開發一套，人力成本太高了。
bot的理想非常豐滿，大公司描繪的場景也确實很美，但現實的bot卻狠狠地澆了一盆冷水下來。期望越高，失望越大。如果媒體一味地吹捧bot，仿佛整個世界明天就會是bot的了，對bot的發展并無益處，捧殺隻會帶來氣泡，破裂之後，一切如初。
功能強大的、開放域的bot在短期内是比較難實作的，但是如果降低期望，将bot不應當做是一種技術層面的革命，而應當做互動層面的革新才是理性的态度，bot作為一種入口，可能大家都不再需要一個随身攜帶的終端，隻需要找到一個可以識别身份，可以聯網的硬體，比如一面鏡子，就可以執行很多的task，訂機票、買東西等等等等。bot這個時候起到的是一個操作的入口和背後執行各種不同task的黑箱，我們不需要看到整個執行過程，也不需要知道原理是什麼，通過一些簡單的語言互動，就能完成一些複雜的task，終端要做的事情就是回報結果和接收輸入，執行的過程都在雲端，各種bot雲。
而這一切的關鍵是解決好task-oriented bot，用更多data driven的解決方案來代替傳統的人工features和templates。
|問題描述
bot是一個綜合性的問題，涉及到下面三個主要問題：
1、response generation(selection)
對話生成是最後一個步驟，是輸出的部分。簡單總結下，有四種solutions：
solution 1 直接根據context來生成對話，這方面最近的paper非常地多，尤其是seq2seq+attention架構席卷了nlp的很多任務之後，對話生成的benchmark也一次又一次地被各種model重新整理着。對話生成的問題，被定義為基于某個條件下的生成模型，典型的根據context來predict words，涉及到句子生成的問題，評價問題就會是一個比較難的問題。
solution 2 當然有的paper并不是将對話生成定義為語言模型問題，而是一個next utterance selection的問題，一個多選一的問題，給定一個context，給定一個utterance candidate list，從list中選擇一個作為response，當然這類問題的難度會小很多，評價起來也非常容易，但是資料集準備起來要多花一些功夫，而且在實際應用中不好被借鑒。
solution 3 rule-based或者說template-based，response的最終形式其實是填充了一個模闆而成的，大多數的東西是給定的，隻有一些具體的value需要來填充。這一類解決方案很适合做task-oriented bot，但過多的人工features和templates導緻了其難以移植到其他task上。
solution 4 query-based或者說example-based，response是來自于一個叫做知識庫的資料庫，裡面包含了大量的、豐富的example，根據使用者的query，找到最接近的example，将對應的response傳回出來作為輸出。這一類解決方案非常适合做娛樂、搞笑用的bot，核心技術在于找更多的資料來豐富知識庫，來清洗知識庫。但畢竟respnose是從别人那裡拿出來的，可能會很搞笑，但大多數會牛頭不對馬嘴。
2、dialog state tracking(dst)
有的paper稱dst為belief trackers，這個部件其實是bot的核心，它的作用在于了解或者捕捉user intention或者goal，隻有當你真的知道使用者需要什麼，你才能做出正确的action或者response。關于這個部分，會有dialog state tracking challenge比賽。一般來說都會給定一個state的範圍，通過context來predict使用者屬于哪個state，有什麼樣的需求，是需要查詢天氣還是要查詢火車票。
3、user modeling
bot面向具體的業務，都是和真實的user來打交道的，如果隻是簡單的faq bot，回答幾個常見的問題可能不需要這塊，但如果是其他更加複雜、細緻的業務，都需要給使用者模組化，相同的問題，bot給每個人的response一定是不同的，這個道理非常簡單。user modeling，需要涉及的不僅僅是簡單的使用者基本資訊和使用者的一些顯式回報資訊，而更重要的是使用者的history conversations，這些隐式的回報資訊。就像是推薦系統火起來之前，大家都是中規中矩地賣東西，但是有一些聰明人開始分析使用者的行為，不僅是那些點贊行為，更多的是那些使用者不經意間留下的“蛛絲馬迹”，進而知道了使用者對哪些東西潛在地感興趣，也就是後來推薦系統在做的事情。對user進行模組化，就是做一個個性化的bot，生成的每一個response都有這個user鮮明的特點。
|語料
大型的語料都是用來訓練開放域bot對話生成模型的，資料源一般都是來自社交網站。而對于task-oriented bot來說，客戶的資料一般規模都非常地小，這也正是難以将data driven的方案直接套用到task-oriented bot上的一個主要原因。
[1]中給出了bot訓練語料的survey，感興趣的同學可以讀一下這篇survey。
圖來自文章[13]，英文的語料确實比較多，sina weibo那個語料是華為諾亞方舟實驗室release的[12]。從twitter或者微網誌上産生bot資料的話，“conversational in nature”效果不如從ubuntu chat logs這種聊天室産生的資料更加适合訓練response生成模型，因為更加天然無公害。文章[5]也用了一個大型中文語料，資料來自百度貼吧。
|模型
研究bot的paper是在太多了，這是一個非常活躍的研究領域，細分的方向也非常的多，接下來按照所針對的研究問題來分别介紹一些模型。
seq2seq生成模型
現在最流行的解決方案是seq2seq+attention，encoder将user query feed進來，輸出一個vector representation來表示整個query，然後作為decoder的condition，而decoder本質上就是一個語言模型，一步一步地生成response，[2]采用就是這種方案，google用了海量的參數訓練出這麼一個模型，得到了一個不錯的bot。
而典型的seq2seq存在一個問題，就是說容易生成一些“呵呵”的response，即一些非常safe，grammatical但沒有實際意義的response，比如”i don’t know!”之類的。原因在于傳統的seq2seq在decoding過程中都是以mle(maximum likelihood estimate)為目标函數，即生成最grammatical的話，而不是最有用的話，這些safe句子大量地出現在訓練語料中，模型學習了之後，無可避免地總是生成這樣的response，而文章[3]借鑒了語音識别的一些經驗，在decoding的時候用mmi（maximum mutual information）作為目标函數，提高了response的diversity。
文章[4]認為類似于rnnlm這樣的語言模型在生成人話品質不高的根本原因在于，沒有處理好隐藏在utterance中的随機feature或者說noise，進而在生成next token（short term goal）和future tokens（long term goal）效果一般。
在生成每一個utterance時，需要用到四個部分，encoder rnn、context rnn、latent variable、decoder rnn，按順序依次輸入和輸出。這裡的latent variable和ir中的lsi有一點異曲同工，latent表明我們說不清他們到底具體是什麼，但可能是代表一種topic或者sentiment，是一種降維的表示。
文章[5]提出了一種叫做content introducing的方法來生成短文本response。
step 1 給定query之後，預測一個keyword作為response的topic，這個topic詞性是名詞，這裡的keyword并不能捕捉複雜的語義和文法，而隻是根據query的每個詞來預估出一個pmi（pointwise mutual information）最高的名詞作為keyword.
step 2 [5]的模型叫做sequence to backward and forward sequences，首先進行backward step，給定一個query，用encoder表示出來得到一個context，decoder的部分首先給定keyword作為第一個詞，然後進行decoding，生成的這部分相當于keyword詞前面的部分；接下來進行的是forward step，也是一個典型的seq2seq，用encoder将query表示成context，然後給定backward生成的話和keyword作為decoder的前半部分，繼續decoding生成後半部分。整個的流程這樣簡單描述下：
step 1 query + keyword => backward sequence
step 2 query + keyword + backward sequence(reverse) => forward sequence
step 3 response = backward (reverse) sequence + keyword + forward sequence
user modeling模型
文章[6]針對的問題是多輪對話中response不一緻的問題，将user identity（比如背景資訊、使用者畫像，年齡等資訊）考慮到model中，建構出一個個性化的seq2seq模型，為不同的user，以及同一個user對不同的請将中生成不同風格的response。
[6]的模型叫speaker model，是一個典型的seq2seq模型，不同的地方在于在decoding部分增加了一個speaker embedding，類似于word embedding，隻是說這裡對使用者進行模組化。因為無法對使用者的資訊顯式地進行模組化，是以用了一種embedding的方法，通過訓練來得到speaker向量，下面左邊的圖是speaker向量在二維平面上的表示，具有相似背景資訊的user就會很接近，與word向量一個道理。
reinforcement learning模型
用增強學習來解決人機對話問題具有很悠久的曆史，隻不過随着alphago的炒作，deepmind公司将增強學習重新帶回了舞台上面，結合着深度學習來解決一些更難的問題。
增強學習用long term reward作為目标函數，會使得模型通過訓練之後可以predict出品質更高的response，文章[7]提出了一個模型架構，具有下面的能力：
1. 整合開發者自定義的reward函數，來達到目标。
2. 生成一個response之後，可以定量地描述這個response對後續階段的影響。
兩個bot在對話，初始的時候給定一個input message，然後bot1根據input生成5個候選response，依次往下進行，因為每一個input都會産生5個response，随着turn的增加，response會指數增長，這裡在每輪對話中，通過sample來選擇出5個作為本輪的response。
在一個大型資料集上訓練一個效果不錯的seq2seq作為初始值，用增強學習來提升模型實作自定義reward函數的能力，以達到期待的效果。
文章[7]的模型可以生成更多輪數的對話，而不至于過早地陷入死循環中，而且生成的對話diversity非常好。
task-oriented seq2seq模型
現有的task-oriented bot多是采用rule-based、template-based或者example-based或者是綜合起來用，用data driven的解決方案十分稀有。文章[8]和[9]就是嘗試在bot的個别部件上采用深度學習的技術來做，并且給出了切實可行的方案。
文章[8]先是從一個大家熟知的場景開始介紹，一個經驗豐富的客服是如何帶一個新入職的客服，分為四個階段：
1. 告訴新客服哪些”controls”是可用的，比如：如何查找客戶的資訊，如何确定客戶身份等等。
2. 新客服從老客服做出的good examples中模仿學習。
3. 新客服開始試着服務客戶，老客服及時糾正他的錯誤。
4. 老客服放手不管，新客服獨自服務客戶，不斷學習，不斷積累經驗。
[8]的模型架構就是依照上面的過程進行設計的：
開發者提供一系列備選的actions，包括response模闆和一些api函數，用來被bot調用。
由專家提供一系列example dialogues，用rnn來學習。
用一個模拟user随機産生query，bot進行response，專家進行糾正。
bot上線服務，與真實客戶進行對話，通過回報來提高bot服務品質。
一個完整的工作流程由上圖描述，具體步驟看下圖：
訓練的時候是用一部分高品質的資料進行監督學習sl，用增強學習rl來優化模型，得到品質更高的結果。
文章[9]平衡了兩種流行方案的優缺點，提出了一套有參考價值的、具有實際意義的seq2seq解決方案。
一共五個元件：
1、 intent network
這個部分可以了解為seq2seq的encoder部分，将使用者的輸入encode成一個vector。
2、 belief trackers
又被稱為dialogue state tracking(dst)，是task-oriented bot的核心部件。本文的belief trackers具有以下的作用：
支援各種形式的自然語言被映射成一個有限slot-value對集合中的元素，用于在資料庫中進行query。
追蹤bot的state，避免去學習那些沒有資訊量的資料。
使用了一種weight tying strategy，可以極大地減少訓練資料的需求。
易擴充新的元件。
3、 database operator
資料庫查詢的輸入來自于belief trackers的輸出，即各種slot的機率分布，取最大的那個作為db的輸入，進行查詢，擷取到相應的值。
4、 policy network
這個元件是像一個膠水，起到粘合其他上面三個元件的作用。輸入是上面三個元件的輸出，輸出是一個向量。
5、 generation network
最後一個元件是生成模型，本質上是一個語言模型，輸入是policy network的輸出，輸出是生成的response，再經過一些處理之後可以傳回給使用者了。這裡的處理主要是将response中的slot，比如s.food還原成真實的值。這一步和文章[8]的step 10一樣，将具體的值還原到entity上。
完全用end-to-end來解決task-oriented是不可能的事情，一定是在一個架構或者體系内用這種seq2seq的解決方案來做這件事情，文章[8]和[9]給出了很大的啟發。
knowledge sources based模型
純粹的seq2seq可以解決很多問題，但如果針對具體的任務，在seq2seq的基礎上增加一個相關的knowledge sources會讓效果好很多。這裡的knowledge可以是非結構化的文本源，比如文章[10]中的ubuntu manpages，也可以是結構化的業務資料，比如文章[9]中的database，也可以是一個從源資料和業務資料中提取出的knowledge graph。
文章[10]作者将bot任務定義為next utterance classification，有一點像question answering任務，給定一個context和一個response candidate list作為備選答案，通過context來從candidate list中選擇正确的response。本文的貢獻在于在context的基礎上，引入了task相關的外部專業知識庫，并且這個知識庫是非結構化的。
模型是三個rnn encoder組成，一個rnn來encode context，一個rnn來encode response，還有一個rnn來encode knowledge，然後綜合起來做預測，選出最合适的response。模型被稱作knowledge encoder。因為資料集采用的是ubuntu technical support相關的資料集，外部資源就選用了ubuntu manpages。
context sensitive模型
文章[11]的模型比較簡單，但考慮的問題意義很大，history information的模組化對于bot在解決實際工程應用的幫助很大，也直接決定了你的bot是否能夠work。作者将history context用詞袋模型表示，而不是我們經常采用的rnn，然後将context和使用者query經過一個簡單的fnn，得到一個輸出。
|評價
bot response評價很難，雖然說可以借鑒機器翻譯的自動評價方法bleu來做，但效果不會太好。幾乎每篇paper都是會花錢雇人來做人工評價，設計一套評價機制來打分，人工的評價更具有說服力。對于實際工程應用更是如此，使用者說好才是真的好。而不是簡單地拿着自己提的、有偏的名額，和幾個方法或者其他公司的bot進行對比，來說明自己好。
|思考
讀了一些paper，也和一線在做bot應用的工程師交流之後，有了一點思考，總結如下：
1、要不要做bot？流行一種說法是市面上沒有好用的bot，要解決bot的問題需要很多技術同時進步，可能還需要非常長的一段時間，現在用這個東西來做business，簡直荒謬。我個人的看法是，解決具體task的bot，結合目前先進的技術，做一些架構性的工具，并不是那麼遙遠的事情，雖然不容易，但卻非常有意義，解決了垂直領域的bot問題，才有可能解決open domain的bot問題。也正是因為不容易，提高了門檻，才會出現真正的機會，誕生一些很牛的技術公司。
2、open domain還是task-oriented？如果是我，我會選後者，因為前者隻是一個夢想，一個遙不可及的夢想，需要更多的技術層面上的大突破。task-oriented更加具體，更加實用，針對具體的業務，提供一些解決方案，已經有很多企業在做了，雖然一個通用性或者擴充性強的解決方案還沒有出現，但一定是一個趨勢，也是新一代做bot的公司的機會。
3、task-oriented bot為什麼難，該朝哪個方向來發力？end-to-end是一種理想化的模型，用深度學習模型從大量訓練資料中來“捕捉”一些features，“拟合”一些函數，雖然可以得到很不錯的效果，而且使用起來确實很友善，但尴尬就尴尬在具體的task中是拿不到海量資料的，資料規模小了之後，純粹的end-to-end就變得非常雞肋了。然而真實的場景中，很多企業又有一定的資料，也有bot的需求，是以現在成熟的解決方案就是針對你的具體業務，來設計一些features，templates和rules，當客戶的業務發生更改時，需要不斷地維護現有的bot系統，十分費時費力。真實的場景中往往涉及到很多結構化的業務資料，純粹地、暴力地直接根據context生成response是不可能做到的，文章[8][9]都給出了非常有啟發性的解決方案，将end-to-end應用在局部，而非整體上，配合上information extraction和knowledge graph等技術，實作一個高可用的架構體系，這個應該是task-oriented bot的發展方向。
4、response的生成應該與哪些因素有關呢？response品質的好壞，需要聯系到這幾個features：（1）user query，使用者的提問，使用者在這輪對話中到底在問什麼，準确地了解使用者的意圖，這是至關重要的。（2）user modeling，對使用者進行模組化，包括使用者的基本資訊，還有更重要的是使用者history conversation logs的mining，這個工作很難，但同時也很見水準，也是一家技術公司證明自己技術牛逼的一種途徑。logs的挖掘現在很常見，不見得大家都做的很好，而這裡的logs不是一般的設定好的、結構化的名額，而是非結構化的文本logs，挖掘起來難度更大。另外一點，也是paper種看到的，user emotion，情感分析是nlp中研究比較多的task，使用者的情緒直接關系到銷售的成敗，如果技術足夠牛，可以考慮的因素就可以足夠多，對user的分析也就足夠清晰。将history生挂在模型中不是一個好辦法，因為history是不斷增長，會導緻模型在捕捉資訊時出現問題，更好的辦法可能是build user profile之類的東西，将history沉澱出來，作為一個vector representation，或者一種knowledge graph來表征一個user。有了這種能力的bot，說的冠冕堂皇一點就是個性化的bot。（3）knowledge，外部知識源，涉及到具體業務的時候，業務資料也是一種knowledge，如何将knowledge模組化到模型中，在生成對話的時候可以更加專業和準确也是一個非常重要的問題。bot是一個綜合性的難題，不僅僅是系統架構上的難，而且是模組化上的難。
5、我一直覺得做人和看問題都不可以極端，世界并非非黑即白，而是介于兩者之間的連續值。不可能說要麼做成一個open-domain巨無霸的bot，要麼就是一個什麼具體功能都沒有的bot，不能隻看到現有的bot不成熟，以及幻想中的bot遙不可及，就開始黑這個領域，還嘲笑人家能夠居然拿到投資。争吵這些毫無意義，真正有意義的是深挖這個領域，找到痛點和難點，逐個擊破，不斷地推進這個領域的發展，而不是像一些街邊看熱鬧的人一樣，簡直無趣！在很多領域突破之前，仿佛都看不到曙光，但幾年之後很多當時難以解決的問題不都是紅海一片，滿大街都是了麼？做一個通用的bot可能很長一段時間内都是一件比較困難的事情，但做一個高可用、擴充性不錯的bot解決方案還是有盼頭的，不必過度自信，也不必妄自菲薄，踏踏實實地做就是了。
本文作者：clickstone