1. 程式人生 > >ElasticSearch6.2.4(18)——Elasticsearch Suggester詳解

ElasticSearch6.2.4(18)——Elasticsearch Suggester詳解

現代的搜尋引擎,一般會具備"Suggest As You Type"功能,即在使用者輸入搜尋的過程中,進行自動補全或者糾錯。 通過協助使用者輸入更精準的關鍵詞,提高後續全文搜尋階段文件匹配的程度。例如在Google上輸入部分關鍵詞,甚至輸入拼寫錯誤的關鍵詞時,它依然能夠提示出使用者想要輸入的內容:  

google_completion_suggester.png

google_terms_suggester.png

如果自己親手去試一下,可以看到Google在使用者剛開始輸入的時候是自動補全的,而當輸入到一定長度,如果因為單詞拼寫錯誤無法補全,就開始嘗試提示相似的詞。 那麼類似的功能在Elasticsearch裡如何實現呢? 答案就在Suggesters API。 Suggesters基本的運作原理是將輸入的文字分解為token,然後在索引的字典裡查詢相似的term並返回。 根據使用場景的不同,Elasticsearch裡設計了4種類別的Suggester,分別是:

  • Term Suggester
  • Phrase Suggester
  • Completion Suggester
  • Context Suggester

在官方的參考文件裡,對這4種Suggester API都有比較詳細的介紹,但苦於只有英文版,部分國內開發者看完文件後仍然難以理解其運作機制。 本文將在Elasticsearch 5.x上通過示例講解Suggester的基礎用法,希望能幫助部分國內開發者快速用於實際專案開發。限於篇幅,更為高階的Context Suggester會被略過。 首先來看一個Term Suggester的示例: 準備一個叫做blogs的索引,配置一個text欄位。

PUT /blogs/
{
  "mappings": {
    "tech": {
      "properties": {
        "body": {
          "type": "text"
        }
      }
    }
  }
}

通過bulk api寫入幾條文件

POST _bulk/?refresh=true
{ "index" : { "_index" : "blogs", "_type" : "tech" } }
{ "body": "Lucene is cool"}
{ "index" : { "_index" : "blogs", "_type" : "tech" } }
{ "body": "Elasticsearch builds on top of lucene"}
{ "index" : { "_index" : "blogs", "_type" : "tech" } }
{ "body": "Elasticsearch rocks"}
{ "index" : { "_index" : "blogs", "_type" : "tech" } }
{ "body": "Elastic is the company behind ELK stack"}
{ "index" : { "_index" : "blogs", "_type" : "tech" } }
{ "body": "elk rocks"}
{ "index" : { "_index" : "blogs", "_type" : "tech" } }
{  "body": "elasticsearch is rock solid"}
{ "index" : { "_index" : "blogs", "_type" : "tech" } }
{  "body": "lucene and elasticsearch rocks"}

此時blogs索引裡已經有一些文件了,可以進行下一步的探索。為幫助理解,我們先看看哪些term會存在於詞典裡。 將輸入的文字分析一下:

POST _analyze
{
  "text": [
    "Lucene is cool",
    "Elasticsearch builds on top of lucene",
    "Elasticsearch rocks",
    "Elastic is the company behind ELK stack",
    "elk rocks",
    "elasticsearch is rock solid"
  ]
}

(由於結果太長,此處略去) 這些分出來的token都會成為詞典裡一個term,注意有些token會出現多次,因此在倒排索引裡記錄的詞頻會比較高,同時記錄的還有這些token在原文件裡的偏移量和相對位置資訊。 執行一次suggester搜尋看看效果:

POST blogs/_search
{
  "size":0,
  "suggest":{
    "text":"lucne rock",
    "my_suggest1":{
      "term":{
        "field":"body",
        "suggest_mode":"missing"
      }
    }
  }
}

suggest就是一種特殊型別的搜尋,DSL內部的"text"指的是api呼叫方提供的文字,也就是通常使用者介面上使用者輸入的內容。這裡的lucne是錯誤的拼寫,模擬使用者輸入錯誤。 "term"表示這是一個term suggester。 "field"指定suggester針對的欄位,另外有一個可選的"suggest_mode"。 範例裡的"missing"實際上就是預設值,它是什麼意思?有點撓頭... 還是先看看返回結果吧:

{
  "took": 3,
  "timed_out": false,
  "_shards": {
    "total": 5,
    "successful": 5,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": 0,
    "max_score": 0,
    "hits": []
  },
  "suggest": {
    "my_suggest1": [
      {
        "text": "lucne",
        "offset": 0,
        "length": 5,
        "options": [
          {
            "text": "lucene",
            "score": 0.8,
            "freq": 2
          }
        ]
      },
      {
        "text": "rock",
        "offset": 6,
        "length": 4,
        "options": [
          {
            "text": "rocks",
            "score": 0.75,
            "freq": 2
          }
        ]
      }
    ]
  }
}

在返回結果裡"suggest" -> "my-suggestion"部分包含了一個數組,每個陣列項對應從輸入文字分解出來的token(存放在"text"這個key裡)以及為該token提供的建議詞項(存放在options數組裡)。  示例裡返回了"lucne","rock"這2個詞的建議項(options),其中"rock"的options是空的,表示沒有可以建議的選項,為什麼? 上面提到了,我們為查詢提供的suggest mode是"missing",由於"rock"在索引的詞典裡已經存在了,夠精準,就不建議啦。 只有詞典裡找不到詞,才會為其提供相似的選項。 如果將"suggest_mode"換成"popular"會是什麼效果? 嘗試一下,重新執行查詢,返回結果裡"rock"這個詞的option不再是空的,而是建議為rocks。

  "suggest": {
    "my_suggest1": [
      {
        "text": "lucne",
        "offset": 0,
        "length": 5,
        "options": [
          {
            "text": "lucene",
            "score": 0.8,
            "freq": 2
          }
        ]
      },
      {
        "text": "rock",
        "offset": 6,
        "length": 4,
        "options": [
          {
            "text": "rocks",
            "score": 0.75,
            "freq": 2
          }
        ]
      }
    ]
  }

回想一下,rock和rocks在索引詞典裡都是有的。 不難看出即使使用者輸入的token在索引的詞典裡已經有了,但是因為存在一個詞頻更高的相似項,這個相似項可能是更合適的,就被挑選到options裡了。 最後還有一個"always" mode,其含義是不管token是否存在於索引詞典裡都要給出相似項。 有人可能會問,兩個term的相似性是如何判斷的? ES使用了一種叫做Levenstein edit distance的演算法,其核心思想就是一個詞改動多少個字元就可以和另外一個詞一致。 Term suggester還有其他很多可選引數來控制這個相似性的模糊程度,這裡就不一一贅述了。 Term suggester正如其名,只基於analyze過的單個term去提供建議,並不會考慮多個term之間的關係。API呼叫方只需為每個token挑選options裡的詞,組合在一起返回給使用者前端即可。 那麼有無更直接辦法,API直接給出和使用者輸入文字相似的內容? 答案是有,這就要求助Phrase Suggester了。 Phrase suggester在Term suggester的基礎上,會考量多個term之間的關係,比如是否同時出現在索引的原文裡,相鄰程度,以及詞頻等等。看個範例就比較容易明白了:

POST blogs/_search
{
  "size":0,
  "suggest":{
    "text":"lucne and elasticsear rock",
    "my_suggest1":{
      "phrase":{
        "field":"body",
        "highlight":{
          "pre_tag":"<div>",
          "post_tag":"</div>"
        }
      }
    }
  }
}

返回結果:

{
  "took": 9,
  "timed_out": false,
  "_shards": {
    "total": 5,
    "successful": 5,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": 0,
    "max_score": 0,
    "hits": []
  },
  "suggest": {
    "my_suggest1": [
      {
        "text": "lucne and elasticsear rock",
        "offset": 0,
        "length": 26,
        "options": [
          {
            "text": "lucene and elasticsearch rock",
            "highlighted": "<div>lucene</div> and <div>elasticsearch</div> rock",
            "score": 0.104138166
          },
          {
            "text": "lucene and elasticsear rocks",
            "highlighted": "<div>lucene</div> and elasticsear <div>rocks</div>",
            "score": 0.10027636
          },
          {
            "text": "lucne and elasticsearch rocks",
            "highlighted": "lucne and <div>elasticsearch rocks</div>",
            "score": 0.084910564
          },
          {
            "text": "lucene and elasticsear rock",
            "highlighted": "<div>lucene</div> and elasticsear rock",
            "score": 0.082233466
          },
          {
            "text": "lucne and elasticsearch rock",
            "highlighted": "lucne and <div>elasticsearch</div> rock",
            "score": 0.06963246
          }
        ]
      }
    ]
  }
}

options直接返回一個phrase列表,由於加了highlight選項,被替換的term會被高亮。因為lucene和elasticsearch曾經在同一條原文裡出現過,同時替換2個term的可信度更高,所以打分較高,排在第一位返回。Phrase suggester有相當多的引數用於控制匹配的模糊程度,需要根據實際應用情況去挑選和除錯。 最後來談一下Completion Suggester,它主要針對的應用場景就是"Auto Completion"。 此場景下使用者每輸入一個字元的時候,就需要即時傳送一次查詢請求到後端查詢匹配項,在使用者輸入速度較高的情況下對後端響應速度要求比較苛刻。因此實現上它和前面兩個Suggester採用了不同的資料結構,索引並非通過倒排來完成,而是將analyze過的資料編碼成FST和索引一起存放。對於一個open狀態的索引,FST會被ES整個裝載到記憶體裡的,進行字首查詢速度極快。但是FST只能用於字首查詢,這也是Completion Suggester的侷限所在。 為了使用Completion Suggester,欄位的型別需要專門定義如下:

PUT /blogs_completion/
{
  "mappings": {
    "tech": {
      "properties": {
        "body": {
          "type": "completion"
        }
      }
    }
  }
}

用bulk API索引點資料:

POST _bulk/?refresh=true
{ "index" : { "_index" : "blogs_completion", "_type" : "tech" } }
{ "body": "Lucene is cool"}
{ "index" : { "_index" : "blogs_completion", "_type" : "tech" } }
{ "body": "Elasticsearch builds on top of lucene"}
{ "index" : { "_index" : "blogs_completion", "_type" : "tech" } }
{ "body": "Elasticsearch rocks"}
{ "index" : { "_index" : "blogs_completion", "_type" : "tech" } }
{ "body": "Elastic is the company behind ELK stack"}
{ "index" : { "_index" : "blogs_completion", "_type" : "tech" } }
{ "body": "the elk stack rocks"}
{ "index" : { "_index" : "blogs_completion", "_type" : "tech" } }
{ "body": "elasticsearch is rock solid"}

查詢:

POST blogs_completion/_search?pretty
{ "size": 0,
  "suggest": {
    "blog-suggest": {
      "prefix": "elastic i",
      "completion": {
        "field": "body"
      }
    }
  }
}

結果:

"suggest": {
    "blog-suggest": [
      {
        "text": "elastic i",
        "offset": 0,
        "length": 9,
        "options": [
          {
            "text": "Elastic is the company behind ELK stack",
            "_index": "blogs_completion",
            "_type": "tech",
            "_id": "AVrXFyn-cpYmMpGqDdcd",
            "_score": 1,
            "_source": {
              "body": "Elastic is the company behind ELK stack"
            }
          }
        ]
      }
    ]
  }

值得注意的一點是Completion Suggester在索引原始資料的時候也要經過analyze階段,取決於選用的analyzer不同,某些詞可能會被轉換,某些詞可能被去除,這些會影響FST編碼結果,也會影響查詢匹配的效果。 比如我們刪除上面的索引,重新設定索引的mapping,將analyzer更改為"english":

PUT /blogs_completion/
{
  "mappings": {
    "tech": {
      "properties": {
        "body": {
          "type": "completion",
          "analyzer": "english"
        }
      }
    }
  }
}

bulk api索引同樣的資料後,執行下面的查詢:

POST blogs_completion/_search?pretty
{ "size": 0,
  "suggest": {
    "blog-suggest": {
      "prefix": "elastic i",
      "completion": {
        "field": "body"
      }
    }
  }
}

居然沒有匹配結果了,多麼費解!  原來我們用的english analyzer會剝離掉stop word,而is就是其中一個,被剝離掉了! 用analyze api測試一下:

POST _analyze?analyzer=english
{
  "text": "elasticsearch is rock solid"
}

會發現只有3個token:
{
  "tokens": [
    {
      "token": "elasticsearch",
      "start_offset": 0,
      "end_offset": 13,
      "type": "<ALPHANUM>",
      "position": 0
    },
    {
      "token": "rock",
      "start_offset": 17,
      "end_offset": 21,
      "type": "<ALPHANUM>",
      "position": 2
    },
    {
      "token": "solid",
      "start_offset": 22,
      "end_offset": 27,
      "type": "<ALPHANUM>",
      "position": 3
    }
  ]
}

FST只編碼了這3個token,並且預設的還會記錄他們在文件中的位置和分隔符。 使用者輸入"elastic i"進行查詢的時候,輸入被分解成"elastic"和"i",FST沒有編碼這個“i” , 匹配失敗。 好吧,如果你現在還足夠清醒的話,試一下搜尋"elastic is",會發現又有結果,why?  因為這次輸入的text經過english analyzer的時候is也被剝離了,只需在FST裡查詢"elastic"這個字首,自然就可以匹配到了。 其他能影響completion suggester結果的,還有諸如"preserve_separators","preserve_position_increments"等等mapping引數來控制匹配的模糊程度。以及搜尋時可以選用Fuzzy Queries,使得上面例子裡的"elastic i"在使用english analyzer的情況下依然可以匹配到結果。

preserve_separators 如果為true,foof將找不到foo Full,只能用foo找到,因為他不能忽略停頓符號 如果為false,foof能找到foo Full,因為忽略了停頓符,當然foo F也能匹配到foo Full

size

返回數量

skip_duplicates

去重(預設為false) 因此用好Completion Sugester並不是一件容易的事,實際應用開發過程中,需要根據資料特性和業務需要,靈活搭配analyzer和mapping引數,反覆除錯才可能獲得理想的補全效果。 回到篇首Google搜尋框的補全/糾錯功能,如果用ES怎麼實現呢?我能想到的一個的實現方式:

  1. 在使用者剛開始輸入的過程中,使用Completion Suggester進行關鍵詞字首匹配,剛開始匹配項會比較多,隨著使用者輸入字元增多,匹配項越來越少。如果使用者輸入比較精準,可能Completion Suggester的結果已經夠好,使用者已經可以看到理想的備選項了。 
  2. 如果Completion Suggester已經到了零匹配,那麼可以猜測是否使用者有輸入錯誤,這時候可以嘗試一下Phrase Suggester。
  3. 如果Phrase Suggester沒有找到任何option,開始嘗試term Suggester。

精準程度上(Precision)看: Completion >  Phrase > term, 而召回率上(Recall)則反之。從效能上看,Completion Suggester是最快的,如果能滿足業務需求,只用Completion Suggester做字首匹配是最理想的。 Phrase和Term由於是做倒排索引的搜尋,相比較而言效能應該要低不少,應儘量控制suggester用到的索引的資料量,最理想的狀況是經過一定時間預熱後,索引可以全量map到記憶體。

原創地址:http://elasticsearch.cn/article/142