相關性 · Elasticsearch權威指南（中文版）

## 相關性簡介我們曾經講過，默認情況下，返回結果是按相關性倒序排列的。但是什么是相關性？相關性如何計算？每個文檔都有相關性評分，用一個相對的浮點數字段 `_score` 來表示 -- `_score` 的評分越高，相關性越高。查詢語句會為每個文檔添加一個 `_score` 字段。評分的計算方式取決于不同的查詢類型 -- 不同的查詢語句用于不同的目的：`fuzzy` 查詢會計算與關鍵詞的拼寫相似程度，`terms`查詢會計算找到的內容與關鍵詞組成部分匹配的百分比，但是一般意義上我們說的全文本搜索是指計算內容與關鍵詞的類似程度。 ElasticSearch的相似度算法被定義為 TF/IDF，即檢索詞頻率/反向文檔頻率，包括一下內容：檢索詞頻率:: 檢索詞在該字段出現的頻率？出現頻率越高，相關性也越高。字段中出現過5次要比只出現過1次的相關性高。反向文檔頻率:: 每個檢索詞在索引中出現的頻率？頻率越高，相關性越低。檢索詞出現在多數文檔中會比出現在少數文檔中的權重更低，即檢驗一個檢索詞在文檔中的普遍重要性。字段長度準則:: 字段的長度是多少？長度越長，相關性越低。檢索詞出現在一個短的 `title` 要比同樣的詞出現在一個長的 `content` 字段。單個查詢可以使用TF/IDF評分標準或其他方式，比如短語查詢中檢索詞的距離或模糊查詢里的檢索詞相似度。相關性并不只是全文本檢索的專利。也適用于`yes|no`的子句，匹配的子句越多，相關性評分越高。如果多條查詢子句被合并為一條復合查詢語句，比如 `bool` 查詢，則每個查詢子句計算得出的評分會被合并到總的相關性評分中。 ## 理解評分標準當調試一條復雜的查詢語句時，想要理解相關性評分 `_score` 是比較困難的。ElasticSearch 在每個查詢語句中都有一個explain參數，將 `explain` 設為 `true` 就可以得到更詳細的信息。 ```Javascript GET /_search?explain <1> { "query" : { "match" : { "tweet" : "honeymoon" }} } ``` <1> `explain` 參數可以讓返回結果添加一個 `_score` 評分的得來依據。 **** 增加一個 `explain` 參數會為每個匹配到的文檔產生一大堆額外內容，但是花時間去理解它是很有意義的。如果現在看不明白也沒關系 -- 等你需要的時候再來回顧這一節就行。下面我們來一點點的了解這塊知識點。 **** 首先，我們看一下普通查詢返回的元數據： ```Javascript { "_index" : "us", "_type" : "tweet", "_id" : "12", "_score" : 0.076713204, "_source" : { ... trimmed ... }, } ``` 這里加入了該文檔來自于哪個節點哪個分片上的信息，這對我們是比較有幫助的，因為詞頻率和文檔頻率是在每個分片中計算出來的，而不是每個索引中： ```Javascript "_shard" : 1, "_node" : "mzIVYCsqSWCG_M_ZffSs9Q", ``` 然后返回值中的 `_explanation` 會包含在每一個入口，告訴你采用了哪種計算方式，并讓你知道計算的結果以及其他詳情： ```Javascript "_explanation": { <1> "description": "weight(tweet:honeymoon in 0) [PerFieldSimilarity], result of:", "value": 0.076713204, "details": [ { "description": "fieldWeight in 0, product of:", "value": 0.076713204, "details": [ { <2> "description": "tf(freq=1.0), with freq of:", "value": 1, "details": [ { "description": "termFreq=1.0", "value": 1 } ] }, { <3> "description": "idf(docFreq=1, maxDocs=1)", "value": 0.30685282 }, { <4> "description": "fieldNorm(doc=0)", "value": 0.25, } ] } ] } ``` <1> `honeymoon` 相關性評分計算的總結 <2> 檢索詞頻率 <3> 反向文檔頻率 <4> 字段長度準則 >**重要**： > 輸出 `explain` 結果代價是十分昂貴的，它只能用作調試工具 > --千萬不要用于生產環境。第一部分是關于計算的總結。告訴了我們 `"honeymoon"` 在 `tweet`字段中的檢索詞頻率/反向文檔頻率或 TF/IDF，（這里的文檔 `0` 是一個內部的ID，跟我們沒有關系，可以忽略。）然后解釋了計算的權重是如何計算出來的：檢索詞頻率: 檢索詞 `honeymoon` 在 `tweet` 字段中的出現次數。反向文檔頻率: 檢索詞 `honeymoon` 在 `tweet` 字段在當前文檔出現次數與索引中其他文檔的出現總數的比率。字段長度準則: 文檔中 `tweet` 字段內容的長度 -- 內容越長，值越小。復雜的查詢語句解釋也非常復雜，但是包含的內容與上面例子大致相同。通過這段描述我們可以了解搜索結果是如何產生的。 >**提示**： >JSON形式的explain描述是難以閱讀的 >但是轉成 YAML 會好很多，只需要在參數中加上 `format=yaml` ## Explain Api #### 文檔是如何被匹配到的當`explain`選項加到某一文檔上時，它會告訴你為何這個文檔會被匹配，以及一個文檔為何沒有被匹配。請求路徑為 `/index/type/id/_explain`, 如下所示： ```Javascript GET /us/tweet/12/_explain { "query" : { "filtered" : { "filter" : { "term" : { "user_id" : 2 }}, "query" : { "match" : { "tweet" : "honeymoon" }} } } } ``` 除了上面我們看到的完整描述外，我們還可以看到這樣的描述： ```Javascript "failure to match filter: cache(user_id:[2 TO 2])" ``` 也就是說我們的 `user_id` 過濾子句使該文檔不能匹配到。