从搜索引擎的角度看中文分词算法

核心：
从应用的角度看中文分词算法，是用于搜索引擎，或者智能识别语义等？应用的不同影响着中文分词的策略选择。

正文：
建立索引或对用户输入的句子分词时，当遇到"XxYyvZz "(每个字母代表一个汉字)这样一个句子时，
如果Xx和Zz是已经收录在词库中的词汇，而Y,y,v,Yy,yv,Yyv均不是词库的词汇，
分词器应该如何处理Yyv这个非词汇组成的孤立串呢？可能的处理情况有：
1、二元分词：Yy/yv
2、单字分词：Y/y/v
3、混合分词：Y/Yy/yv/v
4、不分分词：Yyv
5、通过上下文进行词频统计进行判断
6、根据历史智能学习，根据学习结果判断

比如假设Y=黄，y=西，v=来，那么Yyv就是"黄西来"，对应的分词就是：
1、黄西/西来
2、黄/西/来
3、黄/黄西/西来/来
4、黄西来
5、不定结果
6、不定结果

首先，第5、6种情况应该首先被排除！理由如下：

通过上下文环境词频的统计进行判断，意味着不同的文章，该孤立字符串可能有不同的切分方法。
假设文章1采用Y/yv，文章2采用Yy/v，文章3采用Yyv.
当用户在输入框中仅仅输入Yyv三个字或还有少量的其他字时，
若采用方法5，则因为缺少足够上下文环境用于统计词频，几乎只会产生某一种分词结果。假设就分为了Yyv，那么，文章3可以被检索出来，而文章1和2则永远也不会检索出来！
若采用方法6，则以前被切分为Y/yv，因为自学习后，现在被切为Yyv，那么将导致以前的文章永远不会再被检索出来，除非重新建立索引。
所以方法5、6看起来美丽动人，但在搜索领域里不是很可行。

由这一点展开的，我有2个有反很多人“想法”的结论：

1、为搜索引擎服务的中文分词组件，不能具有上下文词频的功能，否则是不可用的。
2、为搜索引擎提服务的中文分词组件，不能具有自学习的功能，否则是不可用的。
相反，作为为搜索引擎服务的中文分词组件，不是为了智能理解中文，而是为了良好地为用户提供良好的检索体验
要具有良好的检索体验，我认为应该在满足以下3条原则，并取得平衡：
a、索引建立要尽量快(和分词组件密切有关)，检索速度要快(和分词组件关系较疏但亦有关系，先略过不述)
b、用户想要的目标文章不要因为中文分词组件分词的原因被永远派出在检索结果之外(以上的例子违反了这一条，所以被首先排除出我的考虑范围)
c、不要让用户想要的文章淹没在不想要的文章中。

说完以上的一些我个人的看法，我继续讨论Yyv的问题。

paoding曾经采用过第3种方法，但是因认为分出的词语过多，目前2.0.4-alpha2采用的是第1种方法，但自己也一直都在挣扎当中，
今天我似乎能得出一个结论，paoding目前的做法并不好，目前的这种做法可能会违反以上的b原则。

因为XxYyvZz被分成Xx/Yy/yv/Zz后，那么当用以XxY作为输入条件检索文章时，特别是作为短语查询时，XxYyvZz就不会被检索出来：
作为检索条件 XxY 会被paoding-2.0.4-alpha2分成Xx/Y，当使用QueryParser构造Query对象时，因为XxYyvZz的分词结果不满足同时存在这两个Term：Xx和Y，从而被忽略，违反了b原则。
而2.0.4之前采用做法3做法，虽然分出的词语过多，但却能够被检索出，其符合b原则。
(感慨：QueryParser真是个好东西，可用来测试分词组件的到底具不具有正确性)

作为paoding分词的作者，经过了持续的一段时间思考，现在本人比较倾向于使用第2种分词方式，认为它应是最适合的：1、符合b原则：将XxYyvZz分成 Xx/Y/y/v/Zz，这样当用户输入XxY时，XxY会被切成Xx/Y，XxYyvZz符合了：a)同时具有Xx,Y两个term，b)且在分词排序上是近邻且顺序和用户输入一致。
(对Lucene的QueryParser来说，当输入没有分隔的汉字时，QueryParser会调用Analyzer对它进行分词，并理解短语处理)
2、符合c原则：用户以XxY作为输入条件，不会将XxZzYyv的文章检索出来，虽然他可能被分为Xx/Zz/Y/y/v：因为该文章分词结果上Y并没有紧接在Xx这个term后

这种分词(方法2)的坏处：总是比二元分词(方法1)多分出一个词。这样从库的大小上，前者不及后者，库可能相应较大。

----------------------------------
如果paoding-2.0.4-alpha2在这个方面如果真的选择错了，那我会义无反顾地把它改过来，哪怕落了个“不成熟”的帽子！

关键是，还要听听各方的意见先。


----------------------
paoding目前还不是paoding2.x的最终稳定版本。最终的稳定版本应该是2.0.4-beta后的2.0.4-final。
如果您愿意在paoding每次分发时(大概1个月1次)，您能够不嫌麻烦地做到paoding分发时提示的建议(可能需要重新建立索引库或词典重命名)，我建议您下载并使用paoding。(paoding程序bug现在倒是已经很难发现了)
如果不能遵照paoding分发的建议，比如需要重建索引，或不愿意使用未最终稳定的版本，请您等待至2.0.4-final版本(需等待3-6个月)。
谢谢！
---------------------
to new incoming:

Paoding中文分词是一个使用Java开发的，可结合到Lucene应用中的，为互联网、企业内部网使用的中文搜索引擎分词组件。
Paoding填补了国内中文分词方面开源组件的空白，致力于此并希翼成为互联网网站首选的中文分词开源组件。
Paoding中文分词追求分词的高效率和用户良好体验。

我个人对分词看法：我觉得最好的应该切+套。

新名词层出不穷，如果按照传统思维来切，就会忽略了一些词语新的含义。
比如现在一些论坛流行芙蓉姐姐，frjj，frjf，二姐，很二。

而文字大多数情况下还是具有传统含义（和字典中查到类似），如何去比较准确的分辨。

这是网络搜索，还有垂直类搜索，一些特定名词都具有特定含义。


不同搜索对分词要求都不一样，所以我认为一个通用的搜索，要具备切+套。切可以按照传统含义来切，套包含可以不断更新的字典来将一些特定用词从文中套出来。

还有些相似字典，过滤字典，特殊词语的采集。

如何收集这些词语（将人工降到最低）。


这些做完，，分词就需要考虑索引速度和索引大小。搜索速度牵涉比较广，通常瓶颈不是在分词这里。


我现在知道的最好的降低索引大小和提高索引速度的方法（只是针对文章和要求不高的海量搜索）就是文章摘要。我听一网友说起，没想到研究这个的人去做别的了。从我目前获得信息来看，这顶多是在试验阶段。

这是我的工作经验。希望对lz有所帮助，也希望后面的朋友能积极提供自己看法。

svn上的代码取不下来。。。

paoding> 中华人民共和国万岁;
1:      中华/华人/人民/共和/共和国/万岁/


请问这样做成索引，是否搜索 "华人" 的时候，也会命中 "中华人民共和国万岁"

我倒是觉得词频+自我学习才是优秀分词工具应该具备的，关键是因为这些东西是人可调的。
分词之所以出现歧义是因为不具备语义处理能力。
不管你适用的分词算法匹配概率如何精准，没有语义，一些情况下就不可能有精确解。
其实即使有语义，也不能保证完全精确。“下雨天留客天天留我不留”也依然有歧义。
但是语义保证了解的逻辑正确性，规避了解的非理性。
对于搜索要求来说，其实理性解即使有多个，也是认为可以接受的。非理性解的存在其最大的坏处就是增加无意义的搜索结果，使得搜索的精度显得低了。
比如对于前面那位所说的：中华/华人/人民/共和/共和国/万岁/  这样做成索引，搜索 "华人" 的时候，也会命中 "中华人民共和国万岁"  显然有些预期以外

但是话说回来，语义分析超复杂，计算机自动完成（呵呵，召唤高手，我目前搞不定），即使可以实现，性能和效率也要打个问号。似乎只有交给更加智能的人去调了。
我坚信即使是google，目前也是这么手工做的。理论上，不断穷举，可以接近语言的组合极限。

所以我的设计理念是既然计算机搞不定，那就还是留个口子给人吧。用人去检验穷举结果，是最佳手段。语言处理模块，一般都是所谓的人工智能，所以不加点人工，怎么智能地起来呢。