Vector Databases and Hybrid Search
Choosing a vector database is treated, in a weak interview answer, as picking a library off a shelf: "we'll use Pinecone" or "we'll use pgvector" as if the names were interchangeable. A strong answer treats it as a systems decision with the same shape as choosing a database engine — it depends on corpus size, query volume, filtering requirements, operational maturity of the team, and how much of the stack you already run. Interviewers in this space are not testing whether you have memorised a vendor comparison chart; they are testing whether you understand the trade-offs well enough to justify a choice under stated constraints and defend it when the constraints change.
The retrieval layer sits underneath rag-architecture-end-to-end and receives whatever chunking-and-embedding-strategies decided to index — this subject is about what happens once vectors (and their text) need to be stored, searched and filtered at scale. Three sub-problems recur in every serious design: how the index finds approximate nearest neighbours fast enough at the corpus size you actually have, how filtering interacts with that approximation without silently corrupting results, and how to combine semantic (dense) retrieval with lexical (exact-token) retrieval so the system is not blind to SKUs, error codes and names that embeddings routinely blur together. A fourth problem — re-ranking — is the one lever most candidates forget: it recovers precision cheaply because it only has to be right on a short list, not the whole corpus.
Depth here separates AI engineers from people who have only called an SDK. Anyone can call index.query(vector, top_k=10). The interview signal is in the follow-ups: What index type backs that call, and what does its ef_search or nprobe parameter actually trade off? What happens to that query if you also filter on tenant_id = 42 and only 3% of vectors match? Why would you ever run a slower, more expensive cross-encoder after already getting a ranked list back? This subject goes deep on exactly those three questions, plus the operational question interviewers increasingly ask first: do you need a dedicated vector database at all, or is Postgres enough?