The bool query implements the Boolean model and, in this example, will
include only documents that contain either the term quick or the term fox or
both.

As soon as a document matches a query, Lucene calculates its score for that
query, combining the scores of each matching term. The formula used for
scoring is called the practical scoring function. It looks intimidating, but
don’t be put off—most of the components you already know. It introduces a
few new elements that we discuss next.

The query normalization factor (queryNorm) is an attempt to normalize a
query so that the results from one query may be compared with the results of
another.

Even though the intent of the query norm is to make results from different
queries comparable, it doesn’t work very well. The only purpose of
the relevance _score is to sort the results of the current query in the
correct order. You should not try to compare the relevance scores from
different queries.

This factor is calculated at the beginning of the query. The actual
calculation depends on the queries involved, but a typical implementation is as follows:

queryNorm = 1 / √sumOfSquaredWeights

The sumOfSquaredWeights is calculated by adding together the IDF of each
term in the query, squared.

The same query normalization factor is applied to every document, and you
have no way of changing it. For all intents and purposes, it can be ignored.

The coordination factor (coord) is used to reward documents that contain a
higher percentage of the query terms. The more query terms that appear in
the document, the greater the chances that the document is a good match for
the query.

Imagine that we have a query for quick brown fox, and that the
weight for each term is 1.5. Without the coordination factor, the score would
just be the sum of the weights of the terms in a document. For instance:

Document with fox → score: 1.5

Document with quick fox → score: 3.0

Document with quick brown fox → score: 4.5

The coordination factor multiplies the score by the number of matching terms
in the document, and divides it by the total number of terms in the query.
With the coordination factor, the scores would be as follows:

Document with fox → score: 1.5 * 1 / 3 = 0.5

Document with quick fox → score: 3.0 * 2 / 3 = 2.0

Document with quick brown fox → score: 4.5 * 3 / 3 = 4.5

The coordination factor results in the document that contains all three terms
being much more relevant than the document that contains just two of them.

Remember that the query for quick brown fox is rewritten into a bool query
like this:

The bool query uses query coordination by default for all should clauses,
but it does allow you to disable coordination. Why might you want to do this?
Well, usually the answer is, you don’t. Query coordination is usually a good
thing. When you use a bool query to wrap several high-level queries like
the match query, it also makes sense to leave coordination enabled. The more
clauses that match, the higher the degree of overlap between your search
request and the documents that are returned.

However, in some advanced use cases, it might make sense to disable
coordination. Imagine that you are looking for the synonyms jump, leap, and
hop. You don’t care how many of these synonyms are present, as they all
represent the same concept. In fact, only one of the synonyms is likely to be
present. This would be a good case for disabling the coordination factor:

When you use synonyms (see Synonyms), this is exactly what
happens internally: the rewritten query disables coordination for the
synonyms. Most use cases for disabling coordination are handled
automatically; you don’t need to worry about it.

We will talk about boosting a field—making it more important than other
fields—at query time in Query-Time Boosting. It is also possible
to apply a boost to a field at index time. Actually, this boost is applied to
every term in the field, rather than to the field itself.

To store this boost value in the index without using more space
than necessary, this field-level index-time boost is combined with the field-length norm (see Field-length norm) and stored in the index as a single byte.
This is the value returned by norm(t,d) in the preceding formula.

We strongly recommend against using field-level index-time boosts for a few
reasons:

Combining the boost with the field-length norm and storing it in a single
byte means that the field-length norm loses precision. The result is that
Elasticsearch is unable to distinguish between a field containing three words
and a field containing five words.

To change an index-time boost, you have to reindex all your documents.
A query-time boost, on the other hand, can be changed with every query.

If a field with an index-time boost has multiple values, the boost is
multiplied by itself for every value, dramatically increasing
the weight for that field.