我们期望在类似时间和价格的结构化数据上执行一个查询来返回精确匹配的文档。 然而，好的全文检索不应该是完全相同的限定逻辑。 相反，我们可以扩大范围以包括 可能 的匹配，而根据相关性得分将更好的匹配推到结果集的顶部。
事实上，只能完全匹配的全文搜索可能会困扰你的用户。 难道不希望在搜索 quick brown fox 时匹配一个包含 fast brown foxes 的文档， 搜索 Johnny Walker 同时匹配 Johnnie Walker ，搜索 Arnold Shcwarzenneger 同时匹配 Arnold Schwarzenegger ?
如果存在完全符合用户查询的文档，他们应该出现在结果集的顶部，而较弱的匹配可以被包含在列表的后面。 如果没有精确匹配的文档，至少我们可以显示有可能匹配用户要求的文档，它们甚至可能是用户最初想要的！
我们已经在 归一化词元 看过自由变音匹配， 将单词还原为词根 中的词干， 同义词 中的同义词， 但所有这些方法假定单词拼写正确，或者每个单词拼写只有唯一的方法。
Fuzzy matching 允许查询时匹配错误拼写的单词，而语音语汇单元过滤器可以在索引时用来进行 近似读音 匹配。
模糊性
模糊匹配 对待 “模糊” 相似的两个词似乎是同一个词。首先，我们需要对我们所说的 模糊性 进行定义。
在1965年，Vladimir Levenshtein 开发出了 Levenshtein distance， 用来度量从一个单词转换到另一个单词需要多少次单字符编辑。他提出了三种类型的单字符编辑：
- 一个字符 替换 另一个字符： _f_ox → _b_ox
- 插入 一个新的字符：sic → sic_k_
- 删除 一个字符：b_l_ack → back
Frederick Damerau 后来在这些操作基础上做了一个扩展：
- 相邻两个字符的 换位 ： _st_ar → _ts_ar
举个例子，将单词 bieber 转换成 beaver 需要下面几个步骤：
- 把 b 替换成 v ：bie_b_er → bie_v_er
- 把 i 替换成 a ：b_i_ever → b_a_ ever
- 把 e 和 a 进行换位：b_ae_ver → b_ea_ver
这三个步骤表示 Damerau-Levenshtein edit distance 编辑距离为 3 。
显然，从 beaver 转换成 bieber 是一个很长的过程—他们相距甚远而不能视为一个简单的拼写错误。 Damerau 发现 80% 的拼写错误编辑距离为 1 。换句话说， 80% 的拼写错误可以对原始字符串用 单次编辑 进行修正。
Elasticsearch 指定了 fuzziness 参数支持对最大编辑距离的配置，默认为 ２ 。
当然，单次编辑对字符串的影响取决于字符串的长度。对单词 hat 两次编辑能够产生 mad ， 所以对一个只有 3 个字符长度的字符串允许两次编辑显然太多了。 fuzziness 参数可以被设置为 AUTO ，这将导致以下的最大编辑距离：
- 字符串只有 1 到 2 个字符时是 0
- 字符串有 3 、 4 或者 5 个字符时是 1
- 字符串大于 5 个字符时是 2
当然，你可能会发现编辑距离 2 仍然是太多了，返回的结果似乎并不相关。 把最大 fuzziness 设置为 1 ，你可以得到更好的结果和更好的性能。
模糊查询
fuzzy 查询是 term 查询的模糊等价。 也许你很少直接使用它，但是理解它是如何工作的，可以帮助你在更高级别的 match 查询中使用模糊性。
为了解它是如何运作的，我们首先索引一些文档：
POST /my_index/_bulk
{ "index": { "_id": 1 }}
{ "text": "Surprise me!"}
{ "index": { "_id": 2 }}
{ "text": "That was surprising."}
{ "index": { "_id": 3 }}
{ "text": "I wasn't surprised."}
现在我们可以为词 surprize 运行一个 fuzzy 查询：
GET /my_index/_search
{
"query": {
"fuzzy": {
"text": "surprize"
}
}
}
fuzzy 查询是一个词项级别的查询，所以它不做任何分析。它通过某个词项以及指定的 fuzziness 查找到词典中所有的词项。 fuzziness 默认设置为 AUTO 。
在我们的例子中， surprise 比较 surprise 和 surprised 都在编辑距离 2 以内， 所以文档 1 和 3 匹配。通过以下查询，我们可以减少匹配度到仅匹配 surprise ：
GET /my_index/_search
{
"query": {
"fuzzy": {
"text": {
"value": "surprize",
"fuzziness": 1
}
}
}
}
提高性能
fuzzy 查询的工作原理是给定原始词项及构造一个 编辑自动机— 像表示所有原始字符串指定编辑距离的字符串的一个大图表。
然后模糊查询使用这个自动机依次高效遍历词典中的所有词项以确定是否匹配。 一旦收集了词典中存在的所有匹配项，就可以计算匹配文档列表。
当然，根据存储在索引中的数据类型，一个编辑距离 2 的模糊查询能够匹配一个非常大数量的词项同时执行效率会非常糟糕。 下面两个参数可以用来限制对性能的影响：
prefix_length
不能被 “模糊化” 的初始字符数。 大部分的拼写错误发生在词的结尾，而不是词的开始。 例如通过将 prefix_length 设置为 3 ，你可能够显著降低匹配的词项数量。
max_expansions
如果一个模糊查询扩展了三个或四个模糊选项， 这些新的模糊选项也许是有意义的。如 果它产生 1000 个模糊选项，那么就基本没有意义了。 设置 max_expansions 用来限制将产生的模糊选项的总数量。模糊查询将收集匹配词项直到达到 max_expansions 的限制。
模糊匹配查询
match 查询支持开箱即用的模糊匹配：
GET /my_index/_search
{
"query": {
"match": {
"text": {
"query": "SURPRIZE ME!",
"fuzziness": "AUTO",
"operator": "and"
}
}
}
}
查询字符串首先进行分析，会产生词项 [surprize, me] ，并且每个词项根据指定的 fuzziness 进行模糊化。
同样， multi_match 查询也支持 fuzziness ，但只有当执行查询时类型是 best_fields 或者 most_fields ：
GET /my_index/_search
{
"query": {
"multi_match": {
"fields": [ "text", "title" ],
"query": "SURPRIZE ME!",
"fuzziness": "AUTO"
}
},
"explain": true
}
match 和 multi_match 查询都支持 prefix_length 和 max_expansions 参数。
模糊性评分
用户喜欢模糊查询。他们认为这种查询会魔法般的找到正确拼写组合。 很遗憾，实际效果平平。
假设我们有1000个文档包含 Schwarzenegger ，只是一个文档的出现拼写错误 Schwarzeneger 。 根据 term frequency/inverse document frequency 理论，这个拼写错误文档比拼写正确的相关度更高，因为错误拼写出现在更少的文档中！
换句话说，如果我们对待模糊匹配类似其他匹配方法，我们将偏爱错误的拼写超过了正确的拼写，这会让用户抓狂。
模糊匹配不应用于参与评分—只能在有拼写错误时扩大匹配项的范围。
默认情况下， match 查询给定所有的模糊匹配的恒定评分为1。这可以满足在结果列表的末尾添加潜在的匹配记录，并且没有干扰非模糊查询的相关性评分。
在模糊查询最初出现时很少能单独使用。他们更好的作为一个 bigger 场景的部分功能特性，如 search-as-you-type 完成 建议或 did-you-mean 短语 建议。
