作者簡介
苗貝貝 百度高級研發工程師
負責百度智能運維客服平臺ChatOps，在時序數據異常檢測、文本模式識別、相似度網絡等方向也有廣泛的實踐經驗。
乾貨概覽
通常，客服系統主要有兩種應答模式：機器人自動應答和人工應答。當用戶提出問題後，客服系統首先啓動機器人自動應答模式，如果用戶認爲機器人推薦的結果不準確，會進一步請求進入人工問答模式，由專門的客服人員跟進答疑。
據相關機構統計，國內客服的市場規模超過千億，然而，目前機器人應答模式使用率並不高，人工客服仍然是企業使用率最高的應答模式，其原因主要包括兩點：一方面，機器人客服系統實現準確推薦比較困難：由於自然語言本身是模糊的、問題表述方式多樣、問題與答案的詞彙可能存在差異等原因，導致實現準確推薦比較困難。例如：域名轉出、域名怎麼轉出、域名轉出流程等問題其實都在諮詢域名轉出操作；又例如，百度雲虛擬主機的英文縮寫爲BCH，兩種表述都可能被用戶在提問時使用。另一方面，爲機器人客服系統準備知識庫比較困難。首先，爲問題準備答案有比較高的技術門檻，只有具備一定經驗的客服人員才能勝任。其次，客服人員一般是根據最近用戶的提問來擴充整理知識庫的。在這個過程中，很難知道某一問題是否在知識庫中已經存在，容易導致問題的重複整理。重複整理問題不但浪費人力，還可能導致相同目標的問題在知識庫中的答案不一致，降低客服質量。
基於上述背景，本文研究了一種基於自然語言理解的客服QA推薦系統，該系統目前已應用在百度雲客服團隊，在提升百度雲用戶體驗、減輕客服壓力等方面取得了不錯的成效。
現有技術及其缺點
現有客服系統通常將一個Q（問題）A（答案）對看作一個文檔，將整個知識庫看作一個文檔庫，然後利用搜索引擎的關鍵詞匹配技術爲用戶推薦相似問題以及答案。
該技術主要有以下缺點：
關鍵詞匹配技術不擅長處理用戶在問題表述上的差異，無法將用戶問題與知識庫中的QA對進行有效匹配，導致推薦結果不理想。
在整理知識庫時，無法將目標相同的問題聚集起來統一整理，從而導致
整理工作量大，耗時長；
答案只針對單個問題，使得內容侷限，質量較低；
相似問題分別整理，答案很容易不一致，容易導致用戶困惑。
問題分析
我們發現，問題中的詞彙與答案的詞彙之間常常存在比較大的差異，例如：
問題：網站無法打開
答案：使用臨時域名訪問一下是否是用戶解析或者是域名綁定的問題，訪問報什麼錯誤，常見訪問報404，檢查一下訪問的路徑或者是路徑下是否有此文件。訪問報502，需要客戶提供下BCH控制面板-網站監控和網站訪問的截圖，確認下是否是內存不夠用或者請求量過大導致的，如果是配置不夠用，建議客戶升級配置；如果是請求量過大導致，建議客戶確認下是否正常，可以通過FTP的weblogs目錄下的access.log日誌看下是否被攻擊，可以通過配置IP黑名單進行處理。
以上是百度雲客服部門整理的一個真實QA對。可以看出，問題和答案在詞彙上差異巨大。問題中網站無法打開，在答案中表現爲用戶解析有問題、域名綁定有問題、訪問報404、訪問報502等多種不同原因所導致的具體現象。所以，直接根據問題來查找答案很難得到理想的結果。
此外，關於網站無法打開還有如下提問方式：主機無法打開網頁、官網打開不了、無法打開網頁等等其他真實的Q，可以看出，知識庫中的問題之間可能還存在一定的相似性。基於此特徵，如果可以在查詢問題時首先利用問題本身之間的相似度找到知識庫中相似的問題，那麼就可以通過知識庫中的相似問題找到答案，此時，知識庫需要建立問題與答案的映射關係。進一步地，如果可以找到具有同一目標的所有問題，就可以針對這些問題批量整理一個答案，在知識庫中建立問題集與答案的映射關係。那麼，當用戶的問題與某個類別的問題相似時，就能根據這類相似問題集找到目標答案。客服知識庫中問題集與答案的關係可以參見圖1。
圖1 客服知識庫中問題集與答案映射關係
因此，客服系統主要包括兩部分：知識庫管理和推薦系統，其處理流程爲：
圖2 知了系統數據處理流程
在圖2中，藍色的部分對應知識庫管理系統，黃色的部分對應推薦系統。首先，我們利用歷史工單中的問題建立一個初始知識庫。推薦系統利用這個初始知識庫就可以爲用戶提供服務。在提供服務的過程當中，推薦系統將用戶反饋收集起來，並根據這些反饋更新知識庫的內容，從而實現了知識庫的不斷進化。
智能客服系統介紹
1
知識庫生成
百度雲客服團隊擁有大量歷史工單問題，爲了找到具有同一目標的所有問題，可以先對歷史問題進行聚類，將相似問題聚到同一類簇，再針對問題簇中的所有問題統一準備答案，建立問題簇和答案之間的聯繫。此時，所準備的答案能夠解決類簇所代表的一整類問題。
可以採用密度聚類、層次聚類等聚類方法對大量問題進行聚類，並設置距離值爲兩兩問題之間的相似度值。相似度值可以基於SimNet等自然語言處理方法來獲取。聚類完成後，每個問題都會被歸入一個類簇，然後再由客服專家對類簇進行人工檢查，嘗試將算法生成的類簇進一步合併。這樣做是因爲：對於表述不同的相似問題，例如，什麼是BCC與什麼是雲計算服務器，由於基礎語料的侷限性，自然語言處理方法未必能夠爲它們計算出足夠高的相似度，從而導致聚類算法不能將他們聚入同一類簇。所以，就需要通過專家經驗將這些問題聯繫起來。最終，經過聚類以及人工校驗，知識庫中所有相似的問題都被整理到同一個類簇中，然後由客服專家針對整個類簇問題整理答案。
通過聚類操作可以輔助專家實現問題的批量整理，大大降低知識生成成本。並且，相比針對單一問題整理的答案，通過問題集編寫的答案內容更充分，質量也就更好。
2
推薦系統
知識庫建立後，就可以用來回答用戶的提問了。在用戶將問題提交到系統之後，知了系統首先計算用戶問題與知識庫中所有問題的相似度，並選擇相似度值大於某閾值（我們用query_threshold代表這個閾值）的N個問題作爲候選集。然後，系統獲取候選集中每個問題所屬的類簇，N個候選問題一共可以得到n（n<=N）個類簇。最終，系統將這n個類簇對應的答案返回給用戶。
爲了持續優化推薦效果，知了系統保留了用戶的查詢結果並統計線上使用情況，同時還增加了標註反饋功能，用戶在每次查詢完畢後可以對推薦結果進行反饋。
總體來說，我們將用戶的反饋結果分爲三類：
已解決：用戶認爲推薦結果準確，所查詢問題得到了有效解答；
A待更新：用戶認爲所推薦的答案不夠準確，但在一定程度上有助於解決問題，後續對答案進行優化就能夠進一步提高推薦效果；
Q待添加：查詢結果爲空，或者用戶認爲所推薦內容與自己的問題沒有關係。這說明知識庫很有可能尚未覆蓋到這個用戶問題，因此係統會自動把這個問題記錄在案，後續通過知識庫更新的流程將問題添加到知識庫中。
3
知識庫更新
知識庫更新操作需要解決兩部分問題：
對標註爲A待更新狀態的類簇答案進行優化；
將標註爲Q待添加的新問題入庫。
其中，問題 1 比較簡單，通過人工方式由專家完善答案即可，而問題 2 所闡述的問題則可以通過如下描述的離線流程來處理。
首先，計算新問題與知識庫中所有問題之間的相似度，獲取相似度值大於一定閾值（我們用update_threshold代表這個閾值）的Top M個相似問題，這些問題分別屬於m（m<=M）個類簇。需要指出的是，如果知識庫中已經存在新問題所屬的類簇，但因爲該類簇中的所有問題與新問題的相似度都小於query_threshold，那麼該類簇就不會被推薦。因此，update_threshold的值要比query_threshold小一些，以召回知識庫中已存在的相似類簇。倘若人工檢查確認新問題確實應當歸於m個類簇的某一個，那麼將新問題添加到該類簇的問題集即可。如果人工審查發現新問題不屬於任何召回的類簇，則該問題疑似屬於新類簇。我們將所有疑似屬於新類簇的問題集中起來，採用知識庫生成中描述的方法進行處理，就可以生成新的問題集&答案組合。
通過上述的知識庫更新流程，我們不僅解決了新問題進入知識庫的問題，還避免了對這些問題以及答案的重複整理，減少了人工開銷。
總 結
知了系統採用了問題集與答案的形式來管理QA知識庫，這種管理形式具有以下幾個優勢。
首先，在用戶提交了問題之後，推薦系統先匹配知識庫中語義相同的問題，然後展示問題所屬類簇的答案。由於一個問題類簇可以包含表述上差異很大的多個問題，匹配的準確率顯著上升，並使得推薦結果對目標答案的召回率提升到90%以上。
第二，通過對問題進行自然語言分析和聚類，知了系統大大降低了問題整理的工作量。知識庫整理的效率提升到原來的3倍以上。
第三，人工撰寫答案時不再針對單個問題，而是綜合考慮一組目標相同的問題，答案的內容更加全面，質量也更高。
最後，知了系統提供了完善的知識庫進化機制，保證了知識庫能夠緊密跟隨用戶需求與知識的變化，從而避免了推薦效果的退化。
溫馨提示
如果你喜歡本文，請分享到朋友圈，想要獲得更多信息，請關注我們！
如果你有任何問題歡迎留言諮詢~
如果想試用我們的企業級運維平臺NoahEE，請聯繫郵箱：[email protected]
RECOMMEND
推薦閱讀
↓↓↓ 點擊"閱讀原文" 【瞭解更多精彩內容】