In Elasticsearch, how do the ^ field-boost suffix and the boost parameter affect _score?

## What a boost actually is A boost is a plain multiplier applied to the relevance score that one query clause produces. Elasticsearch scores a document by running the scoring queries in the request — each produces a number, BM25 for text queries — and combining them. A boost changes one of those numbers before the combination happens. It does not filter, it does not guarantee an ordering, and it does not make a field "more important" in any absolute sense. It only reweights one contribution inside an arithmetic sum. ## Where you write one There are two syntaxes for the same idea. The caret suffix is a shorthand available in the field lists of `multi_match`, `query_string` and `simple_query_string`: ```json { "multi_match": { "query": "kafka", "fields": ["title^3", "body"] } } ``` The explicit parameter is accepted by nearly every query type and is the general form: ```json { "bool": { "should": [ { "match": { "title": { "query": "kafka", "boost": 3 } } }, { "match": { "body": "kafka" } } ]}} ``` A field with no suffix has boost 1. Both forms do the same thing; the caret is just terser. ## Boosts are relative, not absolute The single most common misunderstanding is treating a boost as a percentage or as a rank guarantee. Neither holds. If a `bool` sums a title clause scoring 2.0 and a body clause scoring 5.0, boosting title by 3 gives 6.0 + 5.0 = 11.0. The title contribution now leads, but a document whose body match is exceptionally strong can still win. Boosting is a nudge on a continuous scale, never a hard tier. Because the combination is linear, multiplying every boost by the same constant changes nothing about the ordering. `title^3, body^1` and `title^6, body^2` produce the same ranking with all scores doubled. Only the *ratio* between boosts matters. This is why absolute score values are not comparable across queries and why chasing a particular `_score` number is a wasted afternoon. Values below 1 are legal and useful: `body^0.5` halves the body clause rather than tripling everything else. Boosts are positive multipliers. When you want to demote a match — documents mentioning "trial version" should rank lower but still appear — the tool is the `boosting` query, which takes a `positive` query, a `negative` query and a `negative_boost` factor between 0 and 1 that multiplies the score of documents matching the negative side. ## Filter context silently ignores boosts Clauses in a `bool`'s `filter` or `must_not` arrays, and anything wrapped in `constant_score`, run in filter context: Elasticsearch answers only "does this match?", skips scoring entirely, and can reuse the cached result. A `boost` written on such a clause is accepted and has no effect on ranking. Candidates who move a clause into `filter` for speed and keep its boost are usually surprised when relevance stops responding. If a signal must influence ranking it has to be in query context (`must` or `should`). ## Why per-field boosting is coarse A per-field boost multiplies the whole clause, so it inherits everything BM25 already did — term frequency, inverse document frequency and the field-length norm. Two fields with wildly different lengths and vocabularies do not produce comparable raw scores, so a boost of 3 on a short `title` and a long `body` is not "three times as important", it is "three times whatever title happened to score". This is why tuning boosts is empirical: change the ratio, measure against judged queries, repeat. It also explains why `multi_match` types matter — `best_fields` takes the maximum clause score via `dis_max`, `most_fields` sums them — and the same boost behaves differently under each. ## Index-time boosting is not the answer Older Elasticsearch let you set a `boost` in the mapping so a field's boost was folded into the stored norm at index time. That is deprecated in current versions and was always a poor trade: the boost was stored with very low precision inside a single-byte norm, it could not be changed without reindexing, and it silently interacted with length normalisation. Query-time boosting costs nothing extra and can be changed per request, which is what you want while you are still tuning. ## Practical guidance Start with 1 everywhere, raise one field at a time, and keep the ratios small — 2 to 5 is a normal range, and boosts of 100 usually mean someone is trying to express a hard ordering that belongs in a sort or a filter. Verify with a judged query set rather than by eyeballing one search, and remember that a boost only matters for documents that actually match the boosted clause: boosting `title` does nothing for a document whose title does not contain the query term.