亲,只收二进制

ES相关度评分不符合预期

Elasticsearch | 作者 ydzll | 发布于2019年10月21日 | 阅读数:474

ES相关度评分有三个参数不太明白,我录入了两条数据,分别为:
{"id":"2","enName":"bad apple can't be eaten"}、{"id":"1","enName":"bad apple"},
根据相关资料,一个字段包含的词项数越少,得分越高,所以我以为搜索"apple"的时候,id为1的数据得分会高于id为2的数据,但是最终结果两条数据得分一致。查看词频(TF)打分公式(freq * (k1 + 1)) / (freq + k1 * (1 - b + b * fieldLength / avgFieldLength)),发现fieldLength和avgFieldLength始终相等,这导致不管字段有多长,最终值都是1.0,这是怎么回事呢?另外查看逆文档频率(IDF),发现语料库的文档总数(docCount)和包含该词的文档数(docFreq)也永远为1.0。各位大佬有知道怎么回事的吗?
已邀请:

ydzll

赞同来自:

es1.png


es2.png

 

hapjin

赞同来自:

给的信息不全,每个shard会计算相应的score的。你要看shard上有哪些文档才行,你这个索引配置的primary shard数量不止一个吧?

laoyang360 - Elastic认证工程师 [死磕Elasitcsearch]知识星球地址:http://t.cn/RmwM3N9;微信公众号:铭毅天下; 博客:https://elastic.blog.csdn.net

赞同来自:

推荐:加上explain:true 解析下。

God_lockin

赞同来自:

应该是文档太少了导致打分不平衡吧

HelloClyde

赞同来自:

加这个参数试试,search_type=dfs_query_then_fetch,但是性能会很差

core_wzw - 某AILab搜索技术负责人

赞同来自:

打分只能发生在具体每个Shard上,因为每个Shard都是一个全局索引,这是引擎设计的,配合建索引阶段Shard文档量负载均衡所有文档时这些参数都会接近相等。
所以,文档量少到一定程度时,有两种方式可以解决参数值不一致的问题:
(1)search_type=dfs_query_then_fetch,相当于计算时会去计算所有Shard上的参数值,实时计算取值,比较慢;
(2)preference=_primary,只在主分片上倒排求交,没有利用副本分片做计算,不算慢。
建议用第二种。

要回复问题请先登录注册