NLP_DataFun：

 

 

智能機器人在滴滴出行場景的技術探索

分享嘉賓：熊超 滴滴 AI Labs

編輯整理：Hoh Xil

內容來源：AI 科學前沿大會

出品社區：DataFun

注：歡迎轉載，轉載請註明出處

本次分享是在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 的特色是除了計算當前的對話，還會把上下文建模進來，從新考慮。好比情緒回覆，若是是一個負向語句，若是單看這句話，它的回覆多是很是通用的，可是結合上下文，好比有的司機聽不到單了，而後他會回覆一些負面語句，這時咱們的回覆是針對聽單場景的安撫。

 

DUA：

原文聚焦的是基於檢索式響應匹配多輪對話，研究如何更好的提取並利用先前對話中的關鍵信息，以及如何建模先前對話內容與響應之間的關係。原文之前的檢索式多輪對話工做，都只是簡單將對話語句內容鏈接起來，這樣作有兩個缺點：(1)忽略了前面語句之間的交互，(2)上下文是冗長和冗餘的，至關於引入不少噪音。爲了解決這些缺點，達成研究目的，原文做者提出了深度對話聚合(Deep Utterance Aggregation，DUA)，它將以前的對話內容組織成上下文，從而造成多個細粒度的上下文表示，而後將每個細粒度的上下文表示對應一個響應進行匹配，最後通過多輪精細的聚合獲得最終的匹配分數。原文的實驗是在三個公開的對話數據集上進行的，其中包含了一個新的數據集--電商對話語料(E-commerce Dialogue Corpus，EDC)，三個數據集上都取得了SOA的性能。

 

《Modeling Multi-turn Conversation with Deep Utterance Aggregation》閱讀筆記 論文原文：https://arxiv.org/pdf/1806.09102.pdf 剛看到小夕的這篇總結我的感受講的很好很容易理解，裏面涉及了4篇論文串燒，按照時間講了算法的發展，文風也蠻有趣（有點嗲，哈哈~） 上海交通大學等2018年發表的文章，主要涉及基於檢索式的多倫問答模型，提出了一個深度對話整合模型（DUA），是針對多輪對話將過去會話直接拼接做爲上下文信息存在噪聲和冗餘等問題，DUA從對話和回覆中採用attention機制挖掘關鍵信息，凸顯關鍵信息忽略冗餘信息，最終得到utterances和response的匹配得分。本文還發布了一個電子商務對話語料庫ECD，涉及到商品諮詢、物流快遞、推薦、談判、聊天等，本文的數據集及代碼。結構以下可分爲5個模塊： DUA的優勢： 最後一輪對話很好的與前面對話結合，其最主要信息能夠更好的用語義相關的方法來解決 每輪會話能夠凸顯關鍵信息，從必定程度上忽略冗餘信息 計算最終匹配得分的時候充分考慮各輪對話之間的關係 Utterance Representation  採用GRU模型將每一個utterance和候選response進行embedding。 Turns-aware Aggregation Utterance Representation是將utterance同等看待沒有考慮the last utterance和以前對話之間的關係，該模塊主要是將最後一個utterance（the last utterance）與context中的其餘utterance以及候選response進行融合，論文中是直接將utterances和response的embedding串聯起來，獲得表徵F。 Matching Attention Flow 該模塊是對上一模塊turns-aware的表徵信息F信息進行處理，採用一個self-matching attention mechanism將冗餘信息進行過濾，挖掘utterances和response中的顯著特徵，即經過一個attention機制的GRU進一步作表徵的交互與融合。  [·,·] 是兩個向量串聯在一塊兒 ,Ct是self-matching attention的輸出 Response Matching 第四模塊在單詞和會話級別上對 response和each utterance進行匹配，通過CNN造成匹配向量。 這裏從兩個粒度進行匹配： 詞粒度：u和r都是相應utterance和response中的某一個詞，經過下式能夠獲得這兩個句子相應位置上的匹配度。最後這些各個位置上詞粒度的匹配度能夠造成一個shape爲(utterance長度，response長度)的矩陣M1 句子粒度：P是上一個模塊中獲得的utterance和response中各個位置上的表徵，一樣能夠獲得一個shape爲(utterance長度，response長度)的矩陣M2 爾後分別在這兩個矩陣上進行CNN卷積操做，獲得卷積以後的表徵。 最後進行max-pooling和flatten以後concatenation。 Attentive Turns Aggregation 將匹配向量按上下文話語的時間順序傳遞GRU，獲得utterance和response的最終匹配得分，分爲三步： 第一步：先經過一個GRU； 第二步：attention機制； 第三步：加一個softmax，獲得匹配度。 參考： 巷裏野貓 https://www.paperweekly.site/papers/2352 https://zhuanlan.zhihu.com/p/44539292

 

 

除此以外，咱們還有些離線的工做：

模型訓練：如上圖，爲 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 的願景是：爲大數據、人工智能從業者和愛好者打造一個分享、交流、學習、成長的平臺，讓數據科學領域的知識和經驗更好的傳播和落地產生價值。

DataFun 成立至今，已經成功在全國範圍內舉辦數十場線下技術沙龍，有超過三百位的業內專家參與分享，彙集了數萬大數據、算法相關領域從業者。

 

點下「在看」，給文章蓋個戳吧！👇

 

---

 

 

 

 

 

 

---

 

 

不錯的科普

 

「回顧」天然語言處理中的多任務學習

 

分享嘉賓：邱錫鵬 復旦大學計算機科學技術學院 副教授，博士生導師

編輯整理：靳韡贇

內容來源：DataFun AI Talk《天然語言處理中的多任務學習》

出品社區：DataFun

 

 

本次報告內容的題目是天然語言處理中的多任務學習，報告主要分爲四個部分：

 

一、基於深度學習的天然語言處理；

二、深度學習在天然語言處理中的困境；

三、天然語言處理中的多任務學習；

四、新的多任務基準平臺。

 

首先簡單介紹一下實驗室狀況，課題組主要聚焦於深度學習與天然語言處理領域，包括語言表示學習、詞法/句法分析、文本推理、問答系統等方面。開源天然語言處理系統FudanNLP，並將在12月中旬推出全新的NLP系統：fastNLP。

 

 

1、天然語言處理簡介

 

天然語言處理就像人類語言同樣，與人工語言的區別在於它是程序語言，天然語言處理包括語音識別、天然語言理解、天然語言生成、人機交互以及所涉及的中間階段。下面列舉出了天然語言處理的基礎技術、核心技術和一些應用：

 

基礎技術：詞法分析、句法分析、實體識別、語義分析、篇章分析、語言模型；

核心技術：機器翻譯、自動問答、情感分析、信息抽取、文本摘要、文本蘊含；

應用：智能客服、搜索引擎、我的助理、推薦系統、輿情分析、知識圖譜。

 

天然語言處理最初由規則驅動，逐步發展爲數據驅動。

 

 

2、深度學習在天然語言處理中的困境

 

因爲缺乏大規模的標註數據或者標註代價過高，目前大部分用在NLP上的神經網絡都不是很深，通常狀況下，一層LSTM+Attention就足夠完成大部分NLP任務。解決問題的方法包括有無監督預訓練、多任務學習和遷移學習。今天咱們主要介紹多任務學習。

 

 

一、無監督預訓練

 

首先咱們來介紹一下NLP中很是重要的無監督預訓練，早期有不少研究者使用詞向量等詞級別的模型，後來發展爲使用句子級別的模型，例如最近出現的ELMo、OpenAI GPT、BERT等，人們從最初學習更好的詞的表示轉變爲學習更好的句子的表示。

 

 

論文Deep Contextualized Word Representations主要描述的是ELMo問題，經過創建兩個雙向的LSTM來預測一個前向、正向的語言模型，而後將它們拼起來，這個模型是一個很是好的遷移模型。

 

 

谷歌新推出的BERT是將機器翻譯中的經常使用模型transformer的雙向訓練用於建模，它在不少任務中取得了較好的效果。

 

 

這些模型證實在NLP中表示學習依然十分重要，表示學習是從文本輸入到計算機內部的一種表示，對於NLP任務，表示學習是指將語義信息表示成稠密、低維的實值向量。表示好以後送到分類器中，好的表示是一個很是主觀的概念，沒有一個明確的標準。通常而言，好的表示具備如下幾個優勢：

 

1）應該具備很強的表示能力，模型須要必定的深度；

2）應該使後續的學習任務變得簡單；

3）應該具備通常性，是任務或領域獨立的。

 

 

二、多任務學習

 

下面給出一個多任務學習的例子，對於兩個單獨的任務訓練兩個模型，對於任務1訓練一個模型1，對於任務2訓練一個模型2，多任務就是將兩個任務放在一塊兒用一個模型來處理。

 

 

多任務學習最先在97年被提出，多任務學習隱含着從其餘任務中學習一種共享的表示，共享表示能夠做爲一種概括偏置，概括偏置能夠看作是對問題相關的經驗數據進行分析，從中概括出反映問題本質的模型的過程，不一樣的學習算法（決策樹、神經網絡、支持向量機）具備不一樣的概括偏置，在學習不一樣的任務過程當中使用共享表示，能夠使在某個任務中學習到的內容能夠幫助其餘任務學習的更好。

 

 

因爲傳統NLP的表示空間是離散的，MTL+NLP在傳統的NLP模型是很是難實現的，隨着深度學習的應用，整個NLP的表示空間變爲連續的，使得任務實現更加容易。例以下圖中taskA和taskB兩個任務能夠共享同一個模型。

 

 

不一樣學習範式之間的關係：多任務學習之上有遷移學習，之下有多標籤學習和多類學習。

 

 

損失函數：假設有m個任務，多任務學習的損失函數是將各個任務的損失函數相加求得聯合損失函數joint loss。

 

 

訓練方式：首先進行Joint Ttaining，Training以後進行Fine Tunning。

 

 

多任務學習工做的優勢：

 

1）隱式的數據加強：一個任務的數據量相對較少，而實現多個任務時數據量就獲得了擴充，隱含的作了一個數據共享。

2）更好的表示學習：一個好的表示須要可以提升多個任務的性能。

3）正則化：共享參數在必定程度上弱化了網絡能力，防止過擬合。

4）竊聽：某個特徵很容易被任務A學習，可是難以被另外一個任務B學習，這多是由於B以更復雜的方式與特徵進行交互或者由於其它特徵阻礙了模型學習該特徵的能力。經過MTL，咱們能夠容許模型竊聽，即經過任務A來學習該特徵。

 

目前NLP中每一個任務只作其中的一塊，若是咱們把這些任務拼起來會取得更好的效果。

 

3、天然語言處理中的多任務學習

 

下面介紹幾種多任務學習的方式，傳統的天然語言處理在輸入端輸入文本，以後進行詞法分析和句法分析最後完成任務，這種方式很難實現，在有了多任務學習以後，不一樣的任務能夠共享詞法分析和句法分析模塊，天然語言處理的方式獲得了簡化。

 

 

天然語言中的多任務學習包括有：多領域任務、多級任務、多語言任務、多模態任務等。

 

 

深度學習+多任務學習有硬共享、軟共享、共享-私有等多種模式。

 

硬共享模式：在下面層共享，上層根據本身不一樣的任務作不一樣的設計；

軟共享模式：每一個任務都有本身的流程，從信息流來看就是從輸入到A有本身的體系流程，還能夠從其餘任務的表示方法中拿一些東西過來；

共享-私有模式：一部分共享，一部分私有的信息傳遞機制。

 

 

此外還有多級共享、函數共享、主輔共享等多種共享模式，下面將一一介紹。

 

 

一、硬共享模式

 

硬共享在下面層共享，上面根據本身的不一樣的任務來作不一樣的設計，這種方法最先在2008年由Ronan Collobert在論文A  Unified Architecture for Natural Language Processing：Deep Neural Networks with Multitask Learning中提出，應用到了不少與語義相關和語法相關的方面，例如機器翻譯、文本分類等。

 

 

後來人們將注意力機制模型用於共享模式，注意力機制不須要使用全部的信息，只須要將其中部分信息選擇出來，人們基於注意力機制作了共享模式。

 

 

原來的多任務學習如圖a所示，下面的s是共享層，p是不一樣任務本身的設計。如今咱們將原有的算法轉換大圖c的形式，全部的表示函數共享，在輸入到具體任務的時候使用一個和任務相關的查詢Q去s中選擇任務相關的信息。雖然表示方式是同樣的，可是針對不一樣的具體任務，會根據每一個任務關注點的不一樣來選擇相應的信息。

 

二、軟共享模式

 

在軟共享模式中沒有嚴格規定共享層。經典網絡cross-stitch結構中，上面是taskA，下面是taskB，在中間部分兩個任務有交互，α是權重係數，表示taskA中有多少信息從自身流過來，有多少信息從taskB中流過來，這樣兩個任務就由兩路，四個係數構成一個矩陣作權重組合，若是用到神經網絡就相似於下圖中右邊的這種形式，這種網絡最初應用於機器視覺領域，後來被人們用於NLP。

 

 

三、共享-私有模式

 

在共享-私有模式中部分網絡模塊在全部的任務中是共享的，經過設置外部記憶共享機制來實現信息共享，神經圖靈機就是在神經網絡中引入一個memory模塊，整個框架就是用神經網絡實現的一個控制器，加讀寫頭和外部輸入。圖靈機所有由神經網絡搭建而成。

 

 

基於神經圖靈機的想法咱們能夠作一個多任務學習，每一個任務咱們均可以看作是一個單獨的圖靈機，外部的memory在全部的任務中共享。在下圖中M是外部記憶，外部記憶由兩個任務共享，每一個任務都會把共享信息寫到外部記憶中，這是一種很是簡單的共享方式。

 

 

爲了不上圖中的負遷移negative transfer，就須要判斷哪些內容是和任務相關的，這就引入了近兩年流行的對抗學習，在對抗學習中，中間的LSTM共享層有一個判決器來區分共享特徵從哪一個任務傳遞過來，在送入LSTM以前會包含有特徵的來源信息。所以咱們但願訓練一個和判決器對抗的網絡，在共享的LSTM層中儘量讓判決器不能區分任務來源。這樣就去掉了特徵的源信息，保證了共享LSTM學到的是與源無關的共享價值信息，這些叫作對抗信息。

 

下面咱們將介紹幾種將來研究的方向：

 

一、函數共享模式

 

以前咱們瞭解的多任務學習都是特徵共享，在函數共享中咱們學的再也不是共享特徵而是共享函數，來生成一些參數或模型，這裏咱們將feature級的共享遷移到函數級的共享，下圖中第一幅圖圖是特徵共享，中間藍色的是共享層，它將學到的特徵送到上下兩個任務中，第二幅圖是函數共享，函數共享中共享層的輸出不是直接送到上下兩個分類器中，而是決定了上下兩個分類器的參數。經過修改分類器來有效利用這些信息。

 

二、多級共享模式

 

2016年Anders Sфgaard等人在論文Deep Multi-task Learning with Low Levels Tasks Supervised at Lower Layers中提出在低級的網絡層次輸出低級的任務，在高級的網絡層次輸出高級的任務。例如在第一層輸出詞性標籤POS tag，在第三層輸出chunk tag，將NLP任務按照不一樣的級別來設計共享模式。

 

 

三、主輔任務模式

 

在作任何一個主要任務的同時均可以引入一個輔助任務。以下圖，咱們對每一個任務引入一個輔助的語言模型，每一個任務都使用左右兩個語言模型，對全部任務進行這種拓展就造成了主輔任務模式。

 

 

四、共享模式搜索

 

共享模式搜索是讓計算機自動搜索這些共享模式，具體作法如圖d所示，咱們但願設計一種靈活的框架，在共享池中放入不少不一樣的模塊，每一個任務在完成過程當中能夠從共享池中挑選一些模塊來組裝本身的guideline。示例中任務A挑選了四、三、1，任務B挑選了三、二、1，這就隱含了A從M4出來，而B從M3出來，C從M2出來，這樣一種層次化的共享模式設計。它自己也能夠實現hard和soft的兩種表示方式，所以是一種很是靈活的表示方式。

 

 

在面向NLP的神經網絡架構搜索中，從共享池中挑選Ma1，Ma2等模塊來組成不一樣的模型，將模型帶入任務中去訓練，獲得正確率做爲reward反饋給分類器從而選擇更合適的組合方式來完成任務。

 

 

下面給出的例子就是對不一樣的任務挑選的不一樣的組合方式，其中有些組合方式很是相似。

 

 

4、新的多任務基準平臺

 

首先介紹一下機器閱讀理解，機器閱讀理解是在閱讀一篇或多篇文檔後，回答一些相關問題。由機器來生成答案，答案可能在原文中出現也可能不在原文中出現，目前機器閱讀理解大部分都假設答案在原文中出現，咱們用的一個主要框架是Biderectional Attention，同時給你context和query，作一個雙向的注意力交互，最終肯定兩個位置，一個是答案開始的位置，一個是答案結束的位置，大部分的問題均可以經過這個框架來解決，這個框架具備通用性。幾乎NLP全部任務均可以轉化成閱讀理解任務經過該框架解決和完成。

 

 

今年新發布的一個NLP通用的多任務學習系統叫作十項全能，選取了十個典型的NLP任務轉化成閱讀理解的形式，例如左下角的情感分類問題，將這些任務轉換到閱讀理解問題後採用Biderectional Attention框架去處理。因爲這些問題的答案不必定出如今背景文檔中，所以須要對Biderectional Attention框架進行改進。

 

 

還有一個較大的框架是GLUE，也是將不少NLP任務轉化成一個統一的形式。下圖中是三個任務：單個句子任務、計算兩個句子類似度、表示兩個句子之間的蘊含關係。這些任務均可以作成encoder和decoder模式。

 

 

5、總結

 

最後，咱們對今天介紹的內容作一個總結。今天主要介紹了天然語言處理簡介、基於深度學習的天然語言處理、深度學習在天然語言處理中的困境、多任務學習和新的多任務基準平臺。總的來講多任務學習的難度會比遷移訓練低而效果比預訓練要高一些。

 

 

另外，在今年12月中旬，咱們將發佈一個模塊化的開源天然語言工具fastNLP。

 

 

這個工具包括Spacy高級接口、AllenNLP自定義模塊、AutoML自動調參。將訓練好的模型開放出來供你們直接調用。

 

 

爲實現模塊化，咱們將NLP分爲四個構成組件：

 

一、編碼器：將輸入編碼爲一些抽象表示，輸入的是單詞序列，輸出是向量序列；

二、交互器：使表示中的信息相互交互，輸入的是向量序列，輸出的也是向量序列；

三、聚合器：聚合信息，輸入向量序列，輸出一個向量；

四、解碼器：將表示解碼爲輸出，輸出一個標籤或者輸出標籤序列。

 

 

這裏咱們給出了兩個示例，分別是文本分類和序列標註。

 

 

能夠應用的場景主要包括：

 

一、直接調用；

二、模型開發；

三、自動化學習。

 

配套PPT下載，請識別底部二維碼關注社區公衆號，後臺回覆【上海NLP】

 

做者介紹：

 

邱錫鵬，復旦大學計算機科學技術學院 副教授，博士生導師，於復旦大學得到理學學士和博士學位。中國中文信息學會青年工做委員會執委、計算語言學專委會委員、中國人工智能學會青年工做委員會常務委員、天然語言理解專委會委員。主要研究領域包括人工智能、機器學習、深度學習、天然語言處理等，而且在上述領域的頂級期刊、會議（ACL/EMNLP/IJCAI/AAAI等）上發表過50餘篇論文。天然語言處理開源工具FudanNLP做者，2015年入選首屆中國科協青年人才託舉工程，2017年ACL傑出論文獎。

 

——END——

 

 

 

文章推薦：

 

「回顧」獵戶星空NLP技術進展及產品應用

「回顧」如何構建知識圖譜？

「回顧」Recent Advances on Object Detection in MSRA

 

 

---

 

阿里小蜜中的情緒回覆能力

分享嘉賓：宋雙永 阿里小蜜

編輯整理：趙文嬌

內容來源：AI 科學前沿大會

出品社區：DataFun

注：歡迎轉載，轉載請註明出處

本次分享內容提綱：

• 阿里小蜜介紹

• 情緒回覆能力介紹

• 客戶情緒安撫

• 客服質量檢測

• 情緒生成式語聊

1、阿里小蜜介紹

傳統的客服模式始於電話客服，會有專業的諮詢顧問幫客戶解答問題。以後有了在線客服和線上申請，在線客服相似於文字聊天，線上申請是非實時的通信方式，能夠理解爲相似留言或者郵件的形式。

1. 智能服務模式

在阿里場景下咱們對問題進行了區分，將其分紅問題諮詢和交易糾紛，分別有專門的顧問進行解答。在智能服務模式下，在問題諮詢端創建了小蜜這樣的產品，若是問題比較複雜，小蜜解決不了，仍是會把問題轉到人工顧問這一端，爲用戶提供更全面的服務。即使這樣，在人工客服一端，也有對應的智能輔助產品，幫助提升人工客服的服務效率，好比檢索是否有歷史類似答案提供給人工客服，幫助他們快速完成解答。

2. 模式的升級與生態圈拓展

智能客服能力創建以前，人工服務的能力來自於自營客服、外包客服和雲客服。模式升級以後，利用智能服務的能力，造成了平臺能力、三方能力、智能人機交互這三種服務模式。服務的對象能夠理解爲三個層次，其中，阿里是包括指淘寶、天貓、鹹魚、淘票票等阿里巴巴內部產品平臺的範圍；商家是指依託於阿里巴巴淘寶和天貓等平臺之上的外部商家；企業則是指純粹外部的企業。

如圖，最下面這層實際上是爲小二進行服務的，小二是阿里客服的簡稱。在上面機器人配置平臺這一層是爲機器人服務提供一些能力。再往上一層是按照產品進行劃分，分紅阿里小蜜、店小蜜和企業小蜜。阿里小蜜主要服務阿里內部的淘寶天貓這樣平臺，店小蜜服務阿里平臺上的商家，企業小蜜服務於外部企業。

2、阿里小蜜情緒回覆能力

咱們今天介紹阿里的小蜜產品在情緒回覆能力上的技術發展。情感機器人的兩個主要發展方向：

• 類人：就是情感越像人越好。

• 多模態：就是情緒的表達其實能夠有多少手段，對人而言，能夠是語言、表情神態、肢體語言等。

從情感處理能力上來講，能夠把機器人分紅三類：

第一類是機器人沒有情感處理能力，阿里小蜜最開始的版本確實是沒有情感處理能力的，只是對高頻場景中的問題進行解答，好比用戶說我要退貨、如何退貨、趕忙給我退貨，獲得的答覆都是阿里平臺上如何退貨的文字描述，但其實第三句是有強烈情緒表達的，可是初期的阿里小蜜沒有這樣的理解能力；

第二類機器人是有完整的情緒識別能力的，目前體現最多的是在一些閒聊場景下，好比小冰，好比在對罵場景下，若是客戶罵機器人，機器人雖然沒有直接的對罵，機器人也會有婉轉的方式，好比 " 180度反彈 " ，雖然沒有直接對罵，可是也表達了對本身辱罵的情緒，這是一種情緒比較完整的機器人；

第三類機器人產品，客服機器人，客戶能夠罵人，可是人工客服和客服機器人是絕對不能有這種情緒的，辱罵、諷刺、挖苦是機器人絕對不能有的情緒。可是有一些，好比高興、委屈是機器人能夠有的，因此小蜜的定位是部分情緒能力缺失的客服機器人。

從多模態角度來講，阿里小蜜目前只考慮了文本，和少許語音。

情緒回覆，今天會講兩個方面，一個是理解情緒，另一個是表達情緒。

3、客戶情緒安撫

從三個方面進行介紹：服務質量檢測，客戶情緒安撫和情緒回覆生成。

先看客戶情緒安撫，針對常見場景，咱們不只僅只是告訴客戶一些流程，好比退貨流程，仍是有一些安撫在裏面。而後看右面的情緒回覆能力，這個情緒回覆能力，和情緒安撫的主要區別是，情緒安撫是業務專家以前預設好的各類答覆，可是情緒回覆採用純生成式的模型，用在閒聊場景，內容不是提早配置好的；最左邊的服務質量監測，若是從小蜜轉到人工客服，小蜜也是繼續服務的，針對服務質量很差的時候，會對人工客服作一些警示，就是提示他，注意本身的服務態度。下面針對這三塊進行更爲詳細的介紹。

針對客戶情緒安撫，咱們分紅離線端和在線端。

離線端，從下往上是以下幾個離線處理，首先是情緒分類模型，這是整個流程最基本的東西，咱們要去識別客戶交流過程當中體現的情緒；而後是主題分類模型，也就是說咱們不只要識別出情緒，還要知道聊的是哪方面的內容；第三步是知識構建，這裏的知識構建應該就是一個問答對，作這一步的緣由是，由於情緒分類和主題分類都比較粗，針對一些高頻的問題，但願給用戶更具體的回覆方式。

在線端，實際上是一個相反的過程，首先識別用戶所說的是否是和以前總結的知識點比較接近，若是有就拿出來進行回答，若是沒有就看是否能夠歸結到某種主題這樣的狀況上，若是再沒有的話，咱們就監測，它是否是僅僅是屬於一種情緒表達，而後給更出更寬泛的情緒安撫。

其中的情緒分類模型：

經過數據分析以及參與經常使用的情緒字典，咱們將情緒劃分爲38類 ( 感激、驚奇、失望、抱歉、期待、疑惑、尷尬、高興、着急、怨恨、喜歡、抑鬱、委屈、輕視、懼怕、孤獨、憤怒、悲傷、滿意、無聊、同情、平靜、煩惱、激動、嫌棄、懊悔、羞愧、解恨、猶豫、思念、感動、敬佩、心慌、低落、驕傲、心虛、羨慕、辱罵 ) ，可是其實咱們針對最經常使用的7類 ( 委屈、恐懼、着急、失望、憤怒、辱罵、感謝 ) 模型訓練出單獨的分類模型，這樣對這7中情緒分類的更準確。

上面是模型圖，最左邊的兩個 poolling 是在作句子級別的語義特徵抽取，這個實際上用的是 swem 算法；中間是 n-gram 多元的特徵抽取，用的是 cnn 的模型，咱們提取了兩元、三元、四元這樣的信息造成特徵；最右側的一塊是 emotion embedding，用到了18年發表一篇文章的思路。在咱們的場景下，label 就是 emotion，因此這一塊叫 emotion embedding，這裏將 word embedding 和 emotion embedding 結合起來實際上是算某個詞在某個 emotion 下面的 attention score，attention 能夠理解爲權重。這樣更直接的體現了詞級別的語義特徵，整個句子從左到右，就是將詞級別的、n-gram 級別的和詞語級別的語義信息結合起來，才能得到比較好的語義分類。由於在線端用戶打的句子都比較短，用這種方式才能實現比較好的語義識別的結果。

第二部分就是主題分類，咱們定義的時候稱呼爲 " 情緒主題類別 " 。好比阿里小蜜有查天氣的功能，而且被高頻使用，這部分有沒有必要放到這個模塊呢？實際上是沒有必要的，通常是經過點擊按鈕引導操做，只是想看看天氣，幾乎沒有情緒表達的。而這裏提到的模型是用於識別情緒主題類別，從情緒的角度，歸結常見的主題，而其它不帶情緒的主題是沒有歸到裏面。下面是針對7類情緒，作了35種情緒主題分類，主題分類架構和剛纔的情緒分類的架構一致。

最後，基於知識的安撫，就是看用戶說的話是否是和某個知識點很相近，這時候咱們就用到匹配回覆這樣的模型能力，在文本匹配這一起能夠分紅兩個功能能力。首先是分紅兩部分，最左邊兩塊是一部分，最右側是一部分，最左邊的兩塊是兩句話，他們分別在提取特徵，最後把特徵合併到一塊兒作分類，最右邊的部分是把兩個句子從一開始就進行交互，把交互的結果，一層層作特徵抽取，這至關於一個交互時間點的不一樣，一個是最後交互，另外一個是一開始交互，咱們把兩種交互抽取特徵的結果結合到一塊兒，作一個準確率更高的文本匹配模型，來實如今線匹配問答。

4、客服質量檢測

咱們只探討兩種服務問題，一種是消極，一種是態度差，消極是指愛搭不理的態度，態度差是指客服雖然給了客服充分的回覆，可是態度很差，好比可能有反懟客戶，諷刺客戶的現象發生。這套服務提供給平臺端和商家端，平臺端就是好比淘寶，天貓這樣阿里自家平臺，商家端是商家本身的店鋪的客服檢測，這是兩個不一樣的模型，由於兩種場景在服務質量的要求上存在不一樣的衡量標準。

在機器人端典型的對話方式是一問一答，而在人工客服端每每出現多問多答的狀況，好比客戶連着說幾句，客服是連着回答幾句。這時候咱們對客服服務質量進行評價就須要很是關注上下文，而且上下文每句話是誰說的，等等這些信息。

模型以下圖，考慮了句子長度、說話人角色，以及內容的語義信息等等特徵。

5、情緒生成式語聊

下圖是比較通用的語義生成模型，這種傳統的生成模型存在的一個問題就是 ' safe response ' 的產生，就是很泛泛的一個回覆，不多有情感傳達在裏面，好比好，哦哦，能夠這樣的回覆。

咱們的目的是讓機器人產生帶情緒的回覆，另外但願回覆更具備針對性一些，而不是所有都是通用的 ' safe response '，在下面的模型裏，除了情緒，咱們還能夠添加 topic 相關的信息，分析出聊天的主題。下面的例子裏，客戶說今天心情很好，聊的是生活化的主題，表達的是高興的情緒，這時候咱們生成 ' 好開心啊 '，回覆用戶。

針對上述的用戶和機器人的情感對應關係，能夠進行預設。好比客戶在表達高興的時候，咱們也要表達出高興，用戶在辱罵咱們的時候，咱們要表達出委屈。

6、將來工做

將來，咱們要作一個 session 滿意度預估，這裏的 session 就是一個完整的對話，目前是經過人工用研分析，是設計一個調查問卷的形式，隨機抽取天天的用戶，而後讓用戶打分，最後的分數就是滿意用戶的佔比。

存在的問題就是：一個是耗費人工；二是天天的統計量是不足的，所以會產生天天統計結果比較大的天然震動。

聯繫咱們：

歡迎對智能問答機器人、天然語言處理、機器學習等領域感興趣的業內優秀同窗、老師、專家關注咱們的算法專家、高級算法專家、資深算法專家等崗位，感興趣能夠發送您的簡歷至：

shuangyong.ssy@alibaba-inc.com 

進行內推，或者郵件諮詢崗位細節，感謝您的關注！

嘉賓介紹：

宋雙永，阿里巴巴小蜜情感語聊算法負責人，智能服務事業部算法專家。致力於智能對話中的情緒回覆能力以及開放域語聊能力的算法研究和業務場景落地，在機器學習和天然語言處理領域積累了多年的實戰經驗，發表了多篇學術文章和專利。

——END——

文章推薦：

阿里小蜜：智能服務技術實踐及場景探索

阿里神馬智能對話問答

阿里媽媽：電商預估模型的發展與挑戰

加入 DataFun 社羣：

請關注社區公衆號，後臺回覆【DF】

關於 DataFun：

DataFun 定位於最實用的數據智能平臺，主要形式爲線下的深度沙龍、線上的內容整理。但願將工業界專家在各自場景下的實踐經驗，經過 DataFun 的平臺傳播和擴散，對即將或已經開始相關嘗試的同窗有啓發和借鑑。

DataFun 的願景是：爲大數據、人工智能從業者和愛好者打造一個分享、交流、學習、成長的平臺，讓數據科學領域的知識和經驗更好的傳播和落地產生價值。

DataFun 成立至今，已經成功在全國範圍內舉辦數十場線下技術沙龍，有超過三百位的業內專家參與分享，彙集了數萬大數據、算法相關領域從業者。

 您的「在看」，個人動力！👇

 

 

 

 

 

 

 

 

 

---

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

回顧·對話機器人在瓜子的實踐

本文根據車好多NLP方向負責人王文斌老師在DataFun「AI+」Talk—— 「Application of AI In Second Hand Market」中分享的《對話機器人在瓜子的實踐》編輯整理而成。

今天主要分享如下幾個方面，首先介紹下什麼是對話機器人，而後講一下技術選型的過程，設計了怎樣的算法架構和系統架構，最後分享下線上的效果以及在瓜子中面臨的一些挑戰。

 

目前對話機器人很火，是有多方面緣由的：第一，圖靈在定義智能時就將對話機器人做爲人工智能的一個標誌；第二，深度學習技術愈來愈成熟，對話機器人在工業界已經達到必定水平；第三，對話機器人因爲有智能客服的積累，有不少公司在作這方面的東西。上面是一個智能客服設計圖，左邊是接入渠道，登陸進來，會提供一些客服產品，如機器人客服、人工在線客服、雲呼叫中心，以及用戶依據產品作一些自助服務。聊天過程當中用戶會將其數據留下來（反饋數據、對話數據、人工客服數據），利用這些數據就能夠作分析，如客服數據能夠作質檢，用戶數據能夠作營銷工做，與CRM接入打通。

 

接下來說一下會什麼要有對話機器人，開始瓜子目標就是提升效率，用機器替代人，達到縮減人力和培訓成本、7*24小時在線服務、質量可控的目標。在發展的過程當中概念慢慢昇華到一個在線化的概念，就是數字化、數據化和智能化。數字化就是將用戶和企業交互的數據都記錄下來，將數據結構化，作成算法可用的數據叫數據化，有了數據化就能夠用建模等一系列智能化手段作一些智能化提高。在線化作後能夠作到整個溝通可追蹤、提供可優化、差別化的服務以及精細化運營，最終推進企業在線化。

在線機器人是在線聊天的一部分，既是整個服務閉環的入口也是出口。用戶能夠在聊天中表達和解決相應的訴求，而搜索、推薦更像是一個被動的過程，IM是一個主動表達訴求的門戶。

 

對話機器人的分類：開放式的有微軟小冰、度祕；任務導向的有訂機票、詢問天氣。從角色定位角度，如提供IM通道其實就是架構，只有有了骨架才能作相應的應用，算法在裏面是一個關鍵的做用，後期其實更多的是偏產品化的東西。對話機器人技術是透明的，區別在於誰作的細節更完善。開發的角度就是完善三個視圖，客戶視圖： 對話內容、對話框、對話框外推薦信息；客服視圖：對話上下文、客戶畫像、背景信息、訂單畫像，管理者視圖：控制檯、知識庫。

對話機器人經典流程：語音喚醒，告訴你要幹嗎，喚醒以後通過語音識別轉化爲文本，這時候能夠作語義理解（其中可能須要知識庫交互），將語義理解的結果經過對話管理引擎拿到用戶對應的話術，將對應的話術轉化爲文本，最後轉化爲語音輸出。

 

 

說明下對話機器人的核心概念，如「幫我定一張明天上午10點從北京到上海的機票」，這句話的意圖就是「訂機票」。槽位就是若是要徹底理解一句話而且可以夠返回結果信息還須要什麼屬性，這句話槽位信息有：起飛時間 = 明天早上10點，起始地 = 北京，目的地 = 上海。

 

接下來說一下技術選型，這是對話機器人選用技術調研的過程。對話機器人開始是基於關鍵詞，而後就是模板技術，目前不少公司還在使用，優勢是質量可控、準確率高，其缺點就是泛化能力比較弱。隨着功能不斷迭代，模板很大程度依賴於人工，不能自主提高本身的泛化能力。而後有了基於搜索的對話機器人，有很強的業務適應能力，其缺點就是準確率低。最近幾年深度學習火起來後，利用深度學習替換原來的模型進行意圖識別，意圖識別相對傳統方法準確率提高很大，可是缺點就是對數據質量要求較高。

模板能夠部分自動生成，若是上線也須要應用方本身審覈與補充，話術也須要應用方本身去配置。搜索技術更多的是先用意圖識別作一個路由器的功能，而後路由到一些小的robot，每一個robot作一類事情。深度學習與傳統分類方法作的事情相似，也是在作多意圖的意圖分類，肯定意圖後會經過一對一或其餘配置方式將其關聯回答。

 

下面是一個模板算法，「泉州過戶到廈門會不會很麻煩」，這個模板在前面沒有出現過，就沒法匹配，須要將模板提取出來，固化到知識庫、模板庫中。

對話機器人發展到後面愈來愈注重運營，有一個管理平臺，就是知識庫。固化知識，給運營提供管理入口。前面例子就是維護問題到模板以及模板到回答的映射關係，人工須要作不少審覈以及一些校對的工做。而搜索方案，將query通過預處理打散成terms，進入搜索系統，若是按照原始結果會獲得一個排序「泉州到廈門過戶問題，泉州到廈門遠嗎，泉州到廈門怎麼坐車，泉州到福州過戶問題，泉州到廈門過戶問題」，最後得出結果與查詢一致，將最相近的query回答返回。而解決排序不正確的方法就是須要海量數據。

 

接下來說一下深度學習的算法架構，深度學習應用不少，以對話機器人而言，基礎技術如分詞、詞性、實體識別均可以用深度學習，數據好的話會比傳統方法好。還有搜索架構中的類似度計算、用來排序的一些特徵也能夠用到深度學習的方法。咱們是從整個結構來看就是一個深度學習的架構，這也是學術界研究的熱點。

深度學習知識庫咱們解決就是意圖與答案一對一的關係，回答對話術自己要求很嚴格，幾乎是一個純人工的過程，有不少人蔘與業務運營。若是是單輪就是一個多分類問題，更重要的是如何創建一種機制將問題積累過程與上線後模型的演進過程變得更加自動化、質量更可控。除了剛纔它談到的技術還有其餘方法如生成模式，學術界較火，主要是應用於閒聊。咱們最後選用深度學習模式，考慮的緣由有如下幾個方面，就是再也不須要人去抽取大量的特徵。

語義理解的流程，包括快速識別、模型識別、搜索識別、類似問題，在這個流程中應用了不少技術。咱們採起的是一個漏斗方式，開始是快速識別（須要實時解決），在快速識別弄一個白名單用關鍵詞或模版匹配馬上糾正，原則是必須準確率要高。90%的問題是依據模型框架，準確率也在90%以上，有了前面兩步，後面是在補充召回的過程，經過搜索系統藉助文本類似度的匹配將一部分數據召回，儘可能讓用戶更多的問題被識別。

 

 

接下來介紹下多輪，我理解多輪是一個更偏工程的過程。裏面更多的算法是在作槽位解析，須要作好三件事，第一個就是填槽，若是對話過程當中槽位未補全，在下輪對話過程當中引導用戶補全槽位信息。再者就是場景管理，須要維護海量用戶的聊天信息。第三點就是可配置，多輪最後面都是一個業務問題，開發一個可配置的界面，讓運營自行配置其須要的對話。多輪的邏輯是在知識庫裏配置的，DM是和業務無關的，只須要按配置的解析結果執行便可。

按照上面設計仍是會出現風險，常見的五個風險有：任何算法的選擇都只是知足當前的需求，數據是歷史數據，算法是當前反饋，業務演化過程不可知； 模型互搏，各類模型都要去作A/BTest肯定哪一種好那種壞，以前更多的判斷是從原理上判斷；意圖爆炸，目前知識庫是基於意圖回答一對一關係，業務相對收斂，可是將來發展速度可能致使意圖不可收斂； 主觀標準的反覆，不少過程都由人工參與，每一個人評判標準不一；模型更新滯後於業務發展，技術發展較快。解決方案就是永遠保持主動，提早應對。

系統架構：前端有一個對話框和消息服務器，相似於IM基本架構，消息服務器會將消息路由到對話管理模塊（中控）。用戶聊天文本會在中控識別意圖和槽位，經過意圖在知識庫中獲取對應的話術。知識庫有一個控制檯，與外部交互的界面，對話管理也會訪問後端雲服務，好比經過ip地址獲取其屬於哪一個城市，除此外還有語義理解、CRM服務等。

 

 

線上效果，左邊是一個單輪對話能力，不管問如何貸款都能準確識別，右邊是一個動態API，相似於知識圖譜想要完成的工做。

 

在瓜子遇到的挑戰：首先是數據，無論作什麼都須要數據。運營，這方面主要是對話機器人自學習的能力，如何設置一些機制使運營可以知足當前業務效果，跟上業務發展速度。最後是產品化，如何將產品細節作得足夠好。

舉例：第一個就是數據來源，以必定規則構造數據，或利用非結構化數據經過遷移學習訓練embedding向量，將向量做爲意圖識別的原始輸入，或模型產生數據反哺模型，不斷迭代。第二個就是話術的確認流程，編輯發起修改，業務反饋，編輯確認，審覈，法務，上線，這是一個理想的模式。人與人之間的平衡： 回答的標準，新增意圖的標準，產品和算法的平衡： 意圖預判、suggest、類似問題、下一個問題，業務和技術的平衡：卡片消息，就是在線化，後臺服務如何讓用戶利用起來。

用戶從不一樣的業務入口進來看到的問題列表是不一樣的，從不一樣業務階段進來看到的問題列表也是不同的。後續但願作到不只根據業務狀態還要基於歷史數據作一些推薦。對話機器人能夠作不少事情，如目前咱們正在作的精準營銷，經過多輪對話完善用戶訴求，給出更加精準的推薦。

 

下面更可能是一種理念，打通CRM等內部系統，能夠利用數據作商業智能，覆蓋售前、售中、售後全部場景，用戶溝通可追蹤可優化，精準營銷，從客服轉化爲專家顧問，實現用戶服務在線化和企業在線化，最終實現整個企業的智能化。

做者介紹：

 

王文斌，車好多NLP方向負責人。碩士畢業於北京大學，曾就任於美團、百度等公司，在編譯器、瀏覽器、IM、大數據等複雜系統研發上有實踐經驗，並在搜索推薦、知識問答、數據挖掘、機器學習、NLP等算法方向有豐富的積累。加入車好多後發起了智能IM項目，實現了對話機器人的成功落地。

團隊介紹：

瓜子NLP團隊，以chatbot等產品，增長人效，提升服務質量，讓瓜子逐步加大服務線上化的比例。團隊承載瓜子服務線上化的重任，是將來瓜子發展的重要基礎能力之一。

——END——

內推信息：

在看NLP算法工程師、數據挖掘工程師機會的小夥伴，歡迎加入文斌老師的團隊，內推郵箱：wangwenbin2@guazi.com。

再看看其餘文章？

回顧·知識圖譜在貝殼找房的從0到1實踐

回顧·機器人·人機交互·技術介紹

回顧·神馬搜索技術演進之路

回顧·深度學習的可解釋性與低頻事件學習在金融領域的研究與應用

回顧·五八同城智能客服系統「幫幫」技術揭祕

 

 

 

 

 

 

---

 

 

 

 

 

美團對話理解技術及實踐

分享嘉賓：江會星 博士 美團點評

編輯整理：李巖哲

內容來源：AI 科學前沿大會

出品社區：DataFun

注：歡迎轉載，轉載請註明出處

智能客服是一種使用天然語言與用戶交互的人工智能系統，經過分析用戶意圖，以人性化的方式與用戶溝通，向用戶提供客戶服務。

本議題首先介紹美團智能客服的對話交互框架，而後就咱們在其中意圖挖掘、意圖理解、情緒識別、對話管理等核心模塊中用到的機器學習算法進行詳細的介紹。

美團點評的使命是 " 幫你們吃得更好，生活更好 " 。美團線上服務的 APP 涵蓋了生活服務方方面面，包括餐飲、外賣、打車、酒店業務等。2018年整年美團的總交易金額達5156.4億元人民幣，同比增長44.3%；2018年美團單日外賣交易筆數超過2100萬筆。美團的各個 APP 上具備大量的客服信息類的數據，這也爲工程師提供了很好的練兵場。

1、智能客服對話框架

當用戶進入到客服界面時每每是帶着一個問題來的，那麼咱們須要作的就是對這個問題進行理解，而後根據理解結果去請求相應服務，去解決用戶的問題。這裏面主要分爲兩大塊，一方面是離線訓練和知識庫整理部分，另外一部分是在線處理部分。

在在線部分，首先須要對問題進行基礎特徵的提取，好比：分詞、語義標籤抽取、情緒分析、NER 識別等；進而進入下面一層-意圖理解層，主要有問題領域分類、意圖識別和屬性抽取；意圖理解以後就進入到了對話管理這個階段，對話管理模塊主要包括兩個部分，狀態追蹤 ( DST ) 和對話決策，DST 根據上下文狀態明確當前用戶的領域和意圖，而對話決策模塊則根據用戶當前意圖決定後續動做；再之下是業務服務層，包括各業務的數據服務接口以及業務數據呈現樣式等。

2、意圖理解

美團圍繞着生活服務有着許許多多場景和業務，針對客服服務而言，用戶多是從單一的業務窗口進入到客服中，這時咱們是知道該客服服務屬於哪一個領域；用戶也有多是從美團的綜合門戶入口進入到客服中，在這種狀況下咱們沒法判斷用戶須要進行哪一個業務領域方面的諮詢。

除此以外，在場景方面，主要涉及單輪 QA 和多輪 Task，針對一些簡單的問題，單輪的 QA 就能夠解決，舉個例子：

U: 美團送餐時間

S: 用戶您好，可否配送是以商家營業時間爲準的。如您所選的商家正在營業，便表明能夠提供點餐及配送服務。

而大量複雜的業務經過單輪的 QA 是沒法完成的，這時候就須要多輪對話，舉個例子：

如何成爲美團商家？

像這種就須要多輪的任務 Task 才能解決。

因爲美團涵蓋衆多的業務領域，因此當用戶提出一個問題時，咱們首先要將這個問題進行領域分類，把它分到某個業務領域去，而後用業務知識去解決這個問題；領域明確後就是意圖分類，根據問題的不一樣類別，好比問答類的、閒聊類的等，採用的方式也會有所差別。接下來將對這兩個方面作詳細介紹。

2.1 領域分類

針對領域分類任務，如上圖所示，咱們首先會從不一樣的業務中收集大量的業務數據，做爲基礎的訓練數據，雖然這些數據來自不一樣的業務，可是依然存在一些問題，主要有如下兩方面：

• 標籤不許：用戶有可能會在某個業務對話中提問其它領域的問題；

• 領域重疊：某些問題可能會在多個領域中出現。

因此，原始數據不能直接拿來做爲訓練數據，必需要通過人工篩選和標註方可以使用。 爲了節約人力成本和提升迭代速度，咱們採用了主動學習框架，模型的迭代主要分爲以下幾步：

1. 蒐集業務數據，爲每條業務數據打上相應的業務標籤

2. 對數據進行模型訓練

3. 將上步訓練好的模型對樣本進行預測

4. 標註人員對預測樣本進行標註，選出錯誤和難分開的樣本

5. 返回第2步，對標註好的數據從新進行訓練

咱們同時也在不一樣的模型上測試領域分類效果，實踐中的各模型效果如上圖所示。 從結果中咱們能夠看出，BERT 的效果是很是高的，可是呢咱們也會考慮模型在實際運行中的效率問題。 對於一個15個字左右的 query 來講，用 TextCNN 模型在 10ms 之內就能夠解決，若是用 BERT 模型的話可能須要 70ms 左右，這個時間仍是比較長的，當前實際上線的時候咱們採用的是 TextCNN 模型。 這是2014年 Yoon Kim 提出的一種方法。

2.2 意圖分類

針對意圖分類，主要包括問答型意圖理解和任務型意圖理解兩個方面。

這兩類問題有着各自的特色，針對問答類，咱們採用檢索和類似度排序的策略，下圖是問答類的設計架構。

針對任務型的意圖理解，咱們採用規則和模型結合的方式，一種是經過規則的方式，好比上下文無關文法，另外一種是採用模型訓練的方式。

上下文無關文法

上圖就是其中一個例子，在工業界這種方式仍是很是通用的，對於問題冷啓動，高頻出現的問題和常規的問題，採用規則的方式可以很好的解決。

多任務學習模型

模型部分咱們把意圖分類和屬性抽取聯合建模，做爲一個多任務學習 ( Multi-task Learning ) 任務，如上圖所示 ( 算法詳見 Zhang, Xiaodong 2016IJCAI ) 。雙向 LSTM 處理後，一方面會經過 softmax 分類輸出意圖多分類的結果 ( 右邊的y^u )；另外經過 CRF 層，標記每個詞的槽位標籤。具體來講，對於 " 幫我找一家明天中午適合10人聚餐的川菜館 "，模型應該能識別出來它是屬於訂餐意圖，同時又可以抽取出時間 " 明天中午 " 、人數 " 10 " 和口味菜系 " 川菜 " 等屬性信息。

2.3 對話狀態追蹤 ( DST )

DST 解決的仍是一個意圖的問題，根據當前上下文的環境或者狀態來明確當前用戶的確切意圖。

上圖是咱們當前的框架，這個 session context 爲上下文信息，NLU 模塊的輸出信息多是多個意圖，咱們須要根據其餘的一些信息，好比，訂單信息、門戶信息，入口信息等，結合 session context 去明確它是屬於哪一個領域。

若是這個領域不能明確怎麼辦？咱們的作法是會跟用戶進行一輪的澄清，反問用戶一次，來解決這個問題，也就是框架最左邊的 " domain不明確進行澄清 " 邏輯。

領域一旦明確後，下一步會進入到意圖這一塊，咱們要明確它當前是什麼意圖，固然接收到的 query 也面臨多意圖判斷的問題，一樣咱們也能夠去作澄清，澄清包括利用上下文信息斷定，或者增長一輪與用戶的交互來澄清，若是明確則繼續下面的流程，這是咱們總體的架構。

舉個栗子：

若是接收到一個信息是 " 牛肉湯撒了 "，首選咱們要判斷它是屬於哪一個領域的，它是屬於外賣商家這個領域，接着判斷其意圖，對意圖進行澄清後得知意圖是 " 如何申請餐損 "，而後走餐損的流程。

3、知識發現

3.1 人在迴路

客服的目的是爲了解決用戶的問題，AI 在現有的 work flow 中節省人力，可是機器解決不了的事情仍是要交給人來解決。因此在下圖中，咱們必定要加一條轉人工的服務。另外咱們利用無監督學習從日誌中挖掘出的知識點也須要人工 " 業務運營 " 來 check 。在整個環路里監督學習從知識庫中學習到的語義表示能力又能夠提供給無監督學習使用，這個在下面會進一步提到。

3.2 無監督學習在知識發現中應用

無監督機器學習主要涉及兩個問題，一個是句子的語義表示，另外一個就是如何作知識聚類。

在語義表示問題上，咱們作了大量的試驗，在迭代的過程當中，咱們用到了 DSSM 模型、seq2seq 模型和 BERT 模型來作意圖的類似度計算，在這個過程當中咱們發現不一樣的模型有各自的特色，它可能抓住不一樣維度的特徵，在離線模型中咱們用多個模型的拼接的方式來表示其語義向量。

在知識點聚類這個問題上，咱們採用用了最通用的 K-means 模型來作的。

上面講到的是意圖和說法的挖掘，在實際業務中咱們有大量的 Task 的問題。下圖呈現的是一個 " 如何申請餐損 " 的 Task 樹。

當用戶的問題觸發 Task 後，Task 機器人根據和用戶的交流來獲取槽信息，調用不一樣 API 接口來獲取槽信息，進而回複用戶。上圖 " 如何申請餐損 " Task 須要明確的槽包括 " 配送方式 " 、" 餐損緣由 " 、 " 申請狀態 "，其中 " 配送方式 " 和 " 餐損緣由 " 是經過與用戶的交互來明確，" 申請狀態 " 則是經過請求後臺服務來明確。

在這個環節中咱們須要作的就是輔助運營人員構建 Task 類的知識。

咱們根據用戶的日誌數據提取相應意圖，而後根據意圖共現，回覆共現去挖掘，當一個用戶問了一個問題以後還會提問哪些問題，當用戶收到反饋以後還會反問哪些問題。根據這些去構建 Task 子樹，離線構建好以後交給運營的同窗，運營同窗審覈經過以後就能夠上線了。

4、情緒識別

4.1 背景介紹

客服熱線是咱們公司對外服務的重要交流通道，在售前、售中和售後的各個環節中發揮着重要做用，爲用戶提供意見處理、資料管理、技術支持等多項服務。然而目前客服熱線在運營過程當中還存在一些痛點，如客服人工坐席的服務水平參差致使客戶的體驗存在差別，另外個別客戶還存在動機複雜等問題。所以如何利用技術提高客服熱線的服務水平、檢測熱線中可能的風險是目前須要解決的一個問題。 本項目對客服熱線中的語音數據進行挖掘與分析，經過量化用戶的情緒能量值，實現對用戶情緒狀態 ( 是否激動、情感傾向等 ) 的追蹤，而且在客戶情緒超過設定閾值時提供預警信息，以便相關人員和應急措施的及時介入，從而爲相關業務部門提供運營數據支撐和智力支持，最終提高客服熱線的服務質量和服務效率。

4.2 特徵提取

FTT：短時傅里葉變換

每幀語音都對應於一個頻譜 ( 經過短時 FFT 計算 )，頻譜表示頻率與能量的關係。

梅爾濾波：實驗觀測發現人耳就像一個濾波器組同樣，它只關注某些特定的頻率份量 ( 人的聽覺對頻率是有選擇性的 ) 。也就說，它只讓某些頻率的信號經過，而壓根就直接無視它不想感知的某些頻率信號。

4.3 模型選擇

特徵處理完成以後就是採用哪一種模型來進行訓練。

在迭代中咱們採用過傳統的機器學習模型，好比 LR、SVM 模型，神經網絡模型，和一些預訓練好的模型，在這個裏面咱們遇到的一個挑戰就是，一個情緒是否是激動的標籤是針對整個通話記錄標註的，可是用戶在通話的過程當中，不是一直的激動，而是在某個通話階段情緒激動，而一個標籤沒法體現出究竟是那一部分激動，是全程激動，仍是部分激動，仍是全程平靜的，其實這個裏面就涉及到一個弱標籤的學習，以下圖所示。

這是19年提出的一個算法，在實際應用中效果不錯，感興趣的同窗能夠根據信息去查找。

在實際的效果上，各個模型的表現以下：

MFCC + LSTM < MFCC + CNN < VGGish + ferture level attention < VGGish + decision level attention

5、展望

• 多輪上下文建模，意圖理解

• 讓用戶作選擇題，作意圖預判，意圖推薦

• 語音與文本多模態，弱標記學習，情緒風險識別

• 對話歷史的話題抽取及切割，話術推薦，坐席助理

以上是當前咱們正在開展及探索的智能客服理解部分的內容，從 ToC 的用戶側，以及 ToB 的坐席助理側兩方面來優化整個客服閉環。

做者介紹：

江會星 博士，美團點評搜索與 NLP 部 NLP 中心的研究員，智能客服團隊負責人，主要負責美團智能客服業務及對話平臺的建設。曾在阿里達摩院語音實驗室從事智能語音對話交互方向研究，主要負責主導的產品有斑馬智行語音交互系統、YunOS 語音助理等。

團隊介紹：

美團點評搜索與 NLP 部 NLP 中心秉承 " 讓機器理解人類語言，讓機器與人天然對話，用數據打造知識大腦 " 的信條，致力於建設世界一流的天然語言處理核心技術和服務能力，打造智能客服對話平臺，打造天然語言處理平臺及知識圖譜 ( 美團大腦 )，助力美團業務場景智能化轉型，提高美團科技水平和品牌影響力。

當前咱們在 NLP 多個方向，包括但不限於意圖理解，對話交互，意圖推薦，風險識別，知識圖譜等崗位招聘算法及工程崗位，Base 北京、上海兩地。歡迎加入咱們團隊，簡歷請投遞至郵箱：

jianghuixing@meituan.com

——END——

文章推薦：

通用領域對話問答

智變中的美團客服

阿里小蜜中的情緒回覆能力

關於 DataFun：

DataFun 定位於最實用的數據智能平臺，主要形式爲線下的深度沙龍、線上的內容整理。但願將工業界專家在各自場景下的實踐經驗，經過 DataFun 的平臺傳播和擴散，對即將或已經開始相關嘗試的同窗有啓發和借鑑。

DataFun 的願景是：爲大數據、人工智能從業者和愛好者打造一個分享、交流、學習、成長的平臺，讓數據科學領域的知識和經驗更好的傳播和落地產生價值。

DataFun 成立至今，已經成功在全國範圍內舉辦數十場線下技術沙龍，有超過三百位的業內專家參與分享，彙集了數萬大數據、算法相關領域從業者。

 您的「在看」，個人動力！👇

 

 

 

 

---

 

 

 

「回顧」智變中的美團客服

 

分享嘉賓：劉學梁老師

編輯整理：趙富旺同窗

內容來源：2018AI先行者大會《智變中的美團客服》

出品社區：DataFun

 

當NLP趕上客服系統確實會發生一些美妙的事情，下面我分享的內容將圍繞美團客服系統中一些比較前沿的技術展開，但願能對你們有所啓發。

今天分享的內容主要分爲如下幾個方面，第一部分首先對美團的客服系統進行簡單介紹，第二部分是本次分享的重點，包括咱們採用了什麼樣的技術方案，技術方案的具體的技術組件是怎樣實現的，背後有着怎樣的思考等等，第三部分展現咱們所作的工做在美團客服系統的落地效果，第四部分對本次分享作一個總結。整體上來講，客服不是一個純靠人能夠解決的問題，也不是一個純靠算法能夠解決的問題，而是須要人機協同解決的問題。同時，它也不是一個靜態的系統，它須要不斷地進化不斷地運營。

1. 客服系統簡介

首先咱們回顧一下客服系統的演變歷史。客服系統的原始階段是語音呼叫中心，這種客服系統純靠人工服務，且支持語音電話，效率低成本高。第二階段進化到了網頁在線客服，這種客服系統基於網頁會話，服務形式支持文本和語音，同時還利於對流量數據進行挖掘。隨着移動互聯網的興起，便有了SaaS客服系統，這種客服系統支持多渠道接入，有了豐富的輔助功能和知識庫管理。現在客服系統進化到了智能客服，它最大的特色就是人機協同，許多簡單問題均可以由機器自主解決，這個系統能夠自主學習不斷進化。回顧客服系統的演變歷史能夠發現，智能化是客服系統的一個演變趨勢。

而後我介紹一下對話系統。對話系統主要包括四類：問答型對話、任務型對話、閒聊型對話、圖譜型對話。在問答型對話中，咱們使用QABot機器人完成簡單任務，這種對話一般是與上下文無關的單輪對話。在任務型對話中，TaskBot機器人完成特定場景下的複雜任務。另外還有ChatBot閒聊型機器人，這種對話一般不以解決實際問題爲目的，咱們的客服系統也有用到這種機器人。最後是圖譜型機器人KBQA，這種機器人可能更多地用在金融、醫療等領域，但還未有成熟的系統，這方面咱們也還處於探索中。

根據智能客服機器人的智能水平，能夠將其分爲四個檔次：簡單檢索機器人、語義識別機器人、場景導向機器人、智慧機器人。簡單檢索機器人只支持特定類型的檢索，只要說法稍微一變可能就不能正確識別，匹配性較差。語義識別機器人基於知識庫，能夠更智能地理解所檢索的問題。場景導向機器人根據不一樣場景量身定製機器人，機器人的聰明程度與場景有關。智慧機器人是智能程度最高的機器人，甚至能夠達到擬人的程度。如今來看，大多數機器人還只是停留在第二個階段，能達到第三個階段的仍是少數。

美團的業務種類繁多，不一樣的業務所須要的客服系統也不盡相同，這無疑給咱們提出了嚴峻的技術挑戰。上圖是客服系統的總體框架圖，藍色部分表明了前面提到的nlp技術對原來客服系統的改進。在用戶端咱們設置了QABot、TaskBot、ChatBot等機器人，在座席端運用了話術提示、轉接提示、情感分析等技術。

下面進入本次分享的第二部分：智變之路，主要聚焦於咱們在這個過程當中作了哪些工做以及咱們背後的思考。

原來的客服系統系統中客戶將請求傳送到客服服務器，而後客服操做平臺就會分配相應的人工客服處理相應的客戶請求，客服操做平臺只具有簡單的知識管理功能。這種客服系統最大的問題就是效率低，須要的人力成本高。對於這樣的客服系統來講，實際上須要的人工客服數目和訂單數目是成正比的。美團如今的業務正處於飛速的發展過程當中，如今就有近萬名客服人員，若是不對客服系統進行改進，能夠想象將來這個隊伍還會擴充不少倍。基於原來客服系統的這些缺點，咱們對這個架構進行了改進，增添了會話管理服務，後面鏈接着QABot、TakBot、ChatBot等機器人以及人工服務，有一個專門的知識管理平臺來支撐QABot、TakBot、ChatBot，AI訓練師對知識管理平臺設計離線學習和自動訓練的算法。除此以外咱們還設計了話術提醒、輿情監控、轉接提示等模塊來輔助人工客服。

咱們也研究過作字典的必要性。以上圖片來源於對外賣的日誌數據分析，能夠看出只是「外賣配送超單」這一個問題對應的問法就有16000多種，原客服系統的簡單檢索很明顯不能知足這種需求，讓檢索系統具備必定的語義識別能力十分必要。

要作好一個AI系統必須知足這樣的條件：要有大量業務專家、要有強大算法團隊、要有大規模GPU計算引擎、要有海量場景數據，這些條件在美團都是知足的，這無疑給了咱們使智能客服系統落地的信心。

這是咱們智變的思路，咱們採用三級漏斗的方式，把問題分爲了三類，第一類簡單諮詢問題由QABot解決，第二類高頻相關的複雜場景下的問題由TaskBot解決，最後TaskBot解決不了的任務再借助人工客服來解決。咱們算法的目標就是隨着時間的演進，不斷地把更多的任務轉向機器解決。

這是咱們的系統架構，當一個請求來臨時，先進入咱們的意圖識別領域，而後被識別到對應的業務領域中，把對應的知識點識別出來。若是識別出來的是一個比較簡單的問題，直接檢索就能夠獲得答案，若是它是和用戶訂單狀態或者行爲有關係的複雜問題，須要根據場景生成不一樣的答案。好比對於催單問題，訂單狀態不同所須要的迴應也不同，若是用戶剛下訂單就要催單，此時告訴用戶騎手的位置比較合適，但用戶是在等了一個小時的狀況下催單，此時須要先安撫客戶的情緒。而對於多輪的任務，如客戶支付寶支付沒法使用，這種任務須要調用好多層才能完成，此時就會調用TaskBot。

接下來介紹一下單輪會話的QABot。它主要由兩部分構成，其中一部分是線上的語義識別，另外一部分是線下的客服運營，運營的目的是發現更多的標準問題以及更多的關聯問題。另外後面還有一個交互層，交互層有可能觸發Task或者直接生成答案。

語義識別主要指把不一樣的問法規整到標準的問法上去，感覺一下上面的例子，不一樣的細節表述其實都是在說餐品有質量問題，而語義識別的目的就是要找到檢索問題的標準表述。爲了解決這個問題，咱們綜合運用了搜索技術、翻譯技術、圖譜技術、深度學習和統計學習技術。

語義識別的流程模擬了人解決問題的思路。人類在解決一個問題的時候會首先考慮之前有沒有相似的問題，對應於語義識別中咱們也首先採用搜索檢索的方法。在找尋類似問題的過程當中，人類一般會考慮：「咱們要找的究竟是哪些問題呢？」，對應於語義識別中，這是一個對問題進行候選篩選的過程。當人類發現一些問題明顯和意圖無關，一般要把他們去掉，對應於語義識別中，這就是要進行意圖識別從而篩選問題。面臨最後挑選出的幾個問題，人類一般要對其進行優先級排序，對應於語義識別中，這就是Rank的過程。最後人類可能還會對結果進行檢查：「問的確實是這個問題嘛？」，這就是語義識別中的語義完整性檢查。這整個過程當中運用了各類各樣的模型來達成語義識別的目的。

先介紹一下基於匹配的識別。基於匹配的識別利用拓展問與標準問的並行數據做爲訓練語料，把拓展問Ngram特徵串做爲關鍵詞創建倒排，Ngram特徵分佈做爲權重，在外賣的例子中只用Top20就能達到99.76%的權重。這一步的篩選爲後面模型節省了不少時間。

下面介紹一種深度模型—DSSM模型。DSSM模型是一個雙塔模型，它在句子embedding上效果很好，所以咱們也借鑑了這一模型。咱們把標準問與拓展問語義相同的句子對做爲正例，把標準問與拓展問語義不一樣的句子對做爲反例，訓練了DSSM模型。模型訓練後，對於任給的一個問題，能夠獲得它的embedding結果，和其餘標準問embedding結果相對比就能夠算出類似度。好比拓展問「個人外賣怎麼還沒到」能夠計算出一個Sentence Vector，而標準問「配送超時催單」和「餐品有質量問題」分別有一個Sentence Vector，經過計算可得，「個人外賣怎麼還沒到」和「配送超時催單」的類似度爲0.98，個人外賣怎麼還沒到」和「餐品有質量問題」的類似度是0.62，因此能夠把「個人外賣怎麼還沒到」的語義識別爲「配送超時催單」。

還有一個效果很好的深度模型—Seq2seq模型。Seq2seq模型自己是一個生成模型，可是咱們把它用來計算句子之間的類似度，咱們把它encoder和attention的結果和不一樣的候選作loss計算，把loss做爲一種度量結果，Loss越小表明輸入和候選越接近。以上兩個深度模型是咱們嘗試過的深度模型中效果最好的兩個。

咱們還採用了一種基於圖譜的識別方法。由於美團積累了不少圖譜信息，美團大腦項目裏面有億級的實體數量，相互之間的關係超過5億，實體與實體之間的關係能夠作一個embedding，這樣實體就能夠變成一個向量表示，而這種向量能夠做爲一種特徵和其餘顯示特徵聯合在一塊兒提供給聚類分類算法，這樣會使算法效果有很大的提高。

還有一種對知識圖譜的用法，咱們從圖譜中抽取一些近義詞上下位等關係做爲並行語料放入一些模型中去，這樣對原有語料進行了很好的擴充。

還有一種模型：基於實例的翻譯。Nagao1984年時提出過這樣一個理論：人類在翻譯簡單句子時不會進行深層次的語義分析。這是一種很簡單的思想：從已知的實體中找到和問題最接近的，把它的答案做爲問題的答案。

這是一個簡單的例子。咱們的語言庫裏面已經有「怎麼都沒人接單啊」、「怎麼還沒人接單呀」、「怎麼今天沒人接單」等句子，庫裏面這些問題的答案都是「無騎手接單」，此時來了一個新的問題「怎麼會沒人接單呢」，經過類似性能夠推斷出它的答案也應該是「無騎手接單」。

下面介紹一個進行意圖識別的模型。咱們根據業務邏輯進行建模，對於外賣來講，能夠把問題分爲幾個大類，好比配送類、紅包類、支付類、帳戶類等等，不一樣大類之間的問題關係能夠依據業務邏輯分別被定義爲互斥或者相容，根據這些關係能夠對候選問題進行語義層面的篩選。根據篩選結果對候選問題進行過濾。

上面介紹的都是QABot用到的模型，下面介紹一下TaskBot的總體框架。TaskBot在咱們這裏被定義爲一個執行引擎，在架構上它是這樣的，請求來臨後，先進行意圖識別，出發對應的Task，Task把對應的決策樹load到內存裏邊，而後它會對決策樹的節點狀態進行記錄，以後調用情感識別、語義識別、實體識別等服務進行分析決定節點之間的狀態流轉。

接下來介紹閒聊機器人。ChatBot不以解決實際問題爲目的，主要用來和用戶進行情感交流。咱們採用兩種方式來作ChatBot，第一種是檢索式，構建一個閒聊庫，檢索給出答案，第二種是生成式模型，從閒聊庫中學習生成模型。生成式比較具備挑戰性，由於客服系統是一個比較嚴肅公開的平臺，必須保證會話的可控性。

這是咱們QABot的落地狀況，數據來自於外賣場景，天天解決72,000個問題，算法離線準確率達到92%，在線智能解決率83%。

這是TaskBot的落地效果，業務場景是打車領域，針對打車司機平臺派單少這一問題，TaskBot的上線方便了司機自助地解決問題，大大提高了這一問題的智能解決率和智能解決量。

最後，對本次分享作一下總結。智能化是客服系統發展的趨勢，是解決有限的客服資源與不斷增加的海量用戶服務請求矛盾的惟一選擇。實踐證實，智能化客服確實能夠大量消除人的重複勞動，業務專家也能夠從繁雜中解脫出來，能夠有更多的時間進行方案優化。最重要的一點，智能化客服系統不是一個純人的系統，也不是一個純算法的系統，也不是一個靜態的系統，它須要人機協同，自主學習不斷進化。還有一點，客服系統如今還主要用於售後方面，咱們如今也在售前的相關研究，後面咱們也會把它用於智能營銷、導購等流程中，這方面咱們也在探索。

 

做者介紹：

 

劉學梁，美團AI平臺部NLP中心客服算法團隊負責人，研發的智能客服系統已上線服務於外賣、打車等領域。曾就任於微信，從事機器翻譯、語音識別相關基礎算法研究工做。

 

團隊介紹：

 

美團點評AI Lab-NLP中心是負責美團點評人工智能技術研發的核心團隊，使命是打造世界一流的天然語言處理核心技術和服務能力，依託NLP（天然語言處理）、Deep Learning（深度學習）、Knowledge Graph（知識圖譜）等技術，處理美團點評海量文本數據，打通餐飲、旅行、休閒娛樂等各個場景數據，構建美團點評知識圖譜，搭建通用NLP Service，爲美團點評各項業務提供智能的文本語義理解服務。 咱們的團隊既注重AI技術的落地，也開展中長期的NLP及知識圖譜基礎研究。目前項目及業務包括美團點評知識圖譜、智能客服、語音語義搜索、文章評論語義理解、美團點評智能助理等。

 

---

注：關注文章底部公衆號，回覆【先行者】，可下載學梁老師分享PPT。

---

 

——END——

 

內推信息：

職級：p2-1到p3-2，以下方向：NLP（在知識圖譜、智能客服、搜索引擎、推薦系統等領域有實際經驗）、智能助手和客服機器人、知識圖譜等算法開發崗，Base北京、上海。歡迎加入學梁老師的團隊，簡歷請投遞至學梁老師的郵箱：

liuxueliang03@meituan.com

 

---

DataFun算法羣1.1招募中，感興趣的小夥伴歡迎加管理員微信：

---

更多幹貨文章:

DataFun定位於最「實用」的數據科學社區，主要形式爲線下的深度沙龍、線上的內容整理。但願將工業界專家在各自場景下的實踐經驗，經過DataFun的平臺傳播和擴散，對即將或已經開始相關嘗試的同窗有啓發和借鑑。DataFun的願景是：爲大數據、人工智能從業者和愛好者打造一個分享、交流、學習、成長的平臺，讓數據科學領域的知識和經驗更好的傳播和落地產生價值。

DataFun社區成立至今，已經成功在全國範圍內舉辦數十場線下技術沙龍，有超過一百位的業內專家參與分享，彙集了萬餘大數據、算法相關領域從業者。