Module 3 Theoretical & Architecture Interview Quiz
10 technical interview questions for Senior Data Engineers, Search Engineers, and AI Platform Architects.
Q1: What is the fundamental difference between an HNSW index and an IVFFlat index in vector databases like pgvector?
👉 Reveal Answer & Architectural Deep Dive
**Answer**: - **IVFFlat (Inverted File Flat)**: Partitions the vector space into $K$ Voronoi cells using $k$-means clustering. During query time, it scans only the vectors inside the centroids closest to the query vector. - *Pros*: Fast build time, small memory footprint. - *Cons*: Low recall on high dimensions, and search accuracy degrades as data drifts unless periodically re-indexed. - **HNSW (Hierarchical Navigable Small World)**: Builds a multi-layer graph where bottom layers contain dense local connections and top layers contain sparse long-distance "highway" links (similar to a Skip List). Query search begins at the top layer and greedily navigates down to the nearest neighbors. - *Pros*: Industry-leading query speed (sub-millisecond) and exceptionally high recall (>99%). - *Cons*: Higher memory usage and longer index build times. HNSW is preferred for 95% of production use cases.Q2: Why is Hybrid Search (BM25 + Dense Vector) strictly superior to Vector-Only search in technical enterprise applications?
👉 Reveal Answer & Architectural Deep Dive
**Answer**: Dense vector search excels at **semantic concepts** (understanding that *"distributed compute"* relates to *"Spark cluster"*), but performs poorly at exact keyword matches: 1. **Specific Identifiers**: Part numbers, UUIDs, table names (`fct_orders_v2`), or error codes (`ORA-00942`, `OutOfMemoryError: Java heap space`). Embeddings often compress these into nearby generic token vectors. 2. **Rare Acronyms**: Internal company codenames or specialized domain jargon. BM25 uses exact inverted indexes to retrieve exact identifier matches with 100% precision. Combining BM25 with Vector Search via Reciprocal Rank Fusion (RRF) gives the best of both worlds: semantic understanding + exact keyword retrieval.Q3: What is the difference between a Bi-Encoder and a Cross-Encoder?
👉 Reveal Answer & Architectural Deep Dive
**Answer**: - **Bi-Encoder**: Encodes the query and the document passage independently into two dense vectors: $\mathbf{u} = f(q)$ and $\mathbf{v} = g(d)$. Similarity is computed via dot product: $\mathbf{u} \cdot \mathbf{v}$. This allows documents to be pre-indexed into a vector database, enabling sub-millisecond retrieval over billions of records. - **Cross-Encoder**: Passes the query and document together into the transformer simultaneously: $h = f([q; ext{SEP}; d])$. All tokens attend to each other across full multi-head attention layers. It produces an exact relevance score between 0.0 and 1.0. While 100x more accurate, it cannot be pre-indexed and is computationally too expensive to run on millions of documents. It is used as a **Stage-2 Re-Ranker** over the top 25-50 candidates returned by the Bi-Encoder.Q4: Explain Matryoshka Representation Learning (MRL) and its cost benefits in data engineering.
👉 Reveal Answer & Architectural Deep Dive
**Answer**: In standard embeddings, all 1,536 dimensions share information equally. Matryoshka embeddings (named after Russian nesting dolls) are trained using a loss function that forces the model to pack the most important semantic information into the **first $D$ dimensions** (e.g., the first 256 or 512 dimensions). **Cost Benefit**: Data engineers can truncate 1536-dimensional vectors to 512 dimensions by simply slicing the array. This reduces vector database storage, memory (RAM), and network transmission by **67%**, while retaining over **99% of original retrieval accuracy**.Q5: What is the "Chunk Size Dilemma", and what is the Parent-Child chunking pattern?
👉 Reveal Answer & Architectural Deep Dive
**Answer**: - **The Dilemma**: Small chunks (e.g., 100 tokens) yield high vector retrieval precision because the embedding represents a single focused concept, but they lack sufficient context for the LLM to synthesize an answer. Large chunks (e.g., 2,000 tokens) contain rich context, but produce diluted vector embeddings that fail cosine similarity checks. - **Parent-Child Solution**: During ingestion, split documents into large 1,500-token **Parent chunks**, then split each parent into small 200-token **Child chunks**. Index only the child chunks into the vector database. When a child chunk matches a user's query, retrieve its **Parent chunk** and pass the complete parent document to the LLM!Q6: How does pgvector compare to a specialized vector database like Pinecone or Qdrant?
👉 Reveal Answer & Architectural Deep Dive
**Answer**: | Criteria | pgvector (PostgreSQL) | Dedicated Vector DB (Pinecone) | | :--- | :--- | :--- | | **Data Architecture** | Unified: Vectors and relational tables in one ACID DB. | Segregated: Vectors in Pinecone, metadata in SQL DB. | | **Transactions & Rollbacks** | Full ACID support; no orphan vectors. | Eventual consistency; requires dual-write orchestration. | | **Max Scale** | Excellent up to ~10-20 million vectors. | Scales to billions of vectors across distributed clusters. | | **Operational Overhead** | Zero if you already run Postgres (RDS, Aurora). | Requires managing another vendor and API. |Q7: Why is Cosine Distance ($ ext{operator } \mathtt{<=!>}$) used instead of Euclidean Distance ($\mathtt{<!-!>}$) for text embeddings?
👉 Reveal Answer & Architectural Deep Dive
**Answer**: Euclidean distance measures the length of the vector difference: $\|u - v\|$. If a short query and a long paragraph discuss the identical topic, their embedding vectors will point in the same direction, but the longer passage may have a larger vector magnitude, causing Euclidean distance to be large (indicating false dissimilarity). Cosine distance evaluates only the angle between vectors: $1 - rac{u \cdot v}{\|u\| \|v\|}$. It normalizes for vector length, making semantic similarity independent of text length.Q8: What is Hypothetical Document Embeddings (HyDE)?
👉 Reveal Answer & Architectural Deep Dive
**Answer**: Users often ask short, ambiguous questions: *"Why did my DAG fail?"*. A vector search for this short question might not match the technical log text in the vector database. **HyDE (Hypothetical Document Embeddings)**: 1. First, ask the LLM to generate a hypothetical passage: *"Write a fictional technical explanation of why an Airflow DAG might fail."* 2. Even if the generated answer contains factual hallucinations, its vocabulary and structure will closely match real documentation. 3. Embed this **hypothetical answer** and search the vector database using its vector. 4. This dramatically increases retrieval recall for ambiguous or terse questions.Q9: How should an enterprise RAG pipeline handle Change Data Capture (CDC) when relational tables update?
👉 Reveal Answer & Architectural Deep Dive
**Answer**: Vector databases do not automatically know when an upstream PostgreSQL or Snowflake table row changes. - **Debezium / Kafka CDC**: Stream table change events (`INSERT`, `UPDATE`, `DELETE`) into a Kafka topic. - A consumer microservice listens to the CDC stream: - On `INSERT`: Generate embeddings and call `index.upsert()`. - On `UPDATE`: Re-generate embeddings for modified text and update the vector ID. - On `DELETE`: Call `index.delete(ids=[row_id])` to eliminate stale/orphan vectors.Q10: What are the primary failure modes of Naive RAG in enterprise data platforms?
👉 Reveal Answer & Architectural Deep Dive
**Answer**: 1. **Low Precision**: Vector search returns irrelevant chunks that confuse the LLM into hallucinating. 2. **Missing Specifics**: Inability to match exact error codes or transaction IDs without hybrid search. 3. **Out-of-Date Chunks**: Ingestion pipeline lacks CDC, so search returns deprecated policies or schemas. 4. **Context Fragmentation**: Chunks cut across table boundaries or functions, leaving the model with half an explanation. 5. **Security Leakage**: Lack of metadata tenant filtering allows users to retrieve confidential corporate context.
Find this content helpful?
☕ Buy me a coffee