How should you choose a distance metric when creating a Qdrant collection?
Match the metric to the embedding model
I start with the embedding model's documentation or training objective. The metric is part of the representation's retrieval semantics, so I would not choose it solely because it is popular.
For normalized semantic embeddings, cosine is a common choice. If the model is explicitly optimized for dot product or magnitude carries useful information, dot product may be more appropriate. Euclidean or Manhattan can make sense for representations whose geometry was designed around those distances.
The trade-off is between following the model's intended geometry and optimizing the application's observed retrieval quality. If documentation is unclear, I would build an evaluation set with representative queries and compare metrics against human or labeled relevance judgments.
One important operational constraint is that the vector configuration is part of the collection schema. Changing the metric is not equivalent to changing a query parameter; if the representation semantics change, plan a migration or a separate vector space.
- 1
Start from the model's documented training and retrieval objective
- 2
Validate the choice with representative relevance data
- 3
Do not assume cosine is universally correct
- 4
Treat metric changes as schema or migration decisions rather than casual query tuning
Scenario Questions
0-2 years experience
- 1Your team is using a text embedding model whose documentation recommends cosine similarity. How would you translate that recommendation into the Qdrant collection configuration?
- 2A developer chooses Euclidean distance because it is familiar. What questions would you ask before accepting that decision?
2-5 years experience
- 1Your offline evaluation shows cosine has higher recall but dot product has better precision. How would you investigate the difference before choosing a production metric?
- 2An embedding provider changes its model and says the new model uses a different similarity objective. What parts of your Qdrant deployment would you review?
5-8 years experience
- 1You need to migrate a high-volume collection from one embedding model and metric to another without downtime. How would you design the dual-write and cutover process?
- 2A model's documentation is ambiguous and labeled relevance data is sparse. What evaluation strategy would you use to select the metric with reasonable confidence?
8+ years experience
- 1You manage a platform hosting dozens of embedding models. How would you establish governance around metric selection, schema compatibility, and offline evaluation?
- 2A new metric improves one business domain but degrades another. Would you standardize globally or allow per-domain vector spaces, and what would drive that decision?
Follow-up Questions
- What would you do if the embedding model documentation gives no metric recommendation?
- How would you compare two metrics using an offline evaluation set?