讨论 mmseg4j 的现状，与改进。

阅读更多

发布最新一个 mmseg4 （1.7.2 与 1.6.2）版，距今也有几个月了。max-word 方式还不完善，有很多需要改进的地方。由于没有个好的想法，以至几个月都没更新。mmseg4j 项目也受到一些的关注，十分有必要改进。这贴说明下 mmseg4 的现状和 todo 功能，同时希望 javaeyer 们给予些建议或想法。

 

字符的处理：先断开不同类型的字符，断开的成为一个“句子”（类：Sentence）。

• 英文、俄文、希腊、数字、其它数字（如：①⑩㈠㈩⒈⒑⒒⒛⑴⑽⑾⒇），分出连续同类型字符。如：mmseg4j 会分出 mmseg，4，j 三个词。改进：英文开头的英文与数据混的应该不分开。
• LETTER_NUMBER （如：ⅠⅡⅢ）单字分。
• OTHER_LETTER 类型的字符（基本就是 cjk），会用 mmseg 算法分词。
• 数字后面是 units.dic 文件出现的字，会单分。主要考虑单位字，改进：单位应该支持词，而不是单个字。
• 除了上面的字符类型的字符都会被忽视。比如符号： ★∑。

 Simple 方式就没什么好说和改进的了。Complex 方式的一个缺点：“都是先从容易的做起” 分为 “都是 | 先 | 从容 | 易 | 的 | 做起”，“容易”分不出来（“从”的频率高于“易”，因此分出“容易”更合理）。是由于mmseg 算法用3个chunk来比较那个更合理，“容易”已经是第4个 chunk了，所以无法参与比较。我曾经想过用一句话比较这些频率信息（要改进吗？），当然要更多的开销。mmseg 作者选3个可能是效果与性能平衡吧。

 

max-word 方式，是我在 Complex 基础上加了一个分词方式。就是把 complex 分出的词再柝出其它词。目前用 max-word 方式分出的词的长度不会超过2。

 

有人词为什么是不超过2？

考虑到很多长词基本都是由 2-3 个字的词组成的。又考虑到类似"咖啡" 能找到 “咖啡厅”，所以草率地决定词长最长为2。

假设："咖啡" 和 “咖啡厅” 在词库中，max-word 方式分为 "咖啡 | 厅"，"咖啡" 和 “咖啡厅” 搜索时（默认Lucene 的 QueryParser 解析出来的 “短语查询”）都可以找到 “咖啡厅”。

 

当然还考虑到complex 分出长度 >= 4的情况，以这种方式也比较好处理。

 

有一些情况不顺眼的：“为什么” 分成 "为 | 什么"。

 

个人觉得：C1C2C3 只有 C1C2 和 C2C3 是词才分出 C1C2 和 C2C3 其它情况应该不再柝分 C1C2C3 了。

 

大部分的搜索应用场景用 max-word 方式的效果都会比 simple 和 complex 要好。之前我喜欢 paoding 的主要理由也是这个。

 

关于 max-word 方面的确没有更好的想法，还希望各位出出主意。

 

要 todo 的功能：

• 默认的词库目录应该在 classpath 下data目录。目前是在 user.dir 下data目录（这样使用 mmseg4j 有些麻烦，之前主要考虑在 solr 中使用方便）。
• 自动检测词库目录，并自动加载。看了：当前几个主要的Lucene中文分词器的比较
• 整理词库 -  好的词库也会影响分词效果，去除 sogou 的高频无用的词（比如：我们的）。再丰富下词库。
• 上面提到的改进？
• 提供添加词库的 api ？
• 需要有繁体转简体？