lucene3.0.3中的CustomerScoreQuery

      我原本以为我已经把lucene3.0.3看的很详细了,结果发现漏了一个很重要的query——CustomerScoreQuery,从名字上看表示用户自定义得分的query,我表示很好奇,因为我花了好大力气才明白了lucene的得分公式,貌似这里竟然可以自己写得分公式了,于是我抱着极大的好奇心看了他的源码,记录在此,方便大家。

     CustomerScoreQuery的原理是这样的,它包含一个主query以及一个或者多个valueScourceQuery,主query和我们平时的query是一样的,可以是任意的query的子类,valueSourceQuery是用来完成我们自定义得分的,他不会进行召回,召回是主query的功能,对于主query召回的的每一个doc,valueSourceQuery可以对其得分进行修改,修改的规则由CustomerScoreQuery配置的CustomScoreProvider设置,他的主要思想就是这样。ValueSourceQuery对doc的得分的修改是根据其内部的ValueSource属性来设置的,我们从这个ValueSouce下手。

      ValueSource:这个类是个抽象类,他最关键的方法是DocValues getValues(IndexReader reader),他表示从指定的reader中获得的对于每一个doc的值,用DocValues进行封装,DocValues也是一个抽象类,通过调用它的floatVal(int doc)、intVal(int doc)来获得每一个doc的值,这个值就可以影响最终的doc的打分。我们看一个ValueSource的实现类FieldCacheSource,它的逻辑是从词典表中获得每一个doc对应的term,然后根据term进行打分,所以他必须执行一个域(即term所在的域),并且这个域必须建立索引且不能分词(这个和之前的FieldCache的逻辑是一样的)。他对getValues的实现是这样的:

 

/**
 * 获得当前的段下当前的域的值,通过DocValues封装,和Sort是一个逻辑。
 */
@Override
public final DocValues getValues(IndexReader reader) throws IOException {
	return getCachedFieldValues(FieldCache.DEFAULT, field, reader);//这里的field就是我们说的term所在的域的名字。
}

 FieldCacheSource类也是一个抽象类,他的getCachedFieldValues没有实现,我们看一个他的实现类:IntFieldSource.getCachedFieldValues(FieldCache, String, IndexReader),即将每个doc所对应的某个域中的term转换为一个int类型的整数的类,他的逻辑和我们在FieldCache中介绍的是一样,代码如下:

 

@Override
public DocValues getCachedFieldValues(FieldCache cache, String field, IndexReader reader) throws IOException {
	final int[] arr = cache.getInts(reader, field, parser);//将FieldCache中当前的reader下的field域的term用parser转换为int,
	return new DocValues() {
		@Override
		public float floatVal(int doc) {
			return (float) arr[doc];
		}
		@Override
		public int intVal(int doc) {
			return arr[doc];
		}
		@Override
		public String toString(int doc) {
			return description() + '=' + intVal(doc);
		}
		@Override
		Object getInnerArray() {
			return arr;
		}
	};
}

 这样就能获得最终的DocValues了,ValueSource的最终目的就是获得DocValues,然后我们再看一下ValueSourceQuery的过程。

      一个Query最重要的就两个,一个是召回doc(doc的召回是scorer的功能),一个是对召回的doc的打分(打分是weight和scorer的功能),也就是生成weight、scorer的方法,ValueSourceQuery的最终生成的Scorer是ValueSourceScorer,其里面的termDocs是一个AllTermDocs,也就是从所有的域中获得term的termDocs,从这里可以看出valueSourceQuery是如何召回的doc了,只不过他是召回了所有的doc(也就是说他召回的doc实际上是没有用的)。我们再看一下ValueSourceScorer的得分的计算也就是其score方法

 

/* (non-Javadoc) @see org.apache.lucene.search.Scorer#score() */
@Override
public float score() throws IOException {
	return qWeight * vals.floatVal(termDocs.doc());//这里的vals就是从ValueSourceQuery中获得的ValueSource属性
}

 他的得分的计算是通过DocValues来计算的,也就是将缓存的term转换为数字来作为得分,还有个qWeight,他是weight计算出来的值,在默认的情况下他是1,因为他是由ValueSourceQuery的getBoost来计算的(计算出来是1)。这样我们搞懂了ValueSourceQuery最终的功能是召回所有的doc,并将每个doc的term解析为数字作为得分的。接下来我们回到CustomerScoreQuery来看一下他是如何召回doc和计算得分的。

      召回doc和得分都是在CustomerScoreQuery最终生成的Scorer——CustomScorer中计算的,我们看一下召回的方法nextDoc,代码:

 

/** 查找下一个doc时是优先调用subQueryScorer的id,然后让各个valueSource也指向这个doc*/
@Override
public int nextDoc() throws IOException {
   int doc = subQueryScorer.nextDoc();//先根据主query来召回doc,
   if (doc != NO_MORE_DOCS) {//如果召回了
        for (int i = 0; i < valSrcScorers.length; i++) {
   	    valSrcScorers[i].advance(doc);//将每一个ValueSourceQuery的scorer都前进到主query召回的doc,
	}
   }
   return doc;
}

 可以看出召回是根据主query召回的,我们看一下打分:

 

@Override
public float score() throws IOException {
	for (int i = 0; i < valSrcScorers.length; i++) {
		vScores[i] = valSrcScorers[i].score();//计算当前的doc下所有的valueSourceScorer的得分
	}
	return qWeight * provider.customScore(subQueryScorer.docID(), subQueryScorer.score(), vScores);//最终的得分要看provider的实现。
}

 provider通过CustomerScoreQuery的getCustomScoreProvider方法获得,这个类决定了如何计算最终的得分,他的customScore方法:

 

@Deprecated
public float customScore(int doc, float subQueryScore, float valSrcScores[]) {
if (valSrcScores.length == 1) {
	return customScore(doc, subQueryScore, valSrcScores[0]);//如果只要一个valueSourceQuery,是将两个的得分相乘,
}
if (valSrcScores.length == 0) {
	return customScore(doc, subQueryScore, 1);//如果没有valueSourceQuery,则直接返回subQuerScore,乘以1和没乘一样。
}
float score = subQueryScore;
for (int i = 0; i < valSrcScores.length; i++) {//如果有多个,是将所有的得分乘起来。
	score *= valSrcScores[i];
}
return score;
}

 通过上面的分析我们知道了customerScorerQuery的来龙去脉,他就是通过valueSource对通过主Query召回的doc的打分进行修改。那么他的用处是什么呢,我们可以做什么拓展呢?我的理解是我们可以通过对得分进行修改,来影响排序,在CustomerScoreQuery的javadoc中也对此进行了说明:可以通过几成CustomerScoreQuery复写其getCustomScoreProvider方法来实现自己的CustomScoreProvider来实现最终的得分的计算,比如我们在搜电商网站中的商品的时候,对于刚上架的商品要比上架很久的商品排在前面,或者新上架的排在后面,就可以通过自己实现一个CustomScoreProvider,用当前的时间减去doc的上架时间作为一个得分的计算方式,然后再和主query的得分通过一定的方式结合起来做出最后的得分。

 

 

 

      

      

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值