讨论 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 ？
• 需要有繁体转简体？

 

 

 

JavaEye目前用的是solo写的mmseg分词算法，这个实现中没有max-word方式，我们采用了他默认的complex方式，对于JavaEye这种技术类型的网站来说，我们觉得mmseg complex实际效果已经令人满意了。

它词库用的和你在mmseg4j提供的不一样，几乎没有长词，以你在文章中提到的“咖啡厅”为例子，它词库中并没有这个词，只有“咖啡”，所以用complex方式也是分为 "咖啡 | 厅"，用"咖啡" 和 “咖啡厅” 搜索时也都可以找到 “咖啡厅”。

关于词库的问题，这是我之前和你站内短信沟通过的，重贴出来：


我觉得如果整理词库，去掉这些长词，直接用complex也会有很好的效果。

关于非中文字符，我觉得不应该包含在mmseg4j的核心功能中，可以实现一个独立的Lucene的filter，将非汉字（你文章中提到的英文/罗马字符/中文符号等）交给standard tokenizer处理，只有汉字才给mmseg4j处理。

疑问：

能否举个实际的例子来说明max-word比complex好？

另外，最大匹配算法的扫描方向如果能够支持反向，对分词的精确度会有非常大提高，以常拿来作分词例子的句子“研究生命科学”为例，如果能够支持反向，那么用simple算法也能够正确分出“研究|生命|科学"，不过我对于Lucene的内部机制不是很了解，据说Lucene拿到的是文本流，只能作正向？

主要也是因为词库中长词问题。还有支持自定义词库，很可能是用户自己添加地名、机构名等。

整理词库十分有必要。



Lucene 是用 Reader。如果工反向只能读完一个句子再分析。



这建议倒可以尝试下，不过目前也是只有汉字才给 mmseg4j 的核心功能处理（mmseg 算法），其它字符都是在 mmseg 分词前处理。