Retrieval-augmented generation and vector search
Domain 3 - Retrieval-augmented generation and vector search
RAG questions test whether you can trace a wrong answer back to ingestion, retrieval, or generation.
Pipeline stages
Ingest → parse → chunk → embed → index → retrieve top-k → optionally rerank → assemble prompt with context → generate with citations.
Rules
- The same embedding model must be used at index time and query time; changing it invalidates the index.
- The similarity metric (cosine, dot product, Euclidean) must match how the index was built.
- Chunk size trades precision against context: small chunks retrieve precisely but fragment meaning; 300–800 tokens with 10–15% overlap is a common starting point.
- Hybrid search combines dense vectors with keyword (BM25) scores and helps with rare identifiers and product codes.
- A reranker re-scores a wider candidate set (top 50 → top 5) and typically improves precision.
- Metadata (document id, page, version, access control) enables citations and permission filtering.
Worked example
Users get plausible but outdated policy answers. Diagnosis order: check chunk metadata for version, check whether the index was rebuilt after the policy update, then check top-k. Reasoning: fluent wrong answers usually mean the right text was never retrieved, not that the model is weak.
Evaluating
Measure retrieval separately from generation: recall@k and context precision for retrieval; faithfulness and answer relevance for generation. If retrieval recall is low, no prompt tweak will fix it.
Traps
- Stuffing 20 chunks in and assuming more context is better.
- No citation metadata, so reviewers cannot verify an answer.
- Indexing PII without redaction.
- Leaving a stale index in place after documents change.
- Tuning the prompt when the failure is actually retrieval.