【大数据开发运维解决方案】Solr6.2默认相似性算法检索匹配得分高于5.1版本问题分析

本文涉及的产品
云原生大数据计算服务MaxCompute,500CU*H 100GB 3个月
简介: 我们之前使用的solr版本是solr5.1,分词器使用的是jcseg1.9.6,后续接触了Solr6.2,分词器使用的是jcseg2.6.0,发现同一个Oracle库的同一套表数据,分别使用solr5.1和solr6.2版本的模板collection配置集做相同的字段配置并成功做索引后,做相同查询,solr6.2检索文档score远高于solr5.1,下面是我们使用的两个solr环境以及另一个单机solr测试环境的基本情况:

Solr6.2默认相似性算法检索匹配得分高于5.1版本问题分析

注意:
我们之前使用的solr版本是solr5.1,分词器使用的是jcseg1.9.6,后续接触了Solr6.2,分词器使用的是jcseg2.6.0,发现同一个Oracle库的同一套表数据,分别使用solr5.1和solr6.2版本的模板collection配置集做相同的字段配置并成功做索引后,做相同查询,solr6.2检索文档score远高于solr5.1,下面是我们使用的两个solr环境以及另一个单机solr测试环境的基本情况:

大数据环境 solr版本
CDH Solr5.1
华为云 Solr6.2
单机 开源Solr6.2

一、问题重现

现有华为云solr6.2和cdh5.1以及开源solr6.2三个环境的solr,索引的数据均从同一个oracle11.2.0.4库表用相同的逻辑取数据,collection或core名字分别为uoc-buyer1、uoc-buyer、uoc-buyer,现分别从三个环境做下面问题查询:

q=engname%3A(ADNAN+UL+HAQ)%5E5+buyeraddr%3A(PP+NO+AF1401302+ADD%5C%3ATOBA+TEK+SINGH%2CPAKISTAN)%5E2+flag%3A(0%5E2+1%5E1)
&fq=%7B!frange+l%3D1.8%7Dquery(%24q)
&fq=-accuracylel%3A1
&fq=countrycode%3APAK
&fq=flag%3A0
&sort=flag+asc%2Caccuracylel+desc%2Cscore+desc
&fl=chnname%2Cengname%2Cbuyeraddr%2Cpuppetbn%2Cflag%2Ctableflag%2Cscore%2Ccountrycode
&wt=json
&indent=true

开源及华为云solr6.2检索得分:
image.png

二、问题分析

1、问题原因是否由于分词器版本不一致导致

因为我们之前开始时使用的是solr5.1,相关代码开发和相识度分数认定的分数线也是基于solr5.1来做的,所以在后续将collection逻辑拿到6.2版本的开源和华为云solr后,发现分数差别很大。
首先怀疑是不是分词器导致的,因为两个solr6.2分词器使用的是jcseg2.6.0,而cdh的solr5.1使用的是1.9.6版本,于是通过三个solr的analyze功能分析要查询的地址:
两个使用jcseg2.6.0的solr6.2:
image.png
使用jcseg1.9.6的solr5.1:
image.png
两个结果比较了下,感觉还是1.9.6版本的英文分词结果更友好,2.6.0版本分词分的太细致了,将本应该在一起的单词也给拆分的七零八落了。
于是根据jcseg1.9.6的默认配置去修改jcseg2.6.0的分词器配置,最终修改后的jcseg-core-2.6.0.jar分词器中的配置文件jcseg.properties内容为:

# Jcseg properties file.
# @Note: 
# true | 1 | on for open the specified configuration or
# false | 0 | off to close it.
# bug report chenxin <chenxin619315@gmail.com>

# Jcseg function
#maximum match length. (5-7)
jcseg.maxlen = 5

#Whether to recognized the Chinese name.
jcseg.icnname = true

#maximum chinese word number of english chinese mixed word. 
jcseg.mixcnlen = 3

#maximum length for pair punctuation text.
jcseg.pptmaxlen = 7

#maximum length for Chinese last name andron.
jcseg.cnmaxlnadron = 1

#Whether to clear the stopwords.
jcseg.clearstopword = false

#Whether to convert the Chinese numeric to Arabic number. like '\u4E09\u4E07' to 30000.
jcseg.cnnumtoarabic = true

#Whether to convert the Chinese fraction to Arabic fraction.
#@Note: for lucene,solr,elasticsearch eg.. close it.
jcseg.cnfratoarabic = false

#Whether to keep the unrecognized word.
jcseg.keepunregword = true

#Whether to do the secondary segmentation for the complex English words
jcseg.ensecondseg = true

#min length of the secondary simple token. (better larger than 1)
jcseg.stokenminlen = 2

#minimum length of the secondary segmentation token.
jcseg.ensecminlen = 1

#Whether to do the English word segmentation
#the jcseg.ensecondseg must set to true before active this function
jcseg.enwordseg = false

#maximum match length for English extracted word
jcseg.enmaxlen = 16

#threshold for Chinese name recognize.
# better not change it before you know what you are doing.
jcseg.nsthreshold = 1000000

#The punctuation set that will be keep in an token.(Not the end of the token).
jcseg.keeppunctuations = @#%.&+

#Whether to append the pinyin of the entry.
jcseg.appendpinyin = false

#Whether to load and append the synonyms words of the entry.
jcseg.appendsyn = true


####for Tokenizer
#default delimiter for JcsegDelimiter tokenizer
#set to default or whitespace will use the default whitespace as delimiter
#or set to the char you want, like ',' or whatever
jcseg.delimiter = default

#default length for the N-gram tokenizer
jcseg.gram = 1


####about the lexicon
#absolute path of the lexicon file.
#Multiple path support from jcseg 1.9.2, use ';' to split different path.
#example: lexicon.path = /home/chenxin/lex1;/home/chenxin/lex2 (Linux)
#        : lexicon.path = D:/jcseg/lexicon/1;D:/jcseg/lexicon/2 (WinNT)
#lexicon.path=/Code/java/JavaSE/jcseg/lexicon
#lexicon.path = {jar.dir}/lexicon ({jar.dir} means the base directory of jcseg-core-{version}.jar)
#@since 1.9.9 Jcseg default to load the lexicons in the classpath
lexicon.path = {jar.dir}/lexicon

#Whether to load the modified lexicon file auto.
lexicon.autoload = true

#Poll time for auto load. (seconds)
lexicon.polltime = 30


####lexicon load
#Whether to load the part of speech of the entry.
jcseg.loadpos = true

#Whether to load the pinyin of the entry.
jcseg.loadpinyin = false

#Whether to load the synonyms words of the entry.
jcseg.loadsyn = true

#Whether to load the entity of the entry
jcseg.loadentity = true

修改后的jcseg分词器分词效果如下:
image.png
已经与jcseg1.9.6分词效果基本一致了,这时候两个solr6.2.0再重做索引,再次执行之前的查询,发现检索得分还是100多分。

2、问题原因是否由于solr6和5默认相似性算法不一致导致

根据上面实验,于是这里怀疑不只是因为分词器分词差异导致的问题,更大的问题应该在于solr5和solr6的相似度得分算法不一样了,为了排除分词器带来的影响,于是将solr6.2使用的分词器也替换成solr5.1使用那一套分词器,再次索引同样的数据,做同样的查询发现得分还是很高,那就说明相似得分差异过大的主要原因是由于solr两个版本的算法不一致导致的了。
经过网上查找资料发现了solr5和solr6的默认相似度算法的确是变了:

默认的相似性改变

当 Schema 没有明确地定义全局 \<similarity/> 时,Solr 的默认行为将依赖于 solrconfig. xml 中指定的
luceneMatchVersion。当 luceneMatchVersion < 6.0 时,将使用
ClassicSimilarityFactory 的实例,否则将使用 SchemaSimilarityFactory
的实例。最值得注意的是,这种改变意味着用户可以利用每个字段类型的相似性声明,并且需要明确声明 SchemaSimilarityFactory
的全局用法。 无论是明确声明还是作为隐式全局默认值使用,当字段类型不声明明确\<similarity/>
时,SchemaSimilarityFactory 的隐式行为也被更改为依赖于 luceneMatchVersion。当
luceneMatchVersion < 6.0 时,将使用 ClassicSimilarity 的实例,否则将使用
BM25Similarity 的实例。可以在 SchemaSimilarityFactory 声明中指定
defaultSimFromFieldType init 选项来更改此行为。请查看
SchemaSimilarityFactoryjavadocs 了解更多详情

于是修改solr6.2的manage-schema,新增similarity显示指定:

<similarity class="solr.ClassicSimilarityFactory"/>

而且由于当前环境索引速度较慢,同时修改solrconfig.xml的索引并行度:

<maxIndexingThreads>32</maxIndexingThreads>

重启solr,重做索引,发现现在索引速度比原来快了一个小时,再次做同样的查询,检索得分已经同solr5.1相似了:
image.png

相关实践学习
基于MaxCompute的热门话题分析
Apsara Clouder大数据专项技能认证配套课程:基于MaxCompute的热门话题分析
相关文章
|
5月前
|
存储 监控 算法
局域网上网记录监控的 C# 基数树算法高效检索方案研究
在企业网络管理与信息安全领域,局域网上网记录监控是维护网络安全、规范网络行为的关键举措。随着企业网络数据量呈指数级增长,如何高效存储和检索上网记录数据成为亟待解决的核心问题。基数树(Trie 树)作为一种独特的数据结构,凭借其在字符串处理方面的卓越性能,为局域网上网记录监控提供了创新的解决方案。本文将深入剖析基数树算法的原理,并通过 C# 语言实现的代码示例,阐述其在局域网上网记录监控场景中的具体应用。
138 7
|
7月前
|
存储 人工智能 算法
通过Milvus内置Sparse-BM25算法进行全文检索并将混合检索应用于RAG系统
阿里云向量检索服务Milvus 2.5版本在全文检索、关键词匹配以及混合检索(Hybrid Search)方面实现了显著的增强,在多模态检索、RAG等多场景中检索结果能够兼顾召回率与精确性。本文将详细介绍如何利用 Milvus 2.5 版本实现这些功能,并阐述其在RAG 应用的 Retrieve 阶段的最佳实践。
1472 1
通过Milvus内置Sparse-BM25算法进行全文检索并将混合检索应用于RAG系统
|
7月前
|
运维 自然语言处理 算法
云栖实录 | 大模型在大数据智能运维的应用实践
云栖实录 | 大模型在大数据智能运维的应用实践
791 3
|
运维 算法 数据可视化
【2021 高校大数据挑战赛-智能运维中的异常检测与趋势预测】2 方案设计与实现-Python
文章详细介绍了参加2021高校大数据挑战赛中智能运维异常检测与趋势预测任务的方案设计与Python实现,包括问题一的异常点和异常周期检测、问题二的异常预测多变量分类问题,以及问题三的多变量KPI指标预测问题的算法过程描述和代码实现。
184 0
|
8月前
|
存储 算法 量子技术
解锁文档管理系统高效检索奥秘:Python 哈希表算法探究
在数字化时代,文档管理系统犹如知识宝库,支撑各行各业高效运转。哈希表作为核心数据结构,通过哈希函数将数据映射为固定长度的哈希值,实现快速查找与定位。本文聚焦哈希表在文档管理中的应用,以Python代码示例展示其高效检索特性,并探讨哈希冲突解决策略,助力构建智能化文档管理系统。
|
10月前
|
机器学习/深度学习 人工智能 运维
智能化运维:AI与大数据在IT运维中的应用探索####
本文旨在探讨人工智能(AI)与大数据分析技术如何革新传统IT运维模式,提升运维效率与服务质量。通过具体案例分析,揭示AI算法在故障预测、异常检测及自动化修复等方面的实际应用成效,同时阐述大数据如何助力实现精准运维管理,降低运营成本,提升用户体验。文章还将简要讨论实施智能化运维面临的挑战与未来发展趋势,为IT管理者提供决策参考。 ####
|
数据采集 运维 Cloud Native
Flink+Paimon在阿里云大数据云原生运维数仓的实践
构建实时云原生运维数仓以提升大数据集群的运维能力,采用 Flink+Paimon 方案,解决资源审计、拓扑及趋势分析需求。
18705 54
Flink+Paimon在阿里云大数据云原生运维数仓的实践
|
11月前
|
算法
雪花算法反思:订单ID生成的痛点与解决方案
雪花算法(Snowflake Algorithm)因其生成唯一ID的能力而被广泛应用于分布式系统中。然而,随着业务的发展和系统规模的扩大,一些隐藏的问题逐渐浮现。本文将探讨使用雪花算法生成订单ID后可能遇到的挑战,并提供相应的解决方案。
498 2
|
11月前
|
机器学习/深度学习 人工智能 监控
智慧交通AI算法解决方案
智慧交通AI算法方案针对交通拥堵、违法取证难等问题,通过AI技术实现交通管理的智能化。平台层整合多种AI能力,提供实时监控、违法识别等功能;展现层与应用层则通过一张图、路口态势研判等工具,提升交通管理效率。方案优势包括先进的算法、系统集成性和数据融合性,应用场景涵盖车辆检测、道路环境检测和道路行人检测等。
787 1
|
12月前
|
机器学习/深度学习 人工智能 运维
智能运维:大数据与AI的融合之道###
【10月更文挑战第20天】 运维领域正经历一场静悄悄的变革,大数据与人工智能的深度融合正重塑着传统的运维模式。本文探讨了智能运维如何借助大数据分析和机器学习算法,实现从被动响应到主动预防的转变,提升系统稳定性和效率的同时,降低了运维成本。通过实例解析,揭示智能运维在现代IT架构中的核心价值,为读者提供一份关于未来运维趋势的深刻洞察。 ###
416 10