What Is SPLADE? Learned Sparse Retrieval

// In plain English

SPLADE is a way to search text that combines the speed of old keyword search with the smarts of a neural network. The name stands for SParse Lexical AnD Expansion model. The short version: it is a smarter BM25. Like BM25, it scores documents by the words they share with your query. Unlike BM25, it uses a trained language model to decide which words matter and to quietly add related words that were never typed.

Picture a librarian with two habits. The first librarian (plain keyword search) only looks for the exact words you said. Search for "car" and a perfect article titled "automobile maintenance" is invisible, because it never uses the word "car." The second librarian (SPLADE) reads your request, silently notes that "car" also implies "vehicle," "automobile," and "motor," and then looks for all of those — while still writing everything down on the same simple index card the first librarian used. You get the recall of a model that understands meaning, but the lookup stays as cheap as a keyword search.

The key word is sparse. A SPLADE vector has one slot for every word in the model's vocabulary (tens of thousands of slots), but almost all of them are zero. Only a few hundred slots, for the words the model thinks are relevant, hold a non-zero weight. That mostly-empty shape is exactly what a classic inverted index — the data structure search engines have used for decades — is built to store and search at scale.

// Why it matters

Retrieval in a RAG system has a hard tradeoff. Keyword search (BM25) is fast, cheap, explainable, and great at exact matches like error codes, product SKUs, and names — but it is blind to synonyms and paraphrases. Dense embeddings catch meaning and paraphrases — but they are heavier to run, can miss exact terms, and produce vectors no human can read. SPLADE is interesting because it lands in the middle and refuses to fully give up either side.

The vocabulary mismatch problem

The single biggest weakness of keyword search is the vocabulary mismatch: the user and the document describe the same idea with different words. A support ticket says "laptop won't turn on"; the fix-it doc says "notebook fails to boot." Zero shared words, so BM25 scores it near zero, even though it is the perfect answer. SPLADE attacks this directly through term expansion — at index time it adds "notebook," "boot," "power," and friends to the document's vector, and at query time it adds the matching expansions to the query, so the two meet.

• Recall without leaving the inverted index. You get embedding-like recall while still searching with the same fast, mature engines (Lucene, Elasticsearch, OpenSearch) that already run keyword search.
• Explainability. Every weight in a SPLADE vector is tied to a real word. You can literally read why a document matched — something a 1,024-number dense vector can never give you.
• Strong out-of-domain behavior. Because it is anchored to actual words, learned sparse retrieval often holds up better than dense embeddings on data that looks nothing like its training set.
• A natural third leg for hybrid search. Many teams combine BM25, dense, and SPLADE and fuse the results, because each catches mistakes the others make.

If you are building retrieval and your queries mix exact tokens (codes, names) with natural-language phrasing, SPLADE is worth knowing. It is the answer to "I want better-than-BM25 recall, but I don't want to throw away my inverted index and explainability to get it."

// How it works

SPLADE is built on a masked language model — the same kind of model (a BERT-style encoder) that, during training, learned to predict missing words in a sentence. That "predict the right word" skill is exactly what powers term expansion. SPLADE reuses the model's output layer, which already scores every word in the vocabulary for how well it fits a position in the text.

From text to a sparse vector

Feed a piece of text through the encoder. For each input token, the model produces a score for every vocabulary word — not just the word that was there, but every word it considers related. SPLADE pools these scores across all the input tokens into a single vector with one entry per vocabulary word, and pushes most entries down to exactly zero. What survives is a short list of weighted terms: the words actually present, plus a handful of expansion words the model decided belong.

Two activation tricks make this work. A ReLU clamps every score at zero or above, so a word either contributes a positive weight or nothing at all — no negative terms. A log saturation (taking the log of one-plus-the-score) keeps any single common word from dominating, mirroring BM25's term-frequency saturation. The result is naturally sparse and well-behaved on an inverted index.

The sparsity knob

Nothing forces the vector to be sparse by default, so SPLADE adds a regularization penalty during training that punishes vectors for having too many non-zero terms. Turn the penalty up and vectors get shorter — faster and cheaper to search, but they may drop useful expansions. Turn it down and you keep more terms — better recall, but bigger index and slower queries. This dial, balancing how many words survive against speed, is the central tuning choice in learned sparse retrieval.

Matching and scoring

At search time the query becomes its own sparse vector the same way. The relevance score is just the dot product: for every term the query and document share, multiply their two weights and add it all up. That is the identical math an inverted index does for BM25 — which is the whole point. The neural model only runs once per document at index time and once per query; the actual lookup is plain, fast, sparse arithmetic.

// SPLADE vs BM25 vs dense embeddings

The clearest way to place SPLADE is between the two retrieval families it borrows from. BM25 is pure lexical matching with a fixed formula. Dense embeddings are pure semantic matching with an opaque vector. SPLADE is lexical in shape but semantic in content.

Notice SPLADE shares a column with BM25 in two places that matter operationally: the same sparse vector shape and the same inverted index. That is why teams already running keyword search can often adopt SPLADE without standing up a separate vector database — the index they have can store learned sparse vectors too.

// Using SPLADE in practice

SPLADE rarely flies solo. In most real systems it is one retriever among several, feeding candidates into fusion and reranking. Here is how it usually fits, and the traps to watch.

Where it sits in the pipeline

A common strong setup runs SPLADE (or SPLADE plus BM25 plus dense) as the first-stage retriever to pull a broad candidate set, blends the lists with reciprocal rank fusion, then sends the top candidates to a cross-encoder reranker for a precise final sort. SPLADE's job is recall: surface every plausibly relevant document cheaply, and let reranking do the expensive fine-grained ordering.

Watch-outs

• Index size can balloon. Expansion adds terms to every document, so an index can grow noticeably versus plain BM25. The sparsity penalty is your lever — tune it against your latency and storage budget, don't accept the default blindly.
• Indexing is heavier. Every document must pass through the neural encoder once, so building the index costs real compute. After that, queries are cheap; the cost is paid up front, not per search.
• The encoder must match your engine. SPLADE leans on engines that support per-term weights in the inverted index. Confirm your search backend can store and score weighted sparse vectors before committing.
• It is not a reranker. SPLADE is a first-stage retriever. It widens the net; it does not give you the razor-sharp top-3 ordering a cross-encoder does. Use both.

// Going deeper

Once the basics click, a few directions are worth knowing. SPLADE is a family, not a single frozen model, and it sits inside a broader move toward learned sparse retrieval that also includes models from other labs.

The variants tell a story about tradeoffs. Early SPLADE expanded both sides but was slow at query time. Later versions added distillation (learning from a stronger cross-encoder teacher) to improve quality, and asymmetric "doc-only" expansion to cut query cost. Every generation is essentially a different answer to the same two questions: how many terms survive, and who pays for expansion — the indexer or the querier?

Distillation is why it competes with dense models. On its own, the masked-language-model signal is decent but not great. Training SPLADE to imitate the relevance judgments of a powerful but slow cross-encoder transfers much of that quality into a cheap-to-serve sparse model. This teacher-student pattern is common across modern retrieval and is a big reason learned sparse methods caught up.

Engineering reality matters more than leaderboard points. Expanded vectors create long posting lists for popular expansion terms, which can slow an inverted index in ways BM25 never does. Production work on learned sparse retrieval is often about index-time pruning, term-weight quantization, and query-term limits — squeezing the same recall out of a smaller, faster index. The interesting problems are systems problems.

Where to go next. Solidify the contrast with BM25 and dense embeddings, since SPLADE only makes sense as the bridge between them. Then study hybrid search and reciprocal rank fusion to see how multiple retrievers combine, and reranking for the precision stage that almost always follows. The durable lesson: there is no single best retriever — there are complementary ones, and SPLADE earns its place by being lexical and semantic at the same time.