Question presented to candidate: "Once we have embeddings, we have to find the closest ones to a query. Explain cosine similarity, dot product and Euclidean distance, when they give different answers, and how search stays fast when there are millions of vectors."
What a strong answer should cover:
- The three measures: dot product (direction and length), cosine similarity (angle only, the dot product divided by both lengths), Euclidean distance (straight-line distance); higher is closer for the first two, lower for the third
- On raw vectors they can rank the same documents differently, because length counts in dot product and Euclidean but not in cosine; on unit-length vectors all three give the same ranking (squared Euclidean = 2 - 2 x cosine), so you normalise and use the cheap dot product
- The rule for choosing: use the metric the embedding model was trained for and the same one at index and query time; dot product without normalisation only where length carries meaning (for example popularity in recommendation)
- Exact (flat) k-nearest-neighbour search costs one distance per stored vector per query, which is fine for small sets and too slow at scale
- Approximate nearest neighbour (ANN) indexes such as IVF (probe a few clusters) and HNSW (walk a layered graph) touch a small fraction of vectors and trade a little recall for a lot of speed, tuned with knobs like
nprobeandef_searchand measured as recall@k against exact search
Code / implementation expected: Optional — computing the three metrics by hand, or a short exact top-k loop, is a strong signal; implementing an ANN index is not expected.