Why retrieval needs two kinds of search, not one.

Inside stage 3. The single bet that pure-vector RAG gets wrong, and how hybrid fixes it.

Warm-up (from Lesson 1, recall before scrolling): name the five stages, and say which one plain search skips. ingest · store · retrieve · synthesize · link — search skips synthesize. Got it without looking? Good. Today we open up retrieve.

The one idea: "Meaning" search and "exact" search fail in opposite directions. Run only one and you silently lose half your answers. Production retrieval runs both and merges them. That is all "hybrid search" means.

Two searches, two blind spots

Vector (dense) search turns your query into an embedding (a point in meaning-space) and finds chunks whose embeddings sit nearby. Ask for "sunny weather" and it happily returns "clear blue skies" with zero shared words. That is its superpower and its trap.

BM25 (sparse / lexical) search matches the actual tokens against an inverted index. Ask for order DKC-0083 or "VAPI" or "บริษัท ดีเคซี" and it nails the exact string. But ask for a synonym and it returns nothing, because the words did not literally appear.

Query type	Vector wins	BM25 wins
"how do I cancel a booking"	finds "reschedule / call to drop a slot"	misses unless those exact words appear
order id DKC-0083	drifts to similar-looking ids, unreliable	exact hit, every time
rare term "PGLite"	may blur into "SQLite / Postgres"	exact hit
"the barber who is good with kids"	finds the trait described in other words	misses, no keyword overlap

This is exactly why the DuckyCutz agent needs both: customers describe what they want in their own words (vector), but barber tables, order ids, and branch names are exact strings (BM25).

Merging the two: RRF

The catch: vector scores run 0 to 1, BM25 scores are unbounded. You cannot just add them. The fix is RRF (reciprocal rank fusion): ignore the raw scores, use only the rank position in each list, and sum 1 / (k + rank) across both. A chunk that ranks high in either list floats up. No score-normalization headache.

Query"who's good with kids?"

Densetop-N by embedding nearness

Sparsetop-N by BM25 keyword

RRFmerge by rank, not score

Rerankcross-encoder re-scores the short list

That last box, rerank, is an optional final pass: a slower, smarter model re-scores just the ~20 survivors for relevance. Cheap to run on a short list, big accuracy gain. We cover it properly in Lesson 3.

Connect it back: gbrain's retrieval is described as "vector + BM25 + RRF + graph signals." You now understand three of those four words exactly. The fourth, graph signals, is Lesson 4. Your Graphiti setup leans on that fourth one hardest.

Retrieval practice

Answer from memory.

A customer gives the exact order id DKC-0083. Which search is reliable?

Why merge dense and sparse results with RRF instead of adding scores?

"The barber who is good with kids" with no matching keywords. Who finds it?

Read this next (primary source)

★ Optimizing RAG with Hybrid Search & Reranking (Superlinked VectorHub). Walks the exact dense → sparse → RRF → rerank pipeline you just learned, with diagrams. ~12 min. It also sets up Lesson 3 (reranking).

New terms today are all in the glossary: embedding, BM25, hybrid search, RRF, rerank.

Ask your teacher. Good next prompts: "show me whether my Graphiti setup uses BM25 at all", "what would the four DuckyCutz query examples retrieve in practice", or "isn't reranking just doing vector search twice?" (it isn't, and the answer is Lesson 3).

← Lesson 1: Anatomy of a knowledge base Next → Lesson 3: Reranking, and why the first results aren't the best