如何通過引入深度學(xué)習(xí)提高客服系統(tǒng)效率，以及如何擴(kuò)展Spark工作流封裝TensorFlow模型

編者按：Uber技術(shù)人員介紹如何通過引入深度學(xué)習(xí)提高客服系統(tǒng)效率，以及如何擴(kuò)展Spark工作流封裝TensorFlow模型，結(jié)合CPU集群和GPU節(jié)點(diǎn)的性能優(yōu)勢.

年初我們在Uber引入了客戶滿意服務(wù)單輔助系統(tǒng)（Customer Obsession Ticket Assistant，COTA），利用機(jī)器學(xué)習(xí)和自然語言處理（NLP）技術(shù)給客戶服務(wù)人員推薦服務(wù)單類別和回復(fù)模板。在我們的客戶服務(wù)平臺集成COTA后，在保持甚至提高客戶滿意度的前提下，英文服務(wù)單的響應(yīng)時(shí)間縮短了10%.

對Uber而言，這只是一個(gè)開始。為了提高COTA表現(xiàn)，我們安排了離線試驗(yàn)。試驗(yàn)顯示，深度學(xué)習(xí)可以將類別模型的top-1預(yù)測精確度從49%提高65%，將回復(fù)模型的top-1預(yù)測精確度從47%提高到55%（更多細(xì)節(jié)請參考我們的KDD論文，arXiv:1807.01337）?？紤]到這些任務(wù)的復(fù)雜度，這真的是很不錯(cuò)的成績。

由于試驗(yàn)的結(jié)果很鼓舞人心，我們決定將我們的深度學(xué)習(xí)模型部署到Uber內(nèi)部的機(jī)器學(xué)習(xí)平臺Michelangelo。為此，我們創(chuàng)建了一個(gè)基于Spark的深度學(xué)習(xí)工作流，以基于Michelangelo的現(xiàn)有基礎(chǔ)設(shè)施產(chǎn)品化第二代COTA（COTA v2）。由于模型的表現(xiàn)會隨著時(shí)間推移而下降，我們同樣創(chuàng)建了模型管理工作流，自動(dòng)重新訓(xùn)練、撤下模型，使模型始終保持最新。

集成到Michelangelo之后，在線測試驗(yàn)證了之前的試驗(yàn)結(jié)果，相比COTA v1系統(tǒng)，COTA v2深度學(xué)習(xí)系統(tǒng)在模型表現(xiàn)、服務(wù)單處理事件、客戶滿意度等關(guān)鍵測度上，有了顯著提升。

初代COTA：挑戰(zhàn)和機(jī)遇

COTA v1主要有兩個(gè)地方需要提高：

對負(fù)面樣本的處理方式過于復(fù)雜，使訓(xùn)練模型變得困難。再加上依賴特定的數(shù)據(jù)表，再訓(xùn)練需要大費(fèi)周章。

擴(kuò)展性不夠，將來的NLP模型難以使用。

為何深度學(xué)習(xí)？

COTA v1的成功促使我們進(jìn)一步投入技術(shù)棧，探索其他服務(wù)解決方案。在全球超過600個(gè)城市提供服務(wù)，支持多種語言和超過5種溝通渠道，Uber的客服涉及Uber旗下各種服務(wù)。這樣的范圍和規(guī)模給我們面臨的挑戰(zhàn)增加了極大的復(fù)雜度。因此，歸類和解決服務(wù)單的方式數(shù)以千計(jì)。此外，Uber的成長需要我們以前所未有的節(jié)奏迭代。如果沒有考慮到業(yè)務(wù)增長，今天奏效的解決方案可能幾個(gè)月后就失效了。

深度學(xué)習(xí)給包括機(jī)器翻譯、語音識別、計(jì)算機(jī)視覺、自然語言理解在內(nèi)的眾多的領(lǐng)域帶來了變革，并在特定任務(wù)上取得了和人類相當(dāng)乃至超過人類的表現(xiàn)。因此，深度學(xué)習(xí)看起來是開發(fā)COTA v2自然的選擇。事實(shí)上，通過離線測試，我們發(fā)現(xiàn)，相比COTA v1，深度學(xué)習(xí)模型可以提供精準(zhǔn)得多的服務(wù)單響應(yīng)預(yù)測。

遷移至基于深度學(xué)習(xí)的COTA v2

簡單來說，COTA v1基于傳統(tǒng)的NLP方法進(jìn)行主題建模，并使用了結(jié)合文本特征、類別特征、數(shù)值特征的機(jī)器學(xué)習(xí)技術(shù)，如下圖上半部分所示：

上：COTA v1；下：COTA v2

COTA v1創(chuàng)建了處理輸入的服務(wù)單消息的NLP工作流，以提取文本特征。并通過另外的特征工程生成余弦相似度。一切特征就緒后，將所有特征傳入一個(gè)二元逐點(diǎn)排序算法，預(yù)測服務(wù)單類別和回復(fù)模板。

上圖的下半部分刻畫了COTA v2所用的深度學(xué)習(xí)架構(gòu)。文本特征經(jīng)過典型的NLP預(yù)處理（例如文本清洗和tokenization，示意圖上沒有顯示），服務(wù)單中的每個(gè)單詞通過一個(gè)嵌入層（示意圖上沒有顯示）編碼為密集表示，并進(jìn)一步通過卷積層編碼整個(gè)文本語料庫。類別特征通過嵌入層編碼，以捕捉不同類別的接近程度。數(shù)值特征通過批歸一化穩(wěn)定訓(xùn)練過程。我們的離線試驗(yàn)表明COTA v2深度學(xué)習(xí)系統(tǒng)較COTA v1有顯著提升（提高了8-16個(gè)百分比），無論是單獨(dú)預(yù)測類型和回復(fù)，還是一次性聯(lián)合預(yù)測類型和回復(fù)，皆是如此。

上圖顯示了深度學(xué)習(xí)模型學(xué)習(xí)到的嵌入的t-SNE圖形。例如，上圖左半部分可視化了一些Uber特定的關(guān)鍵詞，我們發(fā)現(xiàn)，“載具”（vehicle）和“汽車”（car）在t-SNE圖形上非常接近。和支付相關(guān)的單詞，例如“充值”（charge）、“信用”（credit）、“費(fèi)用”（fare），在t-SNE圖像上也聚類在一起。

上圖右半部分可視化了學(xué)習(xí)到的服務(wù)單類型嵌入，其中每個(gè)數(shù)據(jù)點(diǎn)對應(yīng)一個(gè)類型。類型有三種顏色：“搭車人”、“司機(jī)”、“其他”（餐飲、旅館等）。在t-SNE圖形上，“搭車人”和“司機(jī)”的聚類很明顯。這些可視化直觀地確認(rèn)了模型正在學(xué)習(xí)合理的表示，同時(shí)暗示模型足以捕捉單詞間的相關(guān)性和語義聯(lián)系，以及服務(wù)單類型之間的關(guān)系。

部署COTA v2的挑戰(zhàn)和解決方案

由于深度學(xué)習(xí)模型在離線測試上成果喜人，我們決定將其部署到生產(chǎn)系統(tǒng)。然而，同時(shí)集成NLP轉(zhuǎn)換和深度學(xué)習(xí)訓(xùn)練帶來了不小的復(fù)雜度，再加上我們將使用大量訓(xùn)練數(shù)據(jù)，部署COTA v2深度學(xué)習(xí)模型很有挑戰(zhàn)性。

理想情況下，我們想要利用Spark分布式地進(jìn)行NLP轉(zhuǎn)換。Spark計(jì)算通?；贑PU集群。另一方面，深度學(xué)習(xí)訓(xùn)練在基于GPU的基礎(chǔ)設(shè)施上運(yùn)行起來更高效。為了應(yīng)對這一雙重性，我們需要找到一個(gè)同時(shí)使用Spark轉(zhuǎn)換和GPU訓(xùn)練的方法，同時(shí)創(chuàng)建一個(gè)訓(xùn)練深度學(xué)習(xí)模型并提供服務(wù)的統(tǒng)一工作流。

另一項(xiàng)挑戰(zhàn)是我們需要決定如何在Uber業(yè)務(wù)的動(dòng)態(tài)本質(zhì)下保持模型的新鮮度。因此，工作流需要頻繁地重新訓(xùn)練、重新部署模型。

為了解決第一項(xiàng)挑戰(zhàn)，我們創(chuàng)建了一個(gè)深度學(xué)習(xí)Spark工作流（DLSP），同時(shí)使用Spark進(jìn)行NLP轉(zhuǎn)換，使用GPU進(jìn)行深度學(xué)習(xí)訓(xùn)練。至于第二項(xiàng)挑戰(zhàn)，我們集成了一個(gè)內(nèi)部工作規(guī)劃工具，在DLSP的基礎(chǔ)上創(chuàng)建了一個(gè)模型生命周期管理工作流（MLMP），讓我們可以按所需頻率規(guī)劃和運(yùn)行每項(xiàng)工作。這兩個(gè)工作流讓我們得以在Uber的生產(chǎn)系統(tǒng)上訓(xùn)練和部署深度學(xué)習(xí)模型，同時(shí)重新訓(xùn)練和更新模型以保持峰值表現(xiàn)。

在接下來的兩部分中，我們將詳細(xì)討論這兩個(gè)工作流。

COTA v2的深度學(xué)習(xí)Spark工作流

分兩個(gè)階段定義工作流，一個(gè)階段進(jìn)行Spark預(yù)處理，一個(gè)階段進(jìn)行深度學(xué)習(xí)，看起來是分配工作負(fù)荷的最佳方式。我們擴(kuò)展了Spark工作流的概念，得以使用現(xiàn)有的基礎(chǔ)設(shè)施支持批量預(yù)測和實(shí)時(shí)預(yù)測服務(wù)。

訓(xùn)練

模型訓(xùn)練分為兩個(gè)階段，如下圖上部所示：

基于Spark進(jìn)行預(yù)處理：我們利用Uber的大規(guī)模Spark集群進(jìn)行數(shù)據(jù)預(yù)處理，同時(shí)擬合訓(xùn)練和服務(wù)所需的轉(zhuǎn)換。在預(yù)訓(xùn)練時(shí)對數(shù)據(jù)所做的一切轉(zhuǎn)換均保存為Spark轉(zhuǎn)換器，接著用于創(chuàng)建Spark工作流提供服務(wù)。在Spark集群上進(jìn)行分布式預(yù)處理比在單GPU節(jié)點(diǎn)上預(yù)處理數(shù)據(jù)要快得多。我們在Spark集群上計(jì)算擬合轉(zhuǎn)換（需要持續(xù)數(shù)據(jù)的轉(zhuǎn)換，比如StringIndexer）和非擬合轉(zhuǎn)換（比如從字符串中清洗HTML標(biāo)簽）。

基于TensorFlow進(jìn)行深度學(xué)習(xí)訓(xùn)練：一旦完成了第一步的預(yù)處理，我們便利用預(yù)處理過的數(shù)據(jù)基于TensorFlow訓(xùn)練深度學(xué)習(xí)模型。然后合并這一階段訓(xùn)練好的模型和上一階段生成的Spark工作流，得到最終的Spark工作流。最終工作流整合了預(yù)處理轉(zhuǎn)換器和TensorFlow模型，以便運(yùn)行預(yù)測。我們實(shí)現(xiàn)了一個(gè)特殊類型的轉(zhuǎn)換器，稱為TFTransformer，以結(jié)合Spark工作流和TensorFlow模型。因?yàn)樗械腟park工作流都是基于Java實(shí)現(xiàn)的，所以TFTransformer也使用了Java。

服務(wù)

上圖的下半部分展示了如何基于深度學(xué)習(xí)Spark工作流在批量預(yù)測和實(shí)時(shí)預(yù)測服務(wù)使用訓(xùn)練好的模型。我們擴(kuò)展了Michelangelo以支持通用Spark工作流，并利用現(xiàn)有的部署和服務(wù)基礎(chǔ)設(shè)施提供深度學(xué)習(xí)模型服務(wù)。用于提供服務(wù)的工作流運(yùn)行在JVM上。我們觀察到提供服務(wù)時(shí)的延遲為p95 < 10ms（譯者注：95%的情況下延遲低于10毫秒），這展示了使用現(xiàn)有的JVM服務(wù)基礎(chǔ)設(shè)施帶來的低延遲優(yōu)勢。通過擴(kuò)展Spark工作流封裝深度學(xué)習(xí)模型，我們能夠融CPU驅(qū)動(dòng)和GPU驅(qū)動(dòng)兩家之長：1) 基于CPU的Spark轉(zhuǎn)換分布式計(jì)算和Spark工作流低延遲服務(wù)；2) 基于GPU加速深度學(xué)習(xí)模型訓(xùn)練。

模型生命周期管理工作流：模型保鮮

為了避免COTA v2模型的表現(xiàn)隨時(shí)間推移而下降，我們在DLSP的基礎(chǔ)上創(chuàng)建了一個(gè)模型生命周期管理工作流（MLMP）。具體來說，我們利用Uber內(nèi)部工作規(guī)劃工具Piper創(chuàng)建了一個(gè)端到端工作流，以固定頻率重新訓(xùn)練、重新部署模型。

如上圖所示，模型生命周期管理工作流共有6項(xiàng)工作，使用Michelangelo現(xiàn)有的API重新訓(xùn)練模型。這6項(xiàng)工作構(gòu)成了一個(gè)有向無環(huán)圖（DAG），箭頭表示依賴關(guān)系：

數(shù)據(jù)ETL：包括數(shù)據(jù)提取，基本轉(zhuǎn)換，加載工作以準(zhǔn)備數(shù)據(jù)。通常從若干不同的數(shù)據(jù)源拉去數(shù)據(jù)，轉(zhuǎn)換數(shù)據(jù)至恰當(dāng)?shù)母袷?，并放入Hive數(shù)據(jù)庫。

Spark轉(zhuǎn)換：這一步驟轉(zhuǎn)換原始數(shù)據(jù)（文本、類別、數(shù)值，等等）為張量格式，提供給TensorFlow圖作為輸入，以訓(xùn)練模型。底層的轉(zhuǎn)換通過Michelangelo利用了Spark引擎分布式進(jìn)行。轉(zhuǎn)換器保存到模型存儲。

數(shù)據(jù)傳輸：CPU計(jì)算機(jī)集群進(jìn)行Spark轉(zhuǎn)換。深度學(xué)習(xí)訓(xùn)練需要GPU加速進(jìn)程。因此，我們將第二步的輸出數(shù)據(jù)傳輸至GPU機(jī)器。

深度學(xué)習(xí)訓(xùn)練：數(shù)據(jù)一旦傳輸至GPU集群，就會觸發(fā)一項(xiàng)工作，開啟基于定制的Docker容器的GPU會話，并開始深度學(xué)習(xí)訓(xùn)練過程。訓(xùn)練結(jié)束后，將TensorFlow模型文件保存至模型存儲。

模型合并：合并第2步的Spark轉(zhuǎn)換器和第4步的TensorFlow模型，形成最終模型。

模型部署：部署最終模型后，生成model_id以便引用新部署的模型。外部微服務(wù)可以使用服務(wù)框架Thrift引用model_id。

在線測試：COTA v1 vs. COTA v2

為了驗(yàn)證我們在離線試驗(yàn)中觀測到的COTA v2深度學(xué)習(xí)模型的表現(xiàn)，我們在滾動(dòng)式更新系統(tǒng)前進(jìn)行一次在線測試。

測試策略

為了避免早先存在的采樣偏差，我們在A/B測試前先組織了一次A/A測試，如下圖所示：

在A/A測試和A/B測試期間，服務(wù)單以50/50的比例隨機(jī)分配至對照組和實(shí)驗(yàn)組。在A/A測試期間，對照組和實(shí)驗(yàn)組的預(yù)測均由COTA v1模型做出。而在A/B測試期間，實(shí)驗(yàn)組使用COTA v2深度學(xué)習(xí)模型。

結(jié)果

A/A測試跑了一周，A/B測試跑了大概一個(gè)月。下圖展示了我們追蹤的兩個(gè)關(guān)鍵測度：模型精確度（這里我們以服務(wù)單類型為例）和每個(gè)服務(wù)單的平均處理時(shí)間。如下圖上部所示，在A/A測試期間，模型表現(xiàn)沒有差異，而開啟A/B測試后，實(shí)驗(yàn)組的模型大大提升了。這些結(jié)果確認(rèn)了COTA v2深度學(xué)習(xí)系統(tǒng)比COTA v1體改了更精確的解。

如下圖下部所示，在A/B測試期間，實(shí)驗(yàn)組的平均服務(wù)單處理時(shí)間要低得多。另外，從上圖上部我們還能觀測到一個(gè)現(xiàn)象，模型的表現(xiàn)隨著時(shí)間推移而下降，突顯了模型管理工作流MLMP的必要性。（為了保證一致性，在試驗(yàn)期間沒有重新訓(xùn)練模型。）

我們的在線測試再次證明給定足夠的訓(xùn)練數(shù)據(jù)，COTA v2深度學(xué)習(xí)模型的表現(xiàn)明顯超過經(jīng)典的COTA v1機(jī)器學(xué)習(xí)模型。

統(tǒng)計(jì)分析表明，A/A測試期間對照組和實(shí)驗(yàn)組的平均處理時(shí)間沒有顯著差異，而A/B測試期間存在顯著差異。服務(wù)單處理時(shí)間有6.6%的相對縮短。另外，服務(wù)單建議的精確度也提高了。此外，我們也測量了顧客滿意度評分，發(fā)現(xiàn)使用COTA v2后滿意度略有提升。

COTA v2不僅提升了客戶支持的體驗(yàn)，而且通過提高服務(wù)單解決過程的效率每年為公司節(jié)省數(shù)百萬美元。

下一步

鑒于COTA v2中的深度學(xué)習(xí)模型的強(qiáng)力表現(xiàn)，我們計(jì)劃在未來使用服務(wù)單類型預(yù)測決定給定服務(wù)單分配給哪個(gè)客服，因?yàn)閷ｉT處理特定類型問題的客服通常能更快地積累經(jīng)驗(yàn)。這一更新將增加在初次路由中識別解決客戶服務(wù)單的合適客服的概率，提升整個(gè)服務(wù)單支持系統(tǒng)的效率。

我們還打算考察能讓我們更快地回復(fù)僅僅請求信息的服務(wù)單的特性。例如，提問“我如何更新Uber賬戶頭像”的服務(wù)單。這類服務(wù)單，只需直接分享靜態(tài)信息（在這一情形下是指引）就可以解決。在所有服務(wù)單中，這可能只占一小部分，但這些服務(wù)單可以在無需客服監(jiān)督的情況下由COTA v2自動(dòng)處理。提高這些靜態(tài)回應(yīng)的效率可以幫助客戶節(jié)省時(shí)間，也能讓客服集中精力處理更具挑戰(zhàn)性的服務(wù)單，以提供更好的客戶服務(wù)。

COTA是Uber的應(yīng)用機(jī)器學(xué)習(xí)團(tuán)隊(duì)、客戶支持平臺、Michelangelo團(tuán)隊(duì)、Uber AI實(shí)驗(yàn)室通力協(xié)作的成果，主要貢獻(xiàn)者為Uber機(jī)器學(xué)習(xí)團(tuán)隊(duì)數(shù)據(jù)科學(xué)家Huaixin Zheng，Michelangelo團(tuán)隊(duì)機(jī)器學(xué)習(xí)工程師Guoqin Zheng、Naveen Somasundaram，Uber客戶滿意團(tuán)隊(duì)軟件工程師Basab Maulik，Uber應(yīng)用機(jī)器學(xué)習(xí)團(tuán)隊(duì)數(shù)據(jù)科學(xué)管理Hugh Williams，Michelangelo團(tuán)隊(duì)工程管理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的貢獻(xiàn)，以及Molly Vorwerck和Wayne Cunningham幫助編輯本文。