知了 | 基於NLP的智慧問答推薦系統

作者簡介：苗貝貝    百度高階研發工程師

負責百度智慧運維客服平臺ChatOps，在時序資料異常檢測、文字模式識別、相似度網路等方向也有廣泛的實踐經驗。

通常，客服系統主要有兩種應答模式：機器人自動應答和人工應答。當使用者提出問題後，客服系統首先啟動機器人自動應答模式，如果使用者認為機器人推薦的結果不準確，會進一步請求進入人工問答模式，由專門的客服人員跟進答疑。

據相關機構統計，國內客服的市場規模超過千億，然而，目前機器人應答模式使用率並不高，人工客服仍然是企業使用率最高的應答模式，其原因主要包括兩點：一方面，機器人客服系統實現準確推薦比較困難：由於自然語言本身是模糊的、問題表述方式多樣、問題與答案的詞彙可能存在差異等原因，導致實現準確推薦比較困難。例如：域名轉出、域名怎麼轉出、域名轉出流程等問題其實都在諮詢域名轉出操作；又例如，百度雲虛擬主機的英文縮寫為BCH，兩種表述都可能被使用者在提問時使用。另一方面，為機器人客服系統準備知識庫比較困難。首先，為問題準備答案有比較高的技術門檻，只有具備一定經驗的客服人員才能勝任。其次，客服人員一般是根據最近使用者的提問來擴充整理知識庫的。在這個過程中，很難知道某一問題是否在知識庫中已經存在，容易導致問題的重複整理。重複整理問題不但浪費人力，還可能導致相同目標的問題在知識庫中的答案不一致，降低客服質量。

基於上述背景，本文研究了一種基於自然語言理解的客服QA推薦系統，該系統目前已應用在百度雲客服團隊，在提升百度雲使用者體驗、減輕客服壓力等方面取得了不錯的成效。

現有客服系統通常將一個Q（問題）A（答案）對看作一個文件，將整個知識庫看作一個文件庫，然後利用搜尋引擎的關鍵詞匹配技術為使用者推薦相似問題以及答案。 

該技術主要有以下缺點：

我們發現，問題中的詞彙與答案的詞彙之間常常存在比較大的差異，例如：

問題：網站無法開啟

答案：使用臨時域名訪問一下是否是使用者解析或者是域名繫結的問題，訪問報什麼錯誤，常見訪問報404，檢查一下訪問的路徑或者是路徑下是否有此檔案。訪問報502，需要客戶提供下BCH控制皮膚-網站監控和網站訪問的截圖，確認下是否是記憶體不夠用或者請求量過大導致的，如果是配置不夠用，建議客戶升級配置；如果是請求量過大導致，建議客戶確認下是否正常，可以透過FTP的weblogs目錄下的access.log日誌看下是否被攻擊，可以透過配置IP黑名單進行處理。

以上是百度雲客服部門整理的一個真實QA對。可以看出，問題和答案在詞彙上差異巨大。問題中網站無法開啟，在答案中表現為使用者解析有問題、域名繫結有問題、訪問報404、訪問報502等多種不同原因所導致的具體現象。所以，直接根據問題來查詢答案很難得到理想的結果。

此外，關於網站無法開啟還有如下提問方式：主機無法開啟網頁、官網開啟不了、無法開啟網頁等等其他真實的Q，可以看出，知識庫中的問題之間可能還存在一定的相似性。基於此特徵，如果可以在查詢問題時首先利用問題本身之間的相似度找到知識庫中相似的問題，那麼就可以透過知識庫中的相似問題找到答案，此時，知識庫需要建立問題與答案的對映關係。進一步地，如果可以找到具有同一目標的所有問題，就可以針對這些問題批次整理一個答案，在知識庫中建立問題集與答案的對映關係。那麼，當使用者的問題與某個類別的問題相似時，就能根據這類相似問題集找到目標答案。客服知識庫中問題集與答案的關係可以參見圖1。

圖1  客服知識庫中問題集與答案對映關係

因此，客服系統主要包括兩部分：知識庫管理和推薦系統，其處理流程為：

圖2  知了系統資料處理流程

在圖2中，藍色的部分對應知識庫管理系統，黃色的部分對應推薦系統。首先，我們利用歷史工單中的問題建立一個初始知識庫。推薦系統利用這個初始知識庫就可以為使用者提供服務。在提供服務的過程當中，推薦系統將使用者反饋收集起來，並根據這些反饋更新知識庫的內容，從而實現了知識庫的不斷進化。

百度雲客服團隊擁有大量歷史工單問題，為了找到具有同一目標的所有問題，可以先對歷史問題進行聚類，將相似問題聚到同一類簇，再針對問題簇中的所有問題統一準備答案，建立問題簇和答案之間的聯絡。此時，所準備的答案能夠解決類簇所代表的一整類問題。

可以採用密度聚類、層次聚類等聚類方法對大量問題進行聚類，並設定距離值為兩兩問題之間的相似度值。相似度值可以基於SimNet等自然語言處理方法來獲取。聚類完成後，每個問題都會被歸入一個類簇，然後再由客服專家對類簇進行人工檢查，嘗試將演算法生成的類簇進一步合併。這樣做是因為：對於表述不同的相似問題，例如，什麼是BCC與什麼是雲端計算伺服器，由於基礎語料的侷限性，自然語言處理方法未必能夠為它們計算出足夠高的相似度，從而導致聚類演算法不能將他們聚入同一類簇。所以，就需要透過專家經驗將這些問題聯絡起來。最終，經過聚類以及人工校驗，知識庫中所有相似的問題都被整理到同一個類簇中，然後由客服專家針對整個類簇問題整理答案。

透過聚類操作可以輔助專家實現問題的批次整理，大大降低知識生成成本。並且，相比針對單一問題整理的答案，透過問題集編寫的答案內容更充分，質量也就更好。

知識庫建立後，就可以用來回答使用者的提問了。在使用者將問題提交到系統之後，知了系統首先計算使用者問題與知識庫中所有問題的相似度，並選擇相似度值大於某閾值（我們用query_threshold代表這個閾值）的N個問題作為候選集。然後，系統獲取候選集中每個問題所屬的類簇，N個候選問題一共可以得到n（n<=N）個類簇。最終，系統將這n個類簇對應的答案返回給使用者。

為了持續最佳化推薦效果，知了系統保留了使用者的查詢結果並統計線上使用情況，同時還增加了標註反饋功能，使用者在每次查詢完畢後可以對推薦結果進行反饋。

總體來說，我們將使用者的反饋結果分為三類：

知識庫更新操作需要解決兩部分問題：

1. 對標註為A待更新狀態的類簇答案進行最佳化；

2. 將標註為Q待新增的新問題入庫。

其中，問題 1 比較簡單，透過人工方式由專家完善答案即可，而問題 2 所闡述的問題則可以透過如下描述的離線流程來處理。

首先，計算新問題與知識庫中所有問題之間的相似度，獲取相似度值大於一定閾值（我們用update_threshold代表這個閾值）的Top M個相似問題，這些問題分別屬於m（m<=M）個類簇。需要指出的是，如果知識庫中已經存在新問題所屬的類簇，但因為該類簇中的所有問題與新問題的相似度都小於query_threshold，那麼該類簇就不會被推薦。因此，update_threshold的值要比query_threshold小一些，以召回知識庫中已存在的相似類簇。倘若人工檢查確認新問題確實應當歸於m個類簇的某一個，那麼將新問題新增到該類簇的問題集即可。如果人工審查發現新問題不屬於任何召回的類簇，則該問題疑似屬於新類簇。我們將所有疑似屬於新類簇的問題集中起來，採用知識庫生成中描述的方法進行處理，就可以生成新的問題集&答案組合。

透過上述的知識庫更新流程，我們不僅解決了新問題進入知識庫的問題，還避免了對這些問題以及答案的重複整理，減少了人工開銷。

知了系統採用了問題集與答案的形式來管理QA知識庫，這種管理形式具有以下幾個優勢。

首先，在使用者提交了問題之後，推薦系統先匹配知識庫中語義相同的問題，然後展示問題所屬類簇的答案。由於一個問題類簇可以包含表述上差異很大的多個問題，匹配的準確率顯著上升，並使得推薦結果對目標答案的召回率提升到90%以上。

第二，透過對問題進行自然語言分析和聚類，知了系統大大降低了問題整理的工作量。知識庫整理的效率提升到原來的3倍以上。

第三，人工撰寫答案時不再針對單個問題，而是綜合考慮一組目標相同的問題，答案的內容更加全面，質量也更高。

最後，知了系統提供了完善的知識庫進化機制，保證了知識庫能夠緊密跟隨使用者需求與知識的變化，從而避免了推薦效果的退化。