Closed GoogleCodeExporter closed 8 years ago
好吧,这个问题已经被我简化了,其实也算不上大问题。数��
�词有两种情况,一种是“三星”,一种是“n97”,“n97”这�
��的分词效果我是可以接受的,“三星”就很不好。我在TokenB
ranch中加了个方法:
void optimizeTokenBranchs() {
if (lexeme != null) {
return;
}
if(acceptedBranchs != null && acceptedBranchs.size() == 2) {
final TokenBranch firstBranch = acceptedBranchs.get(0);
if (firstBranch.getLeftBorder() == leftBorder &&
firstBranch.getRightBorder() == rightBorder &&
firstBranch.getLexeme().getLexemeType() == Lexeme.TYPE_CJK_NORMAL) {
acceptedBranchs.remove(1);
}
}
if (nextBranch != null) {
nextBranch.optimizeTokenBranchs();
}
}
就是去掉这种情况,done.
Original comment by kafka0...@gmail.com
on 20 Oct 2010 at 6:43
我也注意到这个问题,比如“第一中学”。IKANALYZER在处理数�
��时有问题
Original comment by shunkai...@gmail.com
on 2 Dec 2010 at 3:13
看来ik属于无人照顾状态阿,IKQueryParser后来又被我做了一些��
�改,以满足我的需求。其实除了IKQueryParser,ik分词还有可改�
��之处。我现在需要的两个功能ik都不支持,我看其他的几个�
��词程序也没有很好的支持。
1、分词时有选择性的不过滤一些符号,比如c++、.net、c#,现�
��分词就直接把特殊符号去掉,明显不符合实际情况。
2、词库可以支持多种形式,而不单单是汉字短语,比如“乐p
hone”,尽管现在不支持在搜索查询时通过短语query也能查到��
�果,但与或query可能就会查到不合适的结果。但对于使用分��
�为了其他目的的情况下,在基于词库的基础上,分词的准确�
��很重要。
对于上面的问题,我现在的解决方法就是在通过ik得到每个lem
exe时再做一次分析。当然,如果ik自身能支持会更好。也当然
,可能ik内部的segmenter组合机制可能需要不小的改动。
Original comment by kafka0...@gmail.com
on 17 Dec 2010 at 1:46
请下载IK2012_FF版本,新的smart分词模式将解决分词歧义问题
Original comment by linliang...@gmail.com
on 23 Oct 2012 at 9:37
Original issue reported on code.google.com by
kafka0...@gmail.com
on 20 Oct 2010 at 4:20