Saturday, April 22, 2006

 

Some notes on Chinese Words Segmentation - 2

1.
From http://www.cnblogs.com/tianchunfeng/archive/2004/12/28/83002.html

不同规则的中文分词对Lucene索引的影响
By 田春峰

在中文全文索引中为了建立反向索引需要对文档中的句子进行切分,相关理论请参见车东的介绍。

在lucene 1.3 以后的版本中支持中文建立索引了,他默认的切分规则是按一个个汉字分的。例子见后。

这里主要对比以下3种中文切分对lucene 索引的影响。

第一种:默认的单字切分;

第二种:二元切分(见车东的文章);

第三种:按照词义切分(使用小叮咚的逆向最大切分法)。

上面3种切分的效果如下:

原句:"搜索引擎的发展历史证明,没有做不到只有想不到,让人们更方便准确的获取信息是搜索引擎的使命。"

Lucene默认分词结果:

org.apache.lucene.analysis.standard.StandardAnalyzer:

[搜] [索] [引] [擎] [的] [发] [展] [历] [史] [证] [明] [没] [有] [做] [不] [到] [只] [有] [想] [不] [到] [让] [人] [们] [更] [方] [便] [准] [确] [的] [获] [取] [信] [息] [是] [搜] [索] [引] [擎] [的] [使] [命]

二元切分结结果:

org.apache.lucene.demo.CJKAnalyzer:

[搜索] [索引] [引擎] [擎的] [的发] [发展] [展历] [历史] [史证] [证明] [没有] [有做] [做不] [不到] [到只] [只有] [有想] [想不] [不到] [让人] [人们] [们更] [更方] [方便] [便准] [准确] [确的] [的获] [获取] [取信] [信息] [息是] [是搜] [搜索] [索引] [引擎] [擎的] [的使] [使命]

小叮咚切分结果:

org.apache.lucene.demo.ChineseAnalyzer:

[搜索] [引擎] [的] [发展] [历史] [证明] [有] [做] [不到] [只有] [想] [不到] [人们] [更] [方便] [准确] [的] [获取] [信息] [是] [搜索] [引擎] [的] [使命]

在Lucene索引中,最小的索引单位是Token。基本上可以这样理解Token,在英文中Token是一个单词,在汉语中是不同切分结果中[]内的单词。

我的测试数据:
今天各大网站和blog的新闻,包括经济、政治、教育、娱乐、科技等几大类总共212K的文本文件。

经过Lucene生成索引后的统计信息如下:

单字切分:

单字切分的前15个Term

词义切分:

词义切分的前15个Term

通过上面的对比可以看出: 单字切分的Term要比词义切分的Term少。原因很明显,汉语中常用的字大概4000多个,所以单字切分的Term上限也大概就是这么多,词义切分就不同了,我这里的词义词典大概有4万多个。

从直觉观察来看,索引文件中的Term越多,搜索结果也越快,搜索的相关性也越高。

另外一个有意思的情况是索引文件大小的变化。

在我得测试数据大概80K大小的时候,上面的两种方法产生的索引文件区别不大,可是当数据量大于100K的时候,单字切分的索引文件已经比词义切分索引文件大了30多K了。由于目前对索引文件格式还不了解,现在只能猜测为什么会出现这样的结果了。因为单字切分的Term少,那么指向这个Term的链接信息就越多,(搜索结果也越不相关)。反之亦然。

上面的测试数据中没有过滤常用的汉字。常用的汉字对搜索是没有作用的,比如:的,是等。

(From me: a little bit old)

2.
From http://blog.csdn.net/accesine960/archive/2005/01/08/244811.aspx

一种面向搜索引擎的中文切分词方法

首先说一下搜索引擎切分词的产生的原因。
在进行全文检索时,首先将要检索的内容分割成较短的文字序列。然后生成在每个文字序列中所包含字符串的对应表(索引)。当输入检索语句后,也同样进行分割,与索引进行比较。也就是说,两者即使包含有同样的文字排列,但分割方法不同的话也不能正确检索。
文字的分割方法主要有两种,分别是 词语解析索引 和 文字索引 。
词语解析索引是按照字典中最小的词语单位对文本进行分割,既按词义切分。如中科院的 ICTCLAS。
文字索引是不考虑文本中词的意义,只是按照一定的字长的单位进行切分。如 车东的二元切分法。

上面两种方法对搜索的影响已经在 不同规则的中文分词对Lucene索引的影响 一文中做了对比。
这里想纠正的一点是:我在里面提到: 从直觉观察来看,索引文件中的Term越多,搜索结果也越快,搜索的相关性也越高。
这句话漏掉了一点,就是Term的“质量”问题。比如采用二元切分方法,产生的Term一定比 单字切分 和 词义切分 要多,但是很显然不能提高搜索的相关性。我的看法是二元切分 提高了搜索关键字的命中率而降低了索引结果的相关性。

那么是不是按照词义切分就能解决上面的问题呢?
在跟车东和lhelper谈论GrassLand的开发计划的时候,(车东和lhelper是WebLucene的主要开发者),他们很有方向性的提到:完全按照词义切分不完全适合于全文搜索。

得出这样的结论似乎有悖常理。这也是本文要集中讨论的地方。

上面提到:搜索引擎在建立索引时要和用户搜索时采取相同的切分方法,才能够正确检索。而这正是 词义切分 容易出现差错的地方。原因在于当搜索引擎建立索引时,可以通过算法使文本内容中的词语和字典很好的吻合(ICTCLAS 公测招回准确率在90%左右)。而在对用户在输入的关键字进行分词的时候,一方面用户输入的文本要短,另一方面用户只使用自己认为对的关键词,(还不考虑错字、别字 :-( )这样就造成了前后两者分词的差异。

这种差异导致的结果可想而知,甚至不如文字索引 二元切分 更有效。

这时候我们怎么选择?下面引用相关组织的一点评论:

美国加州大学伯克利分校却在报告中称,使用 按词义切分法按词语单位对检索语句进行分割的方法更为有效。“作为的NTCIR资深小组提出的报告,可信度很高。我们也许可以得出以单词为单位进行分割的方法有效这一结论了”(国立信息学研究所副教授神门典子)。但在作为检索对象的数据方面,为防止检索遗漏有时还是使用 文字索引 进行分割好一些。

上面 伯克利分校 的评论可以作为本文要提出的:面向搜索引擎的中文切分方法 的理论起点。

概括起来就是:以词义切分为主要的切分方法,对于其中偏差的部分采用 文字索引切分法。 搜索引擎切分词的目的不是切分出有意义的词,而是切分出用户需要的关键词。

上面提到的只是一个总的思路,在技术上还有很多细节需要考虑。

我会按照把上面的思路,修改 小叮咚 的分词方法,放在 GrassLand 的中文切分模块中。
另外请大家关注 GrassLand 的进展,多多参与。
田春峰
20040108

3.
From http://blog.donews.com/accesine/archive/2005/07/13/464827.aspx

基于最长词匹配算法变形的分词系统( 文舫工作室贡献 )

这个分词程序是文舫工作室贡献出来的。
强烈推荐看看文舫工作室的开发日志,他们的激情可以鼓励很多人......

自从小叮咚分词程序发布后,很多软件行业的朋友们都来信索取,因为定位的问题,所以小叮咚的分词程序和 ICTCLAS的算法完全不同的。

小叮咚的分词程序的定位是为搜索引擎服务的。可以参考:一种面向搜索引擎的中文切分词方法
ICTCLAS和基于最长词匹配算法变形的分词系统 是面向语法,语义的。

不同的应用导致了不同的分词算法,但是正如车东所说的,我们现在应该跳过分词这个点,面向分词应用了。
我很赞同。

如果大家需要 基于最长词匹配算法变形的分词系统 的代码,可以到这个页面下载申请书,填写后我会给你
发送一份相关代码。

关于分词文德是专家,大家可以下载 Lucene使用者沙龙 中的录音,听听他对分词的一些经验。

这些申请书会在以后整理出来共享的。

相关连接:
文舫工作室的网址
http://www.xerdoc.com/
Lucene使用者沙龙
http://blog.cnblog.org/archives/2005/07/luceneaecee.html

4.
From unknown author

[转]Lucene 中文分词的 highlight 显示


作者:aft 提交日期:2005-10-6 20:48:00

Lucene 中文分词的 highlight 显示
1 、问题的来源

增加分词以后结果的准确度提高了,但是用户反映返回结果的速度很慢。原因是, Lucene 做每一篇文档的相关关键词的高亮显示时,在运行时执行了很多遍的分词操作。这样降低了性能。

2 、解决方法

在 Lucene1.4.3 版本中的一个新功能可以解决这个问题。 Term Vector 现在支持保存 Token.getPositionIncrement() 和 Token.startOffset() 以及 Token.endOffset() 信息。利用 Lucene 中新增加的 Token 信息的保存结果以后,就不需要为了高亮显示而在运行时解析每篇文档。通过 Field 方法控制是否保存该信息。修改 HighlighterTest.java 的代码如下:

// 增加文档时保存 Term 位置信息。

private void addDoc(IndexWriter writer, String text) throws IOException

{

Document d = new Document();

//Field f = new Field(FIELD_NAME, text, true, true, true);

Field f = new Field(FIELD_NAME, text ,

Field.Store.YES, Field.Index.TOKENIZED,

Field.TermVector.WITH_POSITIONS_OFFSETS);

d.add(f);

writer.addDocument(d);

}

// 利用 Term 位置信息节省 Highlight 时间。

void doStandardHighlights() throws Exception

{

Highlighter highlighter =new Highlighter(this,new QueryScorer(query));

highlighter.setTextFragmenter(new SimpleFragmenter(20));

for (int i = 0; i < hits.length(); i++)

{

String text = hits.doc(i).get(FIELD_NAME);

int maxNumFragmentsRequired = 2;

String fragmentSeparator = "...";

TermPositionVector tpv = (TermPositionVector)reader.getTermFreqVector(hits.id(i),FIELD_NAME);

// 如果没有 stop words 去除还可以改成 TokenSources.getTokenStream(tpv,true); 进一步提速。

TokenStream tokenStream=TokenSources.getTokenStream(tpv);

//analyzer.tokenStream(FIELD_NAME,new StringReader(text));

String result =

highlighter.getBestFragments(

tokenStream,

text,

maxNumFragmentsRequired,

fragmentSeparator);

System.out.println("\t" + result);

}

}

最后把 highlight 包中的一个额外的判断去掉。对于中文来说没有明显的单词界限,所以下面这个判断是错误的:

tokenGroup.isDistinct(token)

这样中文分词就不会影响到查询速度了。



<< Home

This page is powered by Blogger. Isn't yours?