Sparse Retrieval

Sparse retrieval scores documents by lexical overlap with the query — high-dimensional vectors where most entries are zero. BM25 is the canonical algorithm; TF-IDF, Lucene-style scoring, and SPLADE (learned sparse) are variants.

Sparse retrieval excels at exact-match queries (product codes, function names, rare terminology) where dense embeddings often miss. It's also faster to update incrementally and easier to interpret — every match has an explainable token overlap.

For RAG, sparse-only retrieval underperforms hybrid on most benchmarks but stays competitive on technical / code corpora where vocabulary is unique.

An engineer building search over a local codebase index finds that dense embeddings consistently fail to retrieve the right file when a user searches for an exact function name like parse_config_v2 — the embedding model treats it as a generic "parsing" concept and returns semantically similar but wrong results. Switching that query path to sparse retrieval (BM25 over tokenized identifiers) fixes it immediately, since the query and the correct chunk share an exact rare token. This is the standard reason code-search tools and log-search tools default to sparse or hybrid: identifiers, error codes, and stack traces are exactly the vocabulary where dense retrieval embeddings are weakest, because rare tokens are undertrained relative to common words.