人工智慧助力阿里雲售後服務

服務問題的爆發

阿里雲連續n個季度實現了三位數的增長！很多人看到光環和利潤的時候，不會想像的到雲計算背後的服務壓力有多大！雲計算大大降低了傳統IT實施的技術門檻，用戶群體迅猛增加。正如王堅博士所說，雲計算正在逐漸成為像「水電一樣的基礎設施」，然而卻遠遠沒有成熟到像水電那樣簡單易用。結果是，門檻的降低、行業的發展帶來了售後服務需求量的爆發。與此同時，雲產品越來越豐富，功能和架構也越來越複雜。雲計算的服務需求本來就遠比購買或者財務操作流程要複雜許多，它帶著強烈的技術屬性，每個客戶使用雲產品的業務場景也是千變萬化。數量和複雜度的疊加，成為了阿里雲這樣的雲計算企業必須要面對的問題！是不是可以通過成千上萬的客服坐席來解決呢？拋開成本不談，如何保證如此大量的客服都具有優秀的服務能力、達到服務標準，還能迅速的跟上產品的演進和更新？阿里雲服務必須找到「人海戰術」之外的突破口！

人工智慧的擔憂

人工智慧此時就該「捨我其誰」地衝上去了吧？而實際上，疑慮重重，一波三折。人工智慧，大數據，機器學習，這些前沿而又高深的技術令人覺得神秘而又憧憬。但在工業界，如何以產品的形態落地依然是個難題。雲計算客服需要的機器人，和大眾熟悉的機器人DeepBlue 和 AlphaGo，差之千里。人工智慧在計算機實驗室里有著很長的歷史，DeepBlue 和 AlphaGo分別在國際象棋和圍棋領域大放異彩，但在商業應用上，它卻仍然停留在用人類教會的知識套路，藉助更快的計算速度，去代替人類的重複勞動，其核心價值在於在既定的「棋譜」規則下能夠「算得快」和「不知疲倦」。

在客服領域，如果服務場景知識體系相對穩定，不需要頻繁地依賴人工重新「教」，那麼機器人是可以勝任的，但，這顯然不是在說雲計算。雲計算正在以驚人的速度創造新的雲產品和雲上IT 解決方案，功能和架構也在快速迭代更新。雲計算智能服務面臨難度更高的考試，必須要「學得快」，而且要儘可能減少對人的依賴！這在人工智慧應用領域是一個行業性的難題，原因就是——很難有足夠的符合要求的數據來「培養」學習能力，這也成為了智能服務持續運行起來的最大擔憂。

雲博士破土而出

面對這些疑慮和挑戰，阿里雲服務團隊投入了一支先鋒力量作為智能服務的開拓者。任務代號：雲博士；任務目標：採用簡單易用的問答機器人方式幫助用戶智能高效的解決雲產品問題。

項目開始沒多久，難題就不出意外地接踵而至。雲博士團隊像打怪獸般的去克服解決了一個有一個棘手問題，殺出一條血路，並愈戰愈勇！在這些磨練的過程中，逐漸打磨了產品的強大能力，誕生了最懂雲計算的高智商機器人「雲博士」！

到底是什麼樣的優秀品質能讓雲博士幫助用戶解決這些複雜的雲計算問題，來穩住阿里雲的人工服務？讓我們逐漸揭開其神秘的面紗。

1 - 半自動化式的技術數據標記

稍微了解一點人工智慧的朋友都知道，要做智能化，首先得有足夠數量的訓練集用來訓練模型。要能解決問題，這個訓練集中需要包含大量的問題和答案，通常一個答案需要對應不同表述方式的問題。並且要得到一個好的模型，數據的質量也是至關重要。通用的做法是由人工整理來生成這個知識庫。雲計算行業的特殊性在這個時候體現出來了：雲計算知識庫的技術門檻高，需要具備深厚的雲計算技術背景的工程師來做，過程中可能還需要實驗驗證，不像業務型的知識庫簡單易學可以通過眾包的方式來實現。

最開始，服務團隊組織了一批售後工程師，利用晚上和周末的時間集中標記數據。但事後發現因為需求量大和知識本身的技術門檻高，人工整理出來的知識庫里存在大量的不準確甚至是錯誤的內容，而且人工的效率也非常低。評測發現，雲博士使用這樣的初始版基礎數據，問題成功解答率遠遠達不到上線的標準。這不僅意味著這一批人工打標整理出來的數據幾乎用不上了，更糟糕的是，它沉重地宣告了這個貌似「通用」的方式對於雲計算這樣的技術領域行不通。

整整一個月，團隊一直反思，人工肯定會存在失誤，而如此大量的使用人力，是否反而增加了人工成本？無數次的嘗試、爭吵和修正方向之後，似乎終於看到了門縫的一絲光。售後工程師在服務客戶的過程中，會留下碎片化的記錄。在仔細看了大量的這樣的記錄之後，團隊逐漸摸索出一套方法來對這些碎片化的非結構化的記錄去做分析，包括去噪、脫敏、段落分解、抽取有用信息、信息聚合等，可以一定比例的自動分析出知識庫所需要的內容。這樣，程序能實現90%以上的工作量，最後由人工做一些確認即可。相對於傳統數據標記，這個確認工作可以明顯降低對人的技術門檻要求，也可以節省大量的人工思考、搜索、實驗的過程。這是一個離線處理大量非結構化數據的過程，存在諸多技術細節上的難度和結果的不確定性。終於，這種方法被實驗論證出可行！就這樣，雲博士的基礎數據在這種半自動化的計算、挖掘以及輕量人工確認的方式中產生了。

2 - 場景化的問答能力，比用戶更了解自己的系統

目前我們接觸到的機器人基本都是通過知識庫來做問答，也就是使用計算模型在基礎數據中找到分數最高的幾個答案，推送給用戶。雲博士在上線初期，亦是如此。但很快，我們就發現只通過用戶問題的語義分析通常並不能很準確的定位到問題，有時候還會出現答非所問。舉個例子，用戶問「我的伺服器不能登錄了，怎麼辦？」，機器其實並不能理解這句話背後的意思，它只能去分析這句話和它已經學會的知識庫里的其他語句所代表的意思差距有多大，然後找到最接近的句子對應的知識點作為答案推薦給用戶。而這個問題對應的語義高度接近的句子有很多，對應的答案也有很多，比如：伺服器被攻擊的處理方法，資源跑滿後的優化實踐，啟動伺服器的操作流程等等。為什麼會有這麼多答案呢？原因是：在雲計算的環境下，用戶往往只能看到問題的現象，通過問題現象來探索其背後的真正原因，其實中間還缺失了一環，所以面對多個答案時，機器人並不知道該推薦哪個答案。如果只是靠語義的相似度，經常會出現答非所問的尷尬，這也說明機器人並不「懂」用戶。

通過團隊的不斷摸索，和業務同學的不斷討論，我們建立了場景問答。將現象相同的一類問題定義為一個場景，當用戶的問題命中一個場景時，收集用戶線上的一些運行時數據，來進一步通過決策樹對其真實原因進行細緻的診斷，為用戶提供一個更加適用於當前場景的答案。這時候，當用戶再問「我的伺服器不能登錄了，怎麼辦？」時，雲博士會收集用戶的實例欠費、黑洞/清洗、CPU/帶寬跑滿、運行狀態等等一系列數據，如果診斷出用戶的實例處於關機狀態，則會為用戶推薦如何啟動查看實例的解決方法；如果診斷出用戶的實例欠費了，則會為用戶推薦如何續費的解決辦法。

基於場景的問答，極大的拓展了基於自然語言理解之外的問答能力，能夠對用戶系統的運行健康狀況和用戶行為分析來實現更精準的回答用戶問題。做到相同的問題，不同的用戶，看到不同的答案，千人千面的服務於雲計算的廣大用戶。

3 - 自我學習、自我更新的運轉模式

機器人在線上運轉一段時間後，我們發現業務的效果會逐漸變差。顯而易見，隨著業務的飛速發展，機器人必須要想辦法快速的學習新知識點，淘汰舊知識。目前的通常做法是通過人工方式對數據進行全量查看檢查，剔除其中的錯誤並補充新內容。如同基礎數據標記一樣，這種方式對於雲計算行業是行不通的。

半年多的時間，團隊探索出一個讓雲計算智能服務機器人主動「反省」和「學習」的方案。他們保持演算法白盒化，將其內部每次執行過程中的關鍵路徑以「日誌」的形式記錄下來，把機器人每次解答問題的實際效果也記錄下來。然後對兩者做對比分析，找出機器人知識體系里的錯誤知識Unkown Unknow（機器人認為正確，但實際錯誤）和知識盲點Known Unknown（機器人知道自己不會）。此外，機器人還具備了客戶行為軌跡和人工服務軌跡分析能力，通過工單數據，每天主動向售後工程師「學習」，來持續補充知識盲點所對應的答案。

在這整套的自學習方案中，也有少量的人工審核的工作。對於雲博士產品來說，有一支「人工智慧訓練師」小組專門來兼職做這些數據的輕量人工審核，來長期輔助機器優化最終的業務效果。

雲博士逐漸成長為一支隱形的「售後智能處理組」

隨著雲博士的加入，開始承擔起了阿里雲一部分人工服務量，以更方便快捷的方式服務於我們的線上用戶。現在雲博士已經逐漸成長成為一支日不落的「售後智能處理組」，上線短短數月已經成功幫助使用阿里雲的用戶實時解答數百萬個問題。目前，雲博士每天正在幫助數萬用戶在尋求人工之前自助智能的解決雲產品問題。雲博士還提供了多樣化的服務方式，不僅以PC端、APP端、釘釘群等智能問答機器人的形式隨時隨地聽憑用戶調遣、秒級響應，還在用戶的工單排隊期間提前為大家推薦解決方案。在用戶和產品量迅速增長的背景下，阿里雲的人工服務量維持穩定，並在小幅持續降低。將來，這支智能處理組的能力還在不斷壯大，憑藉阿里雲的技術優勢，更加精準的服務於我們的用戶，做到更聰明，更懂用戶。

對於阿里雲智能服務，可以說，我們現在僅僅是找到了一個方向。除了想辦法解決眼前的問題，更重要的，是想今天的每個決定在明年或者更遠的時間可能會產生什麼價值或是問題，能確保我們選擇的這條路可以持續走下去並且越走越寬，能夠建立雲計算這個行業通用的智能服務解決方案。未來的十年，未來的人工智慧會像互聯網一樣，滲透到每一個場景、每一個設備和每一種服務里。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！