What is a vector store?
A database or retrieval system that stores embeddings with ids, source text, metadata, and index structures for similarity search.
Interview Questions: Vector Stores and Indexing Strategies
Use these to explain vector stores as production retrieval infrastructure.
What should be stored with an embedding?
Chunk id, text, source id, metadata, access labels, source version, embedding model, dimension, and index version.
How do you design collections?
By environment, tenant, domain, model dimension, data sensitivity, and release strategy.
Flat vs approximate index?
Flat search is simple and high recall but slower at scale. Approximate search is faster but may trade recall.
What is blue-green indexing?
Build a new index beside the old one, run evals, then switch traffic if it passes.
How do you handle deletes?
Use deterministic ids, delete retired vectors, enforce active-status filters, and run stale-hit audits.
What can go wrong with metadata?
Missing access, status, version, tenant, or effective-date fields can leak, stale, or wrong-domain content.
What metrics matter?
Recall@k, MRR, latency, empty result rate, stale-hit rate, duplicate rate, build duration, and upsert failures.
How do you release a new embedding model?
Create a new index version, re-embed corpus, run evals, shadow test, and roll out gradually with rollback.
What is the senior answer to "we use a vector DB"?
Which collections, schemas, filters, release gates, evals, rollback paths, and traces make it safe?