Key takeaway
The same vectors can produce a different first neighbour under raw inner product and cosine. Retain the score definition and normalization path with the result.
The highest score needs a definition
A receiving search test returns the same candidate identifiers as an earlier run, but a different record now ranks first. Before blaming an embedding model, establish which numerical comparison ordered the vectors. Inner product, cosine similarity and squared Euclidean distance express different operations. A score column labelled similarity does not identify one of them.
Faiss documents that database-vector norms affect maximum inner-product ranking. It separately describes normalizing both indexed and query vectors for cosine search, and reports squared L2 distance for its L2 metric. These details belong in the receiving contract before a reviewer interprets a change in order as better retrieval.
Two invented candidates expose the changed winner
This hypothetical fixture uses query q=[1,0] and exactly two nonzero candidate vectors: A=[0.8,0.6] and B=[2,2]. It uses ordinary exact mathematical definitions, with equal coordinate weighting and no approximate index, quantization or learned transformation. These are invented coordinates rather than model outputs for a company archive.
A has norm 1 and B has norm √8. Raw dot products are 0.8 and 2, so maximum inner product puts B first. Dividing each dot product by both vector norms gives cosine 0.8 for A and 1/√2≈0.707107 for B, putting A first. Squared L2 distances from the query are 0.4 and 5, also favouring A under a minimum-distance rule. The author recomputed these small calculations locally; no Faiss search was run.
| Synthetic candidate | Raw inner product | Cosine similarity | Squared L2 distance |
|---|---|---|---|
| A: [0.8,0.6] | 0.8 | 0.8 | 0.4 |
| B: [2,2] | 2 | ≈0.707107 | 5 |
Normalize the intended objects at the intended stage
Scikit-learn defines cosine similarity as the normalized dot product. Its equivalence to a linear kernel applies on L2-normalized data. Preserve whether vectors were normalized before indexing, at query time, or only while computing a displayed score. Those are observable stages to compare; a reviewer should not infer them from the final number.
For a cosine-through-inner-product implementation, verify the indexed candidate vectors and the query transformation together. Normalizing only the query scales all of its raw dot products by one positive factor and does not remove differences in candidate norms. The fixture therefore needs candidate-side evidence as well. A zero vector requires an explicitly documented implementation policy because division by its norm is not defined by the ordinary cosine formula.
Keep metric agreement separate from relevance
Save the vector dimension, coordinate order, embedding/model version, preprocessing, normalization convention, index metric and whether larger or smaller values are preferred. Retain original and transformed fixture vectors when their handling is permitted. If the implementation reports L2 while downstream code expects its square root, the ranking can remain unchanged while numerical thresholds change.
Correct arithmetic does not establish that A answers a user’s question better. That requires separate relevance judgments and task evidence. Approximate indexing, score ties and numerical precision can introduce further differences; this two-vector fixture deliberately makes no claim about them. Do not convert a metric-contract pass into a model-quality or deployment approval.
Return a receiving test with an expected order
The accepted result for this illustration is two explicitly named orderings: B first under raw maximum inner product, A first under cosine. A receiving team can reproduce those expectations before examining a larger permitted package. If the result differs, locate the changed normalization or metric stage before altering the model or declaring the archive defective.
A useful request names the exact fixture, expected scores and ordering, treatment of zero vectors, and the implementation version that should reproduce them. It leaves semantic usefulness unresolved until the relevance review. Record descriptions can establish that agenda without transferring embeddings or source records; a later sample still needs its own approval.