英文版地址: https://www.elastic.co/guide/en/elasticsearch/guide/current/field-centric.html
本书基于 Elasticsearch 2.x 版本，有些内容可能已经过时。
字段中心式查询edit
以上三个源于 most_fields 的问题都因为它是 字段中心式（field-centric） 而不是 词中心式（term-centric） 的：当真正感兴趣的是匹配词的时候，它为我们查找的是最匹配的 字段 。
best_fields 类型也是字段中心式的，它也存在类似的问题。
首先查看这些问题存在的原因，再想如何解决它们。
问题 1 ：在多个字段中匹配相同的词edit
回想一下 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 匹配的文档要比一个字段同时匹配 poland 与 street 文档的评分高。
问题 2 ：剪掉长尾edit
在 匹配精度 中，我们讨论过使用 and 操作符或设置 minimum_should_match 参数来消除结果中几乎不相关的长尾，或许可以尝试以下方式：
{
"query": {
"multi_match": {
"query": "Poland Street W1V",
"type": "most_fields",
"operator": "and",
"fields": [ "street", "city", "country", "postcode" ]
}
}
}
但是对于 best_fields 或 most_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 ：词频edit
在 什么是相关 中，我们解释过每个词默认使用 TF/IDF 相似度算法计算相关度评分：
- 词频
- 一个词在单个文档的某个字段中出现的频率越高，这个文档的相关度就越高。
- 逆向文档频率
- 一个词在所有文档某个字段索引中出现的频率越高，这个词的相关度就越低。
当搜索多个字段时，TF/IDF 会带来某些令人意外的结果。
想想用字段 first_name 和 last_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 的所起作用。
解决方案edit
存在这些问题仅仅是因为我们在处理着多个字段，如果将所有这些字段组合成单个字段，问题就会消失。可以为 person 文档添加 full_name 字段来解决这个问题：
{
"first_name": "Peter",
"last_name": "Smith",
"full_name": "Peter Smith"
}
当查询 full_name 字段时：
- 具有更多匹配词的文档会比只有一个重复匹配词的文档更重要。
-
minimum_should_match和operator参数会像期望那样工作。 - 姓和名的逆向文档频率被合并，所以 Smith 到底是作为姓还是作为名出现，都会变得无关紧要。
这么做当然是可行的，但我们并不太喜欢存储冗余数据。取而代之的是 Elasticsearch 可以提供两个解决方案——一个在索引时，而另一个是在搜索时——随后会讨论它们。