Clarify different between dot_product and cosine similarities

[jtibshirani]

Approximate kNN search supports two similarities that are really similar:

• cosine accepts any vector and computes the cosine similarity between them
• dot_product requires vectors to be of magnitude 1, and computes the cosine similarity between them

Our recommendation is to use dot_product if possible, since it avoids computing the vector magnitudes (they're always 1), making search significantly faster. It's a bit confusing to have two similarities for the same use case -- users often just choose cosine and get suboptimal performance.

Maybe we could update cosine to compute and store the vector magnitudes while indexing. We could also compute the query magnitude once per search. Then, we could just reuse the magnitudes during the similarity computation. We do this for non-indexed dense_vector fields and found it really improved performance (#46294). This would require changes to how Lucene indexes vectors, described here: apache/lucene#11228.

We could then either remove dot_product, or expand its purpose. (For example, maybe dot_product could accept vectors of any length, which is helpful in recommendations use cases? This would require research.)

[elasticsearchmachine]

Pinging @elastic/es-search (Team:Search)

[jtibshirani]

This would also help with the byte-sized vectors work (#89784). Currently if you use dot_product with element_type: byte, then we just assume all the vectors have the same magnitude, but don't enforce it. The score is also a bit strange, to account for the fact the vectors can have any length (it's 0.5 + (dot_product / (32768 * dims))). Everything works out more nicely if you use the cosine similarity.

[elasticsearchmachine]

Pinging @elastic/es-docs (Team:Docs)

[benwtrent]

Docs & default behavior have been significantly improved since this issue was opened. Closing