我想开放为 lucene 写的中文分词程序，请求帮助
Gao Pinker
我是 imdict 在线词典的作者高小平，imdict是我从06年就开始开发的项目，目的利用智能中文检索技术来提高用户的查询体验，除了传统的匹配方式查询词典之外，我利用中文全文检索技术实现了联想查询、模糊查询等等。imdict的前端除了网页版以外，还在gtalk和msn上的提供了词典查询机器人。更详细的介绍在这里。
中文分词是中文检索技术的核心之一，imdict的中文检索模块就采用了基于隐马尔科夫模型来进行中文分词，分词成功率比最大匹配法有大大提高，隐马尔科夫模型的中文分词算法来自中科院计算技术研究所的ictclas项目，分词词库用的也是他们家提供的词库。事实上，imdict中文分词模块是我对ictclas(C++)项目的重新实现（基于Java），为了提高效率，对一些不必要的功能进行了删减，例如词性标注、人名识别、时间识别等等。另外我还修改了算法的数据结构，在内存占用量缩减到1/3的情况下把效率提升了数倍。
lucene是java实现的一个高效的搜索引擎软件，对英文的处理已经非常完善，但在中文方面仍然非常欠缺，目前lucene的contribution中，中文分析器（analyzer）只有一个，还是按汉字来逐个切分的，也就是说lucene没有中文分词程序！根据我的实践，在有智能中文分词的情况下，索引文件比没有中文分词的索引文件小1/3，搜索效率也有较大提高，而且搜索结果要比逐字切分准确的多！
我想把我的中文分词模块开源，争取加入到lucene的contribution库中，以方便广大的中文lucene用户和组织。
我想问一下你们知道如何联系lucene的开发组织并把代码加到他们的contribution库中吗？
yuliuxuanke
chen cang
楼主这个可以到lucene的maillist中去问，希望能早日开放出来让大家使用。
谢谢你的分享。
Wan Chaowei
pinker
我写的代码可以使用apache license
但我用的是ictclas的词库，它的授权不是很明确，我也无权将它也用apache license发布
不知道apache lucene的contribution能不能只接受代码，当用户要用时自行去下载词库
On 4月13日, 上午9时40分, chen cang <chinac...@gmail.com> wrote:
> lucene的中文分词有几个不错，比如庖丁分词，极易分词，mmseg，IKAnalyzer等等。
> 楼主这个可以到lucene的maillist中去问，希望能早日开放出来让大家使用。
> 谢谢你的分享。
>
> 2009/4/12 Gao Pinker <xiaoping...@gmail.com>
>
> > 大家好
>
> > 我是 imdict 在线词典 <http://www.imdict.net>
> > 的作者高小平，imdict是我从06年就开始开发的项目，目的利用智能中文检索技术来提高用户的查询体验，除了传统的匹配方式查询词典之外，我利用中文全文检索技术实现了联想查询、模糊查询等等。imdict的前端除了网页版以外，还在gtalk和msn上的提供了词典查询机器人。更详细的介绍在
> > 这里 <http://www.imdict.net/blog/2009/02/15/1234705329457.html>。
amuseme
pinker
项目主页在这里：http://code.google.com/p/imdict-chinese-analyzer/
原代码采用apache license，词库文件遵循ictclas1.0的词库授权
希望大家帮我测试bug，丰富文档，有意愿加入开发的朋友请给我回复
谢谢！
Guozhu.Wen
PS：我现在也在使用你的词典机器人：），挺方便
--
稳
Guozhu Wen
mail: guoz...@gmail.com
douban: http://www.douban.com/people/wentrue/
blog: http://www.wentrue.net/blog/
twitter: https://twitter.com/wentrue
Zixin Wu
Jimmy Ma
lizheng
liugang
--
Yours sincerely
liugang
pinker
文档不明确的部分补齐。有什么问题给我发信吧
On 4月18日, 下午3时49分, Jimmy Ma <jimmybin...@gmail.com> wrote:
> 我想加入开发，请问应该怎么做！？谢谢！
>
> 2009/4/17 pinker <XiaoPing...@gmail.com>
pinker
1. 内核统一使用unicode编码，去掉了编码转换（GBK->Unicode->GBK）这个步骤，因为词典用的还是ictclas的
gb2312字符集，因此分词还受这个限制，但如果有更大字符集的字典，imdict可以很容易地支持
2. 去掉了人名识别，日期识别，词性标注，因为很多时候如果人名识别准确率不够高，会对检索效果产生影响，日期识别作用不大，而其用的正则表达式是效
率下降的一个重要原因
3. 修改了词典结构，核心词典使用的仍是多叉树和二分查找，但bigramDict（保存词汇之间的跳转概率）采用了hash查找的方法，把复杂度控
制在常数级，而以前的bigramDict使用二分查找，复杂度是对数级，相比之下效率提高了许多
这三个是效率提高的主要原因，还有其他的比如在核心模块尽量用基本数据类型代替对象，注意对象重用等等。有了这些，效率提高36倍就不足为奇了，而且还
有提高的空间！
On 4月20日, 上午11时29分, liugang <liuga...@gmail.com> wrote:
> 看了一下代码，imdict是不是只支持GB2312的字符的分词啊？词典结构是采用还是和原来一样，首字hash和二分法查找？
> 为什么效率能提高那么多，到36倍？
>
> 2009/4/20 lizheng <lizheng8...@gmail.com>
>
>
>
> > 最近正好在研究国内地址词条的解析和补充，和分词这个方向差不多，可以算一个分支吧，希望可以计入进来，给我一些帮助，谢谢，我的邮件：
> > lizheng8...@gmail.com 李征
liugang
--
Yours sincerely
liugang
Guozhu.Wen
pinker
现在有一个问题就是词库太旧，98年人民日报的语料库，好多新词都没有加入，但是如果要新建词典就可能需要启动一个专门的项目
On 4月21日, 下午12时25分, liugang <liuga...@gmail.com> wrote:
> 在AbstractDictionary里的getCCByGB2312Id()等几个方法用到了：
> String cchar = new String(buffer, "GB2312");
> byte[] buffer = Character.toString(ch).getBytes("GB2312");
> 。。。
> 之类的代码，就和GB2312绑定了。直接在字典里加入非GB2312的字符是不行的，建议这块是否能改进？
>
> 2009/4/21 pinker <XiaoPing...@gmail.com>
Guozhu.Wen
一方面的原因是词库太旧，都１９９８年的了；
另一方面的原因是词库的领域相关性，ictclas那个是人民日报那种官方文本抽取的词库，我要分的是娱乐文艺型的文本。
再一方面应该跟分词模型有关系，相对于简单的匹配算法，ＨＭＭ需要各种先验参数，如词频。不同语料集这些参数会有所差异，这也是导致词库领域相关性的原因。
lpf...@gmail.com
词。
另外，是否可评估这三个改进，哪个对ictclas的性能提升是最主要的呢？
> > > 的作者高小平，imdict是我从06年就开始开发的项目，目的利用智能中文检索技术来提高用户的查询体验，除了传统的匹配方式查询词典之外，我利用中文全文检-索技术实现了联想查询、模糊查询等等。imdict的前端除了网页版以外，还在gtalk和msn上的提供了词典查询机器人。更详细的介绍在
> > > > > > > > 这里 <http://www.imdict.net/blog/2009/02/15/1234705329457.html>。
>
> > > 中文分词是中文检索技术的核心之一，imdict的中文检索模块就采用了基于隐马尔科夫模型来进行中文分词，分词成功率比最大匹配法有大大提高，隐马尔科夫模型-的中文分词算法来自中科院计算技术研究所的ictclas项目，分词词库用的也是他们家提供的词库。事实上，imdict中文分词模块是我对ictclas(C-++)项目的重新实现（基于Java），为了提高效率，对一些不必要的功能进行了删减，例如词性标注、人名识别、时间识别等等。另外我还修改了算法的数据结构，-在内存占用量缩减到1/3的情况下把效率提升了数倍。
>
> > > lucene是java实现的一个高效的搜索引擎软件，对英文的处理已经非常完善，但在中文方面仍然非常欠缺，目前lucene的contribution中，-中文分析器（analyzer）只有一个，还是按汉字来逐个切分的，也就是说lucene没有中文分词程序！根据我的实践，在有智能中文分词的情况下，索引文件-比没有中文分词的索引文件小1/3，搜索效率也有较大提高，而且搜索结果要比逐字切分准确的多！
>
> > > > > > > > 我想把我的中文分词模块开源，争取加入到lucene的contribution库中，以方便广大的中文lucene用户和组织。
>
> > > > > > > > 我想问一下你们知道如何联系lucene的开发组织并把代码加到他们的contribution库中吗？
>
> > --
> > Yours sincerely
> > liugang- 隐藏被引用文字 -
>
> - 显示引用的文字 -
lpf...@gmail.com
87KB/s，比你说的483k/s慢了很多。
我的机器配置：IBM T400 双核酷睿2 2.5GB/3G内存，切分test.txt（8,430字节）需要93ms。对ictclas4j改进
用utf8编码，保留词性标注和专有名词识别，同样的test.txt文件需要203毫秒。
下次我将ictclas4j的bigdict词典改用hash试试，我的经验是hash和二分效率差不多。
代码如下：
WordDictionary.getInstance();
Token nt = new Token();
Analyzer ca = new ChineseAnalyzer();
BufferedReader br = new BufferedReader(new InputStreamReader(
new FileInputStream("test.txt"), "UTF-8"));
String line = br.readLine();
StringBuilder sb = new StringBuilder();
while(line != null) {
sb.append(line);
line = br.readLine();
}
String content = sb.toString();
StringReader sr = new StringReader(content);
TokenStream ts = ca.tokenStream("sentence", sr);
System.out.println("start: " + (new Date()));
long before = System.currentTimeMillis();
nt = ts.next(nt);
while (nt != null) {
// System.out.println(nt.term());
nt = ts.next(nt);
}
ts.close();
long now = System.currentTimeMillis();
System.out.println("time: " + (now - before) + " ms");
On 4月21日, 下午12时04分, pinker <XiaoPing...@gmail.com> wrote:
> > > 的作者高小平，imdict是我从06年就开始开发的项目，目的利用智能中文检索技术来提高用户的查询体验，除了传统的匹配方式查询词典之外，我利用中文全文检-索技术实现了联想查询、模糊查询等等。imdict的前端除了网页版以外，还在gtalk和msn上的提供了词典查询机器人。更详细的介绍在
> > > > > > > > 这里 <http://www.imdict.net/blog/2009/02/15/1234705329457.html>。
>
> > > 中文分词是中文检索技术的核心之一，imdict的中文检索模块就采用了基于隐马尔科夫模型来进行中文分词，分词成功率比最大匹配法有大大提高，隐马尔科夫模型-的中文分词算法来自中科院计算技术研究所的ictclas项目，分词词库用的也是他们家提供的词库。事实上，imdict中文分词模块是我对ictclas(C-++)项目的重新实现（基于Java），为了提高效率，对一些不必要的功能进行了删减，例如词性标注、人名识别、时间识别等等。另外我还修改了算法的数据结构，-在内存占用量缩减到1/3的情况下把效率提升了数倍。
>
> > > lucene是java实现的一个高效的搜索引擎软件，对英文的处理已经非常完善，但在中文方面仍然非常欠缺，目前lucene的contribution中，-中文分析器（analyzer）只有一个，还是按汉字来逐个切分的，也就是说lucene没有中文分词程序！根据我的实践，在有智能中文分词的情况下，索引文件-比没有中文分词的索引文件小1/3，搜索效率也有较大提高，而且搜索结果要比逐字切分准确的多！
>
> > > > > > > > 我想把我的中文分词模块开源，争取加入到lucene的contribution库中，以方便广大的中文lucene用户和组织。
>
> > > > > > > > 我想问一下你们知道如何联系lucene的开发组织并把代码加到他们的contribution库中吗？
>
> > --
> > Yours sincerely
pinker
是831k/s，当然这个重复内容的文件不能说明问题。
实际上，我是用同学的66M的文本电子书（各种小说）作为测试集，483k/s的分词速度是比较客观的。
关于那三个改动对效率的评估我没有具体测试，因为我是从头到尾一口气重写的，我感觉对效率的提高应该是1>3>2，尤其是1，避免不同的编码相互转换最
重要，同时也是支持UTF8编码的必要步骤