一种中文分词算法

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

一种中文分词算法

1.1.1 最大匹配法分词的缺陷

尽管最大匹配法分词是常用的解决的方案,但是无疑它存在很多明显的缺陷,这些缺陷也限制了最大匹配法在大型搜索系统中的使用频率。最大匹配法的问题有以下几点:

一、长度限制

由于最大匹配法必须首先设定一个匹配词长的初始值,这个长度限制是最大匹配法在效率与词长之间的一种妥协。我们来看一下以下两种情况:

(1)词长过短,长词就会被切错。例如当词长被设成5时,也就意味着它只能分出长度为5以下词,例如当这个词为“中华人民共和国”长度为7的词时,我们只能取出其中的5个字去词库里匹配,例如“中华人民共”,显然词库里是不可能有这样的词存在的。因此我们无法下确的划分出“中华人民共和国”这样的词长大于5的词。

(2)词长过长,效率就比较低。也许有人会认为既然5个字无法满足我们的分词要求,何不将词长加大,例如加到10或者100,毕竟这个世界超过100个字长的词还是很少见的,我们的词长问题不就解决了?然而当词长过长时,我们却要付出另一方面的代价:效率。效率是分词算法、甚至是整个算法理论体系的关键,毕竟算法书里所有的高深的查询或排序算法都是从效率出发的,否则任何笨办法都可以解决分词效率低的问题。设想到我们把字长设成100个词时,我们必须将词从100开始一直往下匹配直到找到要查的字为止,而我们大多数词的字长却只有两三个字,这意味着前97次的匹配算法是徒劳的。

因此我们必须要在词长与效率之间进行妥协,既要求分词尽量准确,又要求我们的词长不能太长。尽管我们可能找到这样一个比较优化的字长值使两者都达到比较满足的状态,但是毕竟不管我们怎么设定,总会有些太长词分出来,或者带来效率问题。

二、效率低

效率低是最大匹配法分词必然会来的问题。即使我们可以将字长设成相当短,例如5(注意,我们不能再缩短字长了,毕竟字长为5以上的词太多了,我们不能牺牲分词的准确),然而当我们的大数词长为2时,至少有3次的匹配算法是浪费掉的。回想一下算法书里提到

的最简单的字符匹配与KMP算法之间天差地别的效率,我们知道通过某种方法,这些浪费的掉的匹配时间是可以补回来的。

三、掩盖分词歧义

中文是如此复杂的语言,它的表达方式如此之多,语法文法如此精妙,机械的电脑是很难理解这么复杂的语言,因此它必然会带来歧意性,以下是两个简单的例子:

A.“有意见分歧”(正向最大匹配和逆向最大匹配结果不同)

有意/ 见/ 分歧/

有/ 意见/ 分歧/

B.“结合成分子时”(正向最大匹配和逆向最大匹配结果相同)

结合/ 成分/ 子时/由于词的歧义性使我们在使用最大匹配法分词会产生错误的结果,而且使用正向分词与逆向分词往往会产生截然不同的结果。尽管使用回溯法或计算计算词的使用频率,可以使出现歧义的可能性减少,但是我们知道,这样的结果是不可避免的,因为中文的变化实在太多了。

四、最大匹配的并不一定是想要的分词方式

最大匹配法基于的理念是找到最大的匹配词,但有的时候除了最大匹配词外,我们也可能只需要这个词的一部分。例如“感冒解毒胶囊”是一个完整的词,按照最大匹配法我们无法对它进行拆分了,这样我们输入“感冒”的时候就根本搜不到我们需要的词。这是我们需要的吗?做为生产这种药的厂商,它肯定希望用户输入“感冒”甚至“解毒”,我们都能查到对应的内容。

1.2 设计自己的中文分词算法

1.2.1 设计目标

基于对分词算法的理解和对最大匹配法分词的分析,我们知道我们必须提出不同的解决方案,使分词算法的效率、分词的长度限制甚至歧义处理上得到提高。因此我们提出了如下的设计目标:

一、高效

中文分词算法必须要高效,毕竟效率对于搜索引擎的重要性是不言而喻的。而且我们面对的是海量的数据,而不是一篇几百字或几千字的文章,效率的差别的影响可能会使最后运行效率差几个小时甚至几天。因此我希望我们设计的算法一定要比最大匹配法高,毕竟我们已经常看到最大匹配法的很多次匹配都是浪费在无用功上了,肯定有办法把这些浪费的时间节省回来。

二、无长度限制

最大匹配法的长度限制真是很讨厌的事,我们很难找到词长与效率的之间的平衡。为什么我们需要长度的限制?为什么我们不能设计出任何词长的词(只要词库中存在)都可以分出来?

三、歧义包容

我们相信长度限制的问题总是可以解决的,因为虽然长度限制这个问题很难,但是它是有规律可循的,它是严谨的科学。但是当我们碰到中文歧义时,我知道不管我们怎么努力,它仍然是不可能彻底解决的。因为中文实在太博大精深了,即使有极强的人工智能和机器学习功能,这样的错误仍然是难以避免。既然无法避免?我们为什么不换一个角度去考虑?我们为什么不可以将出现歧义的各种可能性都包含进去,作为分词的参考。例如上述的“有意见分歧”的两种分词方法:

有意/ 见/ 分歧/

有/ 意见/ 分歧/

为什么我们不能把这样两种结果都拿来分词呢?毕竟分词的目的是为了搜索,而不是为了教小孩读出。如果把两种分词的可能性都告诉搜索引擎,搜索引擎会很高兴的,因为这下不管是“有意”还是“意见”,它都可以搜到了。这就是我提出来另一个目标:歧义包容。

1.2.2 算法的突破口—词库

虽然我们的目标已经确定下来了,但是要想出一个更好的算法却是非常难的事。毕竟算法需要的是灵感与突发奇想,这与系统的架构设计和面向对象的设计与编者编码刚好是相反的,

象设计模式或重构这样的东西我们需要的实践、总结、再实践。而算法需要的却是当我们在山重水复疑无路的时候会换个角度思考。

但是分词算法的突破口在哪里呢?我们必须要有一个词库,我们必须将全文中的词与词库去匹配,这一切都是不可避免的。

真正要改善是就是我们的匹配过程,我们要减少匹配过程中的浪费,我们要解决匹配中的词长限制。但是我们有什么办法呢?每次的匹配我们必须要去词库中查找一次。怎么改善这样的做法?

我们总是把优化的思路定格在更好的匹配算法,更好地处理词条和全文。但是真正束缚我们的却是词库!是基于关系数据库的词库,我们需要的对词库的改造,我们要让我们的词库更适合用于匹配与分词!

这是几十年来关系数据库带给我们的思维:我们查找的词是数据库的某条记录,通过表格与关系代数,我们总能找到这个词。但是正是关系数据库的这种思维束缚着我们,关系数据库让我们的数据结构及关联表达得清楚又简单,并使某些查询的效率变得很高。但是这不适用于中文分词,有的时候退到几十年前流行的数据库模型也许更适合。这就是层次数据库。

我们要做的是将关系数据库的词按字打散,并存放到层次数据库中。以下就是一个示例:

相关文档
最新文档