A hands-on walkthrough of how RAG systems work — no ML background needed. Upload any document and watch a real pipeline run step by step, with plain-English explanations at every stage.
What is RAG?
Large language models know a lot — but they don't know your documents. Retrieval-Augmented Generation bridges that gap:
find the relevant passages first, then ask the model to answer from them.
Instead of retraining the model on your data (expensive, slow, hard to update),
RAG keeps your documents in a searchable vector store. At query time, the most
relevant chunks are retrieved and pasted into the prompt — giving the model
fresh, accurate context on every single request.
RAGEmbeddingsVector StoreFAISSPython
Phase 1IngestionYour document is broken into small pieces, each piece is converted into a number sequence (embedding), and everything is saved into a searchable index. This happens once, offline.
→
Phase 2RetrievalWhen you ask a question, it's converted to the same number format and the index is searched for the most relevant pieces. No LLM involved yet — this is pure search.
→
Phase 3GenerationThe retrieved pieces are handed to an LLM alongside your question. The model reads only those pieces and writes an answer — grounded in your document, not its training data.
Ingestion is the preparation phase — it only runs once per document.
The goal is to make your document searchable by meaning, not just by keyword.
We do this in three sub-steps: split the text into manageable pieces (chunks),
convert each piece into a list of numbers that captures its meaning (embedding),
then store all those number lists in a fast searchable index (vector store).
After this, the document never needs to be processed again.
Upload any PDF or plain-text file under 500 KB. A short article or a few pages of notes works well.
1
Chunking
The document is sliced into short, overlapping pieces so the model never has to read the whole thing at once.
→
2
Embedding
Each chunk is converted to a list of 1,024 numbers. Chunks with similar meaning end up with similar numbers.
→
3
Vector Store
All the number lists are saved in an index (FAISS) that can find the closest match to any new query in milliseconds.
Tip: hover over any chunk pill to read its text preview.
Retrieval is the search phase — this is what happens the moment you ask a question.
Your question is converted into the same number format as the chunks (an embedding),
and the vector store finds whichever chunks are numerically closest to it.
"Closest" means "most similar in meaning" — not matching exact words, but matching intent.
Those top chunks become the context that gets handed to the LLM.
This demo uses semantic search — meaning-based matching via
cosine similarity (a way of measuring the angle between two number lists; a smaller angle = more similar meaning).
Production systems often layer in BM25 (classic keyword matching, like a search engine)
and combine both into hybrid search to get the best of both worlds.
We keep it simple here so you can see the core idea clearly.
Ingest a document above first, then come back here to run a query.
Generation is where the LLM (Large Language Model) finally enters the picture.
An LLM is a model that reads text and writes a response — think of it as a very capable writer
that can only work with whatever text you hand it.
In RAG, we hand it your question plus the retrieved chunks,
forming a prompt — a single block of text the model reads top-to-bottom before writing its answer.
Because the chunks come from your document, the answer is grounded in your content, not the model's general training.
Ingest a document above first, then ask a question here to see the full pipeline complete.
Below you can watch the three sub-steps happen in order:
the top chunks are pulled from the vector store (A),
assembled into the prompt text that gets sent to the model (B),
and the model streams back an answer grounded strictly in those chunks (C).
Notice that the model never sees the rest of your document — only what retrieval selected.
You've now seen the full pipeline run end-to-end. This section steps back and explains
why RAG exists, what problem it actually solves, and why it has become the
dominant approach for building AI systems that work with real-world documents.
The Problem RAG Solves
Large language models are trained on massive static datasets. Once trained, they have a fixed knowledge cutoff and know nothing about your private documents, internal databases, or anything published after training ended.
Fine-tuning can help, but it's expensive, slow, and doesn't update well. You'd have to retrain every time your data changes.
How RAG Works
RAG adds a retrieval step before generation. Your documents are split into chunks, converted into vector embeddings, and stored in a vector database. When a query arrives, the most semantically similar chunks are retrieved and injected into the LLM's prompt as context.
The model then generates an answer grounded in those chunks — not in its parametric memory. This makes answers accurate, updatable, and traceable to a source.
Why It Matters
RAG is the dominant architecture for enterprise AI assistants, document Q&A, knowledge bases, customer support bots, and code search tools. It's what makes AI practical when you need accurate, specific answers rather than fluent generalization.
Because answers cite retrieved chunks, you can audit them — something pure LLM generation can't provide.
What We Built Here
This demo runs a real RAG pipeline on AWS: Amazon Titan Embed Text v2 for embeddings, FAISS for in-memory vector search, and Claude Haiku 4.5 via Amazon Bedrock for generation — all connected through a serverless Lambda function.
Every step you saw is production-grade code, not a toy mock. The same patterns power billion-dollar enterprise systems.
Workflow — Beginner RAG (what this demo runs)
The diagram below maps out every step you just ran through, left to right.
The left half (dark border) is ingestion — it runs once when you upload your document.
The right half is query time — it runs fresh for every question you ask.
Follow the arrows to see how a PDF becomes an answer.
Document
PDF / TXT / HTML
Source
→
Chunking
Fixed-size windows ~500–1000 chars
Indexing
→
Embedding
Titan Embed v2 1024-dim vectors
Indexing
→
Vector Store
FAISS IndexFlatIP cosine similarity
Indexing
User Query
Natural language question
Query
→
Retrieval
Top-k chunks by cosine score
Query
→
Prompt
System + context + question
Query
→
LLM Answer
Claude Haiku 4.5 grounded response
Query
Workflow — Advanced RAG (production patterns)
Once you understand the basics, there's a lot of room to improve each step.
This diagram shows what a production-grade RAG system looks like —
the same five phases, but with smarter strategies at each one.
You don't need to understand all of this now — use it as a map of what's possible
and a reference for where each concept in the "What to explore next" section fits.
Amber-bordered nodes are the stages this demo already covers.