阿里妹導讀：阿里小蜜是2015年阿里釋出的一款智慧客服機器人。2017年雙11期間，阿里小蜜的服務量達到643萬，其中智慧解決率達到95%，佔整體服務量的95%。經過近幾年的發展，能否更進一步解決智慧客服機器人的壓力成為當前我們思考的問題。今天，小蜜機器人實驗室的市丸帶領大家一起思考。

一、背景介紹

真實的服務鏈路中，阿里小蜜系列智慧客服已經很大程度上減輕了人工客服的壓力，但是能否更進一步解決智慧客服機器人的壓力成為當前我們思考的問題。因此我們啟動了預測平臺專案，通過人工智慧技術在使用者與機器人互動前對使用者意圖進行預測，並以主動或被動服務的方式幫助使用者解決當前遇到問題。

目前預測平臺核心圍繞兩個能力建設，訂單預測&問題預測。

訂單預測：預測使用者哪筆訂單遇到了問題

• 阿里小蜜約70%的服務諮詢都是與訂單相關。

• 體驗問題，不管是線上服務的訂單選擇器，還是熱線服務讓使用者手動輸入訂單編號，體驗都不太友善。

• 都不知道使用者哪筆訂單有問題，更何談預測使用者遇到了什麼問題。
  

問題預測：預測使用者遇到了什麼樣的問題

• 預測平臺服務類預測的終極目標。

除此之外，我們還做了場景預測（預測使用者是哪類問題，比如賬戶、物流、權益等等）、先驗知識預測（正負向的一些pattern以及ranking）、使用者預測（預測來電的號碼是哪個淘寶id）等等。

二、落地產品介紹

預測平臺經過半年多的發展，我們已經覆蓋了阿里小蜜、店小蜜、熱線小蜜、XSpace、永珍等CCO的各個服務端產品，下面我們就舉例看下幾個已經落地的產品形態以及他們的效果。

阿里小蜜：

上圖是阿里小蜜的落地場景，分別是訂單預測，問題預測猜你想問形態和問題預測bot形態。

• 訂單預測主要在各個訂單選擇器的入口，比如輸入框旁邊的“+”鍵、問題預測或者對話系統NLU識別到使用者意圖後部分需要使用者先提供訂單等場景，演算法對使用者訂單列表做reranking。目前，無意圖場景和有意圖場景對比上線前點選率提升均約16%-20%浮動，點選部分滿意度提升3.2%。

• 問題預測猜你想問形態，在使用者各個渠道進入阿里小蜜後都會出現，目前部分場景優先做全覆蓋策略，部分場景優先做高準確策略，前者點選率較上線前提高約2-3倍，後者點選率高於上線前近10倍。

• 問題預測bot形態，我們模型判斷非常高準確部分以上圖第三種形態呈現給使用者，告訴使用者是否XX訂單有XX問題。目前這部分的有效率高於阿里小蜜整體有效率35個百分點，滿意度也高3個點，但是覆蓋率相對較低，僅3%。

除了阿里小蜜外，我們還覆蓋了下面幾個場景：

• 熱線小蜜（熱線智慧客服機器人）：使用者進線優先反問使用者是否遇到了“XXX問題”，如果是則播報解決方案，否的話走熱線流程；當對話判斷到意圖後則會反問使用者是否“XXX訂單遇到了問題”，如果是則走SOP邏輯，否則請使用者提供訂單編號。目前訂單預測已經全場景上線，90%的使用者反饋正確，滿意度提升7%。“問題預測”目前還在開發中，期待今年雙十一給使用者帶來驚喜。
  

• 店小蜜（店鋪智慧客服機器人）：產品形態類似阿里小蜜的猜你想問，近期剛完成全行售後知識預測的上線，售後部分點選率提升4%，解決率提升4%。
  

• Xspace熱線工作臺（熱線人工）。過往的熱線人工服務，大部分小二都會需要使用者手動在手機端輸入訂單號碼，體驗有點糟糕。目前通過訂單預測，避免使用者手動的輸入，對大盤att降低6%+，覆蓋部分ATT降低10%+，服務團隊每天可多接千級電話服務，全年節省成本百萬級。
  

• 永珍（面向商家諮詢的智慧客服機器人）。產品形態也類似猜你想問。覆蓋消保和交易場景，點選率提升4%，解決率提升4%。
  

三、演算法技術介紹

目前演算法部分的核心能力，如下圖，不同的業務場景我們會組裝不同的演算法能力，比如熱線的訂單預測(使用者識別+訂單定位)，線上小蜜的問題預測(意圖分流+訂單定位+召回預測+目標預測)，每個子模組這裡就不做過多的描述，本章節主要介紹其中的演算法邏輯，具體落地方式參考第四章節。

預測/推薦，通常的演算法技術主要通過分類問題或排序問題來解，之前我們也嘗試了相對較基礎的特徵工程+RF的方式以及W&D的模型，另外上圖的不同能力模組中，我們也嘗試了label-lda/xgboost等演算法，因為整個預測平臺演算法技術模組劃分相對較多，今天我們的分享主要圍繞問題預測進行，本章節我們核心介紹近幾個月在問題預測方面的一些進展，具體當前線上的問題預測模型可以參考下面的表格(MV-DSSM正在對比中)。

3.1 問題預測的base 模型

近幾個月，我們核心圍繞deep-ctr的方式支撐業務，具體在不同的業務中對比或上線了DeepFM、PNN（IPNN）、DCN三個模型。以DCN為例，作為對Wide & Deep的擴充套件，DCN模型可以有效學習大規模的稀疏和稠密特徵，能夠以較低的計算開銷（引數較少），有效抓住特徵間的交叉關係。下圖為文獻中網路結構圖：

圖片來源《Deep & Cross Network for Ad Click Predictions》Ruoxi Wang，2017。交叉網路結構形式中，每一層都是學習一個特徵交叉對映f:ℝd→ℝd ，來擬合xl+1−xl 的殘差。一方面，每一層學習的對映f 都是一個對交叉特徵的非線性對映，然後通過擬合殘差的方式，提高權重的敏感度，更適合稀疏的輸入，同時另一方面，方便網路整體的反向傳播，提高網路訓練效率。右側是一般的全連線層，是對原始輸入特徵的非線性對映，最後連線層是softmax。

此外，我們對DeepCTR系列演算法做了一些改進。為了使DeepCTR模型更具通用性，我們參考了Kaggle競賽：Mercari Price Suggesion中4th方案的做法，具體包括：

• input層同時支援One-hot + Multi-hot特徵；

• 使用2vect演算法獨立訓練詞向量；

• 加入文字embedding層；

圖片來自

ChenglongChen/tensorflow-XNN, https://github.com/ChenglongChen/tensorflow-XNN

3.2 強化學習

近期我們正在和計算平臺的團隊合作，基於deep-ctr的base模型（特徵空間較大，但是訓練時間較長更新較慢），結合drl做reranking（根據ctr-score以及實時線上的一些反饋資料，通過構建sequential的排序方式進行episode建模），強化點選率/解決率/滿意率等目標。

3.3 流計算

既然我們有了問題預測的能力，很容易聯想到為什麼我們要等使用者進入我們的服務渠道我們才預測呢？為什麼我們不在使用者使用淘寶的時候實時監控使用者日誌，主動預測使用者的問題並第一時間傳送訊息觸達到使用者，提醒使用者來阿里小蜜我們可以幫助解決他的問題。這就需要藉助流計算的能力。

該模型目前對召回使用者達到86.42%精確率；模擬全量使用者實時計算主動服務場景，覆蓋率為0.1%。TextCNN方法最先由《Convolutional Neural Networks for Sentence Classification》，Kim Yoon提出以解決文字情感分類問題。在工程領域普遍認為是LSTM等複雜序列化模型的替代。

根據我們提出的touch2vect的編碼並結合改進的TextCNN序列資料做分類。首先基於海量使用者的頁面瀏覽路徑，以及隨之遇到的問題，無監督的挖掘背後的“語義資訊”並儲存為編碼模型。在Embedding representation階段，系統通過接入(手淘、天貓)實時瀏覽日誌，將使用者的序列化頁面瀏覽路徑（頁面1>頁面2>…>頁面N）編碼為二維向量作為輸入，通過CNN提取序列化的隱含模式，最後讓模型所啟用的Top“問題/知識”作為預測結果。

目前這個子專案正在進行中，離線評測效果為召回1.5%的前提下，準確率86.3%。不使用rnn based的模型，一是因為rnn效能相對糟糕，況且在日誌高QPS的前提下更加麻煩；二是因為目前第一版模型，以相對簡單探索為主，避免模型太複雜影響調研結論，當然目前也已經開始打算嘗試一些序列化的模型。

四、平臺化方案介紹

隨著早期快速的業務支撐落地拿結果，逐漸發現了以下一些瓶頸：

• 程式碼重複建設，阿里小蜜 、店小蜜、熱線小蜜中程式碼重複開發，邏輯分散，業務無法快速響應。

• 模型評測邏輯分散，各演算法工程師各自維護，重複開發，評測效率低。

• 演算法服務管理分散，各演算法工程師獨立維護，無法統一管理和維護所有演算法服務。

• 模型更新後，演算法服務無法自動化更新，模型迭代效率不高。

因此，今年我們啟動了整個平臺化的程序。整體功能包含演算法流式引擎、取數、特徵工程、模型訓練、演算法灰度、線上評測、自動降級以及自動上線等，提供各類預測服務的一體化平臺。當前階段的重點工作主要在演算法能力模組化（通過可串聯、可編排的演算法流式引擎，實現演算法能力複用，快速響應業務，快速驗證演算法效果）、統一資料來源及特徵工程（可使演算法同學專注演算法實現，驗證演算法效果）、統一演算法服務管理及模型評測（避免演算法評測程式碼重複開發）、演算法服務自動化更新（提升模型釋出效率，保證模型的時效性）、線上推薦點選資料自動迴流（通過線上資料反哺模型，提升模型效果）。

具體方案如上圖，核心分為如下四個部分：

1.執行引擎串聯預測流程，提供預測能力，通過元件化改造預測流程使系統有更好的擴充套件性，業務場景覆蓋從之前的程式碼開發，改造為通過配置化支援。

2.離線計算部分，資料來源主要來源於三部分，odps的離線+TT日誌+TC等線上介面，一部分用於規則部分的計算，另一部分輸出到odps用作離線訓練和實時演算法的輸入資料。

3.實時計算部分，資料來源主要來自於使用者線上的實時日誌資料，通過Blink和EAS服務進行實時計算，輸出預測結果，一部分直接推送給終端使用者，另一部分和使用者進線後的預測結果進行整合。

4.預測平臺管理後臺，主要用於預測服務的運維光立，提供演算法服務管理，預測流程Flow管理，支援演算法自動上線，灰度調控，演算法服務降級等。

演算法流式引擎方案如上圖

• Component：(調演算法，取數，自定義處理)元件。開發者編碼實現最多的地方。

• Module：模組，一組Component的可選實現的順序組合(序列)。

• Switch：開關，條件、順序、併發、重複、終止等邏輯判斷和流程操作的執行器和排程者，用於連線各個上下游Module。開發者須在此做具體實現，支援N路開關（n in, m out）。

• Flow：工作流，一組實現完整預測功能的Module和Switch的DAG組合。一個Module可以被多個flow共享（一次請求只執行一次）。

• biz：業務，由多個可配置的工作流組成，支援一項問題預測業務的問題預測client的呼叫。client呼叫方只關心biz-id。

五、總結

作為一個平臺化支援阿里小蜜家族的專案，目前已經落地了不少CCO touch服務的端，並且還在不斷的努力中，真心感覺這一路大家親密無間的並肩作戰以及大家的付出。

最後打下招聘廣告，阿里小蜜團隊招聘NLP、推薦/預測相關演算法同學，有意向歡迎郵件至：[email protected]

阿里巴巴數學大賽賽題、官方參考答案現已公佈。

長按識別以下二維碼，關注“阿里巴巴機器智慧”公眾號，回覆“數學大賽”，即可下載哦。

 ↑ 翹首以盼等你關注

你可能還喜歡

點選下方圖片即可閱讀

關注「阿里技術」

把握前沿技術脈搏