What happens when you compute cosine similarity against the zero vector?

**Cosine similarity is undefined when one of the vectors is the zero vector.** The formula is: $$\cos(u, v) = \frac{u \cdot v}{\|u\| \, \|v\|}$$ If v is the zero vector, ||v|| = 0 and the denominator is zero. The numerator is also zero. You get 0/0, which is mathematically undefined. What happens in code depends on the library. NumPy returns `NaN` and emits a warning. scikit-learn’s `cosine_similarity` returns 0 silently. Some vector DBs throw. A handful of GPU kernels return garbage memory. Zero vectors are not exotic. They show up when an embedding API returns a default vector after a failed call, when input text is empty, or when a tokenizer produces only padding tokens. Always validate `||v|| > 0` before writing a vector to your index. Treating the zero vector as 'fine, it will sort last' is the bug.

**Cosine with the zero vector is 0/0, mathematically undefined.** The implementation behavior is unsettled. - NumPy returns NaN with a `RuntimeWarning: invalid value encountered in true_divide`. - scikit-learn returns 0 silently. - FAISS returns whatever the underlying SIMD kernel leaves in the register. - Pinecone and Weaviate reject zero vectors at write time but only if the client enforces it. This variance is the bug. A pipeline that happens to use scikit-learn cosine returns a plausible-looking 0 for the zero vector, which sorts last and survives QA. Migrate to NumPy and the same query returns NaN, which downstream sorting libraries handle unpredictably. Zero vectors arise from three sources in practice: empty input strings, all-padding token sequences after truncation, and failed embedding API calls that returned a default-initialized buffer. The fix is a validation step in the indexing client: assert `||v|| > epsilon` before upsert. The interview lesson: undefined math at the boundary leaks through libraries differently. Defend the boundary explicitly.