In Elasticsearch's function_score query, what is the difference between score_mode and boost_mode?

## The two-stage pipeline A `function_score` query wraps an ordinary query and modifies its score with one or more functions. Understanding it is entirely a matter of seeing that there are two separate combination steps, controlled by two similarly named parameters that candidates constantly swap. Step one: every entry in the `functions` array produces a number. `score_mode` reduces that array to a single function score. Step two: `boost_mode` combines that single function score with the score produced by the inner `query`. Written out: `final = boost_mode( query_score, score_mode(f1, f2, ..., fn) )`. If you supply a single function via the shorthand form (no `functions` array), `score_mode` is irrelevant and only `boost_mode` matters. ## score_mode options `multiply` is the default and multiplies the individual function results together. `sum` adds them, `avg` averages them, `max` and `min` take the extreme, and `first` takes the result of the first function whose `filter` matches the document — the classic way to express a priority list of rules where only the highest-priority one should apply. With `multiply`, remember that any function returning a value near zero collapses the whole product to near zero. Decay functions return values in the range 0 to 1, so two multiplied decay functions demote hard. `sum` or `avg` is usually the calmer choice when several independent signals should each contribute. ## Per-function filter and weight Each entry in `functions` may include a `filter`. Functions whose filter does not match the document are skipped, so a filter-plus-`weight` pair is the idiomatic way to say "documents in the electronics category get a 2x nudge". A function with no filter applies to every matching document. `weight` is itself a function — it simply returns the given number — and it can also be attached alongside another function, in which case it multiplies that function's result. Weights are not normalised, with one exception worth knowing: when `score_mode` is `avg`, the weights are used as the weights of a weighted average rather than as plain multipliers. ## boost_mode options `multiply` (default) multiplies the query score by the function score. This preserves relevance ordering within similar signal values and is the right default for signals expressed as ratios. `sum` adds the function score to the query score. This is the choice when you want a bounded additive nudge — a signal that can move a document up by a fixed amount but can never swamp a strong text match, provided the function output is bounded. `replace` discards the query score and uses the function score alone. Documents still have to match the inner query, but relevance no longer participates in ranking. It is occasionally right (ranking a filtered set purely by distance, for example) but is usually a sign that the author wanted a sort, not a score. `avg`, `max` and `min` exist and are rarely the right answer; `max` in particular means the function can only ever raise the score, never lower it. ## max_boost and min_score `max_boost` caps the combined function score before `boost_mode` applies it. It is the safety valve against an unbounded signal — a popularity function on raw counts, for example — turning "one document dominates everything" into "one document gets at most the capped multiplier". `min_score` is applied after the final score is computed and removes documents scoring below the threshold. This is a filter based on the final number, which makes it fragile: scores are not comparable across queries, so a threshold tuned on one query can silently empty the results of another. ## Worked example Suppose the inner query scores 4.0, and there are two functions, `weight: 2` and `weight: 3`. - `score_mode: multiply`, `boost_mode: multiply` gives 4.0 × (2 × 3) = 24. - `score_mode: sum`, `boost_mode: multiply` gives 4.0 × (2 + 3) = 20. - `score_mode: sum`, `boost_mode: replace` gives 5 — the text score is gone. - `score_mode: sum`, `boost_mode: sum` gives 9. Being able to walk through that arithmetic on a whiteboard is exactly what the interviewer is checking. ## Cost `function_score` is a scoring wrapper, not a filter, so its functions run for every document matching the inner query. There is no way to skip documents that cannot make the top hits, because the function could in principle promote any of them. On a query matching millions of documents, that per-document work is the dominant cost, which is why bounded, indexed alternatives exist for the common popularity and recency cases.