本次分享主要會介紹一下ES是如何幫我們完成NLP的任務的。在做NLP相關任務的時候，ES的相似度算法並不足以支撐用戶的搜索，需要使用一些與語義相關的方法進行改進。但是ES的很多特性對我們優化搜索體驗是非常有幫助的。
簡介-Dr.cleaner/Dr.X系列產品
我們主要服務的項目是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在一定程度上保證了它的字面差得不會那么離譜，當字面比較相近的時候它還是能匹配出一些東西。
ES具體操作
這個是最原始的mapping，我們基於這個mapping一步步去做優化。
優化：BM25 or TFIDF
采用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存儲的知識庫。
規則
規則就是純英文字符，去掉數字。主要是品牌名和版本號。
POS Tagging + 詞性過濾
WHY?
WMD的計算強度比較大，如果我們在輸入詞中能把一些不重要的詞去掉，就可以降低WMD的計算強度。
在我們的一些知識庫中，它的表達方式不一樣。但重要的詞換一個表達方式，能夠提高准確率。
解決方案
當前我們的解決方案用Python NLTK進行分析過濾，輸出每個詞的詞性，ES存儲結果。
我們更為推薦的是使用ES分析、過濾、存儲一條龍解決方案，但是這種解決方案需要自己寫一個ES的Pos插件。
推薦方案的優點
性能：Java實現的東西一般來說要比純Python的快，特別是在比較消耗CPU資源的時候。
簡單：邏輯不需要在ES和Python兩邊同時維護。
節省空間：NLTK的模型文件也比較大，多個Docker鏡像就意味着占用多個內存、磁盤。
優化：同義詞
基於Word2vec的同義詞
人為地定義同義詞很難，我們是基於Word2vec生成“同義詞”。
查詢改寫方案
我們的同義詞方案是通過同義詞進行查詢改寫。
其它一些優化
LTR：Learning to Rank
基於Machine Learning的重排序，模型按照預測的點擊概率進行重新排序。
原文鏈接：https://cloud.tencent.com/developer/article/1083908