結合Spark與TF，Uber客服系統引入深度學習
來源：Uber
編譯：weakish
年初我們在Uber引入了 ofollow,noindex">客戶滿意服務單輔助系統（Customer Obsession Ticket Assistant，COTA） ，利用機器學習和自然語言處理（NLP）技術給客戶服務人員推薦服務單類別和回覆模板。在我們的客戶服務平臺整合COTA後，在保持甚至提高客戶滿意度的前提下，英文服務單的響應時間縮短了10%.
對Uber而言，這只是一個開始。為了提高COTA表現，我們安排了離線試驗。試驗顯示，深度學習可以將類別模型的top-1預測精確度從49%提高65%，將回復模型的top-1預測精確度從47%提高到55%（更多細節請參考我們的KDD論文，arXiv:1807.01337）。考慮到這些任務的複雜度，這真的是很不錯的成績。
由於試驗的結果很鼓舞人心，我們決定將我們的深度學習模型部署到Uber內部的機器學習平臺Michelangelo。為此，我們建立了一個基於Spark的深度學習工作流，以基於Michelangelo的現有基礎設施產品化第二代COTA（COTA v2）。由於模型的表現會隨著時間推移而下降，我們同樣建立了模型管理工作流，自動重新訓練、撤下模型，使模型始終保持最新。
整合到Michelangelo之後，線上測試驗證了之前的試驗結果，相比COTA v1系統，COTA v2深度學習系統在模型表現、服務單處理事件、客戶滿意度等關鍵測度上，有了顯著提升。
初代COTA：挑戰和機遇
COTA v1主要有兩個地方需要提高：
- 對負面樣本的處理方式過於複雜，使訓練模型變得困難。再加上依賴特定的資料表，再訓練需要大費周章。
- 擴充套件性不夠，將來的NLP模型難以使用。
為何深度學習？
COTA v1的成功促使我們進一步投入技術棧，探索其他服務解決方案。在全球超過600個城市提供服務，支援多種語言和超過5種溝通渠道，Uber的客服涉及Uber旗下各種服務。這樣的範圍和規模給我們面臨的挑戰增加了極大的複雜度。因此，歸類和解決服務單的方式數以千計。此外，Uber的成長需要我們以前所未有的節奏迭代。如果沒有考慮到業務增長，今天奏效的解決方案可能幾個月後就失效了。
深度學習給包括機器翻譯、語音識別、計算機視覺、自然語言理解在內的眾多的領域帶來了變革，並在特定任務上取得了和人類相當乃至超過人類的表現。因此，深度學習看起來是開發COTA v2自然的選擇。事實上，通過離線測試，我們發現，相比COTA v1，深度學習模型可以提供精準得多的服務單響應預測。
遷移至基於深度學習的COTA v2
簡單來說，COTA v1基於傳統的NLP方法進行主題建模，並使用了結合文字特徵、類別特徵、數值特徵的機器學習技術，如下圖上半部分所示：
COTA v1建立了處理輸入的服務單訊息的NLP工作流，以提取文字特徵。並通過另外的特徵工程生成餘弦相似度。一切特徵就緒後，將所有特徵傳入一個二元逐點排序演算法，預測服務單類別和回覆模板。
上圖的下半部分刻畫了COTA v2所用的深度學習架構。文字特徵經過典型的NLP預處理（例如文字清洗和tokenization，示意圖上沒有顯示），服務單中的每個單詞通過一個嵌入層（示意圖上沒有顯示）編碼為密集表示，並進一步通過卷積層編碼整個文字語料庫。類別特徵通過嵌入層編碼，以捕捉不同類別的接近程度。數值特徵通過批歸一化穩定訓練過程。我們的離線試驗表明COTA v2深度學習系統較COTA v1有顯著提升（提高了8-16個百分比），無論是單獨預測型別和回覆，還是一次性聯合預測型別和回覆，皆是如此。
上圖顯示了深度學習模型學習到的嵌入的t-SNE圖形。例如，上圖左半部分可視化了一些Uber特定的關鍵詞，我們發現，“載具”（vehicle）和“汽車”（car）在t-SNE圖形上非常接近。和支付相關的單詞，例如“充值”（charge）、“信用”（credit）、“費用”（fare），在t-SNE影象上也聚類在一起。
上圖右半部分可視化了學習到的服務單型別嵌入，其中每個資料點對應一個型別。型別有三種顏色：“搭車人”、“司機”、“其他”（餐飲、旅館等）。在t-SNE圖形上，“搭車人”和“司機”的聚類很明顯。這些視覺化直觀地確認了模型正在學習合理的表示，同時暗示模型足以捕捉單詞間的相關性和語義聯絡，以及服務單型別之間的關係。
部署COTA v2的挑戰和解決方案
由於深度學習模型在離線測試上成果喜人，我們決定將其部署到生產系統。然而，同時整合NLP轉換和深度學習訓練帶來了不小的複雜度，再加上我們將使用大量訓練資料，部署COTA v2深度學習模型很有挑戰性。
理想情況下，我們想要利用Spark分散式地進行NLP轉換。Spark計算通常基於CPU叢集。另一方面，深度學習訓練在基於GPU的基礎設施上執行起來更高效。為了應對這一雙重性，我們需要找到一個同時使用Spark轉換和GPU訓練的方法，同時建立一個訓練深度學習模型並提供服務的統一工作流。
另一項挑戰是我們需要決定如何在Uber業務的動態本質下保持模型的新鮮度。因此，工作流需要頻繁地重新訓練、重新部署模型。
為了解決第一項挑戰，我們建立了一個深度學習Spark工作流（DLSP），同時使用Spark進行NLP轉換，使用GPU進行深度學習訓練。至於第二項挑戰，我們集成了一個內部工作規劃工具，在DLSP的基礎上建立了一個模型生命週期管理工作流（MLMP），讓我們可以按所需頻率規劃和執行每項工作。這兩個工作流讓我們得以在Uber的生產系統上訓練和部署深度學習模型，同時重新訓練和更新模型以保持峰值表現。
在接下來的兩部分中，我們將詳細討論這兩個工作流。
COTA v2的深度學習Spark工作流
分兩個階段定義工作流，一個階段進行Spark預處理，一個階段進行深度學習，看起來是分配工作負荷的最佳方式。我們擴充套件了Spark工作流的概念，得以使用現有的基礎設施支援批量預測和實時預測服務。
訓練
模型訓練分為兩個階段，如下圖上部所示：
- 基於Spark進行預處理： 我們利用Uber的大規模Spark叢集進行資料預處理，同時擬合訓練和服務所需的轉換。在預訓練時對資料所做的一切轉換均儲存為Spark轉換器，接著用於建立Spark工作流提供服務。在Spark叢集上進行分散式預處理比在單GPU節點上預處理資料要快得多。我們在Spark叢集上計算擬合轉換（需要持續資料的轉換，比如StringIndexer）和非擬合轉換（比如從字串中清洗HTML標籤）。
- 基於TensorFlow進行深度學習訓練： 一旦完成了第一步的預處理，我們便利用預處理過的資料基於TensorFlow訓練深度學習模型。然後合併這一階段訓練好的模型和上一階段生成的Spark工作流，得到最終的Spark工作流。最終工作流整合了預處理轉換器和TensorFlow模型，以便執行預測。我們實現了一個特殊型別的轉換器，稱為TFTransformer，以結合Spark工作流和TensorFlow模型。因為所有的Spark工作流都是基於Java實現的，所以TFTransformer也使用了Java。
服務
上圖的下半部分展示瞭如何基於深度學習Spark工作流在批量預測和實時預測服務使用訓練好的模型。我們擴充套件了Michelangelo以支援通用Spark工作流，並利用現有的部署和服務基礎設施提供深度學習模型服務。用於提供服務的工作流執行在JVM上。我們觀察到提供服務時的延遲為p95 < 10ms（譯者注：95%的情況下延遲低於10毫秒），這展示了使用現有的JVM服務基礎設施帶來的低延遲優勢。通過擴充套件Spark工作流封裝深度學習模型，我們能夠融CPU驅動和GPU驅動兩家之長：1) 基於CPU的Spark轉換分散式計算和Spark工作流低延遲服務；2) 基於GPU加速深度學習模型訓練。
模型生命週期管理工作流：模型保鮮
為了避免COTA v2模型的表現隨時間推移而下降，我們在DLSP的基礎上建立了一個模型生命週期管理工作流（MLMP）。具體來說，我們利用Uber內部工作規劃工具Piper建立了一個端到端工作流，以固定頻率重新訓練、重新部署模型。
如上圖所示，模型生命週期管理工作流共有6項工作，使用Michelangelo現有的API重新訓練模型。這6項工作構成了一個有向無環圖（DAG），箭頭表示依賴關係：
- 資料ETL： 包括資料提取，基本轉換，載入工作以準備資料。通常從若干不同的資料來源拉去資料，轉換資料至恰當的格式，並放入Hive資料庫。
- Spark轉換： 這一步驟轉換原始資料（文字、類別、數值，等等）為張量格式，提供給TensorFlow圖作為輸入，以訓練模型。底層的轉換通過Michelangelo利用了Spark引擎分散式進行。轉換器儲存到模型儲存。
- 資料傳輸： CPU計算機叢集進行Spark轉換。深度學習訓練需要GPU加速程序。因此，我們將第二步的輸出資料傳輸至GPU機器。
- 深度學習訓練： 資料一旦傳輸至GPU叢集，就會觸發一項工作，開啟基於定製的Docker容器的GPU會話，並開始深度學習訓練過程。訓練結束後，將TensorFlow模型檔案儲存至模型儲存。
- 模型合併： 合併第2步的Spark轉換器和第4步的TensorFlow模型，形成最終模型。
- 模型部署： 部署最終模型後，生成
model_id以便引用新部署的模型。外部微服務可以使用服務框架Thrift引用model_id。
線上測試：COTA v1 vs. COTA v2
為了驗證我們在離線試驗中觀測到的COTA v2深度學習模型的表現，我們在滾動式更新系統前進行一次線上測試。
測試策略
為了避免早先存在的取樣偏差，我們在A/B測試前先組織了一次A/A測試，如下圖所示：
在A/A測試和A/B測試期間，服務單以50/50的比例隨機分配至對照組和實驗組。在A/A測試期間，對照組和實驗組的預測均由COTA v1模型做出。而在A/B測試期間，實驗組使用COTA v2深度學習模型。
結果
A/A測試跑了一週，A/B測試跑了大概一個月。下圖展示了我們追蹤的兩個關鍵測度：模型精確度（這裡我們以服務單型別為例）和每個服務單的平均處理時間。如下圖上部所示，在A/A測試期間，模型表現沒有差異，而開啟A/B測試後，實驗組的模型大大提升了。這些結果確認了COTA v2深度學習系統比COTA v1體改了更精確的解。
如下圖下部所示，在A/B測試期間，實驗組的平均服務單處理時間要低得多。另外，從上圖上部我們還能觀測到一個現象，模型的表現隨著時間推移而下降，突顯了模型管理工作流MLMP的必要性。（為了保證一致性，在試驗期間沒有重新訓練模型。）
我們的線上測試再次證明給定足夠的訓練資料，COTA v2深度學習模型的表現明顯超過經典的COTA v1機器學習模型。
統計分析表明，A/A測試期間對照組和實驗組的平均處理時間沒有顯著差異，而A/B測試期間存在顯著差異。服務單處理時間有6.6%的相對縮短。另外，服務單建議的精確度也提高了。此外，我們也測量了顧客滿意度評分，發現使用COTA v2後滿意度略有提升。
COTA v2不僅提升了客戶支援的體驗，而且通過提高服務單解決過程的效率每年為公司節省數百萬美元。
下一步
鑑於COTA v2中的深度學習模型的強力表現，我們計劃在未來使用服務單型別預測決定給定服務單分配給哪個客服，因為專門處理特定型別問題的客服通常能更快地積累經驗。這一更新將增加在初次路由中識別解決客戶服務單的合適客服的概率，提升整個服務單支援系統的效率。
我們還打算考察能讓我們更快地回覆僅僅請求資訊的服務單的特性。例如，提問“我如何更新Uber賬戶頭像”的服務單。這類服務單，只需直接分享靜態資訊（在這一情形下是指引）就可以解決。在所有服務單中，這可能只佔一小部分，但這些服務單可以在無需客服監督的情況下由COTA v2自動處理。提高這些靜態迴應的效率可以幫助客戶節省時間，也能讓客服集中精力處理更具挑戰性的服務單，以提供更好的客戶服務。