the pipeline, end to end

# ingestion (offline, run once / on updates)
documents -> chunk -> embed -> store in a vector index

# query time (per user request)
user_query -> embed -> similarity search against the index -> top-k chunks
           -> insert chunks into the prompt as context -> generate answer
Two clearly separate phases: ingestion happens ahead of time and is comparatively cheap to get wrong and re-run; query-time retrieval happens on every single request and directly gates answer quality — most RAG debugging time goes into the query-time half.

why RAG instead of just fine-tuning on the documents

RAGFine-tuning on the same documents
Update latency for new/changed docsRe-index the changed doc; minutesRetrain; hours-days
Attribution / citing sourcesNatural — you know exactly which chunks were retrievedHard — knowledge is baked into weights with no traceable source
Reduces hallucination on the covered facts?Yes, when the right chunk is retrievedNot reliably — fine-tuning teaches style/format more than it teaches new facts to recall faithfully
Full decision framework across all three levers: Fine-Tuning vs. RAG vs. Prompting.

where RAG actually fails

FailureUsual cause
Right document exists, wrong/no chunk retrievedPoor chunking boundaries or an embedding model mismatched to the domain — see Chunking & Retrieval Strategies
Retrieved chunks are relevant but answer is still wrongToo many/irrelevant chunks crowding the context, or important chunk placed where "lost in the middle" hurts it — see Context Windows
Model ignores retrieved context and answers from parametric memory anywayPrompt doesn't clearly instruct the model to prefer the provided context over its own knowledge, especially when they conflict

where to go from here

Chunking & Retrieval Strategies — the ingestion-side decisions that most determine RAG quality.
Reranking & RAG Evaluation — improving precision after initial retrieval, and measuring it.
Embeddings & Vector Similarity — the building block underneath retrieval.