建议器

通过使用建议器，可基于提供的文本建议类似的词语。

POST my-index-000001/_search
{
  "query" : {
    "match": {
      "message": "tring out Elasticsearch"
    }
  },
  "suggest" : {
    "my-suggestion" : {
      "text" : "tring out Elasticsearch",
      "term" : {
        "field" : "message"
      }
    }
  }
}

请求

建议功能通过使用建议器，基于提供的文本建议类似的词语。建议请求部分与 _search 请求中的查询部分一起定义。如果省略了查询部分，则只返回建议。

示例

每个请求可以指定多个建议。每个建议都有一个任意的名称。在下面的例子中，需要两条建议。my-suggest-1 和 my-suggest-2 建议都使用 term 建议器，但不同于 text。

POST _search
{
  "suggest": {
    "my-suggest-1" : {
      "text" : "tring out Elasticsearch",
      "term" : {
        "field" : "message"
      }
    },
    "my-suggest-2" : {
      "text" : "kmichy",
      "term" : {
        "field" : "user.id"
      }
    }
  }
}

下面的建议响应示例包括 my-suggest-1 和 my-suggest-2 的建议响应。每个建议部分都包含条目。每个条目实际上是建议文本中的一个标记，包含建议条目文本、建议文本中的原始起始偏移量和长度，如果找到，还包含任意数量的选项。

{
  "_shards": ...
  "hits": ...
  "took": 2,
  "timed_out": false,
  "suggest": {
    "my-suggest-1": [ {
      "text": "tring",
      "offset": 0,
      "length": 5,
      "options": [ {"text": "trying", "score": 0.8, "freq": 1 } ]
    }, {
      "text": "out",
      "offset": 6,
      "length": 3,
      "options": []
    }, {
      "text": "elasticsearch",
      "offset": 10,
      "length": 13,
      "options": []
    } ],
    "my-suggest-2": ...
  }
}

每个选项数组都包含一个选项对象，其中包括建议文本、其文档频率以及与建议条目文本相比的分数。分数的意义取决于所用的建议词。术语建议者的分数基于编辑距离。

全局建议文本

为了避免重复建议文本，可以定义一个全局文本。在下面的示例中，建议文本是全局定义的，适用于 my-suggest-1 和 my-suggest-2 建议。

POST _search
{
  "suggest": {
    "text" : "tring out Elasticsearch",
    "my-suggest-1" : {
      "term" : {
        "field" : "message"
      }
    },
    "my-suggest-2" : {
       "term" : {
        "field" : "user"
       }
    }
  }
}

上述示例中的建议文本也可以指定为建议特定选项。建议级别上指定的建议文本将覆盖全局级别上的建议文本。

词语建议器

term 建议器根据编辑距离建议词语。在建议词语之前，先分析所提供的建议文本。建议条款根据分析的建议文本标记提供。term 建议器不考虑作为请求一部分的查询。

常见建议选项

其他词语建议选项

短语建议器

term 建议器提供了一个非常方便的 API，可以在一定的字符串距离内以每个标记为基础访问单词替代项。API 允许单独访问流中的每个令牌，而建议选择留给 API 使用者。然而，通常需要预先选择的建议才能呈现给最终用户。phrase 建议器在 term 建议器的基础上添加了额外的逻辑，以选择完整的已更正短语，而不是基于 ngram-language 模型加权的单个标记。在实践中，这个建议器将能够根据共现和频率更好地决定选择哪些记号。

API 示例

一般来说，phrase 建议器需要在工作前进行特殊映射。本页上的 phrase 提示示例需要以下映射才能工作。reverse 分析器仅在最后一个示例中使用。

PUT test
{
  "settings": {
    "index": {
      "number_of_shards": 1,
      "analysis": {
        "analyzer": {
          "trigram": {
            "type": "custom",
            "tokenizer": "standard",
            "filter": ["lowercase","shingle"]
          },
          "reverse": {
            "type": "custom",
            "tokenizer": "standard",
            "filter": ["lowercase","reverse"]
          }
        },
        "filter": {
          "shingle": {
            "type": "shingle",
            "min_shingle_size": 2,
            "max_shingle_size": 3
          }
        }
      }
    }
  },
  "mappings": {
    "properties": {
      "title": {
        "type": "text",
        "fields": {
          "trigram": {
            "type": "text",
            "analyzer": "trigram"
          },
          "reverse": {
            "type": "text",
            "analyzer": "reverse"
          }
        }
      }
    }
  }
}
POST test/_doc?refresh=true
{"title": "noble warriors"}
POST test/_doc?refresh=true
{"title": "nobel prize"}

一旦设置了分析器和映射，就可以在使用 term 建议器的同一位置使用 phrase 建议器：

POST test/_search
{
  "suggest": {
    "text": "noble prize",
    "simple_phrase": {
      "phrase": {
        "field": "title.trigram",
        "size": 1,
        "gram_size": 3,
        "direct_generator": [ {
          "field": "title.trigram",
          "suggest_mode": "always"
        } ],
        "highlight": {
          "pre_tag": "<em>",
          "post_tag": "</em>"
        }
      }
    }
  }
}

回复中包含的建议由最有可能的拼写更正者首先评分。在这种情况下，我们收到了预期的更正“nobel prize”。

{
  "_shards": ...
  "hits": ...
  "timed_out": false,
  "took": 3,
  "suggest": {
    "simple_phrase" : [
      {
        "text" : "noble prize",
        "offset" : 0,
        "length" : 11,
        "options" : [ {
          "text" : "nobel prize",
          "highlighted": "<em>nobel</em> prize",
          "score" : 0.48614594
        }]
      }
    ]
  }
}

基本短语建议 API 参数

POST test/_search
{
  "suggest": {
    "text" : "noble prize",
    "simple_phrase" : {
      "phrase" : {
        "field" :  "title.trigram",
        "size" :   1,
        "direct_generator" : [ {
          "field" :            "title.trigram",
          "suggest_mode" :     "always",
          "min_word_length" :  1
        } ],
        "collate": {
          "query": {
            "source" : {
              "match": {
                "{{field_name}}" : "{{suggestion}}"
              }
            }
          },
          "params": {"field_name" : "title"},
          "prune": true
        }
      }
    }
  }
}

1. "query"：此查询将针对每个建议运行一次。
2. "{{field_name}}" : "{{suggestion}}"：{{suggestion}} 变量将被每个建议的文本替换。
3. "params": {"field_name" : "title"}：params 中指定了一个额外的 field_name 变量，用于 match 查询。
4. "prune": true：所有建议都将返回一个额外的 collate_match 选项，指示生成的短语是否与任何文档匹配。

平滑模型

phrase 建议器支持多个平滑模型来平衡不频繁的 grams（grams（shingles）在索引中不存在）和频繁 grams（在索引中至少出现一次）之间的权重。通过将 smoothing 参数设置为以下选项之一，可以选择平滑模型。每个平滑模型都支持可以配置的特定属性。

POST test/_search
{
  "suggest": {
    "text" : "obel prize",
    "simple_phrase" : {
      "phrase" : {
        "field" : "title.trigram",
        "size" : 1,
        "smoothing" : {
          "laplace" : {
            "alpha" : 0.7
          }
        }
      }
    }
  }
}

候选生成器

phrase 建议器使用候选生成器生成给定文本中每个词语的可能词语列表。单个候选生成器类似于为文本中的每个词语调用的 term 建议器。生成器的输出随后与建议候选项的其他词语中的候选项一起评分。

目前只支持一种类型的候选生成器，即 direct_generator。短语建议 API 接受键 direct_generator 下的生成器列表；在原始文本中，列表中的每个生成器都是按词语调用的。

直接生成器

直接生成器支持以下参数：

下面的示例显示了一个带有两个生成器的短语建议调用：第一个使用包含普通索引项的字段，第二个使用使用反向过滤器索引的项的字段（标记按反向顺序索引）。这是用来克服直接生成器需要恒定前缀以提供高性能建议的限制。pre_filter 和 post_filter 选项接受普通的分析器名称。

POST test/_search
{
  "suggest": {
    "text" : "obel prize",
    "simple_phrase" : {
      "phrase" : {
        "field" : "title.trigram",
        "size" : 1,
        "direct_generator" : [ {
          "field" : "title.trigram",
          "suggest_mode" : "always"
        }, {
          "field" : "title.reverse",
          "suggest_mode" : "always",
          "pre_filter" : "reverse",
          "post_filter" : "reverse"
        } ]
      }
    }
  }
}

pre_filter 和 post_filter 也可用于在生成候选词后注入同义词。例如，对于 captain usq 查询，我们可能会为词语 usq 生成一个候选 usa，usq 是 america 的同义词。如果这个短语得分足够高，我们就可以向用户展示 captain america。

完成建议器

completion 建议器提供键入时自动完成/搜索功能。这是一种导航功能，可以在用户键入相关结果时引导用户，从而提高搜索精度。它不是为了拼写纠正，或者你指的是像 term 或 phrase 提示器这样的功能。

理想情况下，自动完成功能应该与用户键入的内容一样快，以提供与用户已键入内容相关的即时反馈。因此，completion 建议器针对速度进行了优化。建议器使用能够快速查找的数据结构，但构建成本很高，且存储在内存中。

映射

要使用此功能，请为此字段指定一个特殊映射，该映射为字段值建立索引，以便快速完成。

PUT music
{
  "mappings": {
    "properties": {
      "suggest": {
        "type": "completion"
      },
      "title": {
        "type": "keyword"
      }
    }
  }
}

映射支持以下参数：

索引

你可以像其他领域一样索引建议。建议由输入和可选的权重属性组成。输入是建议查询所匹配的预期文本，权重决定建议的评分方式。建议如下：

PUT music/_doc/1?refresh
{
  "suggest" : {
    "input": [ "Nevermind", "Nirvana" ],
    "weight" : 34
  }
}

支持以下参数：

你可以为一个文档的多个建议编制索引，如下所示：

PUT music/_doc/1?refresh
{
  "suggest": [
    {
      "input": "Nevermind",
      "weight": 10
    },
    {
      "input": "Nirvana",
      "weight": 3
    }
  ]
}

你可以使用下面的速记形式。请注意，你不能以速记形式指定带有建议的权重。

PUT music/_doc/1?refresh
{
  "suggest" : [ "Nevermind", "Nirvana" ]
}

查询

POST music/_search?pretty
{
  "suggest": {
    "song-suggest": {
      "prefix": "nir",
      "completion": {
          "field": "suggest"  
      }
    }
  }
}

1. "prefix": "nir"：用于搜索建议的前缀
2. "completion"：建议类型
3. "field": "suggest" ：在其中搜索建议的字段名称

返回以下响应：

{
  "_shards" : {
    "total" : 1,
    "successful" : 1,
    "skipped" : 0,
    "failed" : 0
  },
  "hits": ...
  "took": 2,
  "timed_out": false,
  "suggest": {
    "song-suggest" : [ {
      "text" : "nir",
      "offset" : 0,
      "length" : 3,
      "options" : [ {
        "text" : "Nirvana",
        "_index": "music",
        "_id": "1",
        "_score": 1.0,
        "_source": {
          "suggest": ["Nevermind", "Nirvana"]
        }
      } ]
    } ]
  }
}

!> _source 源元数据字段必须启用（这是默认行为），才能使用建议返回 _source。

建议的配置权重作为 _source 返回。text 字段使用索引建议的 input。默认情况下，建议返回完整的文档 _source。由于磁盘提取和网络传输开销，_source 的大小可能会影响性能。为了节省一些网络开销，请使用源过滤从 _source 中筛选出不必要的字段，以最小化 _source 的大小。请注意 _suggest 端点不支持源过滤，但在 _search 端点上可以使用建议：

POST music/_search
{
  "_source": "suggest",
  "suggest": {
    "song-suggest": {
      "prefix": "nir",
      "completion": {
        "field": "suggest",
        "size": 5
      }
    }
  }
}

1. "_source": "suggest"：过滤源以仅返回 suggest 字段
2. "field": "suggest"：要在其中搜索建议的字段的名称
3. "size": 5：要返回的建议数

结果类似如下：

{
  "took": 6,
  "timed_out": false,
  "_shards": {
    "total": 1,
    "successful": 1,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": {
      "value": 0,
      "relation": "eq"
    },
    "max_score": null,
    "hits": []
  },
  "suggest": {
    "song-suggest": [ {
        "text": "nir",
        "offset": 0,
        "length": 3,
        "options": [ {
            "text": "Nirvana",
            "_index": "music",
            "_id": "1",
            "_score": 1.0,
            "_source": {
              "suggest": [ "Nevermind", "Nirvana" ]
            }
          } ]
      } ]
  }
}

基本完成建议查询支持以下参数：

?> 完成建议器考虑索引中的所有文档。有关如何查询文档子集的说明，参阅上下文建议器。

?> 如果完成查询跨越多个分片，建议分两个阶段执行，其中最后一个阶段从分片获取相关文档，这意味着针对单个分片执行完成请求的性能更高，因为当建议跨越多个分片时，文档获取开销更大。为了获得最佳的完成性能，建议将完成索引到单个分片索引中。如果由于碎片大小导致堆使用率较高，仍然建议将索引拆分为多个碎片，而不是优化完成性能。

跳过重复的建议

查询可以返回来自不同文档的重复建议。可以通过将 skip_duplicates 设置为 true 来修改此行为。设置后，此选项会从结果中过滤出包含重复建议的文档。

POST music/_search?pretty
{
  "suggest": {
    "song-suggest": {
      "prefix": "nor",
      "completion": {
        "field": "suggest",
        "skip_duplicates": true
      }
    }
  }
}

!> 当设置为 true 时，此选项会减慢搜索速度，因为需要访问更多建议才能找到前 N 个。

模糊查询

完成建议器还支持模糊查询——这意味着你可以在搜索中输错，但仍然可以获得返回结果。

POST music/_search?pretty
{
  "suggest": {
    "song-suggest": {
      "prefix": "nor",
      "completion": {
        "field": "suggest",
        "fuzzy": {
          "fuzziness": 2
        }
      }
    }
  }
}

与查询 prefix 共享最长前缀的建议将获得更高的分数。

模糊查询可以采用特定的模糊参数。支持以下参数：

?> 如果你想坚持使用默认值，但仍然使用fuzzy，可以使用 fuzzy:{} 或 fuzzy:true。

正则查询

完成建议器还支持正则表达式查询，这意味着你可以将前缀表示为正则表达式。

POST music/_search?pretty
{
  "suggest": {
    "song-suggest": {
      "regex": "n[ever|i]r",
      "completion": {
        "field": "suggest"
      }
    }
  }
}

正则查询可以采用特定的正则参数。支持以下参数：

上下文建议器

完成建议器会考虑索引中的所有文档，但通常需要提供经过筛选和/或通过某些标准增强的建议。例如，你希望建议由某些艺术家筛选的歌曲标题，或者希望根据他们的流派增加歌曲标题。

要实现建议过滤和/或增强，可以在配置完成字段时添加上下文映射。可以为一个完成字段定义多个上下文映射。每个上下文映射都有一个唯一的名称和类型。有两种类型：category 和 geo。上下文映射在字段映射中的 contexts 参数下配置。

?> 索引和查询启用上下文的完成字段时，必须提供上下文。

?> 允许的最大完成字段上下文映射数为 10。

以下定义了类型，每个类型都有两个用于完成字段的上下文映射：

PUT place
{
  "mappings": {
    "properties": {
      "suggest": {
        "type": "completion",
        "contexts": [
          {
            "name": "place_type",
            "type": "category"
          },
          {
            "name": "location",
            "type": "geo",
            "precision": 4
          }
        ]
      }
    }
  }
}

1. "type": "category"： 定义一个名为 place_type 的 category 上下文，类别必须与建议一起发送。
2. "type": "geo"：定义一个名为 location 的 geo 上下文，类别必须与建议一起发送到该位置。

PUT place_path_category
{
  "mappings": {
    "properties": {
      "suggest": {
        "type": "completion",
        "contexts": [
          {
            "name": "place_type",
            "type": "category",
            "path": "cat"
          },
          {
            "name": "location",
            "type": "geo",
            "precision": 4,
            "path": "loc"
          }
        ]
      },
      "loc": {
        "type": "geo_point"
      }
    }
  }
}

1. "type": "category"：定义一个名为 place_type 的 category 上下文，从 cat 字段中读取类别。
2. "type": "geo"：定义一个名为 location 的 geo 上下文，从 loc 字段中读取类别。

?> 添加上下文映射会增加完成字段的索引大小。完成索引完全驻留在堆中，你可以使用索引统计信息监视完成字段索引大小。

类别上下文

category 上下文允许你在索引时将一个或多个类别与建议关联。在查询时，建议可以通过其关联的类别进行过滤和增强。

映射的设置与上面的 place_type 字段类似。如果定义了 path，则从文档中的该路径读取类别，否则它们必须在建议字段中发送，如下所示：

PUT place/_doc/1
{
  "suggest": {
    "input": [ "timmy's", "starbucks", "dunkin donuts" ],
    "contexts": {
      "place_type": [ "cafe", "food" ]
    }
  }
}

1. "place_type": [ "cafe", "food" ]：这些建议将与 cafe 和 food 类别相关联。

如果映射有路径，那么以下索引请求就足以添加类别：

PUT place_path_category/_doc/1
{
  "suggest": ["timmy's", "starbucks", "dunkin donuts"],
  "cat": ["cafe", "food"]
}

1. "cat": ["cafe", "food"]： 这些建议将与 cafe 和 food 类别相关联。

?> 如果上下文映射引用了另一个字段，并且对类别进行了显式索引，则建议将使用这两组类别进行索引。

类别查询

建议可以按一个或多个类别过滤。以下按多个类别筛选建议：

POST place/_search?pretty
{
  "suggest": {
    "place_suggestion": {
      "prefix": "tim",
      "completion": {
        "field": "suggest",
        "size": 10,
        "contexts": {
          "place_type": [ "cafe", "restaurants" ]
        }
      }
    }
  }
}

?> 如果在查询中设置了多个类别或类别上下文，它们将作为析取合并。这意味着，如果建议至少包含一个提供的上下文值，则建议匹配。

某些类别的建议可以比其他类别的建议更高。以下内容按类别过滤建议，并进一步增强与某些类别相关的建议：

POST place/_search?pretty
{
  "suggest": {
    "place_suggestion": {
      "prefix": "tim",
      "completion": {
        "field": "suggest",
        "size": 10,
        "contexts": {
          "place_type": [
            { "context": "cafe" },
            { "context": "restaurants", "boost": 2 }
          ]
        }
      }
    }
  }
}

1. "place_type"：上下文查询过滤与类别咖啡馆和餐馆相关的建议，并将与餐馆相关的建议提高 2 倍

除了接受类别值外，上下文查询还可以由多个类别上下文子句组成。类别上下文子句支持以下参数：

?> 如果一个建议条目匹配多个上下文，则最终分数将计算为任何匹配上下文产生的最大分数。

地理位置上下文

geo 上下文允许你在索引时将一个或多个地理点或地理哈希与建议关联。在查询时，如果建议位于指定地理位置的特定距离内，则可以对其进行过滤和增强。

在内部，地理点被编码为具有指定精度的地理哈希。

地理映射

除 path 设置外，geo 上下文映射还接受以下设置：

?> 索引时间 precision 设置设置可在查询时使用的最大地理哈希精度。

索引地理上下文

geo 上下文可以通过建议显式设置，或者通过 path 参数从文档中的地理点字段建立索引，类似于 category 上下文。将多个地理位置上下文与建议关联，将为每个地理位置的建议编制索引。以下索引包含两个地理位置上下文：

 PUT place/_doc/1
{
  "suggest": {
    "input": "timmy's",
    "contexts": {
      "location": [
        {
          "lat": 43.6624803,
          "lon": -79.3863353
        },
        {
          "lat": 43.6624718,
          "lon": -79.3873227
        }
      ]
    }
  }
}

地理位置查询

建议可以根据它们与一个或多个地理点的距离进行过滤和增强。以下过滤属于由地理点的编码地理哈希表示的区域内的建议：

POST place/_search
{
  "suggest": {
    "place_suggestion": {
      "prefix": "tim",
      "completion": {
        "field": "suggest",
        "size": 10,
        "contexts": {
          "location": {
            "lat": 43.662,
            "lon": -79.380
          }
        }
      }
    }
  }
}

?> 当指定查询时精度较低的位置时，将考虑该区域内的所有建议。

?> 如果在查询中设置了多个类别或类别上下文，它们将作为析取合并。这意味着，如果建议至少包含一个提供的上下文值，则建议匹配。

在地理哈希表示的区域内的建议也可以比其他建议更高，如下所示：

POST place/_search?pretty
{
  "suggest": {
    "place_suggestion": {
      "prefix": "tim",
      "completion": {
        "field": "suggest",
        "size": 10,
        "contexts": {
          "location": [
                      {
              "lat": 43.6624803,
              "lon": -79.3863353,
              "precision": 2
            },
            {
              "context": {
                "lat": 43.6624803,
                "lon": -79.3863353
              },
              "boost": 2
            }
          ]
        }
      }
    }
  }
}

1. "location"：上下文查询过滤属于地理哈希 （43.662，-79.380） 表示的地理位置的建议（精度为 2），并将属于地理哈希 （43.6624803，-79.3863353） 表示的建议（默认精度为 6）的建议提升 2 倍

?> 如果一个建议条目匹配多个上下文，则最终分数将计算为任何匹配上下文产生的最大分数。

除了接受上下文值之外，上下文查询还可以由多个上下文子句组成。geo 上下文子句支持以下参数：

返回建议器类型

有时你需要知道建议者的确切类型，以便分析其结果。typed_keys 参数可用于更改响应中建议者的名称，以便以其类型作为前缀。

考虑以下两个建议 term 和 phrase 的示例：

POST _search?typed_keys
{
  "suggest": {
    "text" : "some test mssage",
    "my-first-suggester" : {
      "term" : {
        "field" : "message"
      }
    },
    "my-second-suggester" : {
      "phrase" : {
        "field" : "message"
      }
    }
  }
}

在回复中，建议者的名称将分别更改为 term#my-first-suggester 和 phrase#my-second-suggester，以反映每个建议的类型：

{
  "suggest": {
    "term#my-first-suggester": [ 
      {
        "text": "some",
        "offset": 0,
        "length": 4,
        "options": []
      },
      {
        "text": "test",
        "offset": 5,
        "length": 4,
        "options": []
      },
      {
        "text": "mssage",
        "offset": 10,
        "length": 6,
        "options": [
          {
            "text": "message",
            "score": 0.8333333,
            "freq": 4
          }
        ]
      }
    ],
    "phrase#my-second-suggester": [ 
      {
        "text": "some test mssage",
        "offset": 0,
        "length": 16,
        "options": [
          {
            "text": "some test message",
            "score": 0.030227963
          }
        ]
      }
    ]
  },
  ...
}

1. "term#my-first-suggester"：my-first-suggester的名字现在包含了 term 前缀。
2. "phrase#my-second-suggester"：my-second-suggester 的名字现在包含 phrase 前缀。

原文链接