[Elasticsearch] 多欄位搜尋 (五)，elasticsearch欄位

[Elasticsearch] 多欄位搜尋 (五)，elasticsearch欄位
以欄位為中心的查詢(Field-centric Queries)

上述提到的三個問題都來源於most_fields是以欄位為中心(Field-centric)，而不是以詞條為中心(Term-centric)：它會查詢最多匹配的欄位(Most matching fields)，而我們真正感興趣的最匹配的詞條(Most matching terms)。

NOTE

best_fields同樣是以欄位為中心的，因此它也存在相似的問題。

首先我們來看看為什麼存在這些問題，以及如何解決它們。

問題1：在多個欄位中匹配相同的單詞

考慮一下most_fields查詢是如何執行的：ES會為每個欄位產生一個match查詢，讓後將它們包含在一個bool查詢中。

我們可以將查詢傳入到validate-query API中進行查看：

GET /_validate/query?explain{  "query": {    "multi_match": {      "query":   "Poland Street W1V",      "type":    "most_fields",      "fields":  [ "street", "city", "country", "postcode" ]    }  }}

它會產生下面的解釋(explaination)：

(street:poland street:street street:w1v) (city:poland city:street city:w1v) (country:poland country:street country:w1v) (postcode:poland postcode:street postcode:w1v)

你可以發現能夠在兩個欄位中匹配poland的文檔會比在一個欄位中匹配了poland和street的文檔的分值要高。

問題2：減少長尾

在精度控制(Controlling Precision)一節中，我們討論了如何使用and操作符和minimum_should_match參數來減少相關度低的文檔數量：

{    "query": {        "multi_match": {            "query":       "Poland Street W1V",            "type":        "most_fields",            "operator":    "and",             "fields":      [ "street", "city", "country", "postcode" ]        }    }}

但是，使用best_fields或者most_fields，這些參數會被傳遞到產生的match查詢中。該查詢的解釋如下(譯註：通過validate-query API)：

(+street:poland +street:street +street:w1v) (+city:poland +city:street +city:w1v) (+country:poland +country:street +country:w1v) (+postcode:poland +postcode:street +postcode:w1v)

換言之，使用and操作符時，所有的單詞都需要出現在相同的欄位中，這顯然是錯的！這樣做可能不會有任何匹配的文檔。

問題3：詞條頻度

在什麼是相關度(What is Relevance)一節中，我們解釋了預設用來計算每個詞條的相關度分值的相似度演算法TF/IDF：

詞條頻度(Term Frequency)

在一份文檔中，一個詞條在一個欄位中出現的越頻繁，文檔的相關度就越高。

倒排文檔頻度(Inverse Document Frequency)

一個詞條在索引的所有文檔的欄位中出現的越頻繁，詞條的相關度就越低。

當通過多欄位進行搜尋時，TF/IDF會產生一些令人驚訝的結果。

考慮使用first_name和last_name欄位搜尋"Peter Smith"的例子。Peter是一個常見的名字，Smith是一個常見的姓氏 - 它們的IDF都較低。但是如果在索引中有另外一個名為Smith Williams的人呢？Smith作為名字是非常罕見的，因此它的IDF值會很高！

像下面這樣的一個簡單查詢會將Smith Williams放在Peter Smith前面(譯註：含有Smith Williams的文檔分值比含有Peter Smith的文檔分值高)，儘管Peter Smith明顯是更好的匹配：

{    "query": {        "multi_match": {            "query":       "Peter Smith",            "type":        "most_fields",            "fields":      [ "*_name" ]        }    }}

smith在first_name欄位中的高IDF值會壓倒peter在first_name欄位和smith在last_name欄位中的兩個低IDF值。

解決方案

這個問題僅在我們處理多欄位時存在。如果我們將所有這些欄位合并到一個欄位中，該問題就不複存在了。我們可以向person文檔中添加一個full_name欄位來實現：

{    "first_name":  "Peter",    "last_name":   "Smith",    "full_name":   "Peter Smith"}

當我們只查詢full_name欄位時：

• 擁有更多匹配單詞的文檔會勝過那些重複出現一個單詞的文檔。
• minimum_should_match和operator參數能夠正常工作。
• first_name和last_name的倒排文檔頻度會被合并，因此smith無論是first_name還是last_name都不再重要。

儘管這種方法能工作，可是我們並不想儲存冗餘資料。因此，ES為我們提供了兩個解決方案 - 一個在索引期間，一個在搜尋期間。下一節對它們進行討論。