Cosine Similarity vs Euclidean Distance Explained

Two engineers are building a semantic search feature for the same product, using the same embedding model, on the same dataset. One configures the collection to use cosine similarity. The other uses Euclidean distance. They run the same ten queries. For nine of the ten, results are identical. For one query, the top result is completely different.

The query that diverged involved a very short document and a very long document. Both were semantically close to the query. Cosine similarity returned the short document first. Euclidean distance returned the long one. One answer was correct. The other was not.

This is not a contrived example. It is the specific failure mode that emerges when you do not understand what each metric is actually measuring. The choice between cosine similarity and Euclidean distance is not aesthetic. It is a choice about which geometric property of the vector space carries the semantic signal you care about.

This article covers the full picture: the mathematics of each metric, the geometric intuition behind them, how dot product relates to both, when each is appropriate for which embedding models, and what happens operationally inside a vector database when you choose one over the other. This article connects directly to the similarity search mechanics article, which covers how distance computation fits into the full search pipeline, and feeds forward into the exact vs approximate nearest neighbor article, which covers how the chosen metric influences ANN index construction and recall.

The Geometric Intuition Before Any Math

Before the formulas, the geometry.

Imagine two arrows drawn from the same origin point. The arrows represent your two vectors. You want to know how similar they are.

Cosine similarity asks: what is the angle between the arrows? If both arrows point in exactly the same direction, the angle is zero and the similarity is maximum (1.0). If they point in opposite directions, the angle is 180 degrees and the similarity is minimum (−1.0). The lengths of the arrows are completely irrelevant. A short arrow and a long arrow pointing in the same direction are perfectly similar by cosine.

Euclidean distance asks: how far apart are the tips of the arrows? If two arrows of different lengths both point in the same direction, their tips are far apart even though their directions are identical. Length matters because distance is measured from tip to tip, not from direction to direction.

Origin: O = (0, 0)

Arrow A: points to (1, 1)    — length 1.41
Arrow B: points to (3, 3)    — length 4.24  — same direction as A
Arrow C: points to (-1, 2)   — different direction

Cosine similarity:
  sim(A, B) = 1.000   — identical direction, length ignored
  sim(A, C) = 0.316   — different direction

Euclidean distance:
  dist(A, B) = 2.828  — different lengths means different distance
  dist(A, C) = 2.236  — may be "closer" than B by Euclidean measure

For text embeddings, the meaning of a document lives in the direction of its vector. A short summary and a long essay on the same topic have vectors that point in similar directions. Cosine similarity correctly identifies them as semantically close. Euclidean distance sees the length difference as a source of distance and may rank them lower.

This is the core geometric reason why cosine similarity is the standard choice for text and why Euclidean distance is appropriate when the magnitude of the embedding carries signal.

The Mathematics of Cosine Similarity

Cosine similarity is defined as the dot product of two vectors divided by the product of their magnitudes.

cosine_similarity(A, B) = (A · B) / (||A|| × ||B||)

Where:

• A · B is the dot product: the sum of element-wise products
• ||A|| is the L2 norm (length) of A: the square root of the sum of squared elements
• The result ranges from −1 to 1

import numpy as np

def cosine_similarity(a: np.ndarray, b: np.ndarray) -> float:
    dot_product    = np.dot(a, b)
    norm_a         = np.linalg.norm(a)
    norm_b         = np.linalg.norm(b)
    return float(dot_product / (norm_a * norm_b))

# Demonstration: direction matters, length does not
v1 = np.array([1.0, 2.0, 3.0])
v2 = np.array([2.0, 4.0, 6.0])   # exactly 2x longer than v1, same direction
v3 = np.array([1.0, 0.0, 0.0])   # completely different direction

print(f"cosine(v1, v2) = {cosine_similarity(v1, v2):.6f}")   # 1.000000
print(f"cosine(v1, v3) = {cosine_similarity(v1, v3):.6f}")   # 0.267261

# v2 is twice as long as v1 but cosine similarity is 1.0 — identical direction
# v3 is the same length as v1 but cosine similarity is low — different direction

The normalization step (/ (||A|| × ||B||)) is what makes cosine similarity direction-only. By dividing out both magnitudes, the formula reduces the vectors to unit-length versions of themselves before comparing them. This is why documents of different lengths that discuss the same topic get high cosine similarity: their normalized directions converge.

According to Zilliz's similarity metrics guide, cosine similarity measures the difference in orientation between vectors. It is the preferred metric when the model was not trained with a specific magnitude objective.

The range is −1 to 1 in theory, but in practice most embedding models for text produce non-negative values (0 to 1) because they use activation functions like ReLU in their output layers. Scores between 0.7 and 1.0 typically indicate high semantic similarity. Scores below 0.3 typically indicate unrelated content. These thresholds are model-specific and must be calibrated on your actual data.

The Mathematics of Euclidean Distance

Euclidean distance is the straight-line distance between two points in n-dimensional space. It generalizes the Pythagorean theorem to any number of dimensions.

euclidean_distance(A, B) = sqrt(sum_i((A_i - B_i)^2))

def euclidean_distance(a: np.ndarray, b: np.ndarray) -> float:
    diff = a - b
    return float(np.sqrt(np.dot(diff, diff)))

# Demonstration: sensitive to both direction and magnitude
v1 = np.array([1.0, 2.0, 3.0])
v2 = np.array([2.0, 4.0, 6.0])   # same direction as v1, 2x longer
v3 = np.array([1.1, 2.1, 3.1])   # almost same direction, very slightly longer

print(f"euclid(v1, v2) = {euclidean_distance(v1, v2):.6f}")   # 3.741657
print(f"euclid(v1, v3) = {euclidean_distance(v1, v3):.6f}")   # 0.173205

# v2 points in the same direction but is farther away in space
# v3 points in a very slightly different direction but is very close in space

# Compare cosine rankings vs Euclidean rankings:
print()
print(f"cosine(v1, v2) = {cosine_similarity(v1, v2):.6f}")    # 1.000000
print(f"cosine(v1, v3) = {cosine_similarity(v1, v3):.6f}")    # 0.999970

By Euclidean distance, v3 is much closer to v1 than v2 is. By cosine similarity, v2 is essentially identical to v1 and v3 is almost as similar. These are not slightly different answers. They reflect fundamentally different questions about what makes two vectors similar.

According to Baeldung's distance metric analysis, vectors whose Euclidean distance is small have a similar richness to them, while vectors whose cosine similarity is high look like scaled-up versions of one another. Euclidean distance captures absolute closeness in space. Cosine similarity captures directional alignment.

The Relationship Between Them: The Mathematical Bridge

When vectors are normalized to unit length (L2 norm = 1), cosine similarity and Euclidean distance produce identical rankings. This is not an approximation. It is an exact mathematical identity.

Proof:

For unit-length vectors where ||A|| = ||B|| = 1:

euclidean_distance(A, B)^2 = sum_i((A_i - B_i)^2)
                           = sum_i(A_i^2 - 2*A_i*B_i + B_i^2)
                           = ||A||^2 - 2*(A · B) + ||B||^2
                           = 1 - 2*(A · B) + 1
                           = 2 - 2*(A · B)
                           = 2 * (1 - cosine_similarity(A, B))

This means: euclidean_distance^2 = 2 * (1 - cosine_similarity)

import numpy as np

def verify_equivalence_for_normalized_vectors(n_tests: int = 1000, dim: int = 384):
    """
    Verify that normalized vectors produce identical rankings under
    cosine similarity and Euclidean distance.
    """
    mismatches = 0

    for _ in range(n_tests):
        a = np.random.randn(dim).astype(np.float32)
        b = np.random.randn(dim).astype(np.float32)
        c = np.random.randn(dim).astype(np.float32)

        # Normalize all to unit length
        a /= np.linalg.norm(a)
        b /= np.linalg.norm(b)
        c /= np.linalg.norm(c)

        # Rankings by cosine similarity (higher = closer)
        cs_ab = float(np.dot(a, b))
        cs_ac = float(np.dot(a, c))
        cosine_says_b_closer = cs_ab > cs_ac

        # Rankings by Euclidean distance (lower = closer)
        ed_ab = euclidean_distance(a, b)
        ed_ac = euclidean_distance(a, c)
        euclid_says_b_closer = ed_ab < ed_ac

        if cosine_says_b_closer != euclid_says_b_closer:
            mismatches += 1

    print(f"Ranking mismatches: {mismatches} / {n_tests}")
    print(f"Identical rankings: {(n_tests - mismatches) / n_tests * 100:.1f}%")

verify_equivalence_for_normalized_vectors()
# Ranking mismatches: 0 / 1000
# Identical rankings: 100.0%

This mathematical relationship is why most vector databases store normalized vectors and why pre-normalizing embeddings before indexing is standard practice. Once vectors are normalized, the database can use the cheaper dot product computation (skipping the norm division) while preserving cosine similarity semantics exactly.

According to Milvus's similarity metric reference, while the ranking of results remains identical for normalized embeddings, developers observe differences in score interpretation, threshold tuning, and computational efficiency when choosing between cosine similarity and Euclidean distance.

The Dot Product: The Third Metric

Every vector database supports a third metric alongside cosine and Euclidean: the dot product (inner product). Understanding how it relates to the other two removes a common source of confusion.

def dot_product(a: np.ndarray, b: np.ndarray) -> float:
    return float(np.dot(a, b))

# Relationship to cosine similarity:
# dot_product(A, B) = ||A|| × ||B|| × cosine_similarity(A, B)
# cosine_similarity(A, B) = dot_product(A, B) / (||A|| × ||B||)

# When vectors are normalized (||A|| = ||B|| = 1):
# dot_product(A, B) = cosine_similarity(A, B)   [exactly equal]

a = np.array([3.0, 4.0, 0.0])
b = np.array([1.0, 0.0, 0.0])

a_norm = a / np.linalg.norm(a)
b_norm = b / np.linalg.norm(b)

print(f"Raw dot product:            {dot_product(a, b):.6f}")        # 3.000000
print(f"Cosine similarity (raw):    {cosine_similarity(a, b):.6f}")  # 0.600000
print(f"Dot product (normalized):   {dot_product(a_norm, b_norm):.6f}")  # 0.600000
print(f"Cosine (normalized):        {cosine_similarity(a_norm, b_norm):.6f}")  # 0.600000

The raw dot product is sensitive to both direction and magnitude. A vector with large values (high magnitude) will score higher on raw dot product against almost any query vector simply because of its size, even if its direction is not the closest.

This is a problem for text embeddings where you want direction-only comparison. But it is exactly the right behavior for recommendation system embeddings trained with matrix factorization objectives.

Why Text Embeddings Use Cosine Similarity

When an embedding model like OpenAI's text-embedding-3-small or Sentence Transformers' all-MiniLM-L6-v2 encodes a sentence, the output vector's direction encodes the semantic content. The magnitude is an artifact of the model architecture, not a signal.

Consider what happens with documents of different lengths:

from sentence_transformers import SentenceTransformer
import numpy as np

model = SentenceTransformer("all-MiniLM-L6-v2")

short_doc  = "Refunds take 5 business days."
long_doc   = """
Refund processing time depends on several factors including the payment method
used at the time of purchase, the bank's internal processing schedule, and
whether the refund requires manual review by our finance team. In most cases,
refunds for credit card purchases are reflected in your account within 5 to 7
business days. For debit card purchases, the timeline may extend to 10 business
days. Digital wallet refunds typically process faster. All refunds are subject
to our standard verification procedure.
"""
query = "how long do refunds take"

vecs = model.encode([short_doc, long_doc, query], normalize_embeddings=False)
s_raw, l_raw, q_raw = vecs[0], vecs[1], vecs[2]

print(f"Short doc magnitude:  {np.linalg.norm(s_raw):.4f}")
print(f"Long doc magnitude:   {np.linalg.norm(l_raw):.4f}")
print()

# Raw dot product: longer document may win for wrong reasons
print(f"Dot product (short vs query):  {np.dot(s_raw, q_raw):.4f}")
print(f"Dot product (long vs query):   {np.dot(l_raw, q_raw):.4f}")
print()

# Cosine similarity: length-normalized comparison
cs_short = cosine_similarity(s_raw, q_raw)
cs_long  = cosine_similarity(l_raw, q_raw)
print(f"Cosine sim (short vs query):   {cs_short:.4f}")
print(f"Cosine sim (long vs query):    {cs_long:.4f}")

The long document has a higher magnitude (more tokens processed, more activation). The raw dot product may rank it higher than the short document purely because of its size, not because its content is more relevant. Cosine similarity normalizes out the length difference and compares only the semantic direction, which is much closer between both documents and the query.

According to Data Science Collective's vector metric analysis, the dot product considers the raw word count whereas cosine similarity takes proportional word distribution into account. For any vector x, a scaled-up version of x will be closer to x under dot product than x itself, which is clearly wrong behavior for semantic search.

Why Recommendation Systems Use Dot Product

The situation is inverted for recommendation systems using matrix factorization embeddings. These models learn user and item embeddings jointly, where the predicted rating for user u and item i is the dot product user_u · item_i.

import numpy as np

# Matrix factorization: user and item embeddings
# The training objective directly optimizes the dot product score
user_alice = np.array([3.2, 0.8, 2.1, 1.5])   # high activity user (larger magnitude)
user_bob   = np.array([0.4, 0.1, 0.3, 0.2])   # casual user (smaller magnitude)

item_action_movie    = np.array([2.8, 0.2, 1.9, 0.5])
item_romantic_comedy = np.array([0.3, 2.9, 0.4, 2.1])

# Dot product scores: recommend the item with highest score per user
print("Alice's predicted ratings:")
print(f"  Action movie:     {np.dot(user_alice, item_action_movie):.3f}")
print(f"  Romantic comedy:  {np.dot(user_alice, item_romantic_comedy):.3f}")

print("Bob's predicted ratings:")
print(f"  Action movie:     {np.dot(user_bob, item_action_movie):.3f}")
print(f"  Romantic comedy:  {np.dot(user_bob, item_romantic_comedy):.3f}")

In this model, Alice has a higher-magnitude vector because she is a highly active user with strong expressed preferences. If you normalized Alice's vector to unit length before computing dot products, you would eliminate the signal that encodes her enthusiasm. A casual user and a power user with the same preference directions would get identical scores. That is wrong for the recommendation objective.

According to Milvus's dot product documentation, in recommendation systems, embeddings might represent user preferences or item features. If a user's embedding has a larger magnitude due to higher activity or stronger preferences, the dot product naturally weights their similarity higher.

This is Maximum Inner Product Search (MIPS): the problem of finding the vector in a dataset that maximizes the raw dot product with the query. According to research published at OpenReview, MIPS is essential for machine learning and information retrieval, particularly in recommendation systems and RAG applications using inner product similarity.

When to Use Euclidean Distance

Euclidean distance is appropriate when the embedding space was designed so that closeness in absolute position carries the semantic signal rather than angular alignment.

Image embeddings from a CNN encoder provide the clearest example. When a ResNet encodes two images of the same object from slightly different angles, the resulting embeddings differ modestly in both direction and magnitude depending on the lighting and framing. The absolute position of the embedding in the space (captured by Euclidean distance) may be a more reliable indicator of visual similarity than pure direction.

import numpy as np

# Image embeddings: pixel intensity affects magnitude in ways that matter
image_dog_bright    = np.array([0.92, 0.87, 0.11, 0.08])   # well-lit dog photo
image_dog_dark      = np.array([0.46, 0.43, 0.06, 0.04])   # dark room dog photo
image_cat_bright    = np.array([0.15, 0.09, 0.88, 0.91])   # bright cat photo

# Euclidean distance captures both direction and magnitude shift
print("Euclidean distances:")
print(f"  dog_bright vs dog_dark:   {euclidean_distance(image_dog_bright, image_dog_dark):.4f}")
print(f"  dog_bright vs cat_bright: {euclidean_distance(image_dog_bright, image_cat_bright):.4f}")

print()
print("Cosine similarities:")
print(f"  dog_bright vs dog_dark:   {cosine_similarity(image_dog_bright, image_dog_dark):.4f}")
print(f"  dog_bright vs cat_bright: {cosine_similarity(image_dog_bright, image_cat_bright):.4f}")

For the image case, the brightness (magnitude) difference between the two dog photos is meaningful context about the visual environment. Cosine similarity would discard that context and might erroneously rank a brightly-lit cat photo as more similar to the bright dog photo than the dark dog photo.

According to Proptimise AI's metric comparison, for image and audio retrieval, Euclidean distance often outperforms cosine similarity because magnitude information captures critical visual or auditory properties.

The key question to ask: does the magnitude of the embedding vectors in your model carry semantic signal? If yes, use Euclidean or dot product. If no, use cosine.

Configuring the Metric in Production Vector Databases

The distance metric is set at collection creation time and cannot be changed without rebuilding the entire index. This decision must be made before the first vector is ingested.

from qdrant_client import QdrantClient, models

client = QdrantClient(host="localhost", port=6333)

# For text embeddings (direction only): use cosine
client.create_collection(
    collection_name="text-search",
    vectors_config=models.VectorParams(
        size=1536,
        distance=models.Distance.COSINE,
    ),
)

# For image embeddings (direction + magnitude): use Euclidean
client.create_collection(
    collection_name="image-search",
    vectors_config=models.VectorParams(
        size=2048,
        distance=models.Distance.EUCLID,
    ),
)

# For recommendation embeddings (raw dot product): use dot product
client.create_collection(
    collection_name="recommendations",
    vectors_config=models.VectorParams(
        size=128,
        distance=models.Distance.DOT,
    ),
)

The same pattern applies in FAISS:

import faiss
import numpy as np

d = 1536

# Cosine similarity → use IndexFlatIP after normalizing vectors
cosine_index = faiss.IndexFlatIP(d)
# Always normalize_L2 vectors before adding to IndexFlatIP
vectors = np.random.randn(10_000, d).astype(np.float32)
faiss.normalize_L2(vectors)
cosine_index.add(vectors)

# Euclidean distance → use IndexFlatL2 with raw vectors
euclid_index = faiss.IndexFlatL2(d)
raw_vectors = np.random.randn(10_000, d).astype(np.float32)
euclid_index.add(raw_vectors)

# Verify: search returns different results for unnormalized vectors
query = np.random.randn(1, d).astype(np.float32)
query_norm = query / np.linalg.norm(query)

_, cosine_ids = cosine_index.search(query_norm, k=5)
_, euclid_ids = euclid_index.search(query, k=5)

print(f"Cosine top-5:   {cosine_ids[0].tolist()}")
print(f"Euclidean top-5: {euclid_ids[0].tolist()}")
# Results differ because vectors were not normalized before adding to Euclidean index

In Pinecone, Weaviate, and Milvus, the metric is specified as a parameter when creating the index or collection. Consult the model card of your embedding model to find which metric it was trained with. According to Zilliz's metric guide, the rule is to use the same similarity metric that was used to train your embedding model.

The Computational Cost Difference

For normalized vectors, dot product is faster to compute than full cosine similarity because it skips two norm computations. For unnormalized vectors, the difference is minimal.

import numpy as np
import time

d = 1536
n = 10_000
corpus = np.random.randn(n, d).astype(np.float32)
query  = np.random.randn(d).astype(np.float32)

# Normalize
corpus_norm = corpus / np.linalg.norm(corpus, axis=1, keepdims=True)
query_norm  = query / np.linalg.norm(query)

# Dot product (on normalized vectors = cosine similarity)
t0 = time.perf_counter()
for _ in range(100):
    scores_dot = corpus_norm @ query_norm
t1 = time.perf_counter()
dot_ms = (t1 - t0) * 1000 / 100

# Full cosine (computing norms at query time is redundant when pre-normalized)
t0 = time.perf_counter()
for _ in range(100):
    norms  = np.linalg.norm(corpus, axis=1)
    scores_cos = (corpus @ query) / (norms * np.linalg.norm(query))
t1 = time.perf_counter()
cos_ms = (t1 - t0) * 1000 / 100

print(f"Dot product (normalized):  {dot_ms:.3f}ms per 10K comparisons")
print(f"Full cosine (unnormalized): {cos_ms:.3f}ms per 10K comparisons")

# Results vary by hardware, but dot product is typically 2 to 5x faster
# because it skips the per-vector norm computation

This performance gap is why virtually all production embedding pipelines normalize vectors before storage. The normalization is done once at ingestion time. Every subsequent query uses the cheaper dot product computation while preserving cosine similarity semantics. At one million queries per day, the cumulative saving is significant.

A Decision Framework

Your embedding model                     → Recommended metric
─────────────────────────────────────────────────────────────
OpenAI text-embedding-3-small            → Cosine (L2 normalize first)
OpenAI text-embedding-3-large            → Cosine (L2 normalize first)
Sentence Transformers (any SBERT model)  → Cosine (pre-normalized by default)
Cohere embed-english-v3                  → Cosine
Google text-embedding-004                → Dot product (already normalized)
ResNet / ViT image embeddings            → Euclidean (magnitude matters)
CLIP (multimodal)                        → Cosine (trained on cosine objective)
Matrix factorization recommendations     → Dot product (MIPS, raw magnitude signal)
Custom-trained models                    → Check model card or training objective

According to Proptimise AI's metric guide, for most text embedding use cases, cosine similarity is the right choice. Text embeddings encode semantic meaning into vector direction. The magnitude of these vectors often reflects document length or token frequency rather than semantic importance.

When in doubt: check the model documentation. Every major embedding model specifies which metric it was trained with. Using a different metric degrades recall in ways that can be subtle and difficult to diagnose.

What Happens When You Choose Wrong

Using the wrong metric for your embedding model produces systematic errors in ranking. The errors are not random. They have predictable patterns based on which property of the vectors the wrong metric weights incorrectly.

Cosine model with Euclidean metric: Documents with extreme lengths (very short or very long) will be consistently misranked relative to documents of typical length, because the length difference shows up as distance even when the semantic direction is correct.

MIPS model with cosine metric: High-activity users and popular items will lose their distinguishing signal. A power user and a casual user with identical taste profiles will receive identical recommendations even if the power user's stronger preferences should elevate different items.

Euclidean model with cosine metric: Visual features that vary in brightness, scale, or amplitude will be treated as semantically equivalent when they should be distinct.

The diagnostic is: run 100 queries where you know the ground truth relevance, then compare the ranking quality under each metric. If the wrong metric gives consistently worse NDCG or Recall@K on your labeled set, you have confirmed the mismatch and know the direction of the fix.

Connecting the Full Series

This article is C2.2 in the How Vector Databases Work Internally series. The distance metric computed at each step of the HNSW traversal is what this article covers. The similarity search article covers how that distance computation fits into the eight-step search pipeline from query arrival to ranked results. The cross-link between the two articles (C2.1 to C2.2) represents the relationship between the search mechanism and the metric it uses.

The ANN algorithms that use these metrics — HNSW and IVF — are covered in the exact vs approximate nearest neighbor article, the HNSW algorithm article, and the IVF index article. The HNSW graph is built using the metric you specify at collection creation time. Changing the metric after the index is built would require rebuilding the entire graph.

Summary

Cosine similarity measures the angle between two vectors and ignores magnitude. It is the right metric for text embeddings where semantic meaning lives in direction, not length. Euclidean distance measures the straight-line gap between two points and is sensitive to both direction and magnitude. It is appropriate when the embedding model encodes meaningful signal in vector length, as with some image and audio models.

The dot product is the numerator of the cosine formula. For normalized (unit-length) vectors, dot product equals cosine similarity exactly. For unnormalized vectors, dot product is sensitive to magnitude like Euclidean distance but in a different way. MIPS (Maximum Inner Product Search) uses raw dot product for recommendation systems where embedding magnitude encodes preference strength.

For normalized vectors, cosine similarity and Euclidean distance produce identical rankings because of the mathematical relationship: squared Euclidean distance equals 2 times (1 minus cosine similarity). This is why normalizing embeddings before storage is standard practice: it converts cosine similarity to a computationally cheaper dot product with no accuracy loss.

The correct metric for your system is the one your embedding model was trained with. That information is always in the model card or API documentation.

Sources and Further Reading

1. Zilliz. Similarity Metrics for Vector Search. zilliz.com/blog/similarity-metrics-for-vector-search
2. Proptimise AI. Cosine Similarity vs. Euclidean Distance: Choosing the Right Metric for Vector Search. proptimiseai.com/blog/cosine-similarity-vs-euclidean-distance-vector-search
3. Baeldung on CS. Euclidean Distance vs Cosine Similarity. baeldung.com/cs/euclidean-distance-vs-cosine-similarity
4. Milvus AI Reference. Cosine vs Euclidean on Normalized Embeddings. milvus.io/ai-quick-reference/normalized-embeddings-cosine-vs-euclidean
5. Milvus AI Reference. Why Use Dot Product for Unnormalized Embeddings? milvus.io/ai-quick-reference/dot-product-unnormalized
6. Data Science Collective. Cosine Distance vs Dot Product vs Euclidean in Vector Similarity Search. medium.com/data-science-collective/cosine-distance-vs-dot-product-vs-euclidean-in-vector-similarity-search
7. Sean Amarasinghe. Cosine Similarity vs Euclidean Distance. medium.com/@szaranger/cosine-similarity-vs-euclidean-distance
8. MyScale. Cosine Similarity vs Euclidean Distance. medium.com/@myscale/unveiling-the-power-cosine-similarity-vs-euclidean-distance
9. Kopp Online Marketing. What Is MIPS (Maximum Inner Product Search)? kopp-online-marketing.com/what-is-mips-maximum-inner-product-search
10. Harshit Sharma. Maximum Inner Product Search (MIPS) and Its Use in ML. medium.com/@harshit158/maximum-inner-product-mips
11. OpenReview. Identify Dominators: Improving Large-Scale MIPS. openreview.net/forum?id=wtNxByjLW3
12. OneUptime. How to Implement Dot Product Similarity for Vector Search. oneuptime.com/blog/post/2026-01-30-dot-product/view
13. Intuitive Shorts. MIPS vs MCSS: Maximum Inner Product vs Cosine Similarity Search. intuitiveshorts.substack.com/p/short-12-mips-vs-mcss-maximum-inner
14. Weaviate. Distance Metrics Documentation. weaviate.io/developers/weaviate/config-refs/distances
15. Pinecone. Understanding Similarity Metrics in Vector Search. pinecone.io/learn/vector-similarity