[Elasticsearch] 控制相关度 (三) - 通过查询结构调整相关度以及boosting查询

本章翻译自Elasticsearch官方指南的Controlling
Relevance
一章。

通过查询结构调整相关度

ES提供的查询DSL是相当灵活的。你可以通过将单独的查询子句在查询层次中上下移动来让它更重要/更不重要。比如,下面的查询:

quick OR brown OR red OR fox

我们可以使用一个bool查询,对所有词条一视同仁:

GET /_search
{
  "query": {
    "bool": {
      "should": [
        { "term": { "text": "quick" }},
        { "term": { "text": "brown" }},
        { "term": { "text": "red"   }},
        { "term": { "text": "fox"   }}
      ]
    }
  }
}

但是这个查询会给一份含有quick,red及brown的文档和一份含有quick,red及fox的文档完全相同的分数,然而在合并查询(Combining
Queries)
中,我们知道bool查询不仅能够决定一份文档是否匹配,同时也能够知道该文档的匹配程度。

下面是更好的查询方式:

GET /_search
{
  "query": {
    "bool": {
      "should": [
        { "term": { "text": "quick" }},
        { "term": { "text": "fox"   }},
        {
          "bool": {
            "should": [
              { "term": { "text": "brown" }},
              { "term": { "text": "red"   }}
            ]
          }
        }
      ]
    }
  }
}

现在,red和brown会在同一层次上相互竞争,而quick,fox以及red或者brown则是在顶层上相互对象的词条。

我们已经讨论了match,multi_match,term,book以及dis_max是如何对相关度分值进行操作的。在本章的剩余部分,我们会讨论和相关度分值有关的另外三种查询:boosting查询,constant_score查询以及function_score查询。

不完全的不(Not Quite Not)

在互联网上搜索"苹果"也许会返回关于公司,水果或者各种食谱的结果。我们可以通过排除pie,tart,crumble和tree这类单词,结合bool查询中的must_not子句,将结果范围缩小到只剩苹果公司:

GET /_search
{
  "query": {
    "bool": {
      "must": {
        "match": {
          "text": "apple"
        }
      },
      "must_not": {
        "match": {
          "text": "pie tart fruit crumble tree"
        }
      }
    }
  }
}

但是有谁敢说排除了tree或者crumble不会将一份原本和苹果公司非常相关的文档也排除在外了呢?有时,must_not过于严格了。

boosting查询

boosting查询能够解决这个问题。它允许我们仍然将水果或者食谱相关的文档考虑在内,只是会降低它们的相关度
- 将它们的排序更靠后:

GET /_search
{
  "query": {
    "boosting": {
      "positive": {
        "match": {
          "text": "apple"
        }
      },
      "negative": {
        "match": {
          "text": "pie tart fruit crumble tree"
        }
      },
      "negative_boost": 0.5
    }
  }
}

它接受一个positive查询和一个negative查询。只有匹配了positive查询的文档才会被包含到结果集中,但是同时匹配了negative查询的文档会被降低其相关度,通过将文档原本的_score和negative_boost参数进行相乘来得到新的_score。

因此,negative_boost参数必须小于1.0。在上面的例子中,任何包含了指定负面词条的文档的_score都会是其原本_score的一半。

时间: 2024-10-05 23:27:13

[Elasticsearch] 控制相关度 (三) - 通过查询结构调整相关度以及boosting查询的相关文章

[Elasticsearch] 邻近匹配 (三) - 性能,关联单词查询以及Shingles

提高性能 短语和邻近度查询比简单的match查询在性能上更昂贵.match查询只是查看词条是否存在于倒排索引(Inverted Index)中,而match_phrase查询则需要计算和比较多个可能重复词条(Multiple possibly repeated)的位置. 在Lucene Nightly Benchmarks中,显示了一个简单的term查询比一个短语查询快大概10倍,比一个邻近度查询(一个拥有slop的短语查询)快大概20倍.当然,这个代价是在搜索期间而不是索引期间付出的. TIP

[Elasticsearch] 控制相关度 (二) - Lucene中的PSF(Practical Scoring Function)与查询期间提升

本章翻译自Elasticsearch官方指南的Controlling Relevance一章. Lucene中的Practical Scoring Function 对于多词条查询(Multiterm Queries),Lucene使用的是布尔模型(Boolean Model),TF/IDF以及向量空间模型(Vector Space Model)来将它们结合在一起,用来收集匹配的文档和对它们进行分值计算. 像下面这样的多词条查询: GET /my_index/doc/_search { "que

[Elasticsearch] 控制相关度 (一) - 相关度分值计算背后的理论

本章翻译自Elasticsearch官方指南的Controlling Relevance一章. 控制相关度(Controlling Relevance) 对于仅处理结构化数据(比如日期,数值和字符枚举值)的数据库,它们只需要检查一份文档(在关系数据库中是一行)是否匹配查询即可. 尽管布尔类型的YES|NO匹配也是全文搜索的一个必要组成,它们本身是不够的.我们还需要知道每份文档和查询之间的相关程度.全文搜索引擎不仅要找到匹配的文档,还需要根据相关度对它们进行排序. 全文搜索相关度的公式,或者被称为

[Elasticsearch] 全文搜索 (三) - match查询和bool查询的关系,提升查询子句

match查询是如何使用bool查询的 现在,你也许意识到了使用了match查询的多词查询只是简单地将生成的term查询包含在了一个bool查询中.通过默认的or操作符,每个term查询都以一个k语句被添加,所以至少一个should语句需要被匹配.以下两个查询是等价的: { "match": { "title": "brown fox"} } { "bool": { "should": [ { "

[Elasticsearch] 控制相关度 (四) - 忽略TF/IDF

本章翻译自Elasticsearch官方指南的Controlling Relevance一章. 忽略TF/IDF 有时我们不需要TF/IDF.我们想知道的只是一个特定的单词是否出现在了字段中.比如我们正在搜索度假酒店,希望它拥有的卖点越多越好: WiFi 花园(Garden) 泳池(Pool) 而关于度假酒店的文档类似下面这样: { "description": "A delightful four-bedroomed house with ... " } 可以使用

ElasticSearch查询 第四篇:匹配查询(Match)

匹配(Match)查询属于全文(Fulltext)查询,不同于词条查询,ElasticSearch引擎在处理全文搜索时,首先分析(analyze)查询字符串,然后根据分词构建查询,最终返回查询结果.匹配查询共有三种类型,分别是布尔(boolean).短语(phrase)和短语前缀(phrase_prefix),默认的匹配查询是布尔类型,这意味着,ElasticSearch引擎首先分析查询字符串,根据分析器对其进行分词,例如,对于以下match查询: "query":{ "ma

微服务业务开发三个难题-拆分、事务、查询(下)

上集我们阐述了使用微服务体系架构的关键障碍是领域模型,事务和查询,这三个障碍似乎和功能拆分具有天然的对抗.只要功能拆分了,就涉及这三个难题. 然后我们向你展示了一种解决方案就是将每个服务的业务逻辑实现为一组DDD聚合.然后每个事务只能更新或创建一个单独的聚合.然后通过事件来维护聚合(和服务)之间的数据一致性. 在本集中,我们将会向你介绍使用事件的时候遇到了一个新的问题,就是怎么样通过原子方式更新聚合和发布事件.然后会展示如何使用事件源来解决这个问题,事件源是一种以事件为中心的业务逻辑设计和持久化

最最最最最最最最基础的C---数据类型与运算符,三种基本结构,语句

算法处理的对象是数据,数据是以某种特定的形式存在的 数据类型 1字节(byte)=8位 基本数据类型: 整型  (short2字节, int 4字节, long 4字节) 浮点型(float 4字节.double 8字节,long double 16字节) 字符型(char 8字节) 布尔型(bool true(1)&flase(0)) 枚举类型(enum) 构造数据类型:数组类型,    结构体类型(struct)  共用体类型(union) 其他:        指针类型(*)    空类型

ElasticSearch操作实例大全---文档结构操作(2)

接上一篇ElasticSearch操作实例大全---文档结构操作(1) 前提条件--开发环境已安装 (自行百度) 客户端用的是nest 学习elasticSearch主要是要掌握像sqlserver要会操作数据结构的增删改和数据的增删改查,这里主要写elasticSearch的文档结构操作和文档数据操作 一.如果你已经建好了索引,但是需求改变需要新增一个字段,那就改了之后要进行映射,映射主要是确定字段的数据类型 /// <summary> /// 创建mapping /// </summ