solr长文本搜索问题

多关键词搜索排序质量一直一个疼痛的问题&＃xff0c;已经频繁遇到&＃xff0c;目前还没来得及系统解决。

针对之前的解决经验&＃xff0c;做一个小节&＃xff0c;后面可能随着对排序质量的提高&＃xff0c;会越来越突出。

请大家拍砖和丰富这方面的经验&＃xff0c;提升解决需求的效率。

分析

当前默认都是phrasequery执行&＃xff0c;对指定域先分词&＃xff0c;然后按照短语去查询&＃xff0c;当出现分词交叉后&＃xff0c;结果就悲剧了。

当非自动生成phrasequery时候&＃xff0c;指定域也会分词&＃xff0c;然后按照
AND 
或者 OR

拼接起来去查&＃xff0c;此时&＃xff0c;短语的关联性丢失&＃xff0c;挨在一起的可能没有排在前面&＃xff0c;尽管有结果。

当不自动生成phrasequery时候&＃xff0c;"  " 
将查询出当做整体&＃xff0c;此时依然会分词&＃xff0c;只是查询时分词后的拼接去查。例如 “交易成功” 
转为 “交易

成功”

当扩展查询串去查&＃xff0c;可能结果来自扩展串&＃xff0c;有结果但不一定就是期望。

改为 
建索引最多分词、查询最长匹配&＃xff0c;能解压一部分场景需求&＃xff0c;对于精准查询的短语、长文本尤其效果好&＃xff0c;对于追求结果最多不适应。

或者 
业务执行分词然后按照业务需求执行坡度或者相关性激励来调整相关性。例如 (交易

成功)~12 And

交易^10

成功^2

总结&＃xff1a;

新业务依赖长文本查询的&＃xff0c;需要daily仔细测试&＃xff0c;对多关键词的抽样测试不可少。

    

新的对精准匹配要求高的检验使用IK分词&＃xff0c;分别配置建索引和查询的分词模式。

    
DismaxQueryparse 
能有效的减少查询IO和“去重“&＃xff0c;完全可以替代
OR 
扩展查询&＃xff0c;目前发现一个不友好&＃xff0c;例如 
“成功页面 
交易成功”&＃xff0c;这个串中“成功”分量非常大&＃xff0c;导致

结果排序有点糟糕。

    
Dismaqueryparse覆盖lucenequeryparse全部功能&＃xff0c;同时提供更丰富的查询相关性设置, 
分词内部关系式OR

&＃xff0c;一定能保证有结果&＃xff0c;

配饰使用方法&＃xff0c;在solrconfig.xml  requesthandler

中配置 edismax

Phrasequery 
不启用&＃xff0c;一种方法是schema
verison定义为1.4就可以了&＃xff0c;另外是
fieldtype中显示定义不生成&＃xff0c;同时solrconfig中配置lucene 
版本34

问题背景

使用paoding分词&＃xff0c;默认AND 
&＃xff0c;autogeneralPhrasequery
&＃61; true

搜“交易成功 
幻灯片” 
没有结果       --》AND之后幻灯片部分没有结果导致没有结果

搜“交易成功” 
有结果 

搜“幻灯片” 
没有结果----》原因是分词交叉

使用paoding分词&＃xff0c;autogeneralPhrasequery &＃61; false

搜“交易成功 
幻灯片” 
有结果        

结果来自交易成功部分

搜“交易成功”        有结果

搜“幻灯片”          没有结果      

交叉依然没有结果

使用paoding分词&＃xff0c;autogeneralPhrasequery &＃61; false  扩展OR

搜“交易成功 
幻灯片” 
扩展为 
“交易成功 
幻灯片” OR  “交易成功

幻灯片”    有结果&＃xff0c;结果排序严重受关键词、索引影响

搜“交易成功”        扩展为“交易成功”
OR   “

交易成功”   有结果
  多余IO出现了

搜“幻灯片”          扩展为“幻灯片”
  OR
 “

幻灯片”   有结果  

结果排序与期望相差很远&＃xff0c;排在一起的没在前面