我的映射是：
"current_name" => [
"type" => "string",
"index" => "analyzed",
"analyzer" => "russian",
"fields" => [
"raw" => [
"type" => "string",
"index" => "not_analyzed"
],
"raw_lowercase" => [
"type" => "string",
"analyzer" => "tolowercase"
]
]
],
我需要使用以下原则的示例来搜索字段（全部）：
索引字符串-"monkeys"。我需要通过"monkey"找到这份文档。
索引字符串-"你好，我美丽的世界"。我需要通过"hello big world"找到这份文档。
- 索引字符串-"适当"。我需要通过"/apprioat//strong>"找到此文档
总体：索引-"地球是我们太阳系中最美丽的行星"。我想通过"地球是美丽的"找到这份文件。
所有这些原则都应该在用户键入查询快速搜索时应用。语言为俄语。
可选：1）索引-"干得好"。我想通过同义词"good"找到文档。2） 索引-"beaut-worl"发现的"美丽世界"
我该如何实现描述？你对将这些原则与快速搜索相结合有何看法？
自动建议注意事项
- 搜索者期望autosuggest具有高度响应性。如果你的任何一个宽容的建议都有成本>100ms，考虑将其从自动建议移至搜索结果
- 自动建议有助于确认搜索者正朝着正确的方向前进。对于您描述和实施的每一个新的宽松建议功能，请注意坏建议与好建议的比例。由于可用于自动提示的屏幕空间有限，因此通常最好是精确而非全面
实现要求的策略
1） 索引字符串-"monkeys"。我需要通过"猴子"找到这份文件。
这是词尾或将术语的常见屈折减少为词根形式的示例。
例如，将"fitted"、"fitting"、"fits"、"fit"的输入映射到一个通用形式"fit"
索引词和查询词都必须进行词尾处理，这样搜索任何屈折都会产生包含任何其他屈折的结果。
在Elasticsearch发行版中，包括两个俄罗斯词干生成器russian和light_russian，在这里列出（按照实现描述的链接）。
任何一个suggester实现都可以使用自定义分析器进行参数化。默认情况下，他们使用映射中为建议的字段定义的分析器。
2） 索引字符串-"你好，我美丽的世界"。我需要有可能通过"你好，大世界"找到这份文件
一种解决方案就是布尔搜索：hello OR my OR beautiful OR world。Elasticsearch match查询的实现默认为布尔值，并将在给定短语"你好，我美丽的世界"（假设"你好"answers"世界"是由搜索字段的分析器生成的令牌）的情况下执行您所描述的操作
另一种解决方案尝试是使用短语suggester来拼凑查询中的匹配术语。（最大错误数>=0.5，因此术语my beautiful可能被视为拼写错误。）
3） 索引字符串-"适当"。我需要有可能通过"apropriat"找到这份文件。
您正在描述一个模糊搜索。这种搜索在一个术语的拼写中提供了1-2个字符的宽大处理，肯定会帮助长期拼写错误的人和糟糕的打字员。
完成暗示器（只需要一个单词前缀来提供建议）和术语暗示器（仅根据输入的整个术语进行建议）都能够指定查询和字段值之间的"编辑距离"中的模糊性或宽大性。
总体：索引-"地球是我们地球上最美丽的太阳系"。我想通过"地球是美丽的"找到这份文件。
可选：1）索引-"干得好"。我想在以下时间找到文档同义词"好"。2） 索引-"beaut"发现的"美丽世界"worl"
（总的来说）如果用"地球是美丽的"这句打字短语，暗示者可能无法暗示"地球是我们太阳系中最美丽的"。这是因为在原始文件中有许多不相关的术语将"地球"answers"美丽"分隔开来。一个短语搜索，如果slop设置为允许，比如说四个词的间隔（如示例中所示），就会满足这个解决方案。但是您必须在完成逻辑中执行一个（较慢的）搜索请求。
（可选1）此处讨论同义词，这些同义词可以包含在分析器中不过，我会对此进行彻底的拆分测试，因为搜索者可能不会期望在他们的建议中看到同义词
（可选1）我怀疑完成建议者是否会完成多个术语，如"beaut worl"，你可能不得不使用edge ngrams然而，实际上，我怀疑有人会打这个，即使是偶然
在_suggest调用中可以请求多个建议者类型。你最终可能会使用completion和phrase的组合来覆盖你的所有基础。