當Elasticsearch遇見智慧客服機器人

我們主要服務的專案是MAC上的APP——Dr.cleaner以及Dr.X系列產品。

Dr.cleaner在多個國家、地區的清理類MAC APP中排名第一，日活接近百萬。

幸福的煩惱：客服

多語言、跨時區：我們的APP在國內可能還不是非常出名，它的目前的客戶基本都在海外，其中美國是主要客戶，同時也有其它國家跟地區的使用者。

數量跟不上：隨著使用者數的急劇增加，客服的數量跟不上使用者數的增長。

解決方案：客服機器人

客服機器人首要能解決產品相關的問題，其次要能解決MAC/IOS相關的技術問題，多語言的問題需要通過翻譯API翻譯成英語再嘗試給出解決方案。

任何智慧客服如果沒有足夠的知識庫支撐，即使它的演算法再強大也不行。所以我們把很多MAC相關的網站抓下來塞進我們的資料庫中。

StackExcangeApple分論壇（公開資料來源）、Apple Discussion、Mac world、WikiHow…

當使用者問題出現的時候，我們如何從文件知識庫中找出我們需要的東西？我們之前嘗試過直接使用ES，但是距離語義還是太遠了，效果並不好。

WMD也有明顯缺點，它的演算法複雜度非常高，計算速度很慢。WMD不是銀彈，即使WMD之後也可能會得到一些不太好的結果。

我們的知識庫會先經過ES過濾一層。原始的知識庫大概是幾十萬級別，如果直接用WMD計算的話速度會非常慢。ES在一定程度上保證了它的字面差得不會那麼離譜，當字面比較相近的時候它還是能匹配出一些東西。

這個是最原始的mapping，我們基於這個mapping一步步去做優化。

採用BM25之後，當一個詞的出現頻率越高，到一定的閾值之後，它的影響是非常小的。

我們做了一個實驗，修改了mapping，分別使用BM25 or TFIDF。從知識庫中隨機選取100個問題和10個回答，讓ES進行查詢，然後對比兩邊的結果。

我們一共進行了10輪，每輪會有100個回答。如上圖可見，兩個演算法的重複度大概是91%。

根據實驗得出，BM25的作用還是比較明顯的，最終我們採用了BM25去做相似度的演算法。

優化：拼寫檢查與糾錯

我們的方案：Term Suggester + Custom Analyzer

使用Term Suggester

支援直接輸入一句話：How to replace macbookk SSD？

Term Suggester自身調整

設定最小出現次數為3，修改了”string_distance”，把它改為”jarowinkler”。它預設的相似度是基於編輯距離的一些定製化，編輯距離預設會輸出整數。

增加使用者行為資料的支撐。Google的演算法很大一部分就是有使用者行為資料支撐。

“瞻前顧後”，從我們的角度來說，要考慮前後兩個詞的關係。

首先使用Gensim生成備選片語，然後使用規則過濾出比較精確的候選片語。當我們獲得一個正確的片語後，可以根據候選片語生成常見的錯誤寫法。最後再實時處理使用者輸入和批量處理ES儲存的知識庫。

規則

規則就是純英文字元，去掉數字。主要是品牌名和版本號。

WMD的計算強度比較大，如果我們在輸入詞中能把一些不重要的詞去掉，就可以降低WMD的計算強度。

在我們的一些知識庫中，它的表達方式不一樣。但重要的詞換一個表達方式，能夠提高準確率。

解決方案

當前我們的解決方案用Python NLTK進行分析過濾，輸出每個詞的詞性，ES儲存結果。

我們更為推薦的是使用ES分析、過濾、儲存一條龍解決方案，但是這種解決方案需要自己寫一個ES的Pos外掛。

效能：Java實現的東西一般來說要比純Python的快，特別是在比較消耗CPU資源的時候。

簡單：邏輯不需要在ES和Python兩邊同時維護。

節省空間：NLTK的模型檔案也比較大，多個Docker映象就意味著佔用多個記憶體、磁碟。

優化：同義詞

人為地定義同義詞很難，我們是基於Word2vec生成“同義詞”。

我們的同義詞方案是通過同義詞進行查詢改寫。

基於Machine Learning的重排序，模型按照預測的點選概率進行重新排序。

我今天的分享就到這裡，謝謝大家！