Earlier in this series: “How RAG Works: From Document Indexing to Generated Answers,” “Why RAG Systems Split Documents into Chunks,” and “How Embeddings and Similarity Search Work in RAG.”
A RAG system can retrieve passages using more than one kind of signal. Sparse retrieval works with term-level evidence, such as whether particular words or identifiers occur in a chunk. Dense retrieval compares learned vector representations intended to capture relationships in meaning. Hybrid retrieval keeps both paths and combines their candidate lists.
These labels describe how a system generates and orders candidates. They do not say that one method is universally better, and they do not establish whether the retrieved text is correct, current, or sufficient for an answer.
Sparse retrieval keeps term-level signals
A sparse representation has a very large set of possible dimensions, but only a small share are active for a particular query or passage. In a traditional lexical system, those active dimensions correspond to terms. A query containing “AUTH-431” can therefore create a strong signal for chunks containing that same identifier.
BM25 is a common sparse ranking method. It considers signals such as term occurrence, how often a term appears, how common the term is across the collection, and document length. The result is a ranked list of passages based on lexical evidence rather than an embedding-space comparison.
Sparse retrieval is broader than BM25. Learned sparse models may assign weights to a large vocabulary and can sometimes activate related terms. The stable distinction is structural: most dimensions remain zero, and the non-zero dimensions retain term-level meaning.
Dense retrieval compares learned representations
Dense retrieval represents a query and each chunk with an embedding. Unlike a traditional sparse vector, a dense embedding usually contains values across most or all of its dimensions. Those dimensions are learned by the model and are not ordinarily readable as individual words.
The retriever compares the query embedding with stored chunk embeddings using a similarity or distance measure. Because the representation is learned from patterns in data, passages with different wording may still be placed near the query. “Replace my sign-in phone,” for example, may be close to a passage about “enrolling a new authentication device.”
That behavior depends on the embedding model, its training, the query and document encoding setup, and the available chunks. Dense retrieval does not erase lexical information, but it does not preserve exact strings in the same explicit way as a term-based sparse representation.
Hybrid retrieval combines candidate lists
Hybrid retrieval usually runs more than one retrieval path for the same query. A sparse retriever produces one ranked candidate list, while a dense retriever produces another. A fusion step then creates a single list for the next stage of the RAG pipeline.
The lists cannot always be combined by simply adding their raw scores. A BM25 score and a vector-similarity score describe different calculations and may use unrelated scales. Implementations may normalize and weight scores, or they may combine ranks instead. Reciprocal rank fusion is one rank-based method: it uses a passage’s position in each list rather than assuming the original scores are directly comparable.
If the same passage appears in both lists, the fusion step should treat it as one candidate rather than two copies. The final list may then be passed onward directly or through another stage such as filtering or reranking. Hybrid retrieval is therefore a retrieval pipeline, not necessarily a third way of representing every document.
One query, two useful signals
Consider a fictional support collection. The query is: “What does AUTH-431 mean when I replace my sign-in phone?” One chunk contains the exact code AUTH-431 and explains that it appears when an existing device registration is still active. Another chunk is titled “Enroll a new authentication device” and describes the replacement workflow without using the phrase “sign-in phone.”
A sparse path has explicit evidence from the error code and any shared terms. A dense path may also surface the workflow passage because the wording describes a related task. In a hybrid system, both passages can enter the candidate set before fusion. This does not predetermine their final order; it only shows how different signals can contribute candidates.
A second fictional query asks, “What is the meal reimbursement limit under TR-22?” A policy passage may use the phrase “daily meal allowance” and contain the exact identifier TR-22. Here, the same passage can receive lexical evidence from the identifier and semantic evidence from the relationship between “reimbursement limit” and “allowance.” Sparse and dense retrieval are separate mechanisms, but their useful signals need not belong to different documents.
The retrieval method does not validate the evidence
Sparse, dense, and hybrid retrieval all select from the material that has been indexed. If the collection is missing the answer, contains stale text, or divides the relevant statement poorly, changing the retrieval path does not repair the source material.
The names also do not specify the complete system. Tokenization, query rewriting, chunking, filters, candidate counts, fusion rules, and reranking may all affect the final list. Two systems described as “hybrid” can therefore behave differently.
Most importantly, the merged ranking is still a set of candidates. The application must preserve the readable text and source information, decide what to send to the language model, and handle cases in which the evidence is insufficient. Retrieval can provide relevant context; it does not certify the answer.
Sparse retrieval keeps a mostly empty representation whose active dimensions carry term-level signals. Dense retrieval uses learned embeddings and compares their positions. Hybrid retrieval runs multiple retrieval paths and fuses the resulting candidates.
All three approaches ultimately need to return readable chunks and source information. Their job is to generate and order evidence candidates; the later RAG stages still determine how that evidence is assembled and used.
The next explainer will cover metadata filters: what they are, where they enter the retrieval flow, and how they restrict the eligible candidate set before or during search.