前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >关于中文分词

关于中文分词

作者头像
全栈程序员站长
发布2022-07-12 17:06:33
2820
发布2022-07-12 17:06:33
举报

大家好,又见面了,我是全栈君,祝每个程序员都可以多学几门语言。

眼下全量索引17G,不到1300万document花费大约25分钟的时间(Lucene 4.0),吞吐量远远低于lucene nightly build宣称的170G/h的量。换用StandardAnalyzer,有34%的提高,比較下使用的KAnalyzer,mmseg4j1.9.2-snapshot,standardanalyzer,性能分别在1.7M/s,10M/s,20M/s这样量级。所以觉得假设分词性能有明显提高,索引速度应该会有加快。

分析了下眼下使用的KAnalyzer,它同一时候运行正向最大匹配和反向最大匹配,取概率最大那个(1-gram累计词频),假设有歧义/交集的三元组,用概率算第三种分词方式,假设最高,当然选用第三种分词方式。

感觉起来效率不太高,由于有三次匹配,我会尝试例如以下动作:

1)分别測试仅仅使用最大正向和最大反向的性能,有个直观感觉,再建索引看看性能;

2)mmseg相同是启示式的,但仅仅做一次匹配,孰优孰劣,还要看准确率,召回率,必须通过的測试是否都通过,这一套标准须要建立起来

3)算法是一方面,词典质量更重要,算法方面性能,准确率,召回率各个方面做个tradeoff就能够。

4)对于”南京西路”,想保留”南京|西|路”,感觉建个额外字典,某些词必须拆掉就能够了。

5)里面的概率所有改用ln(freq),累计频率所有使用加法,提高效率,少用string,看看是否能用bytesref,按句子分,不要按整块文本分。diffrate = Max / (Min + 1)看起来有点费解…

6)最大匹配里面放进去的匹配规则要揪出来,要看看mmseg4j的实现。

最后想说理论上viterbi算法分词准确率最优,仅仅是性能太差了..

另外补充个,geo眼下按多级(15级)索引,可能是导致索引慢的原因。还有从csv文本到ReusableDocument的反序列化过程也可能拖慢索引速度。

发布者:全栈程序员栈长,转载请注明出处:https://javaforall.cn/118678.html原文链接:https://javaforall.cn

本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
原始发表:2021年12月,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档