Elasticsearches打分機制講解
一 例子
現(xiàn)在，講述一個真實的故事！
故事一定是伴隨著趙忠祥老師的聲音開始的，雨季就要來臨了，又到了動物們發(fā)情的季節(jié)了...
還記得，之前發(fā)生的作家六六吐槽xx的事情嗎？對了，有圖有真相！上圖上圖：
身為吃瓜群眾，要從專業(yè)的角度來分析，就事論事哈：
就搜索結(jié)果本身而言，xx返回了正確的結(jié)果（是的，人家已經(jīng)調(diào)整了，現(xiàn)在搜沒問題！）。因為返回的結(jié)果中，都包含了搜索的關(guān)鍵字。而我們從邏輯上來看，這他娘的一堆廣告算是咋回事！這個吐槽是從用戶的角度出發(fā)的。很顯然，返回的結(jié)果中，尤其是前幾條，有時甚至是前幾頁，都跟我們想要的結(jié)果相差深遠(yuǎn)！
進一步說，僅僅以二元的方式來考慮文檔和查詢的匹配可能是有意義的，也就是百度搜索引擎返回了二元的匹配結(jié)果：是的，找到了，不，老娘沒找到！雖然返回了結(jié)果，其中也包含了我們想要的結(jié)果，即便你要在大堆的廣告中找正確的結(jié)果實屬不易，但就像大家都習(xí)慣了廣告中插播電視劇一樣，習(xí)慣就好嘛！xx從x的角度出發(fā)，為廣告的詞條增加權(quán)重，至于那個真正的結(jié)果，我擦，你也沒給我錢........
而需要xx才能訪問的xx瀏覽器，在正確的給用戶返回二元結(jié)果之前，更多的考慮文檔的相關(guān)性（relevancy），因為就某個結(jié)果而言，如果A文檔要比B文檔更和結(jié)果相關(guān)，那么A文檔在結(jié)果中就要比B文檔靠前，再加上以其他的優(yōu)化，最終將所有結(jié)果返回，而用戶最期待的那條結(jié)果很可能排在最高位，這豈不美哉？
確定文檔和查詢有多么相關(guān)的過程被稱為打分（scoring）。
二 文檔打分的運作機制：TF-IDF
Lucene和es的打分機制是一個公式。將查詢作為輸入，使用不同的手段來確定每一篇文檔的得分，將每一個因素最后通過公式綜合起來，返回該文檔的最終得分。這個綜合考量的過程，就是我們希望相關(guān)的文檔被優(yōu)先返回的考量過程。在Lucene和es中這種相關(guān)性稱為得分。
在開始計算得分之前，es使用了被搜索詞條的頻率和它有多常見來影響得分，從兩個方面理解：
- 一個詞條在某篇文檔中出現(xiàn)的次數(shù)越多，該文檔就越相關(guān)。
- 一個詞條如果在不同的文檔中出現(xiàn)的次數(shù)越多，它就越不相關(guān)！
我們稱之為TF-IDF，TF是詞頻（term frequency），而IDF是逆文檔頻率（inverse document frequency）。
2.1 詞頻：TF
考慮一篇文檔得分的首要方式，是查看一個詞條在文檔中出現(xiàn)的次數(shù)，比如某篇文章圍繞es的打分展開的，那么文章中肯定會多次出現(xiàn)相關(guān)字眼，當(dāng)查詢時，我們認(rèn)為該篇文檔更符合，所以，這篇文檔的得分會更高。
閑的蛋疼的可以Ctrl + f搜一下相關(guān)的關(guān)鍵詞（es，得分、打分）之類的試試。
2.2 逆文檔頻率：IDF
相對于詞頻，逆文檔頻率稍顯復(fù)雜，如果一個詞條在索引中的不同文檔中出現(xiàn)的次數(shù)越多，那么它就越不重要。
來個例子，示例：
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，因為它出現(xiàn)在2篇文檔中，文檔的逆源自得分乘以1/DF，DF是該詞條的文檔頻率，這就意味著，由于ICU詞條擁有更高的文檔頻率，所以，它的權(quán)重會降低。
- 詞條the的文檔頻率是3，它在3篇文檔中都出現(xiàn)了，注意：盡管the在后兩篇文檔出都出現(xiàn)兩次，但是它的詞頻是還是3，因為，逆文檔詞頻只檢查詞條是否出現(xiàn)在某篇文檔中，而不檢查它在這篇文檔中出現(xiàn)了多少次，那是詞頻該干的事兒。
逆文檔詞頻是一個重要的因素，用來平衡詞條的詞頻。比如我們搜索the 996.ICU。單詞the幾乎出現(xiàn)在所有的文檔中（中文中比如的“的”），如果這個鬼東西要不被均衡一下，那么the的頻率將完全淹沒996.ICU。所以，逆文檔詞頻就有效的均衡了the這個常見詞的相關(guān)性影響。以達(dá)到實際的相關(guān)性得分將會對查詢的詞條有一個更準(zhǔn)確地描述。
當(dāng)詞頻和逆文檔詞頻計算完成。就可以使用TF-IDF公式來計算文檔的得分了。
三 Lucene評分公式
之前的討論Lucene默認(rèn)評分公式被稱為TF-IDF，一個基于詞頻和逆文檔詞頻的公式。Lucene實用評分公式如下：
你以為我會著重介紹這個該死的公式？！
我只能說，詞條的詞頻越高，得分越高；相似地，索引中詞條越罕見，逆文檔頻率越高，其中再加商調(diào)和因子和查詢標(biāo)準(zhǔn)化，調(diào)和因子考慮了搜索過多少文檔以及發(fā)現(xiàn)了多少詞條；
查詢標(biāo)準(zhǔn)化，是試圖讓不同的查詢結(jié)果具有可比性，這顯然.....很困難。
我們稱這種默認(rèn)的打分方法是TF-IDF和向量空間模型（vector space model）的結(jié)合。
四 其他的打分方法
除了TF-IDF結(jié)合向量空間模型的實用評分模式，是es和Lucene最為主流的評分機制，但這并不是唯一的，除了TF-IDF這種實用模型之外，其他的模型包括：
- Okapi BM25。
- 隨機性分歧（Divergence from randomness），即DFR相似度。
- LM Dirichlet相似度。
- LM Jelinek Mercer相似度。
這里簡要的介紹BM25幾種主要設(shè)置，即k1、b和discount_overlaps：
- k1和b是數(shù)值的設(shè)置，用于調(diào)整得分是如何計算的。
- k1控制對于得分而言詞頻（TF）的重要性。
- b是介于0 ~ 1之間的數(shù)值，它控制了文檔篇幅對于得分的影響程度。
- 默認(rèn)情況下，k1設(shè)置為1.2，而b則被設(shè)置為0.75
- discount_overlaps的設(shè)置用于告訴es，在某個字段中，多少個分詞出現(xiàn)在同一位置，是否應(yīng)該影響長度的標(biāo)準(zhǔn)化，默認(rèn)值是true。
五 配置打分模型
5.1 簡要配置BM25打分模型
BM25（是不是跟pm2.5好像?。。。┦且环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"
}
}
}
上例是通過similarity參數(shù)來指定打分模型。至于查詢，還是當(dāng)數(shù)據(jù)量比較大的時候，多試幾次，比較容易發(fā)現(xiàn)不同之處。
5.2 為BM25配置高級的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是一個用來修改文檔相關(guān)性的程序。boosting有兩種類型：
- 索引的時候，比如我們在定義mappings的時候。
- 查詢一篇文檔的時候。
以上兩種方式都可以提升一個篇文檔的得分。需要注意的是：在索引期間修改的文檔boosting是存儲在索引中的，要想修改boosting必須重新索引該篇文檔。
6.1 索引期間的boosting
啥也不說了，都在酒里！上代碼：
PUT w4
{
"mappings": {
"doc": {
"properties": {
"name": {
"boost": 2.0,
"type": "text"
},
"age": {
"type": "long"
}
}
}
}
}
一勞永逸是沒錯，但一般不推薦這么玩。
原因之一是因為一旦映射建立完成，那么所有name字段都會自動擁有一個boost值。要想修改這個值，那就必須重新索引文檔。
另一個原因是，boost值是以降低精度的數(shù)值存儲在Lucene內(nèi)部的索引結(jié)構(gòu)中。只有一個字節(jié)用于存儲浮點型數(shù)值（存不下就損失精度了），所以，計算文檔的最終得分時可能會損失精度。
最后，boost是應(yīng)用與詞條的。因此，再被boost的字段中如果匹配上了多個詞條，就意味著計算多次的boost，這將會進一步增加字段的權(quán)重，可能會影響最終的文檔得分。
現(xiàn)在我們再來介紹另一種方式。
6.2 查詢期間的boosting
在es中，幾乎所有的查詢類型都支持boost，正如你想象的那些match、multi_match等等。
來個示例，在查詢期間，使用match查詢進行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"
}
來查詢：
GET w5/doc/_search
{
"query": {
"bool": {
"should": [
{
"match": {
"title":{
"query": "elasticserach rocks",
"boost": 2.5
}
}
},
{
"match": {
"content": "elasticserach rocks"
}
}
]
}
}
}
就對于最終得分而言，content字段，加了boost的title查詢更有影響力。也只有在bool查詢中，boost更有意義。
6.3 跨越多個字段的查詢
boost也可以用于multi_match查詢。
GET w5/doc/_search
{
"query": {
"multi_match": {
"query": "elasticserach rocks",
"fields": ["title", "content"],
"boost": 2.5
}
}
}
除此之外，我們還可以使用特殊的語法，只為特定的字段指定一個boost。通過在字段名稱后添加一個^符號和boost的值。告訴es只需對那個字段進行boost：
GET w5/doc/_search
{
"query": {
"multi_match": {
"query": "elasticserach rocks",
"fields": ["title^3", "content"]
}
}
}
上例中，title字段被boost了3倍。
需要注意的是：在使用boost的時候，無論是字段或者詞條，都是按照相對值來boost的，而不是乘以乘數(shù)。
如果對于所有的待搜索詞條boost了同樣的值，那么就好像沒有boost一樣（廢話，就像大家都同時長高一米似的）！因為Lucene會標(biāo)準(zhǔn)化boost的值。
如果boost一個字段4倍，不是意味著該字段的得分就是乘以4的結(jié)果。所以，如果你的得分不是按照嚴(yán)格的乘法結(jié)果，也不要擔(dān)心。
七 使用“解釋”來理解文檔是如何評分的
一切都不是你想的那樣！是的，在es中，一個文檔要比另一個文檔更符合某個查詢很可能跟我們想象的不太一樣！
這一小節(jié)，我們來研究下es和Lucene內(nèi)部使用了怎樣的公式來計算得分。
我們通過explain=true來告訴es，你要給灑家解釋一下為什么這個得分是這樣的？！背后到底以有什么py交易！
比如我們來查詢：
GET py1/doc/_search
{
"query": {
"match": {
"title": "北京"
}
},
"explain": true,
"_source": "title",
"size": 1
}
由于結(jié)果太長，我們這里對結(jié)果進行了過濾（"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，那么是怎么算出來的呢？
來分析，分詞“北京”在描述字段（title）出現(xiàn)1次，所以TF的綜合得分經(jīng)過"description" : "tfNorm, computed as (freq * (k1 + 1)) / (freq + k1 * (1 - b + b * fieldLength / avgFieldLength)) from:"計算，得分是1.0789746。
那么逆文檔詞頻呢？根據(jù)"description" : "idf, computed as log(1 + (docCount - docFreq + 0.5) / (docFreq + 0.5)) from:"計算得分是4.562031。
所以最終得分是：
1.0789746 * 4.562031 = 4.9223155734126
結(jié)果在四舍五入后就是4.9223156。
需要注意的是，explain的特性會給es帶來額外的性能開銷。所以，除了在調(diào)試時可以使用，生產(chǎn)環(huán)境下，應(yīng)避免使用explain。
以上就是Elasticsearches打分機制講解的詳細(xì)內(nèi)容，更多關(guān)于Elasticsearches打分機制的資料請關(guān)注腳本之家其它相關(guān)文章！
相關(guān)文章
DVWA下載、安裝、使用(漏洞測試環(huán)境搭建)的詳細(xì)教程
這篇文章主要介紹了DVWA下載、安裝、使用(漏洞測試環(huán)境搭建)的詳細(xì)教程,本文通過圖文并茂的形式給大家介紹的非常詳細(xì)，對大家的學(xué)習(xí)或工作具有一定的參考借鑒價值，需要的朋友可以參考下2020-10-10
這篇文章主要為大家介紹了Git配置用戶簽名方式的拓展示例實現(xiàn)全面講解，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進步，早日升職加薪2022-04-04
這篇文章主要介紹了如何利用FFmpeg合并音頻和視頻,詳細(xì)介紹了FFmpeg 多個音頻合并的2種方法，通過場景分享介紹了FFmpeg合并視頻文件的4種方法，需要的朋友可以參考下2023-02-02
這篇文章主要介紹了使用postman進行接口測試的方法(測試用戶管理模塊)，本文給大家介紹的非常詳細(xì)，對大家的學(xué)習(xí)或工作具有一定的參考借鑒價值，需要的朋友參考下吧2021-01-01
SecureCRT是一款支持SSH的終端仿真程序，在今后的工作和學(xué)習(xí)中會經(jīng)常的用到用來連接linux服務(wù)器。本文重點給大家介紹SecureCRT的下載、安裝詳細(xì)過程，感興趣的朋友一起看看吧2021-11-11
大數(shù)據(jù)就業(yè)的三大方向和最熱門十大崗位【推薦】
這篇文章主要介紹了大數(shù)據(jù)就業(yè)的三大方向和最熱門十大崗位,需要的朋友可以參考下2019-06-06
這篇文章主要為大家介紹了git用戶自定義變量查看修改及調(diào)用教程詳解，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進步，早日升職加薪2022-04-04
本文主要介紹了什么是gRPC，文中通過示例代碼介紹的非常詳細(xì)，對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值，需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2023-05-05
DataGrip是一款數(shù)據(jù)庫管理客戶端工具，方便連接到數(shù)據(jù)庫服務(wù)器，執(zhí)行sql、創(chuàng)建表、創(chuàng)建索引以及導(dǎo)出數(shù)據(jù)等。這篇文章主要介紹了DataGrip 2020.1 安裝與激活教程,需要的朋友可以參考下2020-09-09
這篇文章主要介紹了一個30多年編程經(jīng)驗的程序員總結(jié),在我30多年的程序員生涯里,我學(xué)到了不少有用的東西,下面是我這些年積累的經(jīng)驗精華,需要的朋友可以參考下2014-09-09