字段中心式查询编辑

以上三个源于 most_fields 的问题都因为它是 字段中心式(field-centric) 而不是 词中心式(term-centric) 的:当真正感兴趣的是匹配词的时候,它为我们查找的是最匹配的 字段

注意

best_fields 类型也是字段中心式的, 它也存在类似的问题。

首先查看这些问题存在的原因,再想如何解决它们。

问题 1 :在多个字段中匹配相同的词编辑

回想一下 most_fields 查询是如何执行的:Elasticsearch 为每个字段生成独立的 match 查询,再用 bool 查询将他们包起来。

可以通过 validate-query API 查看:

GET /_validate/query?explain
{
  "query": {
    "multi_match": {
      "query":   "Poland Street W1V",
      "type":    "most_fields",
      "fields":  [ "street", "city", "country", "postcode" ]
    }
  }
}

生成 explanation 解释:

(street:poland   street:street   street:w1v)
(city:poland     city:street     city:w1v)
(country:poland  country:street  country:w1v)
(postcode:poland postcode:street postcode:w1v)

可以发现, 两个 字段都与 poland 匹配的文档要比一个字段同时匹配 polandstreet 文档的评分高。

问题 2 :剪掉长尾编辑

匹配精度 中,我们讨论过使用 and 操作符或设置 minimum_should_match 参数来消除结果中几乎不相关的长尾,或许可以尝试以下方式:

{
    "query": {
        "multi_match": {
            "query":       "Poland Street W1V",
            "type":        "most_fields",
            "operator":    "and", 
            "fields":      [ "street", "city", "country", "postcode" ]
        }
    }
}

所有词必须呈现。

但是对于 best_fieldsmost_fields 这些参数会在 match 查询生成时被传入,这个查询的 explanation 解释如下:

(+street:poland   +street:street   +street:w1v)
(+city:poland     +city:street     +city:w1v)
(+country:poland  +country:street  +country:w1v)
(+postcode:poland +postcode:street +postcode:w1v)

换句话说,使用 and 操作符要求所有词都必须存在于 相同字段 ,这显然是不对的!可能就不存在能与这个查询匹配的文档。

问题 3 :词频编辑

什么是相关 中,我们解释过每个词默认使用 TF/IDF 相似度算法计算相关度评分:

词频
一个词在单个文档的某个字段中出现的频率越高,这个文档的相关度就越高。
逆向文档频率
一个词在所有文档某个字段索引中出现的频率越高,这个词的相关度就越低。

当搜索多个字段时,TF/IDF 会带来某些令人意外的结果。

想想用字段 first_namelast_name 查询 “Peter Smith” 的例子, Peter 是个平常的名 Smith 也是平常的姓,这两者都具有较低的 IDF 值。但当索引中有另外一个人的名字是 “Smith Williams” 时, Smith 作为名来说很不平常,以致它有一个较高的 IDF 值!

下面这个简单的查询可能会在结果中将 “Smith Williams” 置于 “Peter Smith” 之上,尽管事实上是第二个人比第一个人更为匹配。

{
    "query": {
        "multi_match": {
            "query":       "Peter Smith",
            "type":        "most_fields",
            "fields":      [ "*_name" ]
        }
    }
}

这里的问题是 smith 在名字段中具有高 IDF ,它会削弱 “Peter” 作为名和 “Smith” 作为姓时低 IDF 的所起作用。

解决方案编辑

存在这些问题仅仅是因为我们在处理着多个字段,如果将所有这些字段组合成单个字段,问题就会消失。可以为 person 文档添加 full_name 字段来解决这个问题:

{
    "first_name":  "Peter",
    "last_name":   "Smith",
    "full_name":   "Peter Smith"
}

当查询 full_name 字段时:

  • 具有更多匹配词的文档会比只有一个重复匹配词的文档更重要。
  • minimum_should_matchoperator 参数会像期望那样工作。
  • 姓和名的逆向文档频率被合并,所以 Smith 到底是作为姓还是作为名出现,都会变得无关紧要。

这么做当然是可行的,但我们并不太喜欢存储冗余数据。取而代之的是 Elasticsearch 可以提供两个解决方案——一个在索引时,而另一个是在搜索时——随后会讨论它们。