一 例子

現(xiàn)在，講述一個(gè)真實(shí)的故事！

故事一定是伴隨著趙忠祥老師的聲音開始的，雨季就要來(lái)臨了，又到了動(dòng)物們發(fā)情的季節(jié)了...

還記得，之前發(fā)生的作家六六吐槽xx的事情嗎？對(duì)了，有圖有真相！上圖上圖：

身為吃瓜群眾，要從專業(yè)的角度來(lái)分析，就事論事哈：

就搜索結(jié)果本身而言，xx返回了正確的結(jié)果（是的，人家已經(jīng)調(diào)整了，現(xiàn)在搜沒問(wèn)題?。Ｒ?yàn)榉祷氐慕Y(jié)果中，都包含了搜索的關(guān)鍵字。而我們從邏輯上來(lái)看，這他娘的一堆廣告算是咋回事！這個(gè)吐槽是從用戶的角度出發(fā)的。很顯然，返回的結(jié)果中，尤其是前幾條，有時(shí)甚至是前幾頁(yè)，都跟我們想要的結(jié)果相差深遠(yuǎn)！

進(jìn)一步說(shuō)，僅僅以二元的方式來(lái)考慮文檔和查詢的匹配可能是有意義的，也就是百度搜索引擎返回了二元的匹配結(jié)果：是的，找到了，不，老娘沒找到！雖然返回了結(jié)果，其中也包含了我們想要的結(jié)果，即便你要在大堆的廣告中找正確的結(jié)果實(shí)屬不易，但就像大家都習(xí)慣了廣告中插播電視劇一樣，習(xí)慣就好嘛！xx從x的角度出發(fā)，為廣告的詞條增加權(quán)重，至于那個(gè)真正的結(jié)果，我擦，你也沒給我錢........

而需要xx才能訪問(wèn)的xx瀏覽器，在正確的給用戶返回二元結(jié)果之前，更多的考慮文檔的相關(guān)性（relevancy），因?yàn)榫湍硞€(gè)結(jié)果而言，如果A文檔要比B文檔更和結(jié)果相關(guān)，那么A文檔在結(jié)果中就要比B文檔靠前，再加上以其他的優(yōu)化，最終將所有結(jié)果返回，而用戶最期待的那條結(jié)果很可能排在最高位，這豈不美哉？

確定文檔和查詢有多么相關(guān)的過(guò)程被稱為打分（scoring）。

二 文檔打分的運(yùn)作機(jī)制：TF-IDF

Lucene和es的打分機(jī)制是一個(gè)公式。將查詢作為輸入，使用不同的手段來(lái)確定每一篇文檔的得分，將每一個(gè)因素最后通過(guò)公式綜合起來(lái)，返回該文檔的最終得分。這個(gè)綜合考量的過(guò)程，就是我們希望相關(guān)的文檔被優(yōu)先返回的考量過(guò)程。在Lucene和es中這種相關(guān)性稱為得分。

在開始計(jì)算得分之前，es使用了被搜索詞條的頻率和它有多常見來(lái)影響得分，從兩個(gè)方面理解：

• 一個(gè)詞條在某篇文檔中出現(xiàn)的次數(shù)越多，該文檔就越相關(guān)。
• 一個(gè)詞條如果在不同的文檔中出現(xiàn)的次數(shù)越多，它就越不相關(guān)！

我們稱之為TF-IDF，TF是詞頻（term frequency），而IDF是逆文檔頻率（inverse document frequency）。

2.1 詞頻：TF

考慮一篇文檔得分的首要方式，是查看一個(gè)詞條在文檔中出現(xiàn)的次數(shù)，比如某篇文章圍繞es的打分展開的，那么文章中肯定會(huì)多次出現(xiàn)相關(guān)字眼，當(dāng)查詢時(shí)，我們認(rèn)為該篇文檔更符合，所以，這篇文檔的得分會(huì)更高。

閑的蛋疼的可以Ctrl + f搜一下相關(guān)的關(guān)鍵詞（es，得分、打分）之類的試試。

2.2 逆文檔頻率：IDF

相對(duì)于詞頻，逆文檔頻率稍顯復(fù)雜，如果一個(gè)詞條在索引中的不同文檔中出現(xiàn)的次數(shù)越多，那么它就越不重要。

來(lái)個(gè)例子，示例：

The rules-which require employees to work from 9 am to 9 pm
In the weeks that followed the creation of 996.ICU in March
The 996.ICU page was soon blocked on multiple platforms including the messaging tool WeChat and the UC Browser.

假如es索引中，有上述3篇文檔：

• 詞條ICU的文檔頻率是2，因?yàn)樗霈F(xiàn)在2篇文檔中，文檔的逆源自得分乘以1/DF，DF是該詞條的文檔頻率，這就意味著，由于ICU詞條擁有更高的文檔頻率，所以，它的權(quán)重會(huì)降低。
• 詞條the的文檔頻率是3，它在3篇文檔中都出現(xiàn)了，注意：盡管the在后兩篇文檔出都出現(xiàn)兩次，但是它的詞頻是還是3，因?yàn)?，逆文檔詞頻只檢查詞條是否出現(xiàn)在某篇文檔中，而不檢查它在這篇文檔中出現(xiàn)了多少次，那是詞頻該干的事兒。

逆文檔詞頻是一個(gè)重要的因素，用來(lái)平衡詞條的詞頻。比如我們搜索the 996.ICU。單詞the幾乎出現(xiàn)在所有的文檔中（中文中比如的“的”），如果這個(gè)鬼東西要不被均衡一下，那么the的頻率將完全淹沒996.ICU。所以，逆文檔詞頻就有效的均衡了the這個(gè)常見詞的相關(guān)性影響。以達(dá)到實(shí)際的相關(guān)性得分將會(huì)對(duì)查詢的詞條有一個(gè)更準(zhǔn)確地描述。

當(dāng)詞頻和逆文檔詞頻計(jì)算完成。就可以使用TF-IDF公式來(lái)計(jì)算文檔的得分了。

三 Lucene評(píng)分公式

之前的討論Lucene默認(rèn)評(píng)分公式被稱為TF-IDF，一個(gè)基于詞頻和逆文檔詞頻的公式。Lucene實(shí)用評(píng)分公式如下：

你以為我會(huì)著重介紹這個(gè)該死的公式？！

我只能說(shuō)，詞條的詞頻越高，得分越高；相似地，索引中詞條越罕見，逆文檔頻率越高，其中再加商調(diào)和因子和查詢標(biāo)準(zhǔn)化，調(diào)和因子考慮了搜索過(guò)多少文檔以及發(fā)現(xiàn)了多少詞條；

查詢標(biāo)準(zhǔn)化，是試圖讓不同的查詢結(jié)果具有可比性，這顯然.....很困難。

我們稱這種默認(rèn)的打分方法是TF-IDF和向量空間模型（vector space model）的結(jié)合。

四 其他的打分方法

除了TF-IDF結(jié)合向量空間模型的實(shí)用評(píng)分模式，是es和Lucene最為主流的評(píng)分機(jī)制，但這并不是唯一的，除了TF-IDF這種實(shí)用模型之外，其他的模型包括：

• Okapi BM25。
• 隨機(jī)性分歧（Divergence from randomness），即DFR相似度。
• LM Dirichlet相似度。
• LM Jelinek Mercer相似度。

這里簡(jiǎn)要的介紹BM25幾種主要設(shè)置，即k1、b和discount_overlaps：

• k1和b是數(shù)值的設(shè)置，用于調(diào)整得分是如何計(jì)算的。
• k1控制對(duì)于得分而言詞頻（TF）的重要性。
• b是介于0 ~ 1之間的數(shù)值，它控制了文檔篇幅對(duì)于得分的影響程度。
• 默認(rèn)情況下，k1設(shè)置為1.2，而b則被設(shè)置為0.75
• discount_overlaps的設(shè)置用于告訴es，在某個(gè)字段中，多少個(gè)分詞出現(xiàn)在同一位置，是否應(yīng)該影響長(zhǎng)度的標(biāo)準(zhǔn)化，默認(rèn)值是true。

五 配置打分模型

5.1 簡(jiǎn)要配置BM25打分模型

BM25（是不是跟pm2.5好像?。。。┦且环N基于概率的打分框架。我們來(lái)簡(jiǎn)要的配置一下：

PUT w2
{
  "mappings": {
    "doc": {
      "properties": {
        "title": {
          "type": "text",
          "similarity": "BM25"
        }
      }
    }
  }
}
PUT w2/doc/1
{
  "title":"The rules-which require employees to work from 9 am to 9 pm"
}
PUT w2/doc/2
{
  "title":"In the weeks that followed the creation of 996.ICU in March"
}
PUT w2/doc/3
{
  "title":"The 996.ICU page was soon blocked on multiple platforms including the messaging tool WeChat and the UC Browser."
}
GET w2/doc/_search
{
  "query": {
    "match": {
      "title": "the 996"
    }
  }
}

上例是通過(guò)similarity參數(shù)來(lái)指定打分模型。至于查詢，還是當(dāng)數(shù)據(jù)量比較大的時(shí)候，多試幾次，比較容易發(fā)現(xiàn)不同之處。

5.2 為BM25配置高級(jí)的settings

PUT w3
{
  "settings": {
    "index": {
      "analysis": {
        "analyzer":"ik_smart"
      }
    },
    "similarity": {
      "my_custom_similarity": {
        "type": "BM25",
        "k1": 1.2,
        "b": 0.75,
        "discount_overlaps": false
      }
    }
  },
  "mappings": {
    "doc": {
      "properties": {
        "title": {
          "type": "text",
          "similarity":"my_custom_similarity"
        }
      }
    }
  }
}
PUT w3/doc/1
{
  "title":"The rules-which require employees to work from 9 am to 9 pm"
}
PUT w3/doc/2
{
  "title":"In the weeks that followed the creation of 996.ICU in March"
}
PUT w3/doc/3
{
  "title":"The 996.ICU page was soon blocked on multiple platforms including the messaging tool WeChat and the UC Browser."
}
GET w3/doc/_search
{
  "query": {
    "match": {
      "title": "the 996"
    }
  }
}

5.3 配置全局打分模型

如果我們要使用某種特定的打分模型，并且希望應(yīng)用到全局，那么就在elasticsearch.yml配置文件中加入：

index.similarity.default.type: BM25

六 boosting

boosting是一個(gè)用來(lái)修改文檔相關(guān)性的程序。boosting有兩種類型：

• 索引的時(shí)候，比如我們?cè)诙xmappings的時(shí)候。
• 查詢一篇文檔的時(shí)候。

以上兩種方式都可以提升一個(gè)篇文檔的得分。需要注意的是：在索引期間修改的文檔boosting是存儲(chǔ)在索引中的，要想修改boosting必須重新索引該篇文檔。

6.1 索引期間的boosting

啥也不說(shuō)了，都在酒里！上代碼：

PUT w4
{
  "mappings": {
    "doc": {
      "properties": {
        "name": {
          "boost": 2.0,
          "type": "text"
        },
        "age": {
          "type": "long"
        }
      }
    }
  }
}

一勞永逸是沒錯(cuò)，但一般不推薦這么玩。

原因之一是因?yàn)橐坏┯成浣⑼瓿?，那么所有name字段都會(huì)自動(dòng)擁有一個(gè)boost值。要想修改這個(gè)值，那就必須重新索引文檔。

另一個(gè)原因是，boost值是以降低精度的數(shù)值存儲(chǔ)在Lucene內(nèi)部的索引結(jié)構(gòu)中。只有一個(gè)字節(jié)用于存儲(chǔ)浮點(diǎn)型數(shù)值（存不下就損失精度了），所以，計(jì)算文檔的最終得分時(shí)可能會(huì)損失精度。

最后，boost是應(yīng)用與詞條的。因此，再被boost的字段中如果匹配上了多個(gè)詞條，就意味著計(jì)算多次的boost，這將會(huì)進(jìn)一步增加字段的權(quán)重，可能會(huì)影響最終的文檔得分。

現(xiàn)在我們?cè)賮?lái)介紹另一種方式。

6.2 查詢期間的boosting

在es中，幾乎所有的查詢類型都支持boost，正如你想象的那些match、multi_match等等。

來(lái)個(gè)示例，在查詢期間，使用match查詢進(jìn)行boosting：

PUT w5
{
  "mappings":{
    "doc":{
      "properties": {
        "title": {
          "type": "text",
          "analyzer": "ik_max_word"
        },
        "content": {
          "type": "text",
          "analyzer": "ik_max_word"
        }
      }
    }
  }
}
PUT w5/doc/1
{
  "title":"Lucene is cool",
  "content": "Lucene is cool"
}
PUT w5/doc/2
{
  "title":"Elasticsearch builds on top of lucene",
  "content":"Elasticsearch builds on top of lucene"
}
PUT w5/doc/3
{
  "title":"Elasticsearch rocks",
  "content":"Elasticsearch rocks"
}

來(lái)查詢：

GET w5/doc/_search
{
  "query": {
    "bool": {
      "should": [
        {
          "match": {
            "title":{
              "query": "elasticserach rocks",
              "boost": 2.5
            }
          }
        },
        {
          "match": {
            "content": "elasticserach rocks"
          }
        }
      ]
    }
  }
}

就對(duì)于最終得分而言，content字段，加了boost的title查詢更有影響力。也只有在bool查詢中，boost更有意義。

6.3 跨越多個(gè)字段的查詢

boost也可以用于multi_match查詢。

GET w5/doc/_search
{
  "query": {
    "multi_match": {
      "query": "elasticserach rocks",
      "fields": ["title", "content"],
      "boost": 2.5
    }
  }
}

除此之外，我們還可以使用特殊的語(yǔ)法，只為特定的字段指定一個(gè)boost。通過(guò)在字段名稱后添加一個(gè)^符號(hào)和boost的值。告訴es只需對(duì)那個(gè)字段進(jìn)行boost：

GET w5/doc/_search
{
  "query": {
    "multi_match": {
      "query": "elasticserach rocks",
      "fields": ["title^3", "content"]
    }
  }
}

上例中，title字段被boost了3倍。

需要注意的是：在使用boost的時(shí)候，無(wú)論是字段或者詞條，都是按照相對(duì)值來(lái)boost的，而不是乘以乘數(shù)。

如果對(duì)于所有的待搜索詞條boost了同樣的值，那么就好像沒有boost一樣（廢話，就像大家都同時(shí)長(zhǎng)高一米似的）！因?yàn)長(zhǎng)ucene會(huì)標(biāo)準(zhǔn)化boost的值。

如果boost一個(gè)字段4倍，不是意味著該字段的得分就是乘以4的結(jié)果。所以，如果你的得分不是按照嚴(yán)格的乘法結(jié)果，也不要擔(dān)心。

七 使用“解釋”來(lái)理解文檔是如何評(píng)分的

一切都不是你想的那樣！是的，在es中，一個(gè)文檔要比另一個(gè)文檔更符合某個(gè)查詢很可能跟我們想象的不太一樣！

這一小節(jié)，我們來(lái)研究下es和Lucene內(nèi)部使用了怎樣的公式來(lái)計(jì)算得分。

我們通過(guò)explain=true來(lái)告訴es，你要給灑家解釋一下為什么這個(gè)得分是這樣的？！背后到底以有什么py交易！

比如我們來(lái)查詢：

GET py1/doc/_search
{
  "query": {
    "match": {
      "title": "北京"
    }
  },
  "explain": true,
  "_source": "title", 
  "size": 1
}

由于結(jié)果太長(zhǎng)，我們這里對(duì)結(jié)果進(jìn)行了過(guò)濾（"size": 1返回一篇文檔），只查看指定的字段（"_source": "title"只返回title字段）。

看結(jié)果：

{
  "took" : 1,
  "timed_out" : false,
  "_shards" : {
    "total" : 5,
    "successful" : 5,
    "skipped" : 0,
    "failed" : 0
  },
  "hits" : {
    "total" : 24,
    "max_score" : 4.9223156,
    "hits" : [
      {
        "_shard" : "[py1][1]",
        "_node" : "NRwiP9PLRFCTJA7w3H9eqA",
        "_index" : "py1",
        "_type" : "doc",
        "_id" : "NIjS1mkBuoj17MYtV-dX",
        "_score" : 4.9223156,
        "_source" : {
          "title" : "大寫的尷尬 插混為啥在北京不受待見？"
        },
        "_explanation" : {
          "value" : 4.9223156,
          "description" : "weight(title:北京 in 36) [PerFieldSimilarity], result of:",
          "details" : [
            {
              "value" : 4.9223156,
              "description" : "score(doc=36,freq=1.0 = termFreq=1.0\n), product of:",
              "details" : [
                {
                  "value" : 4.562031,
                  "description" : "idf, computed as log(1 + (docCount - docFreq + 0.5) / (docFreq + 0.5)) from:",
                  "details" : [
                    {
                      "value" : 4.0,
                      "description" : "docFreq",
                      "details" : [ ]
                    },
                    {
                      "value" : 430.0,
                      "description" : "docCount",
                      "details" : [ ]
                    }
                  ]
                },
                {
                  "value" : 1.0789746,
                  "description" : "tfNorm, computed as (freq * (k1 + 1)) / (freq + k1 * (1 - b + b * fieldLength / avgFieldLength)) from:",
                  "details" : [
                    {
                      "value" : 1.0,
                      "description" : "termFreq=1.0",
                      "details" : [ ]
                    },
                    {
                      "value" : 1.2,
                      "description" : "parameter k1",
                      "details" : [ ]
                    },
                    {
                      "value" : 0.75,
                      "description" : "parameter b",
                      "details" : [ ]
                    },
                    {
                      "value" : 12.1790695,
                      "description" : "avgFieldLength",
                      "details" : [ ]
                    },
                    {
                      "value" : 10.0,
                      "description" : "fieldLength",
                      "details" : [ ]
                    }
                  ]
                }
              ]
            }
          ]
        }
      }
    ]
  }
}

在新增的_explanation字段中，可以看到value值是4.9223156，那么是怎么算出來(lái)的呢？

來(lái)分析，分詞“北京”在描述字段（title）出現(xiàn)1次，所以TF的綜合得分經(jīng)過(guò)"description" : "tfNorm, computed as (freq * (k1 + 1)) / (freq + k1 * (1 - b + b * fieldLength / avgFieldLength)) from:"計(jì)算，得分是1.0789746。

那么逆文檔詞頻呢？根據(jù)"description" : "idf, computed as log(1 + (docCount - docFreq + 0.5) / (docFreq + 0.5)) from:"計(jì)算得分是4.562031。

所以最終得分是：

1.0789746 * 4.562031 = 4.9223155734126

結(jié)果在四舍五入后就是4.9223156。

需要注意的是，explain的特性會(huì)給es帶來(lái)額外的性能開銷。所以，除了在調(diào)試時(shí)可以使用，生產(chǎn)環(huán)境下，應(yīng)避免使用explain。

以上就是Elasticsearches打分機(jī)制講解的詳細(xì)內(nèi)容，更多關(guān)于Elasticsearches打分機(jī)制的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論