前面說了小愛同學已經初步學會了分詞和畫詞云圖，但是在這個過程中他還是遇見了一些問題的。其中最主要的兩個問題是：正則表達式和同義詞處理。

正則表達式是要把文本中一些不規范的字符去除掉，普通字符串處理函數處理起來很麻煩，正則表達式就很方便，但小愛完全不懂這個。

[[332639]]

同義詞處理。當分詞結果中出現了“市民”和“居民”二詞時，我們肯定知道這其實表達的就是一個意思，我們需要將二者合并成一個詞語。

正則表達式雖然不懂，但網上隨便學下還是暫時能滿足需求的。真正讓小愛苦惱的是同義詞處理。

任務(Task)

人為判斷同義詞很簡單，但用程序來判斷就不簡單了。小愛想到了兩種方式：制作一個同義詞庫;計算所有詞語的相似度，將相似度高于閾值的詞語作為同義詞。

• 同義詞庫。在網上百度一番，只發現了一個哈工大的同義詞庫，滿心歡喜地點進去一看，發現頁面已經不存在了，真是欲哭無淚!小愛心想，要不自己制作一個同義詞庫?再仔細一思考其中工作量，算了，還是打消念頭吧，這種方式行不通。
• 相似度計算。小愛查詢到Python中的synonyms庫提供了計算兩個詞語相似度的方法，結果還較為靠譜，于是就準備采用此種方式了。

行動(Action)

在找了一篇幾百字的文章進行測試之后，小愛發現這種方式行得通。于是就正式開始運用于公司的文本數據了。這時，新的問題又出現了。

公司的客戶反饋數據有數十上百萬條，分詞后的詞語集合在去除停用詞之后也有幾萬個，小愛的代碼在計算相似度的時候卡住了。這個時候小愛才醒悟過來：樣本數據分詞的詞語量少，計算量自然少，但隨著詞語數量的增加，計算量也是呈指數增長的。

算了，這種方式小愛也放棄了。

小愛繼續百度查詢，發現了Word2vec庫可以通過大量訓練文本來計算詞語的相似度。但小愛把所有的文本數據進行訓練之后發現相似度結果是非常的不靠譜，想必該庫所需要的訓練樣本是非常之大。

于是，這種方式小愛也放棄了。

結果(Result)

小愛在查詢文本分析(雖然還只是最簡單的詞頻統計)相關資料時發現，NLP方向遠不是一朝一夕就可以有產出的，雖然以前也看過《數學之美》，略微了解一些，但對于志向在于機器學習的小愛來說，這ROI太不值了。

就這樣，小愛不打算繼續專研文本這一塊了，妥妥地驗證了一回從入門到放棄之路啊!