<转>用于Lucene的各中文分词比较
对几种中文分析器，从分词准确性和效率两方面进行比较。分析器依次为：StandardAnalyzer、ChineseAnalyzer、CJKAnalyzer、IK_CAnalyzer、MIK_CAnalyzer、MMAnalyzer（JE分词）、PaodingAnalyzer。
单纯的中文分词的实现一般为按字索引或者按词索引。按字索引顾名思义，就是按单个字建立索引。按词索引就是按词喽，根据词库中的词，将文字进行切分。车东的交叉双字分割或者叫二元分词我觉得应该算是按字索引的改进，应该还是属于字索引的范畴吧。
分词准确性的评估比较难，很难有统一的标准，不同应用的要求也不同，这个统一以“2008年8月8日晚，举世瞩目的北京第二十九届奥林匹克运动会开幕式在国家体育场隆重举行。”为例说明。
分词效率，统一使用《射雕英雄传》的全文文本为例说明。呵呵。对于按词索引的分析器，使用统一的基本词库，词汇量为227,719个。在开发环境下运行，性能不准确，但可比较相对值。
?
?
分析器：
?
StandardAnalyzer
Lucene自带的标准分析器。
?
ChineseAnalyzer
Lucene contrib中附带的分析器，与StandardAnalyzer类似。注意是类似啊，还是有区别的。
?
CJKAnalyzer
Lucene contrib中附带的二元分词
按词
IK_CAnalyzer、MIK_CAnalyzer
http://lucene-group.group.javaeye.com/group/blog/165287。使用版本为2.0.2
?
MMAnalyzer
现在能找到的最新版本是1.5.3。不过在原始网站已经找不到下载了，而且据说声明为不提供维护和支持。因为谈论的人比较多，所以列出来。但在使用中感觉不太稳定。
?
PaodingAnalyzer
庖丁解牛。http://code.google.com/p/paoding/downloads/list。使用版本为2.0.4beta。
?
?? 分词准确性：
?
2008/年/8/月/8/日/晚/举/世/瞩/目/的/北/京/第/二/十/九/届/奥/林/匹/克/运/动/会/开/幕/式/在/国/家/体/育/场/隆/重/举/行/
一元分词，没什么好说的。
ChineseAnalyzer
年/月/日/晚/举/世/瞩/目/的/北/京/第/二/十/九/届/奥/林/匹/克/运/动/会/开/幕/式/在/国/家/体/育/场/隆/重/举/行/
还是有区别吧，这是因为ChineseAnalyzer只对Character.LOWERCASE_LETTER、Character.UPPERCASE_LETTER、和Character.OTHER_LETTER进行了处理，其他类型的都滤掉了。具体可以参见代码。
CJKAnalyzer
2008/年/8/月/8/日晚/举世/世瞩/瞩目/目的/的北/北京/京第/第二/二十/十九/九届/届奥/奥林/林匹/匹克/克运/运动/动会/会开/开幕/幕式/式在/在国/国家/家体/体育/育场/场隆/隆重/重举/举行/
二元分词，作为一元分词的改进，建立的索引小于一元，查询效率较好，能满足一般的查询要求。
PaodingAnalyzer
2008/年/8/月/8/日/晚/举世/瞩目/举世瞩目/目的/北京/二/第二/十/二十/第二十/九/十九/二十九/九届/奥林/奥林匹克/运动/运动会/奥林匹克运动会/开幕/开幕式/国家/体育/体育场/隆重/举行/隆重举行/
细粒度全切分。对于不在词典中的词进行二元分词。
IK_CAnalyzer
2008年/2008/年/8月/8/月/8日/8/晚/举世瞩目/举世/瞩目/目的/北京/第二十九届/第二十九/第二十/第二/二十九/二十/十九/九届/九/奥林匹克运动会/奥林匹克/奥林/运动会/运动/开幕式/开幕/在国/国家/国/体育场/体育/隆重举行/隆重/举行/行/
细粒度全切分。对于不在词典中的词进行二元分词。
MIK_CAnalyzer
2008年/8月/8日/晚/举世瞩目/目的/北京/第二十九届/奥林匹克运动会/开幕式/在国/国家/体育场/隆重举行/
最大匹配分词。和细粒度全切分配合使用。
MMAnalyzer
2008/年/8/月/8/日/晚/举世瞩目/北京/第二十/九届/奥林匹克运动会/开幕式/国家/体育场/隆重举行/
对于不在字典项的内容，进行一元分词。
?
?
分词性能（毫秒）：
?
分析器
第一次
第二次
第三次
分词数
StandardAnalyzer
243
246
241
767675
ChineseAnalyzer
245
233
242
766298
CJKAnalyzer
383
383
373
659264
PaodingAnalyzer
927
899
909
482890
IK_CAnalyzer
1842
1877
1855
530830
MIK_CAnalyzer
2009
1978
1998
371013
MMAnalyzer
2923
2933
2948
392521
需要说明的是，IK_CAnalyzer在性能上对于词典的敏感度较高。
总结：
对于一般性的应用，采用二元分词法应该就可以满足需求。如果需要分词的话，从分词效果、性能、扩展性、还是可维护性来综合考虑，建议使用庖丁解牛。
?
?
mmseg4j 多分词模式与 paoding 分词效果对比发表于：2009年4月12日?| 分类：mmseg4j?| 标签：?mmseg4j,?paoding,?中文分词?|?views(6,709)版权信息: 可以任意转载, 转载时请务必以超链接形式标明文章原文出处, 即下面的声明.
?
原文出处：http://blog.chenlb.com/2009/04/mmseg4j-max-word-segment-compare-with-paoding-in-effect.html
mmseg4j 1.6支持最多分词，应网友的要求：分词效果与 paoding 对比下。观察了 paoding 部分分词结果，现总结下。
paoding 分词效果：
mmseg4j maxword 分词效果：
paoding 几乎把所有的子词都拆出来，有时候还有最长的词，还没搞懂“华南理工大学”会分出“大”；mmseg4j 的 maxword 是在 complex分词后的结果再把子词都拆出来（1.6版按二元，不是词的去掉或保存单字。下一版本可能方式有点不同，“为什么”不应该为“为|什么”，也即是三个字的前后不是词的应该不分，有待研究，:)）。
如“化装和服装” mmseg4j 的 complex是可以较好的分出来（“化装 | 和 | 服装”），而 paoding 少了字频的信息，比较难到这事。mmseg4j complex 也有个缺点：“都是先从容易的做起” 不能把“容易”分出来，这是因为 mmseg 算法是用 3 个chunk的原因，我认为把整句的 chunk （还是仅仅3个chunk）来处理的话，分词效果要好），当然要更多的开销，选3个可能是效果与性能平衡吧。
mmseg4j 没有加任何 stopword，这东西留给使用者自己加，因为我不认为加 stopword 是好的方法。如音乐搜索，给加上 the,this……，还能找到歌曲？
当然分词效果还与词库有关，sogou 的词库是统计得出，有些高频的单字组合也成了词，如“我们的”。如果还要提高 mmseg4j 的分词效果，还要在整理下词库。
?
?
当前几个主要的Lucene中文分词器的比较作者：唐福林 来源：福林雨 博客 ?酷勤网收集 2009-08-04
1. 基本介绍：
paoding?：Lucene中文分词“庖丁解牛” Paoding Analysis
imdict?：imdict智能词典所采用的智能中文分词程序
mmseg4j?： 用 Chih-Hao Tsai 的?MMSeg 算法?实现的中文分词器
ik?：采用了特有的“正向迭代最细粒度切分算法“，多子处理器分析模式
2. 开发者及开发活跃度：
paoding?：qieqie.wang， google code 上最后一次代码提交：2008-06-12，svn 版本号 132
imdict?：XiaoPingGao， 进入了 lucene contribute，lucene trunk 中 contrib/analyzers/smartcn/ 最后一次提交：2009-07-24，
mmseg4j?：chenlb2008，google code 中 2009-08-03 （昨天），版本号 57，log为：mmseg4j-1.7 创建分支
ik?：linliangyi2005，google code 中 2009-07-31，版本号 41
3. 用户自定义词库：
paoding?：支持不限制个数的用户自定义词库，纯文本格式，一行一词，使用后台线程检测词库的更新，自动编译更新过的词库到二进制版本，并加载
imdict?：暂时不支持用户自定义词库。但 原版?ICTCLAS?支持。支持用户自定义 stop words
mmseg4j?：自带sogou词库，支持名为 wordsxxx.dic， utf8文本格式的用户自定义词库，一行一词。不支持自动检测。 -Dmmseg.dic.path
ik?： 支持api级的用户词库加载，和配置级的词库文件指定，无 BOM 的 UTF-8 编码，/r/n 分割。不支持自动检测。
4. 速度（基于官方介绍，非自己测试）
paoding?：在PIII 1G内存个人机器上，1秒 可准确分词 100万 汉字
imdict?：483.64 (字节/秒)，259517(汉字/秒)
mmseg4j?： complex 1200kb/s左右, simple 1900kb/s左右
ik?：具有50万字/秒的高速处理能力
5. 算法和代码复杂度
paoding?：svn src 目录一共1.3M，6个properties文件，48个java文件，6895 行。使用不用的 Knife 切不同类型的流，不算很复杂。
imdict?：词库 6.7M（这个词库是必须的），src 目录 152k，20个java文件，2399行。使用?ICTCLAS?HHMM隐马尔科夫模型，“利用大量语料库的训练来统计汉语词汇的词频和跳转概率，从而根据这些统计结果对整个汉语句子计算最似然(likelihood)的切分”
mmseg4j?： svn src 目录一共 132k，23个java文件，2089行。MMSeg 算法?，有点复杂。
ik?： svn src 目录一共6.6M(词典文件也在里面)，22个java文件，4217行。多子处理器分析，跟paoding类似，歧义分析算法还没有弄明白。
6. 文档
paoding?：几乎无。代码里有一些注释，但因为实现比较复杂，读代码还是有一些难度的。
imdict?： 几乎无。?ICTCLAS?也没有详细的文档，HHMM隐马尔科夫模型的数学性太强，不太好理解。
mmseg4j?：?MMSeg 算法?是英文的，但原理比较简单。实现也比较清晰。
ik?： 有一个pdf使用手册，里面有使用示例和配置说明。
7. 其它
paoding?：引入隐喻，设计比较合理。search 1.0 版本就用的这个。主要优势在于原生支持词库更新检测。主要劣势为作者已经不更新甚至不维护了。
imdict?：进入了 lucene trunk，原版 ictclas 在各种评测中都有不错的表现，有坚实的理论基础，不是个人山寨。缺点为暂时不支持用户词库。
mmseg4j?： 在complex基础上实现了最多分词(max-word)，但是还不成熟，还有很多需要改进的地方。
ik?：? 针对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 字段，就应该使用一个最简单的分词器，按空格分词就可以了。
?
原链：http://blog.csdn.net/chaocy/article/details/5938741
