使用阿里云试用Elasticsearch学习：2.6 深入搜索—

处理结构化数据（比如：时间、数字、字符串、枚举）的数据库，只需检查文档（或关系数据库里的行）是否与查询匹配。

布尔的是/非匹配是全文搜索的基础，但不止如此，我们还要知道每个文档与查询的相关度，在全文搜索引擎中不仅需要找到匹配的文档，还需根据它们相关度的高低进行排序。

全文相关的公式或相似算法（similarity algorithms）会将多个因素合并起来，为每个文档生成一个相关度评分 _score 。本章中，我们会验证各种可变部分，然后讨论如何来控制它们。

当然，相关度不只与全文查询有关，也需要将结构化的数据考虑其中。可能我们正在找一个度假屋，需要一些的详细特征（空调、海景、免费 WiFi ），匹配的特征越多相关度越高。可能我们还希望有一些其他的考虑因素，如回头率、价格、受欢迎度或距离，当然也同时考虑全文查询的相关度。

所有的这些都可以通过 Elasticsearch 强大的评分基础来实现。

本章会先从理论上介绍 Lucene 是如何计算相关度的，然后通过实际例子说明如何控制相关度的计算过程。

Lucene 的实用评分函数

对于多词查询， Lucene 使用布尔模型（Boolean model）、 TF/IDF 以及向量空间模型（vector space model），然后将它们组合到单个高效的包里以收集匹配文档并进行评分计算。

一个多词查询

GET /my_index/_search
{
  "query": {
    "match": {
      "text": "quick fox"
    }
  }
}

会在内部被重写为：

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

bool 查询实现了布尔模型，在这个例子中，它会将包括词 quick 和 fox 或两者兼有的文档作为查询结果。

只要一个文档与查询匹配，Lucene 就会为查询计算评分，然后合并每个匹配词的评分结果。这里使用的评分计算公式叫做实用评分函数（practical scoring function）。看似很高大上，但是别被吓到——多数的组件都已经介绍过，下一步会讨论它引入的一些新元素。

score(q,d)  =  
            queryNorm(q)  
          · coord(q,d)    
          · ∑ (           
                tf(t in d)   
              · idf(t)²      
              · t.getBoost() 
              · norm(t,d)    
            ) (t in q)

score(q,d) 是文档 d 与查询 q 的相关度评分。
queryNorm(q) 是查询归一化因子（新）。
coord(q,d) 是协调因子（新）。
查询 q 中每个词 t 对于文档 d 的权重和。
tf(t in d) 是词 t 在文档 d 中的词频。
idf(t) 是词 t 的逆向文档频率。
t.getBoost() 是查询中使用的 boost（新）。
norm(t,d) 是字段长度归一值，与索引时字段层 boost （如果存在）的和（新）。

上节已介绍过 score 、 tf 和 idf 。现在来介绍 queryNorm 、 coord 、 t.getBoost 和 norm 。

我们会在本章后面继续探讨查询时的权重提升的问题，但是首先需要了解查询归一化、协调和索引时字段层面的权重提升等概念。

查询归一因子

查询归一因子（ queryNorm ）试图将查询归一化，这样就能将两个不同的查询结果相比较。

这个因子是在查询过程的最前面计算的，具体的计算依赖于具体查询，一个典型的实现如下：

queryNorm = 1 / √sumOfSquaredWeights

sumOfSquaredWeights 是查询里每个词的 IDF 的平方和。

相同查询归一化因子会被应用到每个文档，不能被更改，总而言之，可以被忽略。

查询协调

协调因子（ coord ）可以为那些查询词包含度高的文档提供奖励，文档里出现的查询词越多，它越有机会成为好的匹配结果。

设想查询 quick brown fox ，每个词的权重都是 1.5 。如果没有协调因子，最终评分会是文档里所有词权重的总和。例如：

文档里有 fox → 评分： 1.5
文档里有 quick fox → 评分： 3.0
文档里有 quick brown fox → 评分： 4.5

协调因子将评分与文档里匹配词的数量相乘，然后除以查询里所有词的数量，如果使用协调因子，评分会变成：

文档里有 fox → 评分： 1.5 * 1 / 3 = 0.5
文档里有 quick fox → 评分： 3.0 * 2 / 3 = 2.0
文档里有 quick brown fox → 评分： 4.5 * 3 / 3 = 4.5

协调因子能使包含所有三个词的文档比只包含两个词的文档评分要高出很多。

回想将查询 quick brown fox 重写成 bool 查询的形式：

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

bool 查询默认会对所有 should 语句使用协调功能，不过也可以将其禁用。为什么要这样做？通常的回答是——无须这样。查询协调通常是件好事，当使用 bool 查询将多个高级查询如 match 查询包裹的时候，让协调功能开启是有意义的，匹配的语句越多，查询请求与返回文档间的重叠度就越高。

但在某些高级应用中，将协调功能关闭可能更好。设想正在查找同义词 jump 、 leap 和 hop 时，并不关心会出现多少个同义词，因为它们都表示相同的意思，实际上，只有其中一个同义词会出现，这是不使用协调因子的一个好例子

索引时字段层权重提升

我们会讨论查询时的权重提升，让字段权重提升就是让某个字段比其他字段更重要。当然在索引时也能做到如此。实际上，权重的提升会被应用到字段的每个词，而不是字段本身。

将提升值存储在索引中无须更多空间，这个字段层索引时的提升值与字段长度归一值（参见字段长度归一值）一起作为单个字节存于索引， norm(t,d) 是前面公式的返回值。

查询时权重提升

在语句优先级（Prioritizing Clauses）中，我们解释过如何在搜索时使用 boost 参数让一个查询语句比其他语句更重要。例如：

GET my_index/_search
{
  "query": {
    "bool": {
      "should": [
        {
          "match": {
            "text": {
              "query": "quick brown fox",
              "boost": 2 
            }
          }
        },
        {
          "match": { 
            "content": "quick brown fox"
          }
        }
      ]
    }
  }
}

title 查询语句的重要性是 content 查询的 2 倍，因为它的权重提升值为 2 。
没有设置 boost 的查询语句的值为 1 。

查询时的权重提升是可以用来影响相关度的主要工具，任意类型的查询都能接受 boost 参数。将 boost 设置为 2 ，并不代表最终的评分 _score 是原值的两倍；实际的权重值会经过归一化和一些其他内部优化过程。尽管如此，它确实想要表明一个提升值为 2 的句子的重要性是提升值为 1 语句的两倍。

在实际应用中，无法通过简单的公式得出某个特定查询语句的 “正确” 权重提升值，只能通过不断尝试获得。需要记住的是 boost 只是影响相关度评分的其中一个因子；它还需要与其他因子相互竞争。在前例中， title 字段相对 content 字段可能已经有一个 “缺省的” 权重提升值，这因为在字段长度归一值中，标题往往比相关内容要短，所以不要想当然的去盲目提升一些字段的权重。选择权重，检查结果，如此反复。

使用查询结构修改相关度

Elasticsearch 的查询表达式相当灵活，可以通过调整查询结构中查询语句的所处层次，从而或多或少改变其重要性，比如，设想下面这个查询：
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 文档的评分相同，这里 Red 和 brown 是同义词，可能只需要保留其中一个，而我们真正要表达的意思是想做以下查询：

quick OR (brown OR red) OR 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 OR brown 则是处于顶层且相互竞争的词。

我们已经讨论过如何使用 match 、multi_match 、term 、bool 和 dis_max 查询修改相关度评分。本章后面的内容会介绍另外三个与相关度评分有关的查询： boosting 查询、 constant_score 查询和 function_score 查询。

Not Quite Not

在互联网上搜索 “Apple”，返回的结果很可能是一个公司、水果和各种食谱。我们可以在 bool 查询中用 must_not 语句来排除像 pie 、 tart 、 crumble 和 tree 这样的词，从而将查询结果的范围缩小至只返回与 “Apple” （苹果）公司相关的结果：

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

但谁又敢保证在排除 tree 或 crumble 这种词后，不会错失一个与苹果公司特别相关的文档呢？有时， must_not 条件会过于严格。

权重提升查询

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 相乘的方式降级后的结果。

为了达到效果， negative_boost 的值必须小于 1.0 。在这个示例中，所有包含负向词的文档评分 _score 都会减半。

忽略 TF/IDF

有时候我们根本不关心 TF/IDF ，只想知道一个词是否在某个字段中出现过。可能搜索一个度假屋并希望它能尽可能有以下设施：

WiFi
Garden（花园）
Pool（游泳池）

这个度假屋的文档如下：

put house/_doc/1
{ "description": "A delightful four-bedroomed house with ... " }
put house/_doc/2
{ "description": "A delightful four-bedroomed house with wifi... " }
put house/_doc/3
{ "description": "A delightful four-bedroomed house with wifi and pool and garden... " }
put house/_doc/4
{ "description": "A delightful four-bedroomed house with wifi and big garden and small garden and pool" }
put house/_doc/5
{ "description": "A delightful four-bedroomed house with pool... " }

可以用简单的 match 查询进行匹配：

GET /_search
{
  "query": {
    "match": {
      "description": "wifi garden pool"
    }
  }
}

但这并不是真正的全文搜索，此种情况下，TF/IDF 并无用处。我们既不关心 wifi 是否为一个普通词，也不关心它在文档中出现是否频繁，关心的只是它是否曾出现过。实际上，我们希望根据房屋不同设施的数量对其排名——设施越多越好。如果设施出现，则记 1 分，不出现记 0 分。

constant_score 查询

在 constant_score 查询中，它可以包含查询或过滤，为任意一个匹配的文档指定评分 1 ，忽略 TF/IDF 信息：

GET /_search
{
  "query": {
    "bool": {
      "should": [
        { "constant_score": {
          "filter": { "match": { "description": "wifi" }}
        }},
        { "constant_score": {
          "filter": { "match": { "description": "garden" }}
        }},
        { "constant_score": {
          "filter": { "match": { "description": "pool" }}
        }}
      ]
    }
  }
}

或许不是所有的设施都同等重要——对某些用户来说有些设施更有价值。如果最重要的设施是游泳池，那我们可以为更重要的设施增加权重：

GET /_search
{
  "query": {
    "bool": {
      "should": [
        { "constant_score": {
          "filter": { "match": { "description": "wifi" }}
        }},
        { "constant_score": {
          "filter": { "match": { "description": "garden" }}
        }},
        { "constant_score": {
          "filter": { "match": { "description": "pool" } },
          "boost": 2
        }}
      ]
    }
  }
}

pool 语句的权重提升值为 2 ，而其他的语句为 1 。

"hits": [
      {
        "_index": "house",
        "_id": "3",
        "_score": 4,
        "_source": {
          "description": "A delightful four-bedroomed house with wifi and pool and garden... "
        }
      },
      {
        "_index": "house",
        "_id": "4",
        "_score": 4,
        "_source": {
          "description": "A delightful four-bedroomed house with wifi and big garden and small garden and pool"
        }
      },
      {
        "_index": "house",
        "_id": "5",
        "_score": 2,
        "_source": {
          "description": "A delightful four-bedroomed house with pool... "
        }
      },
      {
        "_index": "house",
        "_id": "2",
        "_score": 1,
        "_source": {
          "description": "A delightful four-bedroomed house with wifi... "
        }
      }
    ]

function_score 查询

function_score 查询是用来控制评分过程的终极武器，它允许为每个与主查询匹配的文档应用一个函数，以达到改变甚至完全替换原始查询评分 _score 的目的。

实际上，也能用过滤器对结果的子集应用不同的函数，这样一箭双雕：既能高效评分，又能利用过滤器缓存。

Elasticsearch 预定义了一些函数：

weight
为每个文档应用一个简单而不被规范化的权重提升值：当 weight 为 2 时，最终结果为 2 * _score 。
field_value_factor
使用这个值来修改 _score ，如将 popularity 或 votes （受欢迎或赞）作为考虑因素。
random_score
为每个用户都使用一个不同的随机评分对结果排序，但对某一具体用户来说，看到的顺序始终是一致的。
衰减函数 —— linear 、 exp 、 gauss
将浮动值结合到评分 _score 中，例如结合 publish_date 获得最近发布的文档，结合 geo_location 获得更接近某个具体经纬度（lat/lon）地点的文档，结合 price 获得更接近某个特定价格的文档。
script_score
如果需求超出以上范围时，用自定义脚本可以完全控制评分计算，实现所需逻辑。

如果没有 function_score 查询，就不能将全文查询与最新发生这种因子结合在一起评分，而不得不根据评分 _score 或时间 date 进行排序；这会相互影响抵消两种排序各自的效果。这个查询可以使两个效果融合：可以仍然根据全文相关度进行排序，但也会同时考虑最新发布文档、流行文档、或接近用户希望价格的产品。正如所设想的，查询要考虑所有这些因素会非常复杂，让我们先从简单的例子开始，然后顺着梯子慢慢向上爬，增加复杂度。

按受欢迎度提升权重

设想有个网站供用户发布博客并且可以让他们为自己喜欢的博客点赞，我们希望将更受欢迎的博客放在搜索结果列表中相对较上的位置，同时全文搜索的评分仍然作为相关度的主要排序依据，可以简单的通过存储每个博客的点赞数来实现它：

PUT /blogposts/_doc/1
{
  "title":   "About popularity",
  "content": "In this post we will talk about...",
  "votes":   6
}
PUT /blogposts/_doc/2
{
  "title":   "About popularity",
  "content": "In this post we will talk about...",
  "votes":   2
}

在搜索时，可以将 function_score 查询与 field_value_factor 结合使用，即将点赞数与全文相关度评分结合：

GET /blogposts/_search
{
  "query": {
    "function_score": { 
      "query": { 
        "multi_match": {
          "query":    "popularity",
          "fields": [ "title", "content" ]
        }
      },
      "field_value_factor": { 
        "field": "votes" 
      }
    }
  }
}

function_score 查询将主查询和函数包括在内。
主查询优先执行。
field_value_factor 函数会被应用到每个与主 query 匹配的文档。
每个文档的 votes 字段都必须有值供 function_score 计算。如果没有文档的 votes 字段有值，那么就必须使用 missing 属性提供的默认值来进行评分计算。

"hits": [
      {
        "_index": "blogposts",
        "_id": "1",
        "_score": 1.0939294,
        "_source": {
          "title": "About popularity",
          "content": "In this post we will talk about...",
          "votes": 6
        }
      },
      {
        "_index": "blogposts",
        "_id": "2",
        "_score": 0.36464313,
        "_source": {
          "title": "About popularity",
          "content": "In this post we will talk about...",
          "votes": 2
        }
      }
    ]

在前面示例中，每个文档的最终评分 _score 都做了如下修改：

new_score = old_score * number_of_votes

然而这并不会带来出人意料的好结果，全文评分 _score 通常处于 0 到 10 之间，如下图 Figure 29, “受欢迎度的线性关系基于 _score 的原始值 2.0” 中，有 10 个赞的博客会掩盖掉全文评分，而 0 个赞的博客的评分会被置为 0 。
在这里插入图片描述

modifier

一种融入受欢迎度更好方式是用 modifier 平滑 votes 的值。换句话说，我们希望最开始的一些赞更重要，但是其重要性会随着数字的增加而降低。 0 个赞与 1 个赞的区别应该比 10 个赞与 11 个赞的区别大很多。

对于上述情况，典型的 modifier 应用是使用 log1p 参数值，公式如下：

new_score = old_score * log(1 + number_of_votes)

log 对数函数使 votes 赞字段的评分曲线更平滑，如图 Figure 30, “受欢迎度的对数关系基于 _score 的原始值 2.0” ：
在这里插入图片描述
带 modifier 参数的请求如下：

GET /blogposts/_search
{
  "query": {
    "function_score": {
      "query": {
        "multi_match": {
          "query":    "popularity",
          "fields": [ "title", "content" ]
        }
      },
      "field_value_factor": {
        "field":    "votes",
        "modifier": "log1p" 
      }
    }
  }
}

"hits": [
      {
        "_index": "blogposts",
        "_id": "4",
        "_score": 0.1594491,
        "_source": {
          "title": "About popularity",
          "content": "In this post we will talk about...",
          "votes": 67
        }
      },
      {
        "_index": "blogposts",
        "_id": "3",
        "_score": 0.15888926,
        "_source": {
          "title": "About popularity",
          "content": "In this post we will talk about...",
          "votes": 66
        }
      },
      ......
	]

modifier 为 log1p 。

修饰语 modifier 的值可以为： none （默认状态）、 log 、 log1p 、 log2p 、 ln 、 ln1p 、 ln2p 、 square 、 sqrt 以及 reciprocal 。想要了解更多信息请参照： field_value_factor 文档.

factor

可以通过将 votes 字段与 factor 的积来调节受欢迎程度效果的高低：

GET /blogposts/_search
{
  "query": {
    "function_score": {
      "query": {
        "multi_match": {
          "query":    "popularity",
          "fields": [ "title", "content" ]
        }
      },
      "field_value_factor": {
        "field":    "votes",
        "modifier": "log1p",
        "factor":   2 
      }
    }
  }
}

双倍效果。

添加了 factor 会使公式变成这样：

new_score = old_score * log(1 + factor * number_of_votes)

factor 值大于 1 会提升效果， factor 值小于 1 会降低效果，如图 Figure 31, “受欢迎度的对数关系基于多个不同因子” 。
在这里插入图片描述

boost_mode

或许将全文评分与 field_value_factor 函数值乘积的效果仍然可能太大，我们可以通过参数 boost_mode 来控制函数与查询评分 _score 合并后的结果，参数接受的值为：
multiply
评分 _score 与函数值的积（默认）
sum
评分 _score 与函数值的和
min
评分 _score 与函数值间的较小值
max
评分 _score 与函数值间的较大值
replace
函数值替代评分 _score

与使用乘积的方式相比，使用评分 _score 与函数值求和的方式可以弱化最终效果，特别是使用一个较小 factor 因子时：

GET /blogposts/_search
{
  "query": {
    "function_score": {
      "query": {
        "multi_match": {
          "query":    "popularity",
          "fields": [ "title", "content" ]
        }
      },
      "field_value_factor": {
        "field":    "votes",
        "modifier": "log1p",
        "factor":   0.1
      },
      "boost_mode": "sum" 
    }
  }
}

将函数计算结果值累加到评分 _score 。

之前请求的公式现在变成下面这样（参见 Figure 32, “使用 sum 结合受欢迎程度” ）：

new_score = old_score + log(1 + 0.1 * number_of_votes)

在这里插入图片描述

max_boost

最后，可以使用 max_boost 参数限制一个函数的最大效果：

GET /blogposts/_search
{
  "query": {
    "function_score": {
      "query": {
        "multi_match": {
          "query":    "popularity",
          "fields": [ "title", "content" ]
        }
      },
      "field_value_factor": {
        "field":    "votes",
        "modifier": "log1p",
        "factor":   0.1
      },
      "boost_mode": "sum",
      "max_boost":  1.5 
    }
  }
}

无论 field_value_factor 函数的结果如何，最终结果都不会大于 1.5 。

max_boost 只对函数的结果进行限制，不会对最终评分 _score 产生直接影响。

过滤集提升权重

回到忽略 TF/IDF 里处理过的问题，我们希望根据每个度假屋的特性数量来评分，当时我们希望能用缓存的过滤器来影响评分，现在 function_score 查询正好可以完成这件事情。

到目前为止，我们展现的都是为所有文档应用单个函数的使用方式，现在会用过滤器将结果划分为多个子集（每个特性一个过滤器），并为每个子集使用不同的函数。

在下面例子中，我们会使用 weight 函数，它与 boost 参数类似可以用于任何查询。有一点区别是 weight 没有被 Luence 归一化成难以理解的浮点数，而是直接被应用。

查询的结构需要做相应变更以整合多个函数：

GET /_search
{
  "query": {
    "function_score": {
      "query": {
        "bool": {
          "filter": [
            { "term": { "city": "Barcelona" }}
          ],
          "should": [
            {
              "constant_score": {
                "filter": { "term": { "features": "wifi" }},
                "boost": 1
              }
            },
            {
              "constant_score": {
                "filter": { "term": { "features": "garden" }},
                "boost": 1
              }
            },
            {
              "constant_score": {
                "filter": { "term": { "features": "pool" }},
                "boost": 2
              }
            }
          ]
        }
      },
      "score_mode": "sum"
    }
  }
}

function_score 查询有个 filter 过滤器。
functions 关键字存储着一个将被应用的函数列表。
函数会被应用于和 filter 过滤器（可选的）匹配的文档。
pool 比其他特性更重要，所以它有更高 weight 。
score_mode 指定各个函数的值进行组合运算的方式。

随机评分

你可能会想知道一致随机评分（consistently random scoring）是什么，又为什么会使用它。之前的例子是个很好的应用场景，前例中所有的结果都会返回 1 、 2 、 3 、 4 或 5 这样的最终评分 _score ，可能只有少数房子的评分是 5 分，而有大量房子的评分是 2 或 3 。

作为网站的所有者，总会希望让广告有更高的展现率。在当前查询下，有相同评分 _score 的文档会每次都以相同次序出现，为了提高展现率，在此引入一些随机性可能会是个好主意，这能保证有相同评分的文档都能有均等相似的展现机率。

我们想让每个用户看到不同的随机次序，但也同时希望如果是同一用户翻页浏览时，结果的相对次序能始终保持一致。这种行为被称为一致随机（consistently random）。

random_score 函数会输出一个 0 到 1 之间的数，当种子 seed 值相同时，生成的随机结果是一致的，例如，将用户的会话 ID 作为 seed

越近越好

很多变量都可以影响用户对于度假屋的选择，也许用户希望离市中心近点，但如果价格足够便宜，也有可能选择一个更远的住处，也有可能反过来是正确的：愿意为最好的位置付更多的价钱。

如果我们添加过滤器排除所有市中心方圆 1 千米以外的度假屋，或排除所有每晚价格超过 £100 英镑的，我们可能会将用户愿意考虑妥协的那些选择排除在外。

function_score 查询会提供一组衰减函数（decay functions），让我们有能力在两个滑动标准，如地点和价格，之间权衡。

有三种衰减函数—— linear 、 exp 和 gauss （线性、指数和高斯函数），它们可以操作数值、时间以及经纬度地理坐标点这样的字段。所有三个函数都能接受以下参数：

origin
中心点或字段可能的最佳值，落在原点 origin 上的文档评分 _score 为满分 1.0 。
scale
衰减率，即一个文档从原点 origin 下落时，评分 _score 改变的速度。（例如，每 £10 欧元或每 100 米）。
decay
从原点 origin 衰减到 scale 所得的评分 _score ，默认值为 0.5 。
offset
以原点 origin 为中心点，为其设置一个非零的偏移量 offset 覆盖一个范围，而不只是单个原点。在范围 -offset <= origin <= +offset 内的所有评分 _score 都是 1.0 。

这三个函数的唯一区别就是它们衰减曲线的形状，用图来说明会更为直观（参见 Figure 33, “衰减函数曲线” ）。
在这里插入图片描述
图 Figure 33, “衰减函数曲线” 中所有曲线的原点 origin （即中心点）的值都是 40 ， offset 是 5 ，也就是在范围 40 - 5 <= value <= 40 + 5 内的所有值都会被当作原点 origin 处理——所有这些点的评分都是满分 1.0 。

在此范围之外，评分开始衰减，衰减率由 scale 值（此例中的值为 5 ）和衰减值 decay （此例中为默认值 0.5 ）共同决定。结果是所有三个曲线在 origin +/- (offset + scale) 处的评分都是 0.5 ，即点 30 和 50 处。

linear 、 exp 和 gauss （线性、指数和高斯）函数三者之间的区别在于范围（ origin +/- (offset + scale) ）之外的曲线形状：

linear 线性函数是条直线，一旦直线与横轴 0 相交，所有其他值的评分都是 0.0 。
exp 指数函数是先剧烈衰减然后变缓。
gauss 高斯函数是钟形的——它的衰减速率是先缓慢，然后变快，最后又放缓。

选择曲线的依据完全由期望评分 _score 的衰减速率来决定，即距原点 origin 的值。

回到我们的例子：用户希望租一个离伦敦市中心近（ { “lat”: 51.50, “lon”: 0.12} ）且每晚不超过 £100 英镑的度假屋，而且与距离相比，我们的用户对价格更为敏感，这样查询可以写成：

GET /_search
{
  "query": {
    "function_score": {
      "functions": [
        {
          "gauss": {
            "location": { 
              "origin": { "lat": 51.5, "lon": 0.12 },
              "offset": "2km",
              "scale":  "3km"
            }
          }
        },
        {
          "gauss": {
            "price": { 
              "origin": "50", 
              "offset": "50",
              "scale":  "20"
            }
          },
          "weight": 2 
        }
      ]
    }
  }
}

location 字段以地理坐标点 geo_point 映射。
price 字段是数值。
参见理解价格语句，理解 origin 为什么是 50 而不是 100 。
price 语句是 location 语句权重的两倍。

location 语句可以简单理解为：

以伦敦市中作为原点 origin 。
所有距原点 origin 2km 范围内的位置的评分是 1.0 。
距中心 5km （ offset + scale ）的位置的评分是 0.5 。

理解 price 价格语句

price 语句使用了一个小技巧：用户希望选择 £100 英镑以下的度假屋，但是例子中的原点被设置成 £50 英镑，价格不能为负，但肯定是越低越好，所以 £0 到 £100 英镑内的所有价格都认为是比较好的。

如果我们将原点 origin 被设置成 £100 英镑，那么低于 £100 英镑的度假屋的评分会变低，与其这样不如将原点 origin 和偏移量 offset 同时设置成 £50 英镑，这样就能使只有在价格高于 £100 英镑（ origin + offset ）时评分才会变低。

weight 参数可以被用来调整每个语句的贡献度，权重 weight 的默认值是 1.0 。这个值会先与每个句子的评分相乘，然后再通过 score_mode 的设置方式合并。

脚本评分

最后，如果所有 function_score 内置的函数都无法满足应用场景，可以使用 script_score 函数自行实现逻辑。

举个例子，想将利润空间作为因子加入到相关度评分计算，在业务中，利润空间和以下三点相关：

price 度假屋每晚的价格。
会员用户的级别——某些等级的用户可以在每晚房价高于某个 threshold 阀值价格的时候享受折扣 discount 。
用户享受折扣后，经过议价的每晚房价的利润 margin 。

计算每个度假屋利润的算法如下：

if (price < threshold) {
  profit = price * margin
} else {
  profit = price * (1 - discount) * margin;
}

我们很可能不想用绝对利润作为评分，这会弱化其他如地点、受欢迎度和特性等因子的作用，而是将利润用目标利润 target 的百分比来表示，高于目标的利润空间会有一个正向评分（大于 1.0 ），低于目标的利润空间会有一个负向分数（小于 1.0 ）：

if (price < threshold) {
  profit = price * margin
} else {
  profit = price * (1 - discount) * margin
}
return profit / target

Elasticsearch 里使用 Groovy 作为默认的脚本语言，它与JavaScript很像，上面这个算法用 Groovy 脚本表示如下：

price  = doc['price'].value 
margin = doc['margin'].value 

if (price < threshold) { 
  return price * margin / target
}
return price * (1 - discount) * margin / target

price 和 margin 变量可以分别从文档的 price 和 margin 字段提取。
threshold 、 discount 和 target 是作为参数 params 传入的。

最终我们将 script_score 函数与其他函数一起使用：

GET /_search
{
  "function_score": {
    "functions": [
      { ...location clause... }, 
      { ...price clause... }, 
      {
        "script_score": {
          "params": { 
            "threshold": 80,
            "discount": 0.1,
            "target": 10
          },
          "script": "price  = doc['price'].value; margin = doc['margin'].value;
          if (price < threshold) { return price * margin / target };
          return price * (1 - discount) * margin / target;" 
        }
      }
    ]
  }
}

location 和 price 语句在衰减函数中解释过。
将这些变量作为参数 params 传递，我们可以查询时动态改变脚本无须重新编译。
JSON 不能接受内嵌的换行符，脚本中的换行符可以用 \n 或 ; 符号替代。

这个查询根据用户对地点和价格的需求，返回用户最满意的文档，同时也考虑到我们对于盈利的要求。

script_score 函数提供了巨大的灵活性，可以通过脚本访问文档里的所有字段、当前评分 _score 甚至词频、逆向文档频率和字段长度规范值这样的信息（参见 see 脚本对文本评分）。
有人说使用脚本对性能会有影响，如果确实发现脚本执行较慢，可以有以下三种选择：

尽可能多的提前计算各种信息并将结果存入每个文档中。
Groovy 很快，但没 Java 快。可以将脚本用原生的 Java 脚本重新实现。（参见原生 Java 脚本）。
仅对那些最佳评分的文档应用脚本，使用重新评分中提到的 rescore 功能。

可插拔的相似度算法

在进一步讨论相关度和评分之前，我们会以一个更高级的话题结束本章节的内容：可插拔的相似度算法（Pluggable Similarity Algorithms）。 Elasticsearch 将实用评分算法作为默认相似度算法，它也能够支持其他的一些算法，这些算法可以参考相似度模块文档。

Okapi BM25

能与 TF/IDF 和向量空间模型媲美的就是 Okapi BM25 ，它被认为是当今最先进的排序函数。 BM25 源自概率相关模型（probabilistic relevance model），而不是向量空间模型，但这个算法也和 Lucene 的实用评分函数有很多共通之处。

BM25 同样使用词频、逆向文档频率以及字段长归一化，但是每个因子的定义都有细微区别。与其详细解释 BM25 公式，倒不如将关注点放在 BM25 所能带来的实际好处上。

词频饱和度

TF/IDF 和 BM25 同样使用逆向文档频率来区分普通词（不重要）和非普通词（重要），同样认为（参见词频）文档里的某个词出现次数越频繁，文档与这个词就越相关。

不幸的是，普通词随处可见，实际上一个普通词在同一个文档中大量出现的作用会由于该词在所有文档中的大量出现而被抵消掉。

曾经有个时期，将最普通的词（或停用词，参见停用词）从索引中移除被认为是一种标准实践，TF/IDF 正是在这种背景下诞生的。TF/IDF 没有考虑词频上限的问题，因为高频停用词已经被移除了。

Elasticsearch 的 standard 标准分析器（ string 字段默认使用）不会移除停用词，因为尽管这些词的重要性很低，但也不是毫无用处。这导致：在一个相当长的文档中，像 the 和 and 这样词出现的数量会高得离谱，以致它们的权重被人为放大。

另一方面，BM25 有一个上限，文档里出现 5 到 10 次的词会比那些只出现一两次的对相关度有着显著影响。但是如图 TF/IDF 与 BM25 的词频饱和度所见，文档中出现 20 次的词几乎与那些出现上千次的词有着相同的影响。

这就是非线性词频饱和度（nonlinear term-frequency saturation）。
在这里插入图片描述

字段长度归一化（Field-length normalization）

在字段长归一化中，我们提到过 Lucene 会认为较短字段比较长字段更重要：字段某个词的频度所带来的重要性会被这个字段长度抵消，但是实际的评分函数会将所有字段以同等方式对待。它认为所有较短的 title 字段比所有较长的 body 字段更重要。

BM25 当然也认为较短字段应该有更多的权重，但是它会分别考虑每个字段内容的平均长度，这样就能区分短 title 字段和长 title 字段。

在查询时权重提升中，已经说过 title 字段因为其长度比 body 字段自然有更高的权重提升值。由于字段长度的差异只能应用于单字段，这种自然的权重提升会在使用 BM25 时消失。

BM25 调优

不像 TF/IDF ，BM25 有一个比较好的特性就是它提供了两个可调参数：

k1
这个参数控制着词频结果在词频饱和度中的上升速度。默认值为 1.2 。值越小饱和度变化越快，值越大饱和度变化越慢。
b
这个参数控制着字段长归一值所起的作用， 0.0 会禁用归一化， 1.0 会启用完全归一化。默认值为 0.75 。

在实践中，调试 BM25 是另外一回事， k1 和 b 的默认值适用于绝大多数文档集合，但最优值还是会因为文档集不同而有所区别，为了找到文档集合的最优值，就必须对参数进行反复修改验证。

更改相似度

相似度算法可以按字段指定，只需在映射中为不同字段选定即可：

调试相关度是最后 10% 要做的事情

本章介绍了 Lucene 是如何基于 TF/IDF 生成评分的。理解评分过程是非常重要的，这样就可以根据具体的业务对评分结果进行调试、调节、减弱和定制。

实践中，简单的查询组合就能提供很好的搜索结果，但是为了获得具有成效的搜索结果，就必须反复推敲修改前面介绍的这些调试方法。

通常，经过对策略字段应用权重提升，或通过对查询语句结构的调整来强调某个句子的重要性这些方法，就足以获得良好的结果。有时，如果 Lucene 基于词的 TF/IDF 模型不再满足评分需求（例如希望基于时间或距离来评分），则需要更具侵略性的调整。

除此之外，相关度的调试就有如兔子洞，一旦跳进去就很难再出来。最相关这个概念是一个难以触及的模糊目标，通常不同人对文档排序又有着不同的想法，这很容易使人陷入持续反复调整而没有明显进展的怪圈。

我们强烈建议不要陷入这种怪圈，而要监控测量搜索结果。监控用户点击最顶端结果的频次，这可以是前 10 个文档，也可以是第一页的；用户不查看首次搜索的结果而直接执行第二次查询的频次；用户来回点击并查看搜索结果的频次，等等诸如此类的信息。

这些都是用来评价搜索结果与用户之间相关程度的指标。如果查询能返回高相关的文档，用户会选择前五中的一个，得到想要的结果，然后离开。不相关的结果会让用户来回点击并尝试新的搜索条件。

一旦有了这些监控手段，想要调试查询就并不复杂，稍作调整，监控用户的行为改变并做适当反复尝试。本章介绍的一些工具就只是工具而已，要想物尽其用并将搜索结果提高到极高的水平，唯一途径就是需要具备能评价度量用户行为的强大能力。