jieba-fenci 结巴分词与繁简体转换 segment

拓展阅读

DFA 算法详解

为了便于大家学习，项目开源地址如下，欢迎 fork+star 鼓励一下老马~

敏感词 sensitive-word

分词 segment

结巴分词

请参考 结巴分词原理。

结巴分词的不足

这里是针对如果使用繁简体转换，仅仅想使用分词。

那么结巴分词会有哪些不足呢？

• HMM 是一种面向未来的分词（预测），但是繁体是一种面向过去的（词组/字固定）

看似非常有用的 HMM，到了繁简体转换全部成为了鸡肋。

• 词库较大。

结巴分词是面向全体汉字分组的，所以分词的词库较大，这对于繁简体转换的词组某种程度而言是多余的。

• 前缀树算法内存占用过大

前缀树的性能相对是非常占优势的，但是内存占用较多。

可是繁简体词组一般为 2-4 个字，那么这种空间和时间的平衡能否重新界定？

比如直接存储在一个 set 中，直接截取 2、3、4 个字进行匹配，最多也就三次，而 trie-tree 也要至少两次的匹配。

如果是贪心算法，可以倒过来。从 432 开始匹配。

• 概率

结巴分词需要考虑的是一个概率问题，比如 台中 和 台、中。

到底是单字还是一个词？这个分词的结果是按照概率来的。

但是如何确定一个词到底是否是一个词，这个界定真的很模糊，除非结合这个词的上下文。

我个人觉得对于繁简体拆分，这个概率是可以牺牲的。

判断与替换的同时进行

以前的实现

以前的实现 opencc4j 的时候，主要考虑的是将各个部分拆分开，便于后期拓展和优化。

比如分词，可以采用各种不同的分词策略。

自定义分词与映射

如果采用自定义分词，其实在分词的时候，可以做到同时进行映射。

但是作用不见得很大，可以考虑下。

多线程

对于大文本，使用单线程处理，显然是一件很蠢的事情。

毕竟现在是多核的时代，java 对于多线程的支持也日渐成熟。

后期可以考虑使用多线程对大文本进行拆分，并行处理。

代价与收益

如果一个文本很短，拆分的收益反而是不如线程的上线文切换带来的消耗。

所以这里有个阈值去判断，当超过特定长度的文本，使用多线程会受益大于代价。

这个需要进行压测，实际数据说话。

参考资料

对Python中文分词模块结巴分词算法过程的理解和分析