阿里妹導讀：阿里小蜜是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層；
3.2 強化學習
近期我們正在和計算平臺的團隊合作，基於deep-ctr的base模型（特徵空間較大，但是訓練時間較長更新較慢），結合drl做reranking（根據ctr-score以及實時線上的一些反饋數據，通過構建sequential的排序方式進行episode建模），強化點擊率/解決率/滿意率等目標。
3.3 流計算
既然我們有了問題預測的能力，很容易聯想到為什麼我們要等用戶進入我們的服務渠道我們才預測呢？為什麼我們不在用戶使用淘寶的時候實時監控用戶日誌，主動預測用戶的問題並第一時間發送消息觸達到用戶，提醒用戶來阿里小蜜我們可以幫助解決他的問題。這就需要藉助流計算的能力。
根據我們提出的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]
閱讀更多 阿里技術 的文章
