客服是在使用者服務體驗不完美的情況下，儘可能幫助體驗順暢進行下去的一種解決辦法，是問題發生後的一種兜底方案。而智慧客服能讓大部分簡單的問題得以快速自助解決，讓複雜問題有機會被人工高效解決。在使用者服務的全旅程中，美團平臺/搜尋與NLP部提供了問題推薦、問題理解、對話管理、答案供給、話術推薦和會話摘要等六大智慧客服核心能力，以期達到低成本、高效率、高質量地與使用者進行溝通的目的。本文主要介紹了美團智慧客服核心技術以及在美團的實踐。
1 背景
目前，美團的年交易使用者量為6.3億，服務了770萬生活服務類商家。此外，在美團優選業務中還有一個很大的團長群體。美團平臺涵蓋吃、住、行、遊、購、娛等200多個生活服務品類，在平臺服務的售前、售中、售後各個環節，都有大量資訊諮詢、訂單狀態獲取以及申訴投訴等溝通訴求。另外，作為一家擁有幾萬名員工的上市企業，員工之間亦有大量的溝通訴求。面對以上這些需求，如果都是通過人力進行實現，顯然不符合公司長遠發展的目標，這就需要引入智慧客服。
1.1 面對不同場景的智慧客服落地
首先，我們看看日常生活中幾種最為常見的客服場景。
- 售前場景：比如消費者在平臺選擇入住酒店，對房型價格、酒店設施、入退房政策等，下單前都有很強的資訊諮詢訴求。
- 售中場景：比如外賣催單還沒到，新增備註不要辣、加開發票等諮詢等等，售前和售中場景主要發生在消費者和商家或平臺之間。
- 售後場景：比如外賣場景投訴菜品少送、騎手送餐超時、要求退款等，酒店場景投訴酒店到店無法入住等，售後往往涉及到客服座席、消費者、騎手和商家，需要多方協同解決。
- 辦公場景：比如IT、人力資源、財務、法務等諮詢，產運研對提供的介面產品的諮詢答疑，產品對銷售顧問的答疑，以及銷售顧問對商家的答疑等等。
1.2 面對不同人群的智慧客服落地
溝通是人類的一項基本需求，在絕大多數場景下，我們對溝通的追求都是以低成本、高效率和高質量為目標，而對話機器人也需要同時滿足這三點要求。目前我們按照服務的群體進行劃分，智慧客服落地場景大體可以分為以下四類：
- 面向使用者：提供智慧客服機器人，來幫助他們自助解決大部分的問題。
- 面向座席：用話術推薦或者會話摘要等能力來提升人工座席的工作效率，改善人工座席的工作體驗。
- 面向商家：打造商家助手來降低商家回覆的費力度，改善消費者和商家的溝通體驗。
- 面向員工：通過對話機器人，可以自助給員工進行答疑，從而提升辦公效率。
1.3 智慧客服是什麼
要回答智慧客服是什麼，可以先看看客服是什麼。我們的理解是，客服是在使用者服務體驗不完美的時候，來幫助體驗順暢進行下去的一種解決辦法，是問題發生後的一種兜底方案。而智慧客服能讓大部分簡單的問題得以快速自助解決，讓複雜問題有機會被人工高效解決。
上圖展示的是使用者服務旅程。首先，使用者會通過線上打字或者撥打熱線電話的方式進線尋求服務，其中線上諮詢流量佔比在85%以上。當使用者進入到服務門戶後，先是使用者表達需求，然後是智慧機器人響應需求，過程中機器人先要理解問題，比如是追加備註或是修改地址，還是申請退款等等，繼而機器人嘗試自助解決。如果解決不了，再及時地流轉到人工進行兜底服務。最後，當使用者離開服務時，系統會傳送調查問卷，期待使用者對本次服務進行評價。
2 智慧客服核心技術
2.1 對話互動技術概述
智慧客服背後的技術主要是以對話互動技術為核心。常見的對話任務可分為閒聊型、任務型和問答型：
- 閒聊型：通常是不關注某項特定任務，它的主要的目標是和人進行開放領域的對話，關注點是生成流暢、合理且自然的回覆。
- 任務型：通常是幫助使用者完成某項任務指令，如查詢酒店、查詢訂單狀態、解決使用者的退款申請等等。使用者的需求通常比較複雜，需要通過多輪互動來不斷收集任務所需的必要資訊，進而根據資訊進行決策，執行不同的動作，最終完成使用者的指令。
- 問答型：側重於一問一答，即直接根據使用者的問題給出精準答案。問答型和任務型最本質的區別在於，系統是否需要維護一個使用者目標狀態的表示和是否需要一個決策過程來完成任務。
在技術實現上，通常又可以劃分為檢索式、生成式和任務式：
- 檢索式：主要思路是從對話語料庫中找出與輸入語句最匹配的回覆，這些回覆通常是預先儲存的資料。
- 生成式：主要思路是基於深度學習的Encoder-Decoder架構，從大量語料中習得語言能力，根據問題內容及相關實時狀態資訊直接生成回答話術。
- 任務式：就是任務型對話，通常要維護一個對話狀態，根據不同的對話狀態決策下一步動作，是查詢資料庫還是回覆使用者等等。
閒聊、問答、任務型對話本質都是在被動地響應使用者需求。在具體業務中還會有問題推薦、商品推薦等來主動引導使用者互動。在美團的業務場景裡主要是任務型和問答型，中間也會穿插一些閒聊，閒聊主要是打招呼或者簡單情緒安撫，起到潤滑人機對話的作用。
如前面使用者服務流程所介紹的那樣，使用者的溝通物件可能有兩個，除了跟機器人溝通外，還可能跟人工溝通。如果是找客服場景人工就是客服座席，如果是找商家場景人工就是商家。機器人的能力主要包括問題推薦、問題理解、對話管理以及答案供給。
目前，衡量機器人能力好壞的核心輸出指標是不滿意度和轉人工率，分別衡量問題解決的好壞，以及能幫人工處理多少問題。而在人工輔助方面，我們提供了話術推薦和會話摘要等能力，核心指標是ATT和ACW的降低，ATT是人工和使用者的平均溝通時長，ACW是人工溝通後的其它處理時長。
2.2 智慧機器人——多輪對話
這是一個真實的多輪對話的例子。當使用者進入到服務門戶後，先選擇了一個推薦的問題“如何聯絡騎手”，機器人給出了聯絡方式致電騎手。同時為了進一步釐清場景，詢問使用者是否收到了餐品，當使用者選擇“還沒有收到”的時候，結合預計送達時間和當前時間，發現還未超時，給出的方案是“好的，幫使用者催一下”，或者是“我再等等吧”，這時候使用者選擇了“我再等等吧”。
這個例子背後的機器人是怎麼工作的呢？首先當使用者輸入“如何聯絡騎手”的時候，問題理解模組將它與知識庫中的擴充問進行匹配，進而得到對應的標準問即意圖“如何聯絡騎手”。然後對話管理模組根據意圖“如何聯絡騎手”觸發相應的任務流程，先查詢訂單介面，獲取騎手電話號碼，進而輸出對話狀態給到答案生成模組，根據模板生成最終結果，如右邊的紅框內容所示。在這個過程中涉及到要先有意圖體系、定義好Task流程，以及訂單的查詢介面，這些都是業務強相關的，主要由各業務的運營團隊來維護。那麼，對話系統要做的是什麼呢？一是將使用者的輸入與意圖體系中的標準問進行匹配，二是完成多輪互動裡面的排程。
問題理解是將使用者問題與意圖體系進行匹配，匹配到的擴充問所對應的標準問即使用者意圖。機器人的工作過程實際是要做召回和精排兩件事情。召回更多地是用現有檢索引擎實現，技術上更多地關注精排。
美團自研的智慧客服系統是從2018年開始搭建的，在建設的過程中，我們不斷地將業界最先進的技術引入到我們的系統中來，同時根據美團業務的特點，以及問題理解這個任務的特點，對這些技術進行適配。
比如說，當2018年底BERT（參見《美團BERT的探索和實踐》一文）出現的時候，我們很快全量使用BERT替換原來的DSSM模型。後面，又根據美團客服對話的特點，我們將BERT進行了二次訓練及線上學習改造，同時為了避免業務之間的干擾，以及通過增加知識區分性降低噪音的干擾，我們還做了多工學習（各業務在上層為獨立任務）以及多域學習（Query與擴充問匹配，改為與擴充問、標準問和答案的整體匹配），最終我們的模型為Online Learning based Multi-task Multi-Field RoBERTa。經過這樣一系列技術迭代，我們的識別準確率也從最初不到80%到現在接近90%的水平。
理解了使用者意圖後，有些問題是可以直接給出答案解決的，而有些問題則需要進一步釐清。比如說“如何申請餐損”這個例子，不是直接告訴申請的方法，而是先釐清是哪一個訂單，是否影響食用，進而釐清一些使用者的訴求是部分退款還是想安排補送，從而給出不同的解決方案。這樣的一個流程是跟業務強相關的，需要由業務的運營團隊來進行定義。如右邊任務流程樹所示，我們首先提供了視覺化的TaskFlow編輯工具，並且把外呼、地圖以及API等都元件化，然後業務運營人員可以通過拖拽的方式來完成Task流程設計。
對話引擎在與使用者的真實互動中，要完成Task內各步驟的匹配排程。比如這個例子裡使用者如果不是點選”可以但影響就餐了…”這條，而是自己輸入說“還行，我要部分退款”，怎麼辦？這個意圖也沒有提前定義，這就需要對話引擎支援Task內各步驟的模糊匹配。我們基於Bayes Network搭建的TaskFlow Engine恰好能支援規則和概率的結合，這裡的模糊匹配演算法複用了問題理解模型的語義匹配能力。
這是另外一個例子，在使用者問完“會員能否退訂”後，機器人回覆的是“無法退回”，雖然回答了這個問題，但這個時候使用者很容易不滿意，轉而去尋找人工服務。如果這個時候我們除了給出答案外，還去釐清問題背後的真實原因，引導詢問使用者是“外賣紅包無法使用”或者是“因換綁手機導致的問題”，基於順承關係建模，使用者大概率是這些情況，使用者很有可能會選擇，從而會話可以進一步進行，並給出更加精細的解決方案，也減少了使用者直接轉人工服務的行為。
這個引導任務稱為多輪話題引導，具體做法是對會話日誌中的事件共現關係以及順承關係進行建模。如右邊圖所示，這裡原本是要建模句子級之間的引導，考慮到句子稀疏性，我們是將其抽象到事件之間的引導，共現關係我們用的是經典的協同過濾方式建模。另外，考慮到事件之間的方向性，我們對事件之間的順承關係進行建模，公式如下：
並通過多目標學習，同時考慮點選指標和任務指標，如在非轉人工客服資料和非不滿意資料上分別建模順承關係，公式如下：
最終，我們在點選率、不滿意度、轉人工率層面，都取得了非常正向的收益。
美團平臺涵蓋吃、住、行、遊、購、娛等200多個生活服務品類，當使用者是從美團App或點評App等綜合服務門戶入口進入服務時，需要先行確定使用者要諮詢的是哪個業務，這裡的一個任務是“判斷使用者Query是屬於哪個業務”，該任務我們叫做領域識別。若能明確判斷領域時，則直接用該領域知識來解答；當不能明確判斷時，則還需要多輪對話互動與使用者進行澄清。比如使用者輸入“我要退款”，在多個業務裡都存在退款意圖，這個時候就需要我們先判斷是哪個業務的退款意圖，如果判斷置信度不高，則給出業務列表讓使用者自行選擇來進行澄清。
領域識別模型主要是對三類資料建模：各領域知識庫的有標資料、各領域大量弱監督無標資料和個性化資料。
- 依據從各領域知識庫的有標資料中學習得到的問題理解模型訊號，可以判斷使用者輸入屬於各業務各意圖的可能性。
- 我們注意到除了美團App、點評App等綜合服務入口涉及多個業務外，還有大量能夠明確業務的入口，比如說訂單入口，從商品詳情頁進來的入口，這些入口進來的對話資料是有明確業務標籤資訊的。因此，我們可以得到大量的弱監督的各業務領域的資料，基於這些資料我們可以訓練一個一級分類模型。
- 同時，有些問題是需要結合使用者訂單狀態等個性化資料才能進一步明確的。比如“我要退款”，多個業務裡都會有。因此，又要結合使用者狀態特徵一起來訓練一個二級模型，最終來判斷使用者的輸入屬於哪個業務。
最終，該二級領域識別模型在滿意度、轉人工率以及成功轉接率指標上都取得了非常不錯的收益。
2.3 智慧機器人——問題推薦
在介紹完多輪對話基礎模組問題理解和對話管理後，接下來我們介紹一下智慧機器人的另外兩個模組：問題推薦和答案供給。如前面多輪對話的例子所示，當使用者進入服務門戶後，機器人首先是要如何引導使用者精準地表達需求，這樣即可降低使用者迷失或者直接轉人工服務，也降低了若機器人不能正確理解時帶來的多輪澄清等無效互動。
該問題是一個標準的曝光點選問題，它的本質是推薦問題。我們採用了CTR預估任務經典的FM模型來作為基礎模型，同時結合業務目標，期望使用者點選的問題的解決方案能夠解決使用者問題，該問題最終定義為“曝光、點選、解決”問題，最終的模型是結合多目標學習的ESSM-FM，對有效互動的轉化率、轉人工率和不滿意度等指標上都帶來了提升。
2.4 智慧機器人——答案供給
售後客服場景通常問題較集中，且問題的解決多依賴業務內部系統資料及規則，通常是業務部門維護知識庫，包括意圖體系、Task流程和答案等。但在售前場景，知識多來自於商戶或商品本身、使用者體驗及評價資訊等，具有使用者問題開放、知識密度高、人工難以整理答案等特點。比如去哪個城市哪個景點遊玩，附近有哪些酒店，酒店是否有浴缸，酒店地址在哪裡等，都需要諮詢”決策”，針對這些訴求，我們通過智慧問答來解決諮詢以及答案供給問題。
智慧問答就是從美團資料中習得答案供給，來快速回答使用者的問題，基於不同的資料來源，我們建設了不同的問答技術。
- 針對商家基礎資訊，比如問營業時間、地址、價格等，我們通過圖譜問答（KBQA）來解決。利用商家基礎資訊構建圖譜，通過問題理解模型來理解問題，進而查詢圖譜獲取準確的答案。
- 針對社群資料，即商戶詳情頁中“問大家”模組的使用者問使用者答的社群資料，構建社群問答（Community QA）能力，通過對使用者問題與問大家中的”問答對”的相似度建模，選擇相似度最高的作為答案，來回答使用者的一些開放性問題。
- 針對UGC評論資料以及商戶政策等無結構化資料，構建文件問答（Document QA）能力，針對使用者問題利用機器閱讀理解技術從文件中抽取答案，類似我們小時候語文考試中的閱讀理解題，進一步回答使用者的一些開放性問題。
最後，針對多個問答模組給出的答案，進行多答案來源的答案融合排序，來挑選最終的答案，此外這裡還考察了答案真實性，即對“相信多數認為正確的則正確”建模。這部分的詳細介紹大家可以參考《美團智慧問答技術探索與實踐》一文。
3 人工輔助核心技術
3.1 人工輔助——話術推薦
前文介紹的都是智慧機器人技術，使用者除了跟機器人溝通外，還可能是跟人工溝通。我們在客服座席職場調研過程中發現，座席在與使用者的對話聊天中經常回復相似甚至相同的話術，他們一致期望提供話術推薦的能力來提高效率。此外，除了請求客服座席幫助外，很多情況下使用者與商家直接溝通會使得解決問題更高效，而溝通效率不僅影響到消費者的體驗，也影響到了商家的經營。比如在外賣業務中，消費者的下單率和商家的回覆時長有較為明顯的反比關係，無論是客服座席還是商家，都有很強的話術推薦訴求。
那麼，話術推薦具體要怎麼做呢？常見的做法是先準備好常用通用話術庫，部分座席或商家也會準備個人常見話術庫，然後系統根據使用者的Query及上下文來檢索最合適的話術來推薦。我們根據調查發現，這部分知識庫維護得很不好，既有業務知識變更頻繁導致已維護的知識很快不可用因素，也有座席或商家本身意願不強的因素等。另外，針對新客服座席或者新商家，可用的經驗更少。因此我們採用了自動記憶每個座席及其同技能組的歷史聊天話術，商家及其同品類商家的歷史聊天話術，根據當前輸入及上下文，預測接下來可能的回覆話術，無需人工進行整理，大大提升了效率。
我們將歷史聊天記錄構建成“N+1”QA問答對的形式建模，前N句看作問題Q，後1句作為回覆話術A，整個框架就可以轉化成檢索式的問答模型。在召回階段，除了文字資訊召回外，我們還加入了上文多輪槽位標籤，Topic標籤等召回優化，排序為基於BERT的模型，加入角色資訊建模，角色為使用者、商家或者座席。
整個架構如上圖所示，分為離線和線上兩部分。另外上線後我們也加入了一層CTR預估模型來提升採納率。當前多個業務的話術推薦平均採納率在24%左右，覆蓋率在85%左右。話術推薦特別是對新座席員工價值更大，新員工通常難以組織話術，通過採納推薦的話術可以來縮減熟練週期，觀測發現，3個月內座席員工的平均採納率是3個月以上座席員工的3倍。
3.2 人工輔助——會話摘要
在客服場景座席跟使用者溝通完後，還需要對一些必要資訊進行工單紀要，包括是什麼事件，事件發生的背景是什麼，使用者的訴求是什麼，最後的處理結果是什麼等等。而填寫這些內容對座席來說其實是很不友好，通常需進行總結歸納，特別是有些溝通進行的時間還比較長，需要來回翻看對話歷史才能正確總結。另外，為了持續對於服務產品進行改善，也需要對會話日誌進行相應事件抽取及打上標籤，從而方便經營分析。
這裡有些問題是選擇題，有些問題是填空題，比如這通會話具體聊的是哪個事件，我們提前整理有比較完整的事件體系，可以看成是個選擇題，可以用分類或者語義相似度計算模型來解決。又比如說事件發生的背景，如外賣退款的背景是因餐撒了、酒店退款的背景是到店沒有房間等，是個開放性問題，分析發現可以很好地從對話內容中抽取，可以用摘要抽取模型來解決。而對於處理結果，不僅僅依賴對話內容，還包括是否外呼，外呼了是否商家接通了，後續是否需要回訪等等，我們實驗發現生成模型更有效。具體使用的模型如上圖所示，這裡事件選擇考慮到經常有新事件的新增，我們轉成了雙塔的相似度計算任務，背景抽取採用的是BERT-Sum模型，處理結果採用的是谷歌的PEGASUS模型。
04 小結與下一步計劃
4.1 小結——互動立方
前面介紹了美團智慧客服實踐中的一些核心技術，過程中也穿插著介紹了客服座席與消費者/商家/騎手/團長等之間的溝通提效，以及消費者與商家之間的溝通提效。除了這兩部分之外，在企業辦公場景，其實還有員工之間、銷售顧問與商家之間的大量溝通。如果一個個去做，成本高且效率低，解決方案是把智慧客服中沉澱的能力進行平臺化，最好“一攬子”進行解決，以固定成本來支援更多的業務需求。於是我們搭建了美團的對話平臺-摩西對話平臺，用“一攬子”方案以固定成本來解決各業務的智慧客服需求。
4.2 小結——對話平臺“摩西”
構建一個怎麼樣的對話平臺，才能提供期望的沒有NLP能力的團隊也能擁有很好的對話機器人呢？首先是把對話能力工具化和流程化。如上圖所示，系統可分為四層：應用場景層、解決方案層、對話能力層、平臺功能層。
- 應用場景層：在售前應用場景，一類需求是商家助手，如圖中所列的美團閃購IM助手和到綜IM助手，需要輔助商家輸入和機器人部分接管高頻問題能力；還有一類需求是在沒有商家IM的場景需要智慧問答來填補諮詢空缺，比如圖中所列的酒店問一問和景點問答搜尋；另外售中、售後以及企業辦公場景，各自需求也不盡相同。
- 解決方案層：這就要求我們有幾套解決方案，大概可以分為智慧機器人、智慧問答、商家輔助、座席輔助等。每個解決方案的對話能力要求也有所不同，這些解決方案是需要很方便地對基礎對話能力進行組裝，對使用方是透明的，可以拿來即用。
- 對話能力層：前面也進行了相應的介紹，六大核心能力包括問題推薦、問題理解、對話管理、答案供給、話術推薦和會話摘要。
- 平臺功能層：此外，我們需要提供配套的運營能力，提供給業務方的運營人員來日常維護知識庫、資料分析等等。
其次，提供“一攬子”的解決方案，還需要針對處在不同階段的業務提供不同階段的解決方案。
- 有些業務只希望維護好常用的問答，能回答高頻的問題就好，那麼他們只需要維護一個入門級的機器人，只需要在意圖管理模組來維護它的意圖，意圖的常見說法以及答案就可以了。
- 而對於有運營資源的團隊，他們希望不斷地去豐富知識庫來提升問答能力，這個時候可以使用知識發現模組，可以自動地從每天的日誌裡面發現新意圖及意圖的新說法，運營人員只需要每天花一點時間來確認新增及維護答案即可，這是一個進階的業務方。
- 還有一些高階的業務方希望呼叫他們業務中的API來完成複雜問題的求解。這個時候他們可以使用TaskFlow編輯引擎，在平臺上直接註冊業務的API，通過視覺化拖拽的方式來完成Task編輯。
此外， 為了進一步方便更多的業務介入，我們也提供了一些閒聊、通用指令、地區查詢等官方技能包，業務方可以直接勾選使用。另外，隨著我們不斷在業務中沉澱，也會有越來越多的官方行業技能包。整體方向上是逐步讓業務方使用的門檻變得越來越低。
4.3 下一步計劃
前文所介紹的對話系統是一種Pipeline式對話系統，按照功能劃分為不同的模組，各個模組單獨建模，依次串聯。這種方式的好處是可以做到不同團隊職責的有效分工，比如研發同學專注於建設好問題推薦模型、問題理解模型和Task引擎等；業務運營同學專注於意圖體系維護、Task流程設計以及答案設計等等。它的劣勢也很明顯，模組耦合，誤差累積，很難聯合優化，進而各模組負責的同學可能會去修修補補，容易導致動作變形。
另一類建模方式是End-to-End，將Pipeline式對話系統的各個模組聯合建模成一個模型，直接實現語言到語言的轉變，此類方法最初應用在閒聊式對話系統裡面，近期隨著大規模預訓練模型的快速發展，學術上也逐漸開始研究基於預訓練模型的端到端任務型對話系統。它的優點是模型可以充分利用無監督人人會話，用資料驅動可以快速迭代；缺點是模型的可控性差，不易解釋且缺乏干預能力。目前主要以學術研究為主，未見成熟的應用案例。
除了使用這種大量無監督的人人會話日誌外，還有一種思路是基於Rule-Based TaskFlow構建規則的使用者模擬器，進行互動以生成大量的對話資料，進而訓練對話模型。為了保證對話系統的魯棒性，也可使用類似對抗攻擊的方法優化，可以模擬Hard User的行為，不按順序執行TaskFlow，隨機打斷、跳轉某個對話節點等等。
此外，通過對比分析人機對話日誌和人人對話日誌，人機對話比較僵硬死板，無法有效捕捉使用者的情緒，而人就很擅長這方面。這在客服場景非常重要，使用者往往進來就是帶著負面情緒的，機器人需要有共情能力。而端到端資料驅動的對話和對話共情能力建設，也將是接下來一段時間我們嘗試的重點方向。
閱讀美團技術團隊更多技術文章合集
前端 | 演算法 | 後端 | 資料 | 安全 | 運維 | iOS | Android | 測試
| 在公眾號選單欄對話方塊回覆【2020年貨】、【2019年貨】、【2018年貨】、【2017年貨】等關鍵詞，可檢視美團技術團隊歷年技術文章合集。
| 本文系美團技術團隊出品，著作權歸屬美團。歡迎出於分享和交流等非商業目的轉載或使用本文內容，敬請註明“內容轉載自美團技術團隊”。本文未經許可，不得進行商業性轉載或者使用。任何商用行為，請傳送郵件至tech@meituan.com申請授權。