Context Storage, Modeling, and Retrieval (RAG) with Databricks
This domain tests how you model retrieval-ready context and assemble a grounded RAG request. The exam expects you to separate source-of-truth storage from retrieval indexes, choose retrieval strategies, apply metadata filters, and produce cited, budget-aware context.
Storage and index patterns
- Keep chunk text and metadata in a Delta table; treat the Vector Search index as a derived serving structure.
- A Delta Sync index can sync from a source table and compute managed embeddings; Direct Vector Access is appropriate when you supply vectors yourself.
- Retrieval should combine semantic similarity with metadata filters, and use keyword or hybrid search when exact identifiers, codes, or names matter.
- Every retrieved item should carry chunk_id, doc_id, source, and version so the answer can cite evidence.
Retrieval and assembly
- Retrieve broadly, then rerank narrowly. A common pattern is top-k 10–20 into a reranker, then 3–6 chunks into the prompt.
- Apply filters before top-k when the filter is on indexed metadata; filtering after top-k can remove the only relevant evidence.
- Deduplicate near-identical chunks and enforce a token budget that reserves room for instructions, tool output, and the answer.
- Place the strongest evidence near the instruction and require citations.
Worked example
A policy assistant must answer by jurisdiction and effective date. The chunk table includes jurisdiction, effective_date, doc_id, and chunk_id. The Delta Sync index exposes those as metadata columns. A query for a California refund rule is issued with a jurisdiction filter and an effective_date filter, top-k 12, then reranked to 5 chunks. The prompt includes the policy instruction, the five chunks with citations, and a refusal rule when evidence is insufficient. Reasoning: filtering before retrieval prevents Oregon or expired policies from crowding out the correct chunk; reranking reduces context size without losing recall.
Traps
- Post-filtering after top-k, which often returns too little or irrelevant evidence.
- Using only semantic search for exact codes or product identifiers.
- Making top-k so large that relevant evidence is buried and token cost rises.
- Mixing chunks from different embedding model versions in one index.
- Returning an answer without chunk-level citations.