本次分享是在2019年 AI 科學前沿大會上的分享，主要介紹智能對話機器人在滴滴出行場景中的技術探索，主要内容為：
- 單輪問答
- 多輪對話
- 整體架構
▌單輪問答
單輪問答指識别使用者問題，并給出相應答案。這種場景下的目标是做到識别準确，盡量了解使用者問題，給出合适的答案。
開發過程中的難點和挑戰：
- 資料：标注資料少，這是 NLP 領域的痛點問題，因為标注成本相對較高；
- 業務：業務線比較多，我們目前支援滴滴場景下的業務線有10多個，會導緻資料标注的問題更突出，資料量少的業務，可标注的資料更少。
- 語言：使用者的表達方式靈活多樣，即同一個語義有多種表達方式。
針對上述問題，我們想了一些辦法，分析了滴滴場景下和其他智能客服的差別，比如快車和專車業務線，都是由不同模型來支援的，但是快車和專車業務其實是非常相似的，經過統計分析，二者知識點重複率接近一半。我們考慮是否可以把大業務線的資料遷移到小的業務線，但是當我們細看資料的時候，發現還是不一樣的，因為不同業務場景下的相似問，還是有差別的，比如業務獨有的知識，不能直接用在其他業務線上。
為了解決這些問題，我們一直在想資料如何更好的去遷移，減少資料的标注量。提出了類似 Multi-Task 多任務學習的架構，因為我們有不同的業務線，如果不考慮 Multi-Task 結構的話，每個業務線會有一個模型。有了 Multi-Task 之後，可以多個業務線共享一個語義模型，讓模型的泛化能力更強，為了解決不能直接映射的問題，每個業務線還有獨立的模型在後面，優化各自的目标。語義模型可以有任意模型，我們嘗試過 CNN、LSTM、Transformer、Bert 等。
上圖為我們加上 Multi-Task 之後的一些實驗結果，包括 CNN、LSTM、Transformer、Bert，其中，橙色和藍色為 Top1 準确率，灰色和黃色為 Top3 準确率，橙色為模型本身的結果，藍色為模型+Multi-Task 之後的結果，從結果上看，CNN+Multi-Task 後有一定的提升，從這一點上看 Multi-Task 還是有幫助的，進而我們做了更多的實驗，比如 Bert+Multi-task 的 Top1 準确率相比于 CNN 有了顯著的提升，在本身沒有增加新的成本的情況下，提升顯著，為什麼加了 Multi-Task 後結果這麼好呢？我們發現，新的模型特征抽取的能力比較強，但是也存在一些特點，需要足夠的資料，才能讓模型發揮出能力，我們看四個 Multi-task 模型對比（藍色），給了充足的資料後，效果提升明顯。效果好是不是因為模型好就可以了？也不是，其實如果單獨業務線，同樣的資料下，從圖中不使用 Multi-task 模型結果（橙色）的對比可以看出 CNN 的效果反而更好。原因是在資料不充足的情況下，複雜的模型參數更多，容易引起過拟合。
除了分類的結構，我們也嘗試了搜尋+語義比對+排序的架構，主要是用來做情緒安撫，思路是把候選的問答對語料，通過搜尋、生成式模型得到候選，然後經過粗排，粗排是用文本相關性的分數來計算，最後交給多輪對話深度比對模型，主要參考了去年這篇的論文：Modeling Multi-turn Conversation with Deep Utterance Aggregation ，DUA 的特點是除了計算目前的對話，還會把上下文模組化進來，重新考慮。比如情緒回複，如果是一個負向語句，如果單看這句話，它的回複可能是非常通用的，但是結合上下文，比如有的司機聽不到單了，然後他會回複一些負面語句，這時我們的回複是針對聽單場景的安撫。
除此之外，我們還有些離線的工作：
模型訓練：如上圖，為 Multi-Task 整體的一個效果，我們建立了一個每天模型自動更新的 pipeline，包括自動測試、自動上線。剛剛也提過了，資料很重要，我們會标注新的資料，來解決新的問題的出現，是以我們采用的是主動學習 Active Learning 的思想，去對邊界樣本進行采樣，這樣标注效率會更高，構模組化型訓練及線上服務的閉環，來達到每天模型更新的效果，讓新的知識、新的問題，更快的更新到我們的服務上來。讓機器人有了自我學習進化的能力。
資料标注：其實在現有的标注語料中，還存在噪音，準确率沒有那麼高。我們通過聚類的方式，把已經标注的語料聚類，這時有些樣本是偏離聚類中心的，然後把偏離的樣本通過人工檢查，如果真的錯了，就可以把噪音删除，如果是對的則保留。
▌多輪對話
在出行場景下，存在倆大類的問題，一類是咨詢了問題，比如使用者需要咨詢一些政策、規則等資訊；還有一類是尋求解決的，這兩類問題，單輪問答都很難解決使用者問題，為此我們提出了多輪對話。
1. 整體架構
我們可以看下這個例子，比如有乘客回報，司機繞路，如果是單輪的話，隻能給一個答案，而我們現在可以通過互動的方式來引導使用者去選擇訂單，選擇訂單之後，我們可以直接調用背景的接口服務能力，去判斷是否繞路了，如果真實存在，我們就會直接在機器人裡把多收的費用返還給乘客，提升了使用者體驗。
具體的方法：将傳統的多輪對話，多輪互動，引入滴滴客服機器人。主要包括幾大子產品：
① 語言了解
- 意圖識别，知識點的識别，明确問的問題是什麼
- 屬性抽取，可以了解為選擇訂單，日期等等
② 對話管理
- 對話狀态跟蹤：結合目前語義了解的結果，并結合曆史對話，上下文綜合來看，得到對話的狀态（Act 和 slot）
- 對話政策：給定對話狀态，選擇對應的動作，目前主要采用狀态機的方式，并嘗試強化學習對話政策
③ 語言生成
- 有了動作之後，我們就需要生成使用者可以了解的語言。
以上是多輪對話的整體架構。
2. 語言了解
意圖識别：
我們采用的模型為 BERT + Multi-Task Learning
槽位抽取：
我們主要是基于規則和模型結合的方法，如選訂單的元件，模型如 BILSTM + CRF 模型， 來對槽位資訊進行抽取。
3. 對話管理
這個剛剛有介紹過，右圖為狀态機，基于規則配置，左圖為我們在研發的強化學習模型，它需要一個使用者的模拟器來模拟使用者，抽樣使用者目标，根據目标和機器人去互動，從互動中生成經驗，再根據經驗進行學習，達到自動學習的效果，而不是像右邊狀态機，是由領域内的專家來配置的。
4. 智能反問
如果使用者表達的意圖不清晰，無法精确定位問題的時候，我們采用了智能反問技術：
- 圖譜查詢：通過圖譜去查詢，得到相關聯的知識點。
- 反問引導：産品形式上，在這個例子中，我們會引導使用者，會問使用者是實時單還是預約單，使用者隻要選擇之後，會給使用者推送一個更具體的、有針對性的答案。
5. 閑聊-寒暄
機器人裡都會涉及到閑聊，比如“你好”，“謝謝”之類的。針對這些問題做的工作有：
分類模型、檢索比對等，專家編寫的答案，現在我們在探索的是生成模型，讓答案更靈活。
▌機器人架構
我們整體看下機器人的架構：使用者的請求來了之後，将“查詢”和“上下文”作為輸入去查詢 frontend，frontend 作為機器人的中控，也會包括一些業務邏輯，然後通過ranker子產品做分發和選擇，下面有問答型、任務型、多輪對話型、閑聊型、圖譜型等，綜合的做一個仲裁去選擇，給到使用者一個最終的答案。
最後講一下智能客服的整體架構：
産品：我們支援的業務，包括智能客服（計程車、快車、專車等一系列業務）、司機助手、國際化客服等。
這就是我們整體的架構，這就是我今天要分享的内容，謝謝大家。
嘉賓介紹
熊超，滴滴AI Labs 智能對話團隊負責人。2010年畢業于北京航空航天大學模式識别與智能系統專業。畢業後加入騰訊從事搜尋廣告算法政策研發工作。2013年加入阿裡巴巴從事智能人機互動方向。2017年加入滴滴，組建智能客服算法團隊，主要研究方向為多輪對話，問答，智能輔助，強化學習和智能推薦。擔任頂級期刊和學術會議，如TKDE，KDD等審稿人。多項智能客服領域技術專利發明人，專利覆寫多輪對話、問答、閑聊、智能預測等。
——END——
關于 DataFun：
DataFun 定位于最實用的資料智能平台，主要形式為線下的深度沙龍、線上的内容整理。希望将工業界專家在各自場景下的實踐經驗，通過 DataFun 的平台傳播和擴散，對即将或已經開始相關嘗試的同學有啟發和借鑒。
DataFun 的願景是：為大資料、人工智能從業者和愛好者打造一個分享、交流、學習、成長的平台，讓資料科學領域的知識和經驗更好的傳播和落地産生價值。