How does the fuzziness parameter behave in an Elasticsearch match query, and what does AUTO mean?
answer
- measured in single-character edits
- short words get no allowance
- two is as far as it goes
- a swap counts as one edit
- first letters can be pinned as exact
basics
~20 sfuzziness allows each analyzed term to match index terms within an edit distance, capped at 2 edits. AUTO scales with term length: no edits for terms of 1-2 characters, one edit for 3-5, two edits above that.
solid answer
~50 s`fuzziness` is applied **per analyzed term**, after the query string has gone through the field's analyzer. Each term then matches index terms within a Levenshtein edit distance, where an edit is an insertion, deletion or substitution — and, because `fuzzy_transpositions` defaults to true, swapping two adjacent characters counts as one edit as well. The maximum distance is 2; you cannot ask for more. `fuzziness: "AUTO"` scales the allowance with term length so short words are not turned into wildcards: 0 edits for terms of one or two characters, 1 edit for three to five, and 2 edits for longer terms. You can customise the thresholds as `AUTO:4,7`. Two companion parameters control cost: `prefix_length` requires that many leading characters to match exactly, and `max_expansions` caps how many index terms each fuzzy term may expand into. Fuzziness is not supported by `match_phrase` or by `multi_match`'s `cross_fields` type.
code
json · 12 lines{
"query": {
"match": {
"title": {
"query": "elasticserch",
"fuzziness": "AUTO",
"prefix_length": 1,
"max_expansions": 50
}
}
}
}go deeper
Recall that fuzziness gives typo tolerance measured in single-character edits and that AUTO is the sensible setting because it skips very short terms.
State the AUTO thresholds, explain that edits are counted per analyzed term with transpositions costing one, and describe what prefix_length and max_expansions each bound.
Show the production stance: fuzzy clauses boosted below exact ones, prefix_length raised for cost, awareness that max_expansions trades recall for safety, and index-time ngram or phonetic fields where typo tolerance is central.
Own typo tolerance as a strategy — query-time fuzziness versus index-time normalization versus an explicit did-you-mean path — and judge it on measured precision loss for correctly spelled queries, not on anecdotes.
## What fuzziness actually does A `match` query analyzes its input into terms and looks each one up in the inverted index. With `fuzziness` set, each lookup becomes a fuzzy lookup: instead of one exact term, the engine finds every term in the field's dictionary within a given **edit distance** of the query term, and matches documents containing any of them. Edit distance here is Levenshtein distance: the number of single-character insertions, deletions or substitutions needed to turn one string into the other. With `fuzzy_transpositions` (default true) a swap of two adjacent characters also costs one edit — the Damerau variant — which matters because transposition is one of the most common human typing errors. `teh` reaching `the` in a single edit is exactly this. The maximum allowed distance is 2. That is a Lucene constraint, and it is a sensible one: the automaton used to enumerate matching terms grows quickly, and a distance of 3 on short words starts matching unrelated vocabulary. ## AUTO A fixed distance is a bad fit for real vocabulary. Two edits on a four-letter word can reach hundreds of unrelated terms; two edits on a fifteen-letter medical term barely covers a typo. `fuzziness: "AUTO"` therefore scales with the length of the term: - 1–2 characters: 0 edits (must match exactly) - 3–5 characters: 1 edit - more than 5 characters: 2 edits The thresholds are configurable as `AUTO:[low],[high]` — `AUTO:4,7` means exact below 4 characters, one edit from 4 to 6, two edits from 7 up. `AUTO` is the value you should reach for by default; a hard-coded `2` on a general search box is a common cause of bizarre matches on short terms. ## The cost controls Fuzzy lookups are more expensive than exact ones because the engine must enumerate the matching portion of the term dictionary rather than seeking to a single entry. Two parameters bound that: - **`prefix_length`** (default 0) — the number of leading characters that must match exactly. Raising it to 1 or 2 is the single most effective performance lever, because it restricts enumeration to one branch of the dictionary. It also happens to match human behaviour: people rarely mistype the first letter. - **`max_expansions`** (default 50) — the maximum number of index terms a fuzzy term may expand into. This cap applies per shard, and the terms selected are not guaranteed to be the "best" ones, so a low cap on a dense vocabulary silently costs recall and can make results differ between shards. It is a safety valve, not a relevance knob. There is also `fuzzy_rewrite`, which controls how the expanded terms are turned into a scoring query; the default is chosen so that the exact term does not get outranked by a rare misspelling that happens to have a very high inverse document frequency. ## What fuzziness does not do - It works on **analyzed terms**, not on the raw string. If your analyzer stems aggressively, the fuzzy match happens against the stems. - It is per term, so it cannot fix a missing or extra *word*; `minimum_should_match` handles that. - `match_phrase` does not support it, so "phrase with typo tolerance" is not a single query — you either combine clauses or reach for the `intervals` query, whose `fuzzy` rule can sit inside a proximity expression. - `multi_match`'s `cross_fields` type does not support it either. - It knows nothing about phonetics or keyboard layout: `nite` and `night` are two edits apart, while `phone` and `fone` are not close at all in edit distance. ## Alternatives and how they combine When typo tolerance matters a great deal, edit distance is rarely the whole answer. Index-time approaches are cheaper at query time: an ngram or edge-ngram analyzer on a dedicated multi-field, or a phonetic token filter for name search. A separate "did you mean" path using the suggest APIs can propose a corrected query rather than silently blending fuzzy hits into the result set. The usual production shape puts fuzziness in a lower-boosted `should` clause alongside an exact clause, so an exact match always wins and fuzzy hits only fill in behind. Turning fuzziness on globally at high distance is the classic way to make precision collapse: a search for `sale` starts returning `pale`, `sole`, `sales` and `sane`, and the users who notice are the ones who typed correctly. ## Interview traps Saying "fuzziness 2 means two wrong characters anywhere including extra words" mixes term-level and query-level ideas. Saying `max_expansions` improves recall gets the direction backwards — it only ever limits. And claiming fuzziness works on phrases is a straightforward factual error.
- What does prefix_length do, and why does raising it help?It is the number of leading characters that must match exactly before fuzziness applies. Because the engine enumerates the term dictionary to find candidates, pinning even one or two leading characters restricts that walk to a single branch and cuts the work sharply. It also reflects reality: people mistype the middle of a word far more often than its first letter.
- Why can max_expansions cause results to differ between shards?The cap limits how many index terms each fuzzy term expands into, and it is applied per shard against that shard's own term dictionary. Different shards hold different vocabulary, so each may select a different subset of variants once the cap bites. Treat it as a safety valve against runaway expansion, not as a tuning knob for relevance.
- How would you get typo tolerance and phrase adjacency at the same time?Not with match_phrase, which does not accept fuzziness. Either combine clauses in a bool — an exact phrase clause boosted above a fuzzy match clause — or use the intervals query, whose fuzzy rule can sit inside an ordered expression with max_gaps. For heavy typo tolerance, an index-time ngram or phonetic multi-field is usually cheaper than doing it all at query time.
saying these in an interview costs you the question
- Thinks fuzziness tolerates missing or extra whole words
- Says max_expansions increases recall rather than capping it
- Claims edit distances above 2 are allowed
- Applies a flat fuzziness of 2 to every term including short ones
- Expects match_phrase to accept fuzziness