自定义评分器Similarity,提高搜索体验

首先说一下lucene对文档的评分规则:

 

score(q,d)   =   coord(q,d) ·  queryNorm(q) · ( tf(t in d) ·  idf(t)2 ·  t.getBoost() ·  norm(t,d) )

具体可以查看相关文章:http://blog.chenlb.com/2009/08/lucene-scoring-architecture.html

 

这里先考虑三个因素coord(q,d)与tf(t in d),当查询串中,命中的词越多,coord计算的值则越大,某个词在文档中出现的次数越多则tf的值越大。还有就是norm(t,d),这个主要是文档boost与字段boost的影响。值越大,对整体评分的影响越重。

首先说tf对搜索结果的影响:

这里是在于本站使用的搜索评分开始是默认的评分器的情况下,但发现有些不足之处。因为站内搜索主要是视频的标题与标签。对于一个视频文档来说,标题或者与标签重复的词本身就是无意义的,比如标题为"美女美女美女美女",标签为“美女”,如果让tf 的作用变大,明显示会使得它的评分更大,而其实并不是视频网站想要的效果。因为我们更想让它更加发散,这样,用户的点击率才会高。所以我们应该让所有命中词的文档的tf 不受频率的影响,使其tf=1.0f;如下自定义的评分器

 

 

 

/** * @author yuzhy * 实现自已的评分器 * 文档中重复多少个词不影响分数 * */ public class MySolrSimilarity extends DefaultSimilarity { @Override public float tf(float freq) { return 1.0f; } @Override public float tf(int freq) { return 1.0f; } }

 

别小看这段代码 ,因为使用这种评分,对于一个文档来说,一个term在文档出现的频率并不影响,即是不用担心作弊的情况,因为在这方面上他们的分数都是一样的。之前还考虑了对标题与标签的重复字符串的处理,采用后缀树结构来处理公共子串,后来发现这种方法来得更简洁。

因为使用的是solr来作搜索服务来架构,所以首先修改solr默认的Similarity类。在solr 的配置文件schemal.xml,最后中修改或增加:

 

<similarity class="com.wole.solr.search.MySimilarity"/>

 

设置为自定义的评分器,重启solr服务后,自定义的评分器就生效了。搜索" 美女"后,不再出现“美女美女美女美女”文档靠前排的效果了。

 

 

 

接着说一下coord的影响:

搜索“htc Incredible S” 三个词,由于没有这完全命中,则使用了宽松规则,即命中一个词也返回进行排序,之前的评分,前几条的结果为:

 

<doc> <str name="Subject">S.H.E爱而为一的魔力 幕后全纪录</str> <str name="tag">she selina hebe ella 爱而为一</str> <int name="public_time">1103150000</int> <int name="times">370</int> <int name="hd">1</int> </doc> − <doc> <str name="Subject">1000种死法-S04-01.1024X576.x264</str> <str name="tag">1000种死法 </str> <int name="public_time">1103140000</int> <int name="times">692</int> <int name="hd">1</int> </doc> − <doc> <str name="Subject">p-s-1</str> <str name="tag"> </str> <int name="public_time">1103150000</int> <int name="times">58</int> <int name="hd">1</int> </doc>  

 

 

可以看到,命中的词S 的文档给排到较前,本应该让命中越来的词的文档分数更高,但因为这三个文档在其它方面影响到评分,使得它的最后分数高于命中多个词的文档,而排到最前,所以这样的搜索体验不够好,好的体验应该是让命中的词越多排得越高,所以我首先降低计算norm(t,d)的值。测试调了其权重值,让coord占更大的比例值,效果马上出来更好的,其前三条记录为:

 

<doc> <str name="Subject">不可思议htc Incredible 对比 apple iphone4</str> <str name="tag">Incredible htc apple iphone4 苹果</str> <int name="public_time">1009250000</int> <int name="times">29758</int> <int name="hd">0</int> </doc> − <doc> <str name="Subject">不可思议 htc Incredible 比拼 苹果 iphone 3gs</str> <str name="tag">不可思议 Incredible htc 苹果 apple</str> <int name="public_time">1009250000</int> <int name="times">20231</int> <int name="hd">0</int> </doc> − <doc> <str name="Subject">HTC incredible拆解全过程</str> <str name="tag">手机 HTC incredible DROID系列 </str> <int name="public_time">1005030000</int> <int name="times">3649</int> <int name="hd">0</int> </doc>

 

这里命中两个词htc Incredible的文档给排到最前面来,显然这才更符合用户需要的。即使没有完全命中,它的相关性会更逼近。

 

最后讲一下norm(t,d):

 

没有norms 意味着
索引阶段禁用了文档boost 和域的boost 及长度标准化。好处在于节省内存,不用在搜索阶
段为索引中的每篇文档的每个域都占用一个字节来保存norms 信息了。但是对norms 信息
的禁用是必须全部域都禁用的,一旦有一个域不禁用,则其他禁用的域也会存放默认的
norms 值。因为为了加快norms 的搜索速度,Lucene 是根据文档号乘以每篇文档的norms
信息所占用的大小来计算偏移量的,中间少一篇文档,偏移量将无法计算。也即norms 信
息要么都保存,要么都不保存。

 

norm(t,d) 压缩几个索引期间的加权和长度因子:

  • Document boost - 文档加权,在索引之前使用 doc.setBoost()
  • Field boost - 字段加权,也在索引之前调用 field.setBoost()
  • lengthNorm(field) - 由字段内的 Token 的个数来计算此值,字段越短,评分越高,在做索引的时候由 Similarity.lengthNorm 计算。

以上所有因子相乘得出 norm 值,如果文档中有相同的字段,它们的加权也会相乘:

norm(t,d)   =   doc.getBoost() ·  lengthNorm(field) · f.getBoost()

field f in d named as t

 

 

 

 

搜索组件为dismax,其中文档bf的计算是由三个字段

 

public_time (视频发布时间)^15,times(视频播放数)^15,hd(视频高清)^4

 

字段的bf值为

qf=Subject^1+tag^0.3

 

如果想让coord的值靠前,计算文档 boost 与字段boost  的值应该降低一个级别。

改为:

public_time (视频发布时间)^1.5,times(视频播放数)^1.5,hd(视频高清)^0.4

 

 

这样 norm计算的值就远远小于 coord ,使命中越多词分数越高的效果

 

 

 

 

 

 

 

 

norm(t,d)   =   doc.getBoost() ·  lengthNorm(field) · f.getBoost()

field f in d named as t

你可能感兴趣的:(Solr,Lucene,iPhone,HTC,文档,float)