← Back to modules

RAG Fundamentals — Core

The retrieve-then-generate pipeline: loading, chunking, embedding, retrieval, reranking, grounded generation, evaluation, hybrid search, and RAG vs fine-tuning.

Medium50 questions

Sample questions

1

What problem does Retrieval-Augmented Generation primarily solve?

  • It permanently updates the model's weights with new facts at query time
  • It grounds answers in retrieved external documents, not parametric memory alone
  • It compresses the model so it runs on smaller hardware
  • It removes the need for a prompt by inferring intent from embeddings

Why

RAG retrieves relevant text at query time and conditions generation on it, grounding answers in an external, updatable knowledge source rather than only the model's frozen parameters. It doesn't change weights, shrink the model, or replace the prompt.

2

What is the correct high-level order of a basic RAG pipeline at query time?

  • Generate a draft, then retrieve documents to verify it
  • Fine-tune on the query, then generate from the updated weights
  • Rerank the whole corpus, then embed only the top document
  • Embed the query, retrieve relevant chunks, then generate grounded on them

Why

At query time you embed the user's query, retrieve the most relevant chunks from the index, and generate an answer conditioned on them. Generating first, fine-tuning per query, or reranking the entire corpus are not the standard flow.

3

Why are documents split into chunks before indexing in a RAG system?

  • To reduce the model's parameter count during retrieval
  • To retrieve focused, well-embedding passages that fit the context
  • To convert the documents into a single averaged embedding
  • To guarantee the whole document is always returned intact

Why

Chunking gives retrieval the right granularity: small enough to be a focused, well-embedded unit and to fit the context budget, but big enough to stay coherent. It doesn't affect parameters, isn't a single averaged vector, and deliberately avoids returning whole documents.

4

What is the purpose of overlap between adjacent chunks?

  • To store each chunk twice for redundancy against data loss
  • To keep boundary-straddling context attached to its sentence
  • To reduce the total number of embeddings that must be stored
  • To force every chunk to have exactly the same token count

Why

A little overlap keeps a sentence or idea that spans a chunk boundary intact in at least one chunk, so retrieval doesn't miss context cut in half. It isn't for redundancy or uniform sizing, and it increases (not reduces) the number of chunks.

5

In dense retrieval, how does the system decide which chunks are relevant to a query?

  • By comparing the query embedding to chunk embeddings via a similarity metric
  • By counting shared keywords between the query and each chunk
  • By asking the LLM to read every chunk in the corpus first
  • By selecting the most recently added chunks by timestamp

Why

Dense retrieval embeds the query and chunks into the same vector space and ranks by similarity (e.g. cosine/dot product), capturing meaning beyond exact words. Keyword counting is lexical (BM25), reading the whole corpus is infeasible, and recency isn't relevance.

Free account

Take the full module

These are the first few of 50 questions. A free account opens the rest as a scored drill.

  • Every question in this module
  • Instant feedback and supporting reading
  • Your score and progress, saved

Free · your email is used for progress only.