Signal Score00/40
GenAI 2026 · Module 10 · RAG Pipeline Recap

Signal Path

Eight notebooks, eight capabilities that turn a guessing LLM into a grounded one. Five interview questions wait at every station below.

Why
Chunk
Frame
Embed
Store
Sparse
Hybrid
Rerank
Begin the recap↓
Station 01 · The Problem

A model that never opened your files

Ask any LLM about your internal policy and it answers instantly and confidently, using patterns from its training data instead of your actual document. Three failure modes, one root cause: it has never read your world.

Hallucination Knowledge freeze Private data isolation
Closed book
"What is the home internet stipend at Northwind Logistics?"
"…a stipend of $75 per month…"
With retrieval
Same question, after handing it the real policy PDF
"…a stipend of $45 per month… [HR-2024-17 §7.3]"
◆ Live · Failure Rate on Knowledge Queries

Scroll this into view to watch the measured gap between closed-book and grounded answers.

Closed-book LLM
42%
With RAG grounding
8%
Station 02 · Ingestion & Chunking

Parsing decides what's even possible to retrieve

A table read as flat text loses its meaning before chunking ever begins. Once parsing is right, six chunking strategies compete on the same tradeoff: precision vs. context.

01
Fixed size
Cuts blindly, even through a table row.
02
Recursive
Prefers paragraph and line breaks.
03
Semantic
Cuts where the topic actually shifts.
04
Sentence window
Match small, hand back the neighbours.
05
Parent / small-to-big
Match a child, return its parent section.
06
Doc-type aware
Code, Markdown, HTML each split on their own structure.
Small chunk (≈150 tok)
High precision, narrow context. Risk: the retrieved sentence has lost the paragraph that explains it.
Large chunk (≈1500 tok)
Broad context, diluted embedding. Risk: the vector represents three topics blended into one average.
◆ Interactive · Drag the Chunk Size

Move the slider and this paragraph gets re-cut live. Watch the chunk count change.

chunk size120 chars
Chunks produced0
Precision (narrow match)0%
Context breadth0%
Station 03 · Frameworks

Same lesson, two toolkits

We built the same ingestion and chunking pipeline twice: once in LangChain, once in LlamaIndex. The parser mattered. The framework mostly didn't, except for one thing.

LangChain
notebook 02 · manual wiring
  • Explicit loaders + splitters, composed by hand
  • Sentence-window & parent-child needed custom code
  • Maximum control, more boilerplate
LlamaIndex
notebook 03 · batteries included
  • SentenceWindowNodeParser in one line
  • HierarchicalNodeParser builds parent/child automatically
  • Less code for retrieval-specific node structures
Takeaway: the parser and chunking strategy decide retrieval quality. The framework just decides how much code it takes to get there. LlamaIndex earns its keep on the hierarchical and windowed node parsers.
◆ Live · Lines of Code to Ship Each Pattern

Scroll into view: same three retrieval patterns, counted in each framework.

Basic loader + split
18
↳ LlamaIndex
9
Sentence window
46
↳ LlamaIndex
6
Parent / child
64
↳ LlamaIndex
8
Station 04 · Embeddings

Meaning, turned into geometry

"How do plants make food using light" and "Photosynthesis converts sunlight into glucose" share almost no words, yet they sit close together once embedded. An unrelated sentence sits far away.

Broken #1 · different dims Broken #2 · same dims, wrong model
0.87 0.11 "how plants make food" "photosynthesis…" unrelated sentence
The one non-negotiable rule
Index and query must use the exact same embedding model. Swap models mid-way and nearest neighbour stops meaning anything, because the two vector spaces no longer line up.
◆ Interactive · Same Model vs. Mismatched Model

Toggle the embedding model used at query time and watch the "nearest neighbours" scatter.

Query lands beside its true neighbours. Retrieval works.VALID
Station 05 · Vector Databases

Same search, three levels of who runs it

FAISS
library, not a database
We built the HNSW graph and IVF clusters ourselves, to see the mechanics.
Chroma
embedded database
Same HNSW core, plus metadata filters and persistence, with zero infrastructure to run.
Pinecone
managed service
Someone else runs the infrastructure. You pay for that in cost and lock-in.
recall latency exact search, 100% efSearch ↑
efSearch (HNSW) and nprobe (IVF) are the dials. Turn them up: recall climbs toward the exact-search line, and so does latency. Every vector database is tuning this same tradeoff underneath.
◆ Interactive · Drag efSearch

Watch the marker slide along the recall/latency curve as you turn the search-width dial.

recall latency
recall: n/aquery latency: n/a
Station 06 · Sparse Retrieval

The keyword matcher that refused to die

We already had dense embeddings. So why does every major search engine still run a keyword scorer underneath? Because raw counts have no ceiling, and BM25 fixes that.

score term freq TF-IDF, unbounded BM25, saturates
Stuff a keyword 50 times into a document and TF-IDF's score keeps climbing forever. BM25 caps the benefit of repetition and normalizes for document length, which is why it beat TF-IDF in production search. SPLADE goes a step further: a learned sparse model that still keeps BM25-style term matching inside it.
◆ Interactive · Stuff the Keyword

Drag to repeat a keyword in a document N times. Watch TF-IDF run away while BM25 tops out.

keyword repeated1×
TF-IDF score
0.0
BM25 score
0.0
Station 07 · Hybrid Search

Two retrievers, one blind spot each

Across 16 real queries, dense and sparse each won on different questions, and each went completely blind on the other's home turf.

Sparse · blind to meaning
Query "heart attack" scores 0.000 against a document that only says "myocardial infarction." Zero shared tokens, zero score, no matter how relevant the document actually is.
Dense · fuzzy on exact terms
Ask for an exact product code or error string and embeddings blur it into "something similar," when you needed the literal match.
Naively summing BM25 and cosine scores fails, because the two live on completely different scales. Reciprocal Rank Fusion fuses on rank position instead of raw score. Across all 16 test queries, hybrid beat both single-stage retrievers on every metric.
◆ Interactive · Tune the Fusion Weight

Drag alpha from pure sparse to pure dense and watch these three documents reorder live.

← sparse (BM25)α = 0.50dense (embeddings) →
Station 08 · Reranking

Fusion gets it into the list. Reranking puts it on top.

Same transformer architecture, two completely different jobs: encode once vs. compare directly.

Bi-encoder
pass 1 · done ahead of time
Query and document are embedded independently, then compared by cosine similarity. Fast enough to search millions of chunks, but the two texts never actually "see" each other.
Cross-encoder
pass 2 · done at search time
Query and document are fed into the transformer together, so self-attention can directly model word-to-word interaction. Far more accurate, far slower, so it only runs on the top 20–50 fused candidates.
Cross-encoder · pointwise FlashRank · CPU-only Cohere Rerank · managed API ColBERT · late interaction RankGPT · listwise LLM
◆ Interactive · Pick a Reranker

Every method trades accuracy against latency differently. Click one to see the trade live.

Accuracy (NDCG@10)
0%
Latency (relative)
0ms

Signal Path · Complete

The full retrieval pipeline, station by station

01
Why RAG
02·03
Parse & Chunk
04
Embed
05
Store
06
Sparse
07
Hybrid Fuse
08
Rerank
→
Generate
0/40Correct
Answer all 40 to reveal your badge
Your tier updates live as you answer each Interview Radar question above.