当前几个主要的Lucene中文分词器的比较

原文见：http://blog.fulin.org/2009/08/lucene_chinese_analyzer_compare.html，更多讨论请去原文处。

1. 基本介绍：

：Lucene中文分词“庖丁解牛” Paoding Analysis
：imdict智能词典所采用的智能中文分词程序
： 用 Chih-Hao Tsai 的 实现的中文分词器
：采用了特有的“正向迭代最细粒度切分算法“，多子处理器分析模式

2. 开发者及开发活跃度：

：， google code 上最后一次代码提交：2008-06-12，svn 版本号 132
：， 进入了 lucene contribute，lucene trunk 中 contrib/analyzers/smartcn/ 最后一次提交：2009-07-24，
：，google code 中 2009-08-03 （昨天），版本号 57，log为：mmseg4j-1.7 创建分支
：，google code 中 2009-07-31，版本号 41

3. 用户自定义词库：

：支持不限制个数的用户自定义词库，纯文本格式，一行一词，使用后台线程检测词库的更新，自动编译更新过的词库到二进制版本，并加载
：暂时不支持用户自定义词库。但 原版 支持。支持用户自定义 stop words
：自带sogou词库，支持名为 wordsxxx.dic， utf8文本格式的用户自定义词库，一行一词。不支持自动检测。 -Dmmseg.dic.path
： 支持api级的用户词库加载，和配置级的词库文件指定，无 BOM 的 UTF-8 编码，\r\n 分割。不支持自动检测。

4. 速度（基于官方介绍，非自己测试）

：在PIII 1G内存个人机器上，1秒 可准确分词 100万 汉字
：483.64 (字节/秒)，259517(汉字/秒)
： complex 1200kb/s左右, simple 1900kb/s左右
：具有50万字/秒的高速处理能力

5. 算法和代码复杂度

：svn src 目录一共1.3M，6个properties文件，48个java文件，6895 行。使用不用的 Knife 切不同类型的流，不算很复杂。
：词库 6.7M（这个词库是必须的），src 目录 152k，20个java文件，2399行。使用 HHMM隐马尔科夫模型，“利用大量语料库的训练来统计汉语词汇的词频和跳转概率，从而根据这些统计结果对整个汉语句子计算最似然(likelihood)的切分”
： svn src 目录一共 132k，23个java文件，2089行。 ，有点复杂。
： svn src 目录一共6.6M(词典文件也在里面)，22个java文件，4217行。多子处理器分析，跟paoding类似，歧义分析算法还没有弄明白。

6. 文档

：几乎无。代码里有一些注释，但因为实现比较复杂，读代码还是有一些难度的。
： 几乎无。 也没有详细的文档，HHMM隐马尔科夫模型的数学性太强，不太好理解。
： 是英文的，但原理比较简单。实现也比较清晰。
： 有一个pdf使用手册，里面有使用示例和配置说明。

7. 其它

：引入隐喻，设计比较合理。search 1.0 版本就用的这个。主要优势在于原生支持词库更新检测。主要劣势为作者已经不更新甚至不维护了。
：进入了 lucene trunk，原版 ictclas 在各种评测中都有不错的表现，有坚实的理论基础，不是个人山寨。缺点为暂时不支持用户词库。
： 在complex基础上实现了最多分词(max-word)，但是还不成熟，还有很多需要改进的地方。
：  针对Lucene全文检索优化的查询分析器IKQueryParser

8. 结论

个人觉得，可以在 mmseg4j 和 paoding 中选一个。关于这两个分词效果的对比，可以参考：

http://blog.chenlb.com/2009/04/mmseg4j-max-word-segment-compare-with-paoding-in-effect.html

或者自己再包装一下，将 paoding 的词库更新检测做一个单独的模块实现，然后就可以在所有基于词库的分词算法之间无缝切换了。

ps，对不同的 field 使用不同的分词器是一个可以考虑的方法。比如 tag 字段，就应该使用一个最简单的分词器，按空格分词就可以了。