需求:
个性化得分排序：类似 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 仍然是最本质的因子。
其他的扩展仍然是围绕他们展开的。本质没有脱离向量模型。
