The simplest thing that works
Naive RAG (also called Standard RAG) is the direct implementation of the three-stage pipeline from Lesson 2, with no extra machinery added at any stage: split documents into fixed-size chunks, embed each chunk once, and at question time retrieve the top-k most similar chunks and pass them straight into the prompt.
"Naive" here is a description of architectural simplicity, not a judgment. For a well-scoped knowledge base of clean, self-contained documents, such as a product FAQ or a set of internal policy pages, naive RAG is often good enough, and every architecture in the rest of this course exists specifically to fix a way naive RAG falls short once the data or the questions get harder.
What "top-k" actually means
The k in top-k is a number you choose, commonly between 3 and 10, and it is the single biggest lever in a naive RAG system. Too small, and a relevant chunk sitting at rank 6 never reaches the model. Too large, and irrelevant chunks dilute the prompt and can actively distract the model from the material that matters, a problem that gets worse, not better, as more chunks are stuffed in.
Why this counts as a baseline, not a finished design
Naive RAG makes a fixed decision at every stage, one chunk size for every document regardless of structure, one retrieval pass regardless of question difficulty, no check on whether what came back is actually relevant. Lesson 5 works through exactly where those fixed decisions break, which is the direct motivation for Advanced RAG in Lessons 6 and 7.
Checkpoint
- Naive RAG: chunk, embed, top-k retrieve, generate, with no additional optimization at any stage.
- Top-k is the biggest tuning lever: too small misses relevant chunks, too large dilutes and distracts the model.
- Naive RAG is a legitimate baseline for clean, well-scoped data, and the reference point every later architecture improves on.
If anything here still feels unclear, ask before moving to Lesson 5.