# Sparse versus dense retrieval: SPLADE, BM25, and vectors

[Skip to content](#lm-inhoud)Network/[NL](/en/sparse-versus-dense-retrieval-splade-en-bm25-naast-vectoren)EN[Hubhub.llmnet.nlCompare models on task, language, cost and license.](https://hub.llmnet.nl/en/)[Communitycommunity.llmnet.nlPrompt techniques, patterns and system prompts.](https://community.llmnet.nl/en/)[APIapi.llmnet.nlLLMs in production: rate limits, routing, structured output.](https://api.llmnet.nl/en/)[Consultancyconsultancy.llmnet.nlRolling out AI in an organization, pilot to production.](https://consultancy.llmnet.nl/en/)[Newsnieuws.llmnet.nlAI developments, explained for the Netherlands.](https://nieuws.llmnet.nl/en/)[Benchmarkbenchmark.llmnet.nlMeasure AI quality yourself, on your own tasks.](https://benchmark.llmnet.nl/en/)[Careersvacatures.llmnet.nlAI roles, salaries and career paths in the Netherlands.](https://vacatures.llmnet.nl/en/)[Learnleren.llmnet.nlAI concepts in plain language, beginner to builder.](https://leren.llmnet.nl/en/)[Guidegids.llmnet.nlRun AI privately on your own Mac, PC, NAS or home server.](https://gids.llmnet.nl/en/)[Directorydirectory.llmnet.nlMapping the AI ecosystem: tools, models, companies.](https://directory.llmnet.nl/en/)[Radarradar.llmnet.nlSignals from X, research and communities for indie developers.](https://radar.llmnet.nl/en/)[Appsapps.llmnet.nlReviews of AI apps and open-source repos, with tips for builders.](https://apps.llmnet.nl/en/)[llmnet.nl — main site](https://llmnet.nl/en/)[](https://x.com/intent/post?url=https%3A%2F%2Fhub.llmnet.nl%2Fen%2Fsparse-versus-dense-retrieval-splade-en-bm25-naast-vectoren&text=Sparse%20versus%20dense%20retrieval%3A%20SPLADE%2C%20BM25%2C%20and%20vectors)[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fhub.llmnet.nl%2Fen%2Fsparse-versus-dense-retrieval-splade-en-bm25-naast-vectoren)[](https://www.reddit.com/submit?url=https%3A%2F%2Fhub.llmnet.nl%2Fen%2Fsparse-versus-dense-retrieval-splade-en-bm25-naast-vectoren&title=Sparse%20versus%20dense%20retrieval%3A%20SPLADE%2C%20BM25%2C%20and%20vectors)[](#)[](https://x.com/intent/post?url=https%3A%2F%2Fhub.llmnet.nl%2Fen%2Fsparse-versus-dense-retrieval-splade-en-bm25-naast-vectoren&text=Sparse%20versus%20dense%20retrieval%3A%20SPLADE%2C%20BM25%2C%20and%20vectors)[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fhub.llmnet.nl%2Fen%2Fsparse-versus-dense-retrieval-splade-en-bm25-naast-vectoren)[](https://www.reddit.com/submit?url=https%3A%2F%2Fhub.llmnet.nl%2Fen%2Fsparse-versus-dense-retrieval-splade-en-bm25-naast-vectoren&title=Sparse%20versus%20dense%20retrieval%3A%20SPLADE%2C%20BM25%2C%20and%20vectors)[](#)

 
# Sparse versus dense retrieval: SPLADE and BM25 alongside vectors

 By Ivo Donker — compiled with AI assistance (Claude & Gemini)

 When building robust search functionality or a retrieval-augmented generation (RAG) pipeline, the choice of retrieval mechanism forms the foundation of the ultimate answer quality. For years, dense vector retrieval dominated the debate: texts are converted via neural transformer models into dense numerical vectors of typically 768 to 3072 dimensions, after which semantic relatedness is calculated via cosine similarity or dot products. In practice, however, dense retrieval proves vulnerable to exact search terms, serial numbers, out-of-vocabulary domain codes, and technical jargon. This often results in a search error that looks semantically plausible but is factually incorrect.

 To address these blind spots, classic lexico-statistical methods such as BM25 and modern neural sparse architectures such as SPLADE remain indispensable. In this article, we analyze the mathematical foundations, infrastructural footprint, and qualitative trade-offs between traditional sparse indexes, dense vectors, and learned sparse vectors. For an overview of available vector encoding models and their properties, we refer to the article in which we [compare embedding models for search functions and RAG](https://hub.llmnet.nl/en/embeddingmodellen-vergeleken). This article does not cover the operational implementation of database clusters; it focuses on the mathematical and architectural selection process.

 
## 1. The anatomy of Dense Retrieval: semantics versus exact precision

 Dense retrieval represents text fragments as continuous vectors in a multidimensional latent space. The model compresses the full semantic meaning of a sentence or paragraph into a fixed list of real numbers, where nearly every dimension holds a value not equal to zero. A bi-encoder transforms the input query and document chunks independently of each other, after which an Approximate Nearest Neighbor (ANN) index — such as HNSW (Hierarchical Navigable Small World) or IVF-PQ (Inverted File with Product Quantization) — selects the nearest documents.

 The power of dense representations lies in capturing synonyms, paraphrases, and cross-language concepts without specific keywords needing to match literally. When a user searches for "insulating a home against noise pollution," a dense model effortlessly recognizes documents about "installing acoustic wall panels" as relevant. The embedding space brings semantically related concepts close together based on co-occurrence and context patterns learned during pre-training.

 This compression into a dense vector, however, brings a structural drawback: the loss of exact lexico-graphic specificity. When a document contains a unique type ID such as XZ-9042-B, a citizen service number, or a rare biochemical formula, the tokenizer often splits this string into arbitrary subtokens. The dense model assigns these fragments a generic semantic position, causing the unique keyword identity to fade. Dense retrieval therefore shows a systematic tendency toward overgeneralization on entity-specific search queries.

 
## 2. BM25 and the power of inverted indexes

 Best Matching 25 (BM25) is a probabilistic retrieval algorithm that builds on the age-old TF-IDF principle (Term Frequency-Inverse Document Frequency). Instead of dense vectors, BM25 generates an extremely sparse vector the size of the entire vocabulary (often 100,000 to more than 1,000,000 terms). In this sparse vector, virtually all dimensions are zero, except for the positions that exactly match the terms actually present in the document.

 BM25 calculates the relevance score of a document $D$ for a query $Q$ based on the following parameters:

 $$Score(D, Q) = \sum_{i=1}^{N} IDF(q_i) \cdot \frac{f(q_i, D) \cdot (k_1 + 1)}{f(q_i, D) + k_1 \cdot (1 - b + b \cdot \frac{|D|}{avgdl})}$$

 Here, $f(q_i, D)$ represents the term frequency of search term $q_i$ in document $D$, $|D|$ the length of the document, $avgdl$ the average document length across the entire corpus, $k_1$ the parameter for term frequency saturation (typically between 1.2 and 2.0), and $b$ the degree of length normalization (usually 0.75). The inverse document frequency $IDF(q_i)$ ensures that rare terms weigh considerably more heavily than common stop words.

 Because sparse representations are stored in an inverted index, retrieving documents with exact keywords is particularly efficient from a hardware standpoint. No heavy matrix multiplication on a GPU is needed; queries only require traversing ordered posting lists in memory. The fundamental weakness of BM25, however, is the so-called 'vocabulary mismatch problem': if the searcher uses different words than the author (for example, "heart attack" versus "myocardial infarction"), the model fails completely unless manual synonym lists are maintained.

 
## 3. SPLADE: Learned sparse representations via BERT vocabulary

 SPLADE (Sparse Lexical and Anatomic Document Embeddings) bridges the gap between the lexico-graphic precision of BM25 and the semantic understanding of transformer models. Instead of producing a dense vector of 768 numbers, SPLADE projects the hidden state of a BERT-like neural network directly back onto the full vocabulary space of the language model (for example 30,522 dimensions with WordPiece).

 For each token $t$ in the vocabulary, the model generates an importance score $w_j$ for a given document $d$. This happens via a log transformation and saturation function over the sequence of input tokens:

 $$w_j = \max_{t \in d} \log(1 + \text{ReLU}(W_j \cdot h_t + b_j))$$

 Here, $h_t$ is the contextual embedding of token $t$ from the transformer layer, and $W_j$ and $b_j$ are the weights of the vocabulary projection layer. To ensure the resulting vector actually stays 'sparse' (and thus fits into a standard inverted index), a regularization loss is added during training, such as FLOPS regularization or L1 normalization.

 The revolutionary aspect of SPLADE is automated **term expansion**. When SPLADE processes the sentence "the car won't start because of a dead battery," the network not only assigns weight to the present terms but also activates related vocabulary dimensions such as spanning, dynamo, accupool and pechverhelping. These expanded terms are stored directly in the inverted index along with their corresponding weights. This allows SPLADE to capture synonyms without the need for a dense vector space, while simultaneously maintaining high keyword precision.

 
## 4. Structural comparison: BM25, SPLADE, and Dense Embeddings

 The choice between these three methods depends on specific requirements around latency, memory usage, indexing speed, and the nature of the corpus data. The comparison below shows the structural properties per retrieval architecture:

 
 
 
 
 Property | 
 BM25 | 
 Dense Embeddings | 
 SPLADE | 
 

 
 
 
 Vector structure | 
 Sparse (exact vocabulary) | 
 Dense (768–3072 dimensions) | 
 Sparse (learned vocabulary) | 
 

 
 Semantic understanding | 
 None (purely lexico-graphic) | 
 Excellent (contextual) | 
 High (via term expansion) | 
 

 
 Exact ID / OOV match | 
 Excellent | 
 Moderate to poor | 
 Good to excellent | 
 

 
 Indexing computational power | 
 CPU (very low) | 
 GPU/Neural (high) | 
 GPU/Neural (very high) | 
 

 
 Query latency | 
 < 5 ms (CPU) | 
 15–50 ms (ANN search) | 
 10–30 ms (Inverted index) | 
 

 
 Index size on disk | 
 Small (1x corpus size) | 
 Large (depends on vectors) | 
 Medium to large (2-4x BM25) | 
 

 
 Index mechanism | 
 Inverted Index (Lucene/WAND) | 
 HNSW, IVF-Flat, SCaNN | 
 Sparse Inverted Index / Lucene | 
 

 
 
 

 When we analyze the computational costs, it stands out that SPLADE requires significant computational power during the indexing phase. Each document must be passed through a transformer model to calculate the vocabulary weights. The resulting index, however, is operationally simpler to maintain than a heavy vector index, because sparse posting lists can be efficiently flushed to disk and compressed via block-max WAND algorithms.

 
## 5. Hybrid architectures: Reciprocal Rank Fusion and Cross-Encoders

 In production applications, a single retrieval method rarely proves sufficient for every type of search query. That's why modern RAG systems massively opt for a hybrid setup in which sparse and dense search results are combined. To merge the results of two different scoring mechanisms (for example a BM25 score of 14.2 and a cosine distance of 0.82), normalization is necessary.

 The industry standard for this merging is **Reciprocal Rank Fusion (RRF)**. RRF does not look at the absolute scores, but only at the rank order within each result list. The formula for RRF is:

 $$RRF\_Score(d \in D) = \sum_{m \in M} \frac{1}{k + r_m(d)}$$

 Here, $M$ is the set of search methods used (such as BM25 and dense retrieval), $r_m(d)$ the rank position of document $d$ within method $m$, and $k$ a constant smoothing factor (default set to 60). Through this smoothing, documents that score highly in both search methods receive a strong cumulative preference, without outliers in absolute scores distorting the outcome.

 To determine when a hybrid approach is necessary over a single model, the overview article on [the choice between embedding, reranker, or hybrid retrieval](https://hub.llmnet.nl/en/embedding-reranker-of-hybride-welk-retrieval-model-wanneer) offers a complete methodological decision tree. After the initial RRF selection (for example the top 50 documents), a second filtering phase often follows via a neural cross-encoder model, which reassesses the interaction between question and answer per document in detail.

 
## 6. Example: Implementation of a Sparse-Dense Hybrid Fusion

 The Python snippet below shows how a combined RRF pipeline is built programmatically. We combine the hits from a sparse component (BM25 or SPLADE) and a dense vector search to arrive at a final top-k selection:

from typing import Dict, List, Tuple

def reciprocal_rank_fusion(
 dense_results: List[str],
 sparse_results: List[str],
 k: int = 60
) -> List[Tuple[str, float]]:
 """
 Combineert gerangschikte document-ID's via Reciprocal Rank Fusion (RRF).
 """
 rrf_scores: Dict[str, float] = {}

 # Verwerk rangposities uit de dense vectorzoekactie
 for rank, doc_id in enumerate(dense_results, start=1):
 if doc_id not in rrf_scores:
 rrf_scores[doc_id] = 0.0
 rrf_scores[doc_id] += 1.0 / (k + rank)

 # Verwerk rangposities uit de sparse (BM25/SPLADE) zoekactie
 for rank, doc_id in enumerate(sparse_results, start=1):
 if doc_id not in rrf_scores:
 rrf_scores[doc_id] = 0.0
 rrf_scores[doc_id] += 1.0 / (k + rank)

 # Sorteer documenten op basis van de gecombineerde RRF-score
 gesorteerd = sorted(
 rrf_scores.items(),
 key=lambda item: item[1],
 reverse=True
 )
 return gesorteerd

# Voorbeeldlijsten met document-ID's gerangschikt op relevantie
dense_hits = ["doc_alpha", "doc_gamma", "doc_beta", "doc_delta"]
sparse_hits = ["doc_beta", "doc_alpha", "doc_epsilon", "doc_gamma"]

gecombineerde_top_k = reciprocal_rank_fusion(dense_hits, sparse_hits, k=60)
for doc_id, score in gecombineerde_top_k[:3]:
 print(f"Document: {doc_id} | RRF Score: {score:.5f}")

 In this example, doc_alpha scores highest because it falls within the absolute top two in both search paths. The document doc_beta, which ranked dense in third place but sparse in first place, also rises with conviction to the top of the combined index.

 
## 7. Memory usage, latency, and scalability in production

 When rolling out a retrieval system to tens of thousands or millions of documents, the trade-off shifts from theoretical recall to operational costs and memory pressure. Dense vector indexes such as HNSW require the entire vector graph to preferably be held in working memory (RAM) to guarantee acceptable search times. At 10 million vectors of 1536 dimensions (float32), this means at least 60 gigabytes of raw vector data, excluding the overhead of connection edges in the HNSW graph (which often doubles the memory requirement).

 Sparse indexes via BM25, on the other hand, make use of highly optimized posting lists on disk. Thanks to techniques such as block-max WAND, the search engine only needs to load a fraction of the index blocks, keeping the RAM footprint marginal. SPLADE sits in the middle: although the indexing technique is identical to BM25, each document contains significantly more active tokens due to term expansion (an average of 150 to 300 non-zero values per passage versus 30 to 80 for BM25). The inverted index for SPLADE is therefore on average two to four times larger than that of BM25.

 To maximize the quality of the combined result after retrieval, the top-k subset is typically evaluated by a two-stage reranking model. Details on selecting and benchmarking these scoring models can be found in the analysis on [rerankers and search models for advanced RAG systems](https://hub.llmnet.nl/en/rerankers-en-zoekmodellen).

 
## 8. Quantitative evaluation: measurement methods and benchmarks

 To determine which retrieval setup is superior for a specific domain, empirical validation is required. Common academic benchmarks such as BEIR (Benchmarking Information Retrieval) show that no single method wins across all domains:

 
 
- Biomedical datasets (such as BioASQ and NFCorpus): SPLADE and BM25 often outperform 'zero-shot' dense models, due to the large volume of unique Latin nomenclature and specific protein codes.
 
- Argumentation and reasoning (such as Touché-2020): Dense models achieve significantly higher scores because the literal keywords rarely reflect the rhetorical structure of an argument.
 
- Financial and legal data: Hybrid systems (SPLADE + Dense) consistently score 5 to 12 points higher on nDCG@10 than isolated vector models.
 

 The standard measurement methods for expressing retrieval quality are Recall@K (the percentage of relevant documents retrieved within the top-K), MRR@K (Mean Reciprocal Rank, how high the first relevant document ranks), and nDCG@K (Normalized Discounted Cumulative Gain, which weighs the position of all relevant documents). To discover how to structurally set up these metrics within an evaluation pipeline, see the in-depth guide on [RAG evaluation and measuring retrieval and generation quality](https://benchmark.llmnet.nl/en/rag-evaluatie).

 
## Conclusion and strategic decision matrix

 The opposition between sparse and dense retrieval is no longer a binary choice in modern AI design. Where dense vectors excel at abstract contextual understanding and multilinguality, BM25 and SPLADE remain essential for hard keyword precision, product codes, and domain-specific jargon.

 For simple applications with strict budgets, BM25 delivers an extremely reliable baseline with minimal hardware requirements. Anyone seeking maximum precision without the operational complexity of vector graphs finds an excellent alternative in SPLADE thanks to automatic term expansion. For mission-critical production systems where recall and precision are both crucial, a hybrid architecture — in which dense and sparse representations come together via Reciprocal Rank Fusion and are filtered by a cross-encoder — forms the most robust standard.