Lesson deck
RAG architecture and chunking flashcards
Reviewing needs JavaScript. You can read every card in the list below.
Loading your cards...
Back to the lesson7 cards in this deck
Read all 7 cards as a list
- Front
- What is RAG, in one sentence?
- Back
- Retrieving relevant external content and putting it in the prompt so the model's answer is grounded in that content, without changing model weights.
- Front
- Why not embed a whole document as one vector?
- Back
- One vector blends every topic in the document, which dilutes relevance and loses the detail a question asks about. Chunking keeps retrieval specific.
- Front
- Name the chunk-size trade-off and what overlap adds.
- Back
- Small chunks: precise but may lose surrounding context. Large chunks: more context but blurrier matches and a noisier prompt. Overlap keeps boundary facts in at least one chunk, at the cost of more and near-duplicate chunks.
- Front
- What is small-to-big (parent-child) retrieval?
- Back
- Embed small chunks for precise matching, then return their larger parent section so the model gets context. Cost: bigger prompts and de-duplicating shared parents.
- Front
- Why must ACL filtering happen inside retrieval?
- Back
- Post-filtering can empty the top-k and can leak through scores, summaries and caches. Enforce permissions in the query (filter or namespace) and scope caches by identity.
- Front
- A table is split one row per chunk and retrieval gets worse. Why, and how do you fix it?
- Back
- Rows lose their column headers, so the numbers have no meaning. Keep small tables whole, repeat the caption and header in each chunk, or rewrite each row as a sentence before embedding.
- Front
- How do you choose a chunk size without folklore?
- Back
- Index at two or three sizes with other settings fixed, score recall@k on labelled questions, then check prompt cost and a few end-to-end answers.