編者按：Uber技術人員介紹如何通過引入深度學習提高客服系統效率，以及如何擴展Spark工作流封裝TensorFlow模型，結合CPU集群和GPU節點的性能優勢.

年初我們在Uber引入了客戶滿意服務單輔助系統（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；下：COTA v2

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自動處理。提高這些靜態回應的效率可以幫助客戶節省時間，也能讓客服集中精力處理更具挑戰性的服務單，以提供更好的客戶服務。

COTA是Uber的應用機器學習團隊、客戶支持平臺、Michelangelo團隊、Uber AI實驗室通力協作的成果，主要貢獻者為Uber機器學習團隊數據科學家Huaixin Zheng，Michelangelo團隊機器學習工程師Guoqin Zheng、Naveen Somasundaram，Uber客戶滿意團隊軟件工程師Basab Maulik，Uber應用機器學習團隊數據科學管理Hugh Williams，Michelangelo團隊工程管理Jeremy Hermann，感謝Piero Molino、Viresh Gehlawat、Yi-Chia Wang、Joseph Wang、Eric Chen、Paul Mikesell、Alex Sergeev、Mike Del Balso、Chintan Shah、Christina Grimsley、Taj Singh、Jai Malkani、Fran Bell、Jai Ranganathan的貢獻，以及Molly Vorwerck和Wayne Cunningham幫助編輯本文。