第七章 人工智能，7.3 深度學習與自然語言處理在智能語音客服中的應用(作者： 余慈)

7.3 深度學習與自然語言處理在智能語音客服中的應用

1. 前言

95188電話的支付寶熱線目前已經用純語音交互流程全面代替了傳統的按鍵流程，這個我們稱之為“蟻人”的智能語音客服會根據用戶的描述判斷用戶的意圖，從而為不同需求的用戶提供快速的直達服務，或者直接推送自助解決方案，或者發現是屬於緊急問題而直接轉給對應業務線的人工客服處理。智能語音客服流程目前日均處理話務占整體話務數的91%，覆蓋上百類業務線以及上千類問題，以超過70%的問題識別准確率日均成功為客服分流話務上萬通，極大節省了客服人力資源，縮短話務高峰期的用戶等待時間，提升了用戶體驗。在雙11當天蟻人處理超過20萬通電話，為雙11業務提供強有力的支持。

 

2. 系統概要

蟻人流程的交互如下：

1. 用戶撥打95188，按1進支付寶
2. 系統會提示用戶用一句話描述所遇到的問題
3. 用戶在電話里描述他（她）想要解決的問題，比如支付寶密碼忘記了等
4. 系統會把用戶語音輸入轉成文本，然后調用問題識別模塊
5. 對話管理模塊（DM）根據識別結果有不同的路徑：
   1. 識別出用戶要求人工客服，或者需要人工處理的業務類（例如安全問題），就會轉到所對應的業務線的客服處理。
   2. 識別出的業務可以自助解決，系統就會播放TTS給用戶：“我想您遇到的問題是XXXX，請說’正確’，或者’錯誤’”。
   3. 識別失敗，會進入多輪交互流程，進一步向用戶提問並獲得回答以幫助問題識別。
6. 系統識別用戶在確認階段的反饋，如果用戶肯定了問題，就會推送自助方案到支付寶手機端，並提示用戶。如果用戶否定，那么會把用戶轉到人工客服處。

智能語音客服的核心功能是根據與用戶的交互信息判斷出用戶的來電目的，也就是交互步驟#4中的問題識別模塊。問題識別模塊允許通過與用戶的多輪交互來更准確地判斷用戶所遇到的業務問題。引入多輪交互流程因為，如果用戶只有一次描述問題的機會，下列幾個因素的影響往往會導致單輪問題識別無法做出准確的判斷：

• 智能客服的意圖判斷引擎是基於文本的，而現有的語音轉文本技術的字錯誤率基本上高於10%，特別是對於一些環境噪音比較大的電話語音數據，ASR識別錯誤會比較大地影響單輪問題識別模型的准確率。
• 用戶的表達能力差異化。部份用戶難以一次性地准確，完整地描述他（她）的意圖，信息量的不足會使得單輪問題識別模型的識別困難。
• 即在有很人性化的引導語的情況下，現有系統的統計數據證明仍然有相當大比例的用戶（約30%）在面對機器人客服時仍然以“喂”，“你好”等傳統對話方式開始交互， 而不會按系統引導語的提示來描述意圖，導致無效描述。

 

我們訓練了3個DNN，它們之間互相協作來完成整個問題識別流程：

1. 單輪交互問題識別模型：以用戶的初始問題描述（如“我的支付寶賬號登錄不上去了”）為輸入執行分類任務，分類目標是1000個業務問題。
2. 多輪交互問題識別模型：以與用戶的全部對話數據（如“用戶：我花唄開通不了啊”，“系統：您是賣家嗎”，“用戶：是的”）為輸入執行分類任務，分類目標與單輪交互問題識別模型相同，也是1000個業務問題。
3. 問題預測模型：當問題識別結果的置信分不高於設定的閥值時，系統會認為用戶描述信息量不足，問題預測模型就會從問題庫里挑選出對分類最有幫助的問題向用戶詢問，並收集用戶的回答用多輪交互問題識別模型來再次判別。

 

3. 模型介紹

 

3.1 單輪交互問題識別模型

單輪交互問題識別模型的輸入是用戶的一句話描述文本（“我的賬號被盜了”），輸出是該描述所對應的業務分類（“如何解限”）。

我們測試了feedforward neural network和RNN（plain RNN和LSTM）兩種類型的網絡，FFNN的輸入為把句子分詞后的基於詞的bag of word向量；Plain RNN與LSTM的輸入為基於詞的one-hot序列。這兩種類型網絡的各種不同配置測試結果顯示在測試集上的准確率Plain RNN與LSTM會比FFNN高約1.1%，說明用戶描述中的詞的順序對業務分類影響不大，因此從性能及訓練時間上考慮我們選擇了FFNN。通過多次實驗最終確定的結構為：2000維的輸入層à 500的線性變換層 à 500的sigmoid unit à 1000的線性變換àsoftmax輸出。更多的神經元數量，更多的層數和不同的激活函數，如RELU並未產生更好的效果。

支付寶以前的IVR流程中有讓用戶在電話里先描述問題，然后客服接聽電話后會打標出該通電話用戶所遇到的業務問題。我們取了幾個月的數據幾千萬條，對數據作了一些預處理：分詞及詞頻統計、停用詞表過濾、句子長度過濾等。生成的輸入所用詞表包含按詞頻排序的top 2000個詞，擴展詞表對准確率沒有幫助。清洗完剩下有效描述文本幾百萬條。

 

3.2 多輪交互問題識別模型

多輪交互問題識別模型的輸入是與用戶的全部對話內容（如“用戶：我花唄開通不了啊”，“系統：您是賣家嗎”，“用戶：是的”），輸出是該段對話所對應的業務分類（“商家怎么開通螞蟻花唄”）。

對序列建模的自然選擇是LSTM，我們構建了包含256個cell的LSTM網絡。把訓練數據中，客服與用戶的所有話拼接在一起形成一個長句，以詞的one-hot序列作為LSTM的輸入。

拉取客服與用戶的380萬通電話錄音轉成文本，這些電話在接聽后被客服人員標注了所對應的業務類別，因此天然就是多輪的訓練語料，通過BPTT可以訓練出LSTM網絡用於擬合這些實際發生的對話數據所對應的業務類別的分布。

 

3.3 問題預測模型

問題預測模型的輸入也是用戶的全部對話內容，它的輸出是預先定義的問題庫中的某一個問題。問題庫的數據來源是從幾百萬通電話錄音中提取客服詢問用戶的問句，通過文本聚類，將同義的問句歸到同一類別，每一個問句類別形成一個典型問題，再通過人工review的方式篩選出最終的問題庫。例如：

• 余額寶的收支明細嗎?
• 余額寶轉出嗎?
• 余額寶轉入嗎?
• 大陸公司嗎?
• 大陸個人用戶嗎?
• 實名認證嗎?

問題預測的目標是挑選一個問題，這個問題如果獲得肯定的回答對分類到某個業務幫助最大。用數學建模如下：假設問題庫的問題個數為N，業務類別總數為K，令Pi=第i（i = 1 ~ N）個問題是肯定回答的概率，Tj = P(業務分類為j | P1 P2 … PN)為業務類型為j的條件概率（j = 1 ~ K），當問題i變為肯定回答時的信息增益為InfoGain(i) = Entropy(T) – Pi * Entropy(T| Pi =1) – (1- Pi)*Entropy(T| Pi =0))，要挑選出來的問題就是 i = argmax(InfoGain(i))。公式中還有一個問題是如何計算Tj = P(業務分類為j | P1 P2 … PN)，為此我們用了一個多層神經網絡FFNN來建模從N個問題的回答的分布到業務類型的分布的映射。這個模型的訓練數據也是來源於電話錄音數據，每一通電話為一個訓練數據，與之前的問題庫建立流程類似，我們從電話錄音文本中提取客服問的問題與用戶的回答，轉化成P1 P2 … PN向量，加上該通電話的業務類型標注形成了data-label的有監督訓練語料。多輪流程的交互過程就是模型預測並提出一個問題，用戶給出一個回答。根據這個問答，更新對應的問答分布(P1 P2 … PN)。根據更新后的輸入，重新計算每個問題回答改變后的信息增益，選取信息增益最大的問題，向用戶繼續提問，直到用戶意圖足夠清晰，多輪交互的LSTM網絡能夠給出高於閥值的分類目標。

 

3.4 迭代優化

在第一版單輪交互問題識別模型上線時識別准確率只有四十幾，其主要原因在於訓練語料中存在大量的噪聲，即眾多不同的客服人員對用戶描述或電話標注業務類型時存在不少錯誤或者不一致的情況。這個原因有可能是由於業務熟練程度的原因導致錯誤標注，或者因為用戶的描述本身未包含足夠的信息，或表達有誤。采用的解決辦法是：

1. 用帶噪聲的數據訓練出一個模型
2. 用模型識別一遍訓練數據，設定一個閥值找出邊界樣本
3. 根據業務詞表過濾一遍，剩下的再人工檢查修正

經過幾輪迭代后，識別准確率有很明顯的提升。除了訓練數據的預處理，我們還在智能客服語音流程里加入了反饋機制：在問題識別完成后會拿識別結果向用戶詢問系統是否准確地判斷出他（她）的問題，用戶可以表示肯定或者否定。這部份數據也會在下一個模型迭代周期中成為訓練數據的一部份。我們在工程上也建立了數據拉取à清洗àID化的自動作流程，形成了數據閉環，使得模型迭代接近全自動化。

 

4. 蟻人背后的團隊

蟻人項目涉及眾多的系統間的交互，CC、MRCP、CSIVR、ASR、TTS、Gateway、DM等。整個系統的復雜程度很高，它的成功上線離不開眾多小伙伴們的艱苦努力：感謝冷風、聖衣、良穆在和DM對接中的工作；小伙伴周躦在工程上給予的大力支持；智捷及初敏在算法及工程上的各種建設性建議；九清、弈客、心詩、婻西、佑助等在蟻人從誕生到落地運營的過程中的巨大努力；感謝坤承在模型訓練上給予的大力支持；高傑在項目初期的架構規划上的工作；感謝SPEECH小伙伴們長秦、蕭言、燕丹等的鼎力相助，以及眾多我無法一一列舉的伙伴們。