前面说了小爱同学已经初步学会了分词和画词云图，但是在这个过程中他还是遇见了一些问题的。其中最主要的两个问题是：正则表达式和同义词处理。
正则表达式是要把文本中一些不规范的字符去除掉，普通字符串处理函数处理起来很麻烦，正则表达式就很方便，但小爱完全不懂这个。
同义词处理。当分词结果中出现了“市民”和“居民”二词时，我们肯定知道这其实表达的就是一个意思，我们需要将二者合并成一个词语。
正则表达式虽然不懂，但网上随便学下还是暂时能满足需求的。真正让小爱苦恼的是同义词处理。
任务(Task)
人为判断同义词很简单，但用程序来判断就不简单了。小爱想到了两种方式：制作一个同义词库;计算所有词语的相似度，将相似度高于阈值的词语作为同义词。
- 同义词库。在网上百度一番，只发现了一个哈工大的同义词库，满心欢喜地点进去一看，发现页面已经不存在了，真是欲哭无泪!小爱心想，要不自己制作一个同义词库?再仔细一思考其中工作量，算了，还是打消念头吧，这种方式行不通。
- 相似度计算。小爱查询到Python中的synonyms库提供了计算两个词语相似度的方法，结果还较为靠谱，于是就准备采用此种方式了。
行动(Action)
在找了一篇几百字的文章进行测试之后，小爱发现这种方式行得通。于是就正式开始运用于公司的文本数据了。这时，新的问题又出现了。
公司的客户反馈数据有数十上百万条，分词后的词语集合在去除停用词之后也有几万个，小爱的代码在计算相似度的时候卡住了。这个时候小爱才醒悟过来：样本数据分词的词语量少，计算量自然少，但随着词语数量的增加，计算量也是呈指数增长的。
算了，这种方式小爱也放弃了。
小爱继续百度查询，发现了Word2vec库可以通过大量训练文本来计算词语的相似度。但小爱把所有的文本数据进行训练之后发现相似度结果是非常的不靠谱，想必该库所需要的训练样本是非常之大。
于是，这种方式小爱也放弃了。
结果(Result)
小爱在查询文本分析(虽然还只是最简单的词频统计)相关资料时发现，NLP方向远不是一朝一夕就可以有产出的，虽然以前也看过《数学之美》，略微了解一些，但对于志向在于机器学习的小爱来说，这ROI太不值了。
就这样，小爱不打算继续专研文本这一块了，妥妥地验证了一回从入门到放弃之路啊!
