<翻译>-ES自动补全

:::info 自动翻译，主要看一下右边的目录结构。很多地方翻译的比较奇怪，可以对照原文看：https://www.elastic.co/guide/en/elasticsearch/reference/7.14/search-suggesters.html ::: Suggests
使用建议者建议基于所提供文本的类似术语。建议的部分功能仍在开发中。

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"}

设置分析器和映射后，您可以在同一地点使用phrase建议器，然后使用”建议者term：

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>"
        }
      }
    }
  }
}

响应包含由最有可能的拼写更正首先评分的建议。在这种情况下，我们获得了预期的更正”诺贝尔奖”。

{
  "_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 
        }
      }
    }
  }
}

平滑模型

phrase建议器支持多个平滑模型，以平衡指数中不存在的不常克（克（带状疱疹）和常用克（在索引中至少出现一次）之间的重量。平滑模型可以通过将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下的发电机列表：列表中的每一个生成器在原始文本中每个术语都调用。

直接发电机

直接发电机支持以下参数：

下列示例显示了一个phrase建议使用两个生成器进行呼叫：第一个使用包含普通索引字的字段，第二个使用使用反reverse过滤器索引的字段（令牌是反向顺序的索引）。这用于克服直接发电机的局限性，需要固定前缀才能提供高性能建议。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我们可能会生成一个usa这个词usq这是america同义词。这允许我们呈现captain america给用户，如果这句话得分足够高。

完成建议器

completion建议器提供自动完成/即用即用式搜索功能。这是一个导航功能，引导用户在打字时获得相关结果，提高搜索精度。它不是用于拼写校正或像term或phrase建议者这样的”你意味着”功能。
理想情况下，自动完成的功能应与用户类型一样快，以提供与用户已经输入的内容相关的即时反馈。因此，completion建议器针对速度进行了优化。建议者使用数据结构，使快速查找，但造价昂贵，并存储在内存中。

映射

要使用此功能，请指定该字段的特殊映射，该映射可对快速完成的字段值进行索引。

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

映射支持以下参数：

索引

您像任何其他字段一样索引建议。建议由input和可选weight属性组成。input是预期文本与建议查询相匹配，weight决定建议的评分方式。对建议进行索引如下：

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" ]
}

查询

建议工作照常进行，但您必须指定建议类型作为completion。建议是近乎实时的，这意味着新的建议可以通过刷新和文件删除后永远不会显示可见。此请求：

POST music/_search?pretty
{
  "suggest": {
    "song-suggest": {
      "prefix": "nir",        
      "completion": {         
          "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",
        "_type": "_doc",
        "_id": "1",
        "_score": 1.0,
        "_source": {
          "suggest": ["Nevermind", "Nirvana"]
        }
      } ]
    } ]
  }
}

_source启用_source元数据字段（默认行为）以启用返回_source的建议。
建议的配置重量返回为_scoretext字段使用您的索引建议的input。建议默认退回_source完整文档。由于磁盘取取和网络传输开销_source的大小可能会影响性能。为了节省一些网络开销，使用源过滤从_source过滤掉不必要的字段，以最大限度地减少_source大小。请注意，_suggest端点不支持源筛选，但使用_search端点的建议确实如此：

POST music/_search
{
  "_source": "suggest",     
  "suggest": {
    "song-suggest": {
      "prefix": "nir",
      "completion": {
        "field": "suggest", 
        "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",
            "_type": "_doc",
            "_id": "1",
            "_score": 1.0,
            "_source": {
              "suggest": [ "Nevermind", "Nirvana" ]
            }
          } ]
      } ]
  }
}

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

完成建议人考虑索引中的所有文档。请参阅上下文建议器，了解如何查询文档子集的解释。
如果完成查询跨越多个碎片，则建议分两个阶段执行，其中最后一阶段从碎片中获取相关文档，这意味着当建议跨越多个碎片时，对单个碎片执行完成请求更具执行力，因为文档获取开销。为了获得最佳完成性能，建议将完成数指数分为单个分项索引。如果由于碎片大小而大量使用，仍建议将索引分解成多个碎片，而不是优化完成性能。

跳过重复建议

查询可以返回来自不同文档的重复建议。可以通过将skip_duplicates设置为真实来修改此行为。设置后，此选项会筛选出带有重复结果建议的文档。

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

设置为真实时，此选项可以减慢搜索速度，因为需要访问更多建议才能找到顶部 N。

模糊查询

完成建议者还支持模糊查询 - 这意味着您可以在搜索中输入错误，并且仍然可以获取结果。

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

共享prefix缀最长前缀的建议得分更高。
模糊查询可以采取特定的模糊参数。支持以下参数：

如果您想坚持默认值，但仍使用模糊值，您可以使用fuzzy: {}fuzzy: true.

雷格克斯查询

完成建议者还支持 regex 查询，这意味着您可以将前缀表示为常规表达

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

regex 查询可以采取特定的 regex 参数。支持以下参数：

上下文建议者

完成建议人会考虑索引中的所有文档，但通常最好提供经筛选和/或由某些标准提升的建议。例如，您希望建议由某些艺术家筛选的歌曲标题，或者您希望根据其流派提升歌曲标题。
要实现建议筛选和/或提升，您可以在配置完成字段时添加上下文映射。您可以为完成字段定义多个上下文映射。每个上下文映射都有一个唯一的名称和类型。有两种类型：category和geo。上下文映射在场映射中的contexts参数下配置。
在索引和查询启用上下文的完成字段时，必须提供上下文。
下列定义类型，每个类型都有两个完成字段的上下文映射：

PUT place
{
  "mappings": {
    "properties": {
      "suggest": {
        "type": "completion",
        "contexts": [
          {                                 
            "name": "place_type",
            "type": "category"
          },
          {                                 
            "name": "location",
            "type": "geo",
            "precision": 4
          }
        ]
      }
    }
  }
}
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"
      }
    }
  }
}

添加上下文映射可增加完成字段的索引大小。完成指数完全是堆居民，您可以使用指数统计监控完成现场索引大小.

类别上下文

category上下文允许您在索引时间将一个或多个类别与建议关联。在查询时间，建议可以由其关联类别进行筛选和提升。
映射设置类似于上面place_type字段。如果path被定义，则从文档中的路径中读取类别，否则它们必须发送到建议字段中：如果该类别是从文档中的路径中读取的，则必须将它们发送到建议字段中：

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

如果映射有path，则以下索引请求将足以添加类别：

PUT place_path_category/_doc/1
{
  "suggest": ["timmy's", "starbucks", "dunkin donuts"],
  "cat": ["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 }
          ]
        }
      }
    }
  }
}

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

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

地理位置上下文

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
            }
          ]
        }
      }
    }
  }
}

如果建议条目与多个上下文匹配，则最终分数将计算为任何匹配上下文产生的最大分数。
除了接受上下文值之外，上下文查询还可以由多个上下文子句组成。支持下列参数作为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
          }
        ]
      }
    ]
  },
  ...
}