Lucene（或 Elasticsearch）使用 布尔模型（Boolean model） 查找匹配文档，并用一个名为 实用评分函数（practical scoring function） 的公式来计算相关度。这个公式借鉴了 词频/逆向文档频率（term frequency/inverse document frequency） 和 向量空间模型（vector space model），同时也加入了一些现代的新特性，如协调因子（coordination factor），字段长度归一化（field length normalization），以及词或查询语句权重提升。

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

一个多词查询

会在内部被重写为：

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

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

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

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

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

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

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

Elasticsearch 的查询表达式相当灵活，可以通过调整查询结构中查询语句的所处层次，从而或多或少改变其重要性，比如，设想下面这个查询：

可以将所有词都放在 bool 查询的同一层中：

这个查询可能最终给包含 quick 、 red 和 brown 的文档评分与包含 quick 、 red 、 fox 文档的评分相同，这里 Red 和 brown 是同义词，可能只需要保留其中一个，而我们真正要表达的意思是想做以下查询：

根据标准的布尔逻辑，这与原始的查询是完全一样的，但是我们已经在 组合查询（Combining Queries） 中看到， bool 查询不关心文档匹配的 程度 ，只关心是否能匹配。

上述查询有个更好的方式：

现在， red 和 brown 处于相互竞争的层次， quick 、 fox 以及 red OR brown 则是处于顶层且相互竞争的词。

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

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

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

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

这个度假屋的文档如下：

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

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

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

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

Elasticsearch 预定义了一些函数：

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

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

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

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

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

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

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

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

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

这个新特性需要注意的地方会在以下小节介绍。

你可能会想知道 一致随机评分（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 （即中心点）的值都是 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) ）之外的曲线形状：

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

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

location 语句可以简单理解为：

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

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

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

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

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

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

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

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

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

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

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

目前，Elasticsearch 不支持更改已有字段的相似度算法 similarity 映射，只能通过为数据重新建立索引来达到目的。

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

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

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

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

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

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

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