一、需求
因为需要对搜索结果进行一个统一化的评分，因此需要仔细研究ES本身的评分规则从而想办法把评分统一。
省流：无法确切统一化
二、ES查询评分规则
之前有说过ES的查询评分原理，那么仔细思考之后就会发现，长文本搜索对应的score会比短文本搜索的score高很多：score=单个分词评分之和，长文本对应的词更多那么score就会更多。
通过在查询中设置参数”explain”:true来查看具体的分数来源(explain的输出代价较大。它只是一个调试工具。不要让在生产中使用)：
1.查询分数基本结构
request：
post http://localhost:9200/policy_index/_search
{
"size": 20,
"query": {
"match": {
"policyTitle": {
"query": "青年大学习"
}
}
},
"explain": true
}response：
可以看到结果集中的一条结果explanation中就是评分的具体信息：
score(总分)=15.48946=score_value(“青年”)+score_value(“大学”)
policyTitle本身存入时和查询时使用的都是ik_max_word分词器(不单独指定search_analyzer即查询默认使用analyzer对应的分词器)，为细粒度划分，“青年大学习”被拆分为多个(可以通过切换分词器或自定义专业词库的形式避免，这里仅做评分解析就不管了)
上面的查询结果中被拆分为青年+大学，根据分词结果，青年+学习也是可以被检索到的(三者都有也行)：
即查询请求会根据分词器在ES内部被重写为以下结构：
"bool": {
"should": [
{
"term": { "policyTitle": "青年" }},
{
"term": { "policyTitle": "大学" }},
{
"term": { "policyTitle": "学习" }}
]
}
}2.单独分词分数
参考：
博客：https://www.cnblogs.com/wangchuanfu/p/7452809.html
官方文档：https://www.elastic.co/guide/en/elasticsearch/guide/master/relevance-intro.html
https://www.elastic.co/guide/en/elasticsearch/guide/master/scoring-theory.html
单独查看第一篇文档中”青年”的得分：9.51721
score(freq=2.0), computed as boost * idf * tf from:
即score=boost * idf * tf
具体参数：
(一)TF/IDF评分模型
(1)tf--频率
该术语在本文档中出现的频率如何？次数越多，分数越高
如果您不关心术语在字段中出现的频率，而您只关心该术语是否存在，那么您可以在字段映射中禁用术语频率：
(2)idf--逆文档频率
该术语在集合中的所有文档中出现的频率是多少？次数越多，分数越低
(二)向量空间评分模型
具体见官网：https://www.elastic.co/guide/en/elasticsearch/guide/master/scoring-theory.html#vector-space-model
介绍：
向量空间模型提供了一种将多项查询与文档进行比较的方法。输出是一个单一的分数，表示文档与查询的匹配程度。为了做到这一点，模型将文档和查询都表示为向量。
向量实际上只是一个包含数字的一维数组，例如：
[1,2,5,22,3,8]在向量空间模型中，向量中的每个数字都是一个词的权重，用词频/逆文档频率计算(词语越稀有，权重越大)。
(虽然 TF/IDF 是计算向量空间模型项权重的默认方法，但它不是唯一的方法。其他模型如 Okapi-BM25 存在并且在 Elasticsearch 中可用。TF/IDF 是默认值，因为它是一种简单、高效的算法，可以产生高质量的搜索结果，并且经受住了时间的考验。)
待匹配内容会根据数组向量形成一条线，而文档中与其匹配的内容也会形成对应的线，那么线越靠近就说明结果越匹配。
(三)实用评分函数
对于多项查询，Lucene 采用布尔模型、 TF/IDF和向量空间模型，并将它们组合在一个高效的包中，一旦文档与查询匹配，Lucene 就会计算该查询的分数，并结合每个匹配项的分数。用于评分的公式称为实用评分函数。
score(q,d) =
queryNorm(q)
· coord(q,d)
· ∑ (
tf(t in d)
· idf(t)²
· t.getBoost()
· norm(t,d)
) (t in q)
1.queryNorm--查询规范化因子
是对查询进行规范化的一种尝试，以便可以将一个查询的结果与另一个查询的结果进行比较。
尽管查询规范的目的是使不同查询的结果具有可比性，但效果并不理想。相关性_score的唯一目的是按照正确的顺序对当前查询的结果进行排序。您不应该尝试比较来自不同查询的相关性分数。
每个文档的查询规范化因子相同，无法更改。
2.coord--协调因子
用于奖励包含较高百分比查询词的文档。文档中出现的查询词越多，文档与查询匹配的可能性就越大，分数越高。
也就是同时包含“青年”“大学”“学习”的文档的分数不仅仅是三者相加的分数，而是会使用协调因子将分数乘以文档中匹配项的数量，然后除以查询中的项总数。
3.tf--词频
4.idf--逆文档频率
5.t.getBoost()--查询提升
用于增加查询中某个字段的重要性：https://www.elastic.co/guide/en/elasticsearch/guide/master/query-time-boosting.html
6.norm--场长范数
字段有多长？字段越短，权重越高。
如果一个术语出现在一个短字段中，那么与同一个术语出现在一个更大的字段中相比，认为更匹配，分数更高。
3.总结
查询分数=分词分数之和
分词分数=boost提升*tf词语出现频率*idf词语在所有文档的此字段中出现频率，其他的参数根据需求设定
三、ES自定义评分规则
即function_score，这个之前有比较详细的讲解，更具体的案例应用和参数讲解见官网：https://www.elastic.co/guide/en/elasticsearch/guide/master/function-score-query.html
在我的案例中使用的是在policyTitle+textContent中查询词语，并根据省份+分类得到一个比例与查询分数进行相乘的形式来计算score，发送query请求并explain查看是否符合我们设定的需求：
总分：39.185825
1.查询得分：10.312058
由词语在policyTitle和textContent中的分数之和组成，正常√
2.自定义得分：3.8000002
由script_score和衰减函数linear的得分2.8+1组成，正常√
其中script_score由分类决定，如果分类与用户的用户画像分类匹配，返回指定权重的分数，用户画像由类似
{金融贸易=0.70000005, 医疗健康=0.1, 其他=0.1, 工业=0.1}形式构成，说明用户常看金融类，那么金融类的得分会更高。
总分=查询得分*自定义得分，正常√，这样就会让符合条件的文档分数大幅提高
3.测试
上面查询的是一个没有特别属性的中义词，会返回令人满意的结果，下面搜索一些具有特殊省份、分类的词语，观察function_score是否会因为设定的省份和分类而极大影响，导致返回不合理的结果。
(1)特殊省份
根据分类判断，正常√
(2)特殊分类
这里发现省份和分类的影响还是很大的
除非查询本身的分数很高，否则会更倾向于符合function中分类和省份的结果。。
搜索：工业废水
(3)特殊省份+特殊分类
这里体现的更明显，由于省份分数为0/1，在查询时甚至完全忽略省份，完全由分类决定
搜索：北京工业废水
考虑控制分类的返回值不超过1.5，尽管用户可能在某一个分类中经常浏览，但是为了避免搜素结果过多的由分类决定而导致查询的结果不理想，于是进行一定的权重控制。控制不匹配分类等的最低返回值为1，这样即使分类、省份都不匹配，如果查询得分很高依然不会受到太大影响，不至于让用户完全无法看到这样的结果。
这样一来，保证function无论如何在1-2.5之间。(考虑通过衰减因子改变省份的值，例如不再是0/1，而是0/0.5，从而减小省份的影响，形成1-2的function分数--最终选择的方案)
(4)修改后再次查询
①特殊分类：工业废水
文档相关性占比很大，分类和省份占比(1-2)
②特殊省份+特殊分类：北京工业废水
这里发现由于在文档中查询“北京工业废水”，由于查询分数不会专注于“北京”，因此往往会按照“工业废水”的高评分*自定义评分来得到高分，暂时想到的解决是：
1.如果涉及特殊省份的查询，引导用户自己单独选中侧边栏的省份选项后再查询(告知用户这样搜索效果更好)
2.去除TF词频的影响，即不在意词语在文档中出现了多少次，只在意是否出现，那么就可以比较好的保证文档中能出现大部分的搜索语句，但是这个就涉及到用户希望出现的结果是什么样的，需要考虑。
四、总结
总之，score=查询得分(分词得分之和)与自定义得分综合计算的结果，其中查询得分涉及比较多，不太好改，而且考虑到查询结果对不同用户的得分观感都是不一样的，不可能用匹配度之类的确切结果进行描述，于是选择以排名第一的结果为100分，将分数称为“推荐指数”等形式的主观词汇，当然后续根据用户体验还会尝试修改，目前想到的解决方案就是这样了。