Exam-style
After swapping to a new embedding model, retrieval quality collapses. Ingestion completes without error, every query returns the requested number of results, and spot checks show the embeddings themselves look reasonable. What is the first thing to check?
Reveal the answer
E. Confirm the index distance metric suits the new model, since the metric is fixed when the index is created
The distance metric is fixed at index creation. S3 Vectors takes distanceMetric of euclidean or cosine on CreateIndex, and an OpenSearch knn_vector field carries a space_type such as l2. Nothing validates that choice against the model that produced the vectors. Once the new embeddings are not unit length, the wrong metric still returns results, ordered by the wrong function. Titan Text Embeddings V2 turns normalisation off on request, so that is not a hypothetical. Dimension is the loud failure by comparison. It is a required index property, so vectors of the wrong width are rejected on write, and a clean ingestion run has ruled it out. Raising top-k, reranking, and hybrid search each recover a little relevance while the ranking function stays wrong underneath.
Q. Retrieval quality collapses after an embedding model swap, and nothing errors. What config is worth checking first?
A. The index distance metric. It is chosen when the index is created: euclidean or cosine on an S3 vector index, space_type on an OpenSearch knn_vector field. Nothing validates it against the model that produced the vectors.
Why? Once the new vectors are not unit length, the wrong metric still returns the requested number of results, ordered by the wrong function. The damage reads as a tuning problem. Dimension is the loud one: it is a required index property, so vectors of the wrong width are rejected on write.