Home / How it works / Dense vs Sparse Vectors: Differences and When to Use Each

Dense vs Sparse Vectors: Differences and When to Use Each

The difference between dense and sparse vectors is that a dense vector fills every position with learned numbers that encode meaning, while a sparse vector marks only the few terms a text contains. A dense vector usually has a few hundred to a few thousand positions. A sparse vector has one position per vocabulary term, almost all of them zero. Dense vectors come from neural embedding models and match by meaning. Sparse vectors come from BM25, TF-IDF, or learned models such as SPLADE and match by terms. In a small illustrative test, a query sharing no words with “How to catch an Alaskan pollock” still scored 0.558 on dense similarity. A query sharing three words scored lowest, at 0.400. Neither vector type wins everywhere. Weaviate’s hybrid search runs both and fuses the results, which is the usual answer in production.

What is the difference between dense and sparse vectors?

The difference between dense and sparse vectors lies in how many positions hold values and what each position means. Dense vectors fill every position with abstract features; sparse vectors fill a few positions tied to specific terms. Weaviate’s documentation describes sparse vectors as mostly zero, and dense vectors as mostly non-zero.

Weaviate’s hybrid search explainer gives the classic example. In “How to catch an Alaskan Pollock,” the dense vector understands that “catch” means fishing, not catching a baseball or a cold. The sparse vector matches “Alaskan Pollock” exactly, which dense vectors can blur. Each type sees what the other misses.

The same split applies to embeddings. “Dense embeddings” and “sparse embeddings” are the same two families, named for the vectors they produce. The dense vectors and sparse vectors pages cover each in depth. One sentence shows the difference most clearly.

What do dense and sparse vectors look like for the same sentence?

For the same sentence, a dense vector is a list of hundreds of small non-zero decimals, while a sparse vector is a huge list with non-zero weights only at the sentence’s own terms. A small test with an open model shows real values. It ran on a laptop in seconds, so anyone can repeat it with their own sentences and see the same pattern.

We embedded “How to catch an Alaskan pollock” with the open all-MiniLM-L6-v2 model, using mean pooling. The dense vector has 384 dimensions, and 381 of them are non-zero. Its first six values are -0.031, 0.015, 0.024, -0.031, -0.017, and 0.014. None of them can be read on its own.

The same model’s tokenizer splits the sentence into seven pieces: how, to, catch, an, alaska, ##n, and pollock. A term-based sparse vector over that 30,522-term vocabulary would have just those seven non-zero positions. Everything else is zero, and every non-zero position names a token.

Then we compared three queries with the sentence:

The pattern is the whole story in small form. “How to catch a cold” shares three words, so a plain term-count match ranks it well, yet it is about illness. “Fishing tips for whitefish” shares no words, so a term match misses it, yet the dense vector places it close. We kept the script and its output so the test can be rerun. The same contrast plays out at search scale.

What is the key difference between dense and sparse retrieval?

The key difference between dense and sparse retrieval is that dense retrieval ranks documents by vector distance, while sparse retrieval ranks documents that share query terms. Dense retrieval uses an approximate vector index; sparse retrieval uses an inverted index and term weights. The indexes, the scoring, and the failure modes all differ.

Sparse retrieval is the classic search engine. An inverted index maps each term to the documents containing it, so a query touches only the lists for its own terms. Weaviate’s documentation describes BM25 scoring as term frequency weighed against how rare the term is in the whole collection, with defaults of k1 set to 1.2 and b set to 0.75. Weaviate calls its keyword search “sparse vector” search for this reason.

Dense retrieval embeds the query and searches an approximate nearest neighbor index, such as HNSW, for the closest document vectors. It has no notion of matching terms at all, only of distance.

Research shows each side winning in different settings. Dense Passage Retrieval, from Karpukhin and colleagues, beat a strong BM25 system by 9 to 19 points in top-20 accuracy on open-domain question answering. The BEIR benchmark, from Thakur and colleagues, found BM25 a robust baseline when models faced domains they were not trained on. Weaviate’s own guidance matches: BM25 suits exact matches and out-of-domain searches. BM25 versus vector search goes further. A third family sits between the two.

How do learned sparse models like SPLADE work?

Learned sparse models like SPLADE work by using a neural network to produce sparse vectors, assigning learned weights to terms and adding related terms the text never used. They keep the inverted index but gain some of the meaning of dense models.

SPLADE was introduced by Formal, Piwowarski, and Clinchant at SIGIR 2021. It uses a transformer to predict a weight for each vocabulary term, then pushes most weights to zero through a sparsity penalty. The result stays sparse, so it works with inverted indexes and exact term matching. The authors report results competitive with both dense and sparse methods of the time.

Expansion is what makes learned sparse vectors different from BM25. A passage about “pollock” might gain weight on “fish” or “cod” even though those words never appear. The vector stays readable, because every non-zero position is still a term, but it now captures some related meaning.

Other learned sparse models follow the same idea, such as Elastic’s ELSER, which Elasticsearch serves through its sparse vector query. They need a model at indexing and query time, like dense models, and their vocabulary is fixed by the model’s tokenizer. For many teams, the choice is not one family but which to lead with.

When should you use dense vectors, and when sparse vectors?

You should use dense vectors when queries describe ideas in varied words, and sparse vectors when queries depend on exact terms; for most real search, you should use both. The content and the queries decide the balance.

Cost differs too. A dense vector stores every dimension, often at 4 bytes each, and needs a vector index in memory for speed. A sparse vector stores only its few non-zero terms. But a learned sparse model still needs inference, just as a dense model does. When to use hybrid search covers the decision in more detail. Combining them is simpler than it sounds.

How do you combine dense and sparse vectors in one search?

You combine dense and sparse vectors by running both searches and fusing their ranked results into one list, which is what hybrid search does. In Weaviate, one hybrid query runs both and a single alpha value sets their weight.

Weaviate’s hybrid search pairs BM25F keyword search, its sparse side, with vector search, its dense side. An alpha of 0 means pure sparse, 1 means pure dense, and the default is 0.75. The two result lists are fused, by default with relative score fusion, which normalizes each side’s scores before adding them.

import weaviate
from weaviate.classes.query import MetadataQuery

client = weaviate.connect_to_local()
articles = client.collections.use("Article")

for alpha in (0.0, 0.5, 1.0):   # pure sparse, balanced, pure dense
    response = articles.query.hybrid(
        query="how to catch an Alaskan pollock",
        alpha=alpha,
        limit=3,
        return_metadata=MetadataQuery(score=True),
    )
    print(alpha, [o.properties["title"] for o in response.objects])

client.close()

Running the same query at three alpha values is a quick way to see what each side contributes on your own data. If pure sparse already finds the right document, the query is term-driven. If only pure dense finds it, meaning carries the query. Most collections land in between, which is why balancing keyword and vector scores matters. Hybrid search and reciprocal rank fusion explain the fusion step. The words “dense” and “sparse” also turn up in other parts of computing.

What do dense and sparse mean for indexes, graphs, and matrices?

Dense and sparse mean the same thing in spirit everywhere, how full a structure is, but a dense or sparse index, graph, or matrix is a different concept from a dense or sparse vector. Searchers often mix them up.

• Dense versus sparse index (databases): in Silberschatz, Korth, and Sudarshan’s Database System Concepts, a dense index has an entry for every search-key value. A sparse index has entries for only some values and works only when the file is sorted on that key. This is about database lookup, not embeddings.
• Dense versus sparse graph: a dense graph has close to the maximum number of edges, roughly the square of its vertex count. A sparse graph has far fewer. Cormen and colleagues’ Introduction to Algorithms recommends adjacency lists for sparse graphs and matrices for dense ones.
• Dense versus sparse matrix: a sparse matrix is mostly zeros and is stored in compressed formats that skip them. A collection of sparse vectors is exactly such a matrix, which is why inverted indexes store it so cheaply.
• Dense versus sparse data: the same idea applied to datasets, where sparse data has many missing or zero fields.

The vector sense is the one that matters for search. Some databases make the link explicit: Oracle, for example, lets a vector column use a SPARSE or DENSE storage format. Related pages include dense versus sparse retrieval, SPLADE and learned sparse retrieval, vector search, and vector indexes.

Dense vectors fill every position with learned features and match by meaning; sparse vectors mark a few terms and match by words. The illustrative test made it concrete: a query with no shared words scored 0.558 on dense similarity, while one sharing three words scored 0.400. Dense retrieval wins on paraphrase and in-domain questions, sparse retrieval on exact terms and unfamiliar domains, and learned sparse models like SPLADE sit between. The practical step is to run both through hybrid search, such as Weaviate’s hybrid query, and tune alpha on your own queries.