Question presented to candidate: "We are building retrieval over about ten million document chunks. Walk me through how you would pick the embedding model, how many dimensions to store, and which distance metric to use, and what would make you change those choices later."
What a strong answer should cover:
- Model choice is an evaluation, not a leaderboard pick: shortlist from MTEB and model cards on hard constraints (languages, max input length, hosting and data rules, price), then measure recall@k or nDCG on your own labelled queries
- The details that silently cost quality: query and document prefixes or task types, the model input limit versus chunk size, multilingual and domain fit
- Dimensions are a storage, memory and latency budget: raw float32 is dimensions x 4 bytes per vector; Matryoshka-trained models (OpenAI
dimensionsparameter, other MRL models) can be truncated and renormalised with small loss, models without that training cannot - Precision is a second lever: int8 scalar quantization (4x smaller) loses little; binary (32x) needs rescoring with the full vectors and works best with many dimensions
- Distance is whatever the model was trained for, normally cosine; normalise once and use dot product, and keep the same metric at index and query time
- Changing model means re-embedding everything: version the index, dual-write or rebuild alongside, evaluate, then switch
Clarifying questions expected:
- Which languages and content types (prose, code, tables) must it handle, and how long are the chunks?
- Can the data be sent to a third-party API, or must the model run in our own environment?
- What is the latency and memory budget for the index, and how fast does the corpus grow?
Code / implementation expected: Optional โ the storage arithmetic for dimensions and precision, or a small recall@k comparison, is a strong signal.