How do the multi_match types best_fields, most_fields and cross_fields differ in Elasticsearch?

## The problem multi_match solves Real documents scatter searchable text across fields: `title`, `description`, `brand`, `tags`, or `first_name` and `last_name`. `multi_match` takes one query string and one list of fields (boostable as `title^3`, and wildcards like `*_name` are allowed) and runs it against all of them. The interesting part is `type`, which decides *how evidence from several fields becomes one score* — and, less obviously, how `operator` and `minimum_should_match` are interpreted. The fundamental split is **field-centric** versus **term-centric**. ## best_fields — field-centric, winner takes most `best_fields` is the default. It runs a `match` per field and wraps them in a disjunction that takes the **maximum** score, optionally adding `tie_breaker` times the sum of the other fields' scores (`tie_breaker` defaults to 0, meaning the losers contribute nothing). The intuition is: the best single field is the best signal. A document whose `title` reads "Java Concurrency in Practice" should beat one that mentions "Java" in the title and "concurrency" three paragraphs into the body. Use it when the query is likely to be satisfied by one field on its own. Its famous failure is the *albino elephant* problem. With `operator: "and"`, the requirement lands **inside each field**: a document must have every term in *the same* field. So searching `"albino elephant"` will not match a document with `albino` in one field and `elephant` in another, even though a human would call that a match. ## most_fields — field-centric, evidence adds up `most_fields` runs the same per-field `match` queries but **sums** the scores. That makes sense when the fields are not independent content but different *analyses of the same content*: a multi-field with a plain analyzer, a language analyzer, and a shingle or ngram variant. A document matching the exact form and the stemmed form and the shingled form is more confidently relevant, so scores accumulate. Using `most_fields` across genuinely different content fields tends to reward documents that repeat the same words everywhere — a document with the term in `title`, `description` and `tags` outscores one that only has a strong title — which is often not what a product owner means by relevant. ## cross_fields — term-centric `cross_fields` inverts the loop. Instead of "for each field, match all terms", it does "for each term, look across the fields". Conceptually the listed fields are treated as one large concatenated field, and term statistics are blended across them so that a term is not scored strangely just because it is rare in one short field and common in a long one. The practical consequences: - `operator: "and"` and `minimum_should_match` now apply **per term across the whole group**, not inside each field. That solves the albino elephant problem: every term must appear *somewhere* in the group. - Fields are grouped by analyzer. Because the group is treated as one field, fields analyzed differently cannot be blended together, so they form separate groups combined like `best_fields`. If you intend cross-field matching, give the fields the same analyzer. - `fuzziness` is not supported by `cross_fields`. The canonical use case is structured data split across columns: person names, address lines, a product whose brand and model live apart. ## The other types - **phrase** — runs `match_phrase` on each field and combines them `best_fields`-style. - **phrase_prefix** — the same with `match_phrase_prefix`, for search-as-you-type where order matters. - **bool_prefix** — runs `match_bool_prefix` on each field: every term but the last is an ordinary term clause and the last becomes a prefix, so order is not required. ## Choosing in an interview A good answer names the decision rule rather than reciting the list. Ask: *can one field plausibly contain the whole query?* If yes, `best_fields`. *Are the fields different analyses of the same text?* Then `most_fields`. *Is the query naturally spread across structured fields?* Then `cross_fields` with a shared analyzer. And say out loud that these are hypotheses to be measured against real query logs, not settings to be guessed at once and forgotten. A very common production shape is not one `multi_match` at all but a `bool` combining a `cross_fields` or `best_fields` clause for recall with boosted phrase clauses on the important fields for precision — one query decides who is in the result set, the other decides who is at the top. ## Traps Expecting `operator: "and"` to mean the same thing under `best_fields` and `cross_fields` is the single most common misunderstanding, and it produces a bug that looks like missing documents rather than a scoring quirk. Second is mixing analyzers under `cross_fields` and wondering why cross-field matching stopped working.