Meaning-based search and exact-term search each have blind spots the other one covers
Every retriever discussed so far assumes semantic (embedding-based) search underneath. That's a deliberate default, but it isn't the only way to search text, and it isn't always the best one on its own — a query containing an exact product code or ID can slip right past it.
Pure embedding-based similarity search — what every retriever in Retrieval Basics and Advanced Retrieval assumes by default. Great at meaning-based matching (finding a relevant passage even when it shares no words with the query), weak at exact-term matching — IDs, codes, and rare proper nouns can all score lower than they should, because an embedding model has typically never seen a specific SKU or ticket number enough times to represent it distinctly.
Wins clearly on: "What's our policy on employees working remotely from another country?" matched against a document that never uses the word "remotely" but discusses "distributed work arrangements" — the meaning overlaps even though the vocabulary doesn't.
BM25 is a classic statistical ranking function — a refinement of TF-IDF (term frequency–inverse document frequency) — that scores a document against a query based on how often query terms appear in it, discounted by how common those terms are across the whole corpus:
The intuition without the formula: a term that appears often in this document, but rarely across the corpus overall, is a strong signal this document is specifically about that term — and a document is not rewarded indefinitely for repeating a term many times (the k1 term causes diminishing returns), which is what stops keyword stuffing from dominating the score. BM25 has no notion of meaning at all — purely literal term matching — so it's strong for exact terms and weak for paraphrased or semantically related queries that don't share vocabulary with the source text.
Wins clearly on: "What does error code E-4471 mean?" — a semantic model has no learned representation that distinguishes E-4471 from E-4472; BM25 matches the literal string directly.
SPLADE (Sparse Lexical and Expansion model) sits between BM25 and dense embeddings: it's a neural model, trained the way dense embedding models are, but it outputs a sparse vector over the vocabulary (like BM25's term-based representation) rather than a dense vector over abstract dimensions. Because it's learned rather than purely statistical, it can also do limited term expansion — activating related terms that weren't literally in the text — while still keeping much of the exact-term precision and interpretability that dense embeddings give up. It's increasingly used as one leg of a hybrid setup alongside dense embeddings, and is covered in more depth in Embeddings.
Hybrid search runs semantic search and BM25 keyword search in parallel, then merges both result sets — typically using Reciprocal Rank Fusion (RRF), which combines results by rank position rather than raw score, since BM25 and cosine scores aren't on the same numeric scale (a BM25 score of 12 and a cosine score of 0.81 can't be averaged meaningfully). RRF instead scores each document by Σ 1 / (k + rank) across every ranked list it appeared in — a document ranked #1 in both lists scores far higher than one ranked #1 in only one list and absent from the other, which is exactly the "agreement across methods" signal hybrid search is trying to capture.
The weights parameter lets one method dominate when a corpus is known to lean one way — a codebase-search tool might weight BM25 higher (exact identifiers matter more there), while a general knowledge-base assistant might weight dense retrieval higher. Use hybrid search whenever queries might include exact terms that matter — product codes, table names, legal clause numbers — very common in enterprise or technical RAG, where neither pure semantic nor pure keyword search covers every case on its own.