需求:

个性化得分排序：类似 Score=
defaultTextScore*facetA + offlineValue*（1-factorA）

方案：

目前直接支持的排序、全部候选方案。推荐1 
和2. 
参见样例！

1: sort by
(score,
offlinevalue*fa)   

这里offlinevalue*fa

中fa可要可不要

2: sort by
(score*fa +offlinevalue*fb) 
这里score *fa

其中fa有很多理解，可要是document boost或者field boost  
或者payload，offline可以是域值

3: sort by
(score*offlinevalue*fa)   

这个场景本质上回到了 score*fa了，又回到了payload 
或者document或者field boost了。

4: sort
by( score * payload |doc_boost | field_boost| term_boost|
queryboost)

需求背景：文本相关第一位的，在文本相关区分度不大的时候，需要将好的商品、或者服务信息优先排（这里仍然受限第一排序文本相关分限制，如果放弃第一维度，只有第二维度的离线分值，那么文本相关性可能非常糟糕，反应到用户就是关键词
不显眼，好的离线值一直占住排头，出现饥饿现象）

进一步扩展，例如topN 先不排序，然后按某种方式排序、实现去重的维度的结果。

分析

1
 最直接，也是推荐的方式。

3-4一回事，只是实现方式上不同：

2

看起来就显得稍微复杂了，其中fa的理解也有多重，

一种fa不是boost(documentsfieldpayload
),而是外部直接传入的。从数学公式角度看一码事。

Eg
tf*itf*payload = score  score*fa
=tf*itf*payload*fa, 
合并fa8payload

就是一项信息了，

同理，offline*fb
 离线计算好就是offline’了，还是offline 
了。这样2

简化为 score+offline了

从上分析来看，只有2种，要么1 
，要么2，

对应2本质是
score+offlinevalue，所谓的因子只是“逻辑理解”，对应实现来说“完全隐去了”

样例Score+offline

query.set("defType","lucene");

query.setQuery("description:店铺
AND _val_:reord_gpa^0.7");

query.setQuery("description:店铺
AND
_val_:sum\(reord_gpa,1\)");

query.setQuery("(description:店铺)^0.3 AND
_val_:sum\(reord_gpa,1\)");

至于: score

中的因子，如果固定0.8，然后所有文档都* 0.8，实际上就等于没起作用。这个0.8 
可以payload或者doc或者field boost引入。

至于:
gpa中的因子，如果固定0.2，那么就直接在离线计算时算好

另外 
在3.*版本中

query.setQuery("title:Aokang");

      
query.add("sort","sum(weight1,query({!dismax qf=title
v='杭州'}))
desc");

      
query.addField("title,score,weight1,weight2,query({!dismax
qf=title v='杭州'}))");

这种新式，是针对局部query得分处理的

木有排序计算，直接返回topN，性能考虑

query.set("sort","_docid_ asc");

注解:BoostQParse,将boost值乘上默认得分上，而一般_val_是将得分add 
到默认文本分上。
目前基于3.* 
序列，尚不能直接对默认文本分进行引入到function中，在4.*可以引用默认得分的中间参数到function中。
目前3.* 可以将function值加上或者乘上默认文本分（dismax的pb)，或者局部query得分作为function的参数

最基础的 payload、documentboost、 fieldboost 、tf、itf 仍然是最本质的因子。
其他的扩展仍然是围绕他们展开的。本质没有脱离向量模型。