Sparse vs. Dense vs. Hybrid Retrieval | Vedanshu
Vedanshu Patel compares BM25, dense embeddings, and reciprocal rank fusion on exact code lookups and paraphrased questions. In this run plain dense retrieval got both right, while the hybrid missed one because a wrong sparse ranking outvoted a right one.
Vedanshu Patel, a fellow at Humanitarians AI, works through a question from the retrieval chapter of a RAG course: is comparing embeddings even the right way to match a question to a passage? There are two genuinely different ways to decide whether a chunk answers a question, and each fails exactly where the other works.
Two questions, one answer
The chapter's example involves two employees asking about the same tuition reimbursement policy. The first quotes an exact code, TR114. The second never says tuition, reimbursement, or policy at all and simply asks whether the company helps pay for grad school. The answer is the same, but the questions are opposite in how they relate to the text.
Sparse retrieval with BM25
The video builds sparse retrieval from scratch using BM25: term frequency, inverse document frequency, length normalization, and saturation, so that a word repeated 50 times does not count 50 times. One detail matters more than it looks. TR114 has to be tokenized as a single term, because splitting it into TR and 114 destroys the exact-match signal before scoring starts.
Each query term contributes its inverse document frequency, scaled by how often it appears in the passage, and the normalizer divides by length so a long passage cannot win just by being long. TR114 appears in exactly one of 12 passages, which gives it the highest IDF in the collection. Run on the code query, it wins at 3.49 ahead of two other policies that merely contain the word reimbursement.
The paraphrase gap
The paraphrase, "help pay for grad school," returns the certification exam policy at 3.82, because that passage literally contains the words "company pays." The right answer comes in third. That is the paraphrase gap, measured.
Adding dense retrieval and fusing
The revision adds dense retrieval using real MiniLM embeddings, which match on meaning instead of words. The query embedding is dotted against every passage embedding, and because the vectors are normalized, the dot product is cosine similarity.
The two rankings are then fused with reciprocal rank fusion. Each candidate scores one over 60 plus its rank in every list it appears in, summed. It uses ranks rather than scores because BM25 scores and cosine similarities are not on a comparable scale. There are no weights and no tuning, and the whole method is four lines long.
The surprising result
Dense retrieval got both queries right. It found TR114 for the code query at 0.6, so the entity-centric weakness the chapter warns about did not show up at 12 passages. The hybrid, the supposedly safe default, missed the paraphrase. On that query the certification policy was sparse's number one and dense's number two, while the right answer was dense's number one and sparse's third. One over 61 plus one over 62 beats one over 63 plus one over 61 by about a quarter of a thousandth. Fusion counted ranks without reasoning about either list, and a confidently wrong ranking outvoted a correct one.
The video states two honest limits. Twelve passages is too small to reproduce dense retrieval's known weakness on rare entities, and one fusion loss is not a verdict on fusion. The summary is not that hybrid always wins.
Key takeaways
- Sparse search matches literal words and misses paraphrases.
- Dense search matches meaning, and here it missed nothing.
- Tokenization matters: splitting TR114 loses the exact-match signal.
- Reciprocal rank fusion sums one over 60 plus rank across lists.
- Fusion uses ranks because BM25 scores and cosine similarities are not comparable.
- A hybrid usually helps and rarely hurts, but this run was a case where it hurt.
- Averages can make fusion look good; look at the queries where it loses.
Try it yourself
Paste this prompt to Claude: take my own document set and build all three retrievers, sparse, dense, and a fused hybrid. Then find the queries where the hybrid is worse than its best single retriever and show the rank arithmetic that made it lose. Asking for the losing cases plus the arithmetic turns a default into a decision you can defend.
Chapters
- 0:00Sparse vs. dense retrieval: Literal words vs. meaning
- 0:20Exact code lookups (TR114) with BM25 keyword search
- 0:45Paraphrase gaps: Why BM25 misses semantic questions
- 1:10Reciprocal Rank Fusion (RRF) and how hybrid search can get outvoted
- 1:35Prompting Claude to stress-test your retrieval fusion arithmetic
Full transcript(auto-generated, with timestamps)
Sparse vs. dense retrieval: Literal words vs. meaning
[0:00]Konnichiwa, I'm Vedanshu Daksesh Patel. Chapter 5 made search fast. Chapter 6 asks whether comparing embeddings is even the right way to match in the first place because there are two genuinely different ways to decide whether a chunk answers a question and each one fails exactly where the other works. Here is the problem and it is the chapter's own example. Two employees the same tuition
Exact code lookups (TR114) with BM25 keyword search
[0:20]Reimbursement policy, two completely different questions. The first quotes an exact code TR114. The second never says tuition or reimbursement or policy at all. Just, does the company help pay for grad school? Same answer, opposite questions. The ask sparse retrieval from scratch. BM25 term frequency, inverse document frequency, length normalization and saturation. So, a word repeated 50 times doesn't count 50 times. One detail
Paraphrase gaps: Why BM25 misses semantic questions
[0:46]Matters more than it looks. Tokenize so TR114 survives as a single term. Split it into TR and 114 and the exact match signal is gone before we start. Read the scoring function. Every query term contributes its inverse document frequency scaled by how often it appears in this passage and that contribution saturates so repetition stops paying. The normalizer divides by document length so a long passage can't win just
Reciprocal Rank Fusion (RRF) and how hybrid search can get outvoted
[1:10]By being long and TR114 appears in exactly one of 12 passages which gives it the highest IDF in the collection. Run it. The code query TR114 wins at 3.49 ahead of two other policies that also contain the word reimbursement. Sparse nails it. Now the paraphrase, help pay for grad school returns the certification exam policy at 3.82 because that passage literally contains the words company pays. The right answer
Prompting Claude to stress-test your retrieval fusion arithmetic
[1:35]Is third. That is the paraphrase gap measured. The revision, add dense retrieval real mini LM embeddings matching on meaning instead of words. Then fuse the two rankings with reciprocal rank fusion. Each candidate scores one over 60 plus its rank in every list it appears in summed. Ranks not scores because BM25 scores and cosine similarities are not on a comparable scale and report all three methods. Two pieces dense embed the query dotted against every passage embedding the vectors are normalized so that dot product is cosine similarity. Then fusion for every rank list a candidate appears in add one over 60 plus its rank. No weights, no tuning. That is the whole of reciprocal rank fusion and it is four lines long. And here is the result I did not expect. Dense got both. It found TR114 for
The code query two at 0.6. The entity-centric weakness the chapter warns about did not show up at 12 passages. In the hybrid, the combination that is supposed to be the safe default, missed the paraphrase. Only plain dense went two for two. Here is why. On the paraphrase, the certification policy was sparse as number one and dense is number two. The right answer was dense as number one but sparse had it third. 1/61 + 1/62 beats 1/63 + 1/61 by a quarter of 1,000. Fusion did not reason about either list. It counted ranks and a confidently wrong ranking outvoted a correct one. So, sparse matches words and misses paraphrases. Dense matches meaning and here missed nothing. Hybrid usually helps and rarely hurts but usually is doing real work in that sentence and this run is one of the
Times it hurt. Two honest limits. 12 passages is too small to reproduce dense retrieval's known weakness on rare entities and one fusion loss is not a verdict on fusion. The chapter says the same thing. The honest summary is not the hybrid always wins. Let your turn paste this. Take my own document set and build all three retrievers, sparse, dense, and a fused hybrid. Then find me the queries where the hybrid is worse than its best single retriever and show me the rank arithmetic that made it lose. That second sentence is the one that earns its keep. Anything will report an average that makes fusion look good. Asking for the cases where it loses plus the arithmetic is what turns a default into a decision you can actually defend. Watch the right answer get outvoted. Vedant Chudaxsh Patel.
More from Humanitarians AI Fellows
2:39AI in Astronomy: Asteroid Tracking, Shrinking Uncertainty Clouds
2:333 Automated Workflows to Prevent and Detect Bad 4K Video Uploads | Vikhyat Raghumanda
2:50AI in Astronomy: Replacing Cosmological Simulations with Emulators
2:52Upstream Video Quality Control: 5 Packages to Catch 4K Render Errors Early | Vikhyat Raghumanda
2:24Embeddings vs. Keyword Matching: Knowing When Closeness Trumps Exactness
2:07