Home / Retrieval models / Sparse Retrieval Explained: From BM25 to Learned Sparse Models

Sparse Retrieval Explained: From BM25 to Learned Sparse Models

Sparse retrieval is search that represents queries and documents as sparse vectors of weighted terms, with a value only for the words they contain. It ranks documents by summing the weights of matching terms through an inverted index. Classic sparse retrieval, such as TF-IDF and BM25, sets those weights from term counts and document length. Learned sparse retrieval, such as SPLADE, uses a neural network to weight terms and to add related terms a document does not literally contain. Both keep the inverted index, so lookups are fast, exact identifiers match precisely, and results are easy to explain term by term. Sparse retrieval’s weakness is vocabulary mismatch: a document that says “reimbursement” will not match a query for “refund” unless expansion bridges the gap. That is why it is often paired with dense vector retrieval in hybrid search. Weaviate’s keyword search is BM25F sparse retrieval.

What is sparse retrieval?

Sparse retrieval is a family of search methods in which each query and document becomes a sparse vector over the vocabulary, and relevance is the overlap of their weighted terms. “Sparse” means almost every dimension is zero.

Picture a vector with one slot for every word in the collection’s vocabulary, which may be tens of thousands of slots. A document about refunds fills a few dozen of them with weights and leaves the rest at zero. A query does the same with its handful of words. The score of a document is the sum, over the words the two share, of the query weight times the document weight. Because only shared words contribute, a search only needs to look at documents that contain at least one query term.

That is the opposite of dense retrieval, where an embedding model maps text into a few hundred numbers that are all non-zero and individually meaningless. Dense retrieval covers that approach, and retrieval models explained places both families side by side. Weaviate’s documentation calls its keyword search “BM25” or “sparse vector” search, which is the classic member of the sparse family. The machinery that makes sparse search fast is the inverted index.

How does sparse retrieval use an inverted index?

Sparse retrieval uses an inverted index, a map from each term to the list of documents that contain it, so a query only reads the lists for its own terms instead of scanning the collection. The lists are called postings.

At indexing time, each document is tokenized and every term records the document, and often a weight or frequency, in its posting list. At query time, the engine reads the posting lists for the query’s terms, accumulates a score for each document that appears, and keeps the top results. A query with three terms touches three lists, however large the collection is.

Engines speed this further by skipping documents that cannot make the top results. WAND, short for Weak AND, uses each term’s maximum possible contribution to skip documents whose best case is too low. Weaviate’s documentation describes adding BlockMax WAND in version 1.30, which splits postings into blocks so whole blocks can be skipped. Weaviate’s blog post on the change headlines a 10 times speed-up for keyword search. With the lookup understood, the remaining question is how terms get their weights.

How does BM25 weight terms in sparse retrieval?

BM25 weights each term by how rare it is across the collection and how often it appears in the document, with diminishing returns for repetition and a penalty for long documents. It is the default keyword ranking in most search engines.

The rarity part is inverse document frequency: a term found in few documents, such as a product code, counts far more than one found everywhere, such as “account”. The frequency part saturates, controlled by the parameter k1, so the tenth mention of a word adds much less than the first. Length normalization, controlled by b, stops long documents winning simply by containing more words. Weaviate’s documentation sets k1 to 1.2 and b to 0.75 by default and advises changing them only with good reason.

BM25F extends BM25 to several fields, so a match in a title can count more than one in the body. Weaviate uses BM25F and lets queries boost properties with a caret, such as title^2. What is keyword search covers BM25 in more depth, with tokenization and stopwords. BM25’s limit is that it only rewards words that literally appear. That limit is called vocabulary mismatch.

Why does sparse retrieval miss relevant documents?

Sparse retrieval misses relevant documents when they express the same idea in different words, because a term that does not appear in a document contributes nothing to its score. This vocabulary mismatch is the central weakness of classic sparse retrieval.

A support article titled “How reimbursements work” never matches a query for “get my money back”, even though it is the right answer. Synonyms, paraphrases, abbreviations and spelling variants all cause the same miss. Stemming helps with word forms; Weaviate’s search operator reference notes that stemming is not yet supported in its BM25, so “refunds” and “refund” stay different tokens there.

There are three remedies. Query-side fixes rewrite or expand the query, covered in query expansion. Hybrid search adds a dense retriever that matches meaning, covered in dense vs sparse retrieval. And learned sparse models fix the representation itself, by teaching the index which unwritten terms a document is about. That third route is what separates modern sparse retrieval from BM25.

What is learned sparse retrieval?

Learned sparse retrieval is sparse retrieval in which a neural network decides the term weights and which extra terms to add. The network is usually a transformer, and its output stays a sparse vector searchable with an inverted index. It keeps the speed and transparency of keyword search and gains some of the meaning of dense search.

The approaches developed in steps. Document expansion, as in docT5query, uses a model to generate questions a document might answer and appends them before BM25 indexing. Learned term weighting, as in DeepImpact and uniCOIL, keeps a document’s own terms but has a model score each one. Learned expansion, as in SPLADE, introduced by Formal and colleagues in 2021, does both: it outputs weights over the whole vocabulary, so a refunds article gains weight on “reimbursement” and “money back”.

Elastic’s ELSER is a learned sparse encoder of this kind, built into Elasticsearch. The SPLADE family and its training are covered in SPLADE and learned sparse retrieval. Learned sparse vectors are longer than BM25’s, since expansion adds terms, so indexes grow and queries touch more postings. Weaviate’s documentation describes its built-in keyword search as BM25F; learned sparse models are not part of its keyword index. The contrast with dense models explains when each one wins.

What is the key difference between dense and sparse retrieval?

The key difference between dense and sparse retrieval is the representation: sparse retrieval matches weighted terms in an inverted index, while dense retrieval compares compact embedding vectors in a vector index. Sparse methods favour exact terms; dense methods favour meaning.

The trade-offs follow from that. Sparse retrieval matches identifiers, names and rare jargon precisely and explains every score by its terms. It needs no training data for BM25 and transfers well to new domains. Dense retrieval matches paraphrases and questions phrased differently from the documents, but can blur exact codes and is only as good as its embedding model on that domain. Learned sparse sits in between, gaining expansion while keeping term matching.

Encoders shape the dense side. Bi-encoders embed queries and documents separately for fast search, cross-encoders read them together for precise reranking, and bi-encoder vs cross-encoder compares the two. ColBERT and late interaction and multi-vector search keep one vector per token, a middle ground between the families. In practice, most systems now combine sparse and dense.

How is sparse retrieval combined with dense retrieval?

Sparse retrieval is combined with dense retrieval through hybrid search, which runs both and fuses their ranked lists, so exact-term matches and meaning matches both reach the top. Weaviate does this in one query.

Weaviate’s hybrid search runs a BM25F keyword search and a vector search in parallel and fuses them, by default with relative score fusion and an alpha weight of 0.75 towards the vector side. Lowering alpha gives sparse retrieval more say, which suits collections full of codes and names. The mechanics are in how hybrid search works, and choosing the weight in when to use hybrid search.

articles = client.collections.use("HelpArticle")

keyword_only = articles.query.bm25(query="refund ERR-4012", limit=5)         # sparse
blended = articles.query.hybrid(query="refund ERR-4012", alpha=0.4, limit=5)  # sparse + dense

Agents that issue many searches per task often call the sparse side directly for exact lookups and the hybrid side for open questions, as described in agentic retrieval and agentic search. Whatever the mix, sparse retrieval remains the part of the system that guarantees a typed identifier is found.

Sparse retrieval represents text as weighted terms and searches them through an inverted index, which makes it fast, exact on identifiers and easy to explain. BM25 sets the weights from term rarity, frequency and length, with k1 of 1.2 and b of 0.75 as Weaviate’s defaults. Its weakness, vocabulary mismatch, is addressed by query expansion, by learned sparse models such as SPLADE that add and weight unwritten terms, and by pairing it with dense retrieval in hybrid search. Use sparse retrieval wherever exact terms matter, and combine it with dense vectors so meaning-level matches are not lost.