How does an Elasticsearch sparse_vector field indexed with ELSER differ from dense_vector kNN?

## Two ways to beat vocabulary mismatch Lexical search fails when the user and the document choose different words for the same idea. There are two families of fix. **Dense retrieval** embeds text into a few hundred or thousand continuous dimensions and finds neighbours geometrically. **Learned sparse retrieval** keeps the vocabulary-shaped representation of classical search but lets a model decide which terms belong and how much each one weighs — including terms the document never contained. ELSER (Elastic Learned Sparse EncodeR) is the second kind. Given a passage, it produces something like `{"laptop": 1.9, "notebook": 1.4, "computer": 1.1, "portable": 0.7, ...}` — an expansion into weighted vocabulary entries. A query is expanded the same way, and matching is the overlap of the two expansions, weighted. ## How it is stored and searched The output goes into a `sparse_vector` field, which stores token-weight pairs. Lucene indexes them as terms with weights, so a search is a big weighted disjunction: for each query token, look up its postings list and accumulate the product of query weight and document weight. That has real architectural consequences relative to `dense_vector`: - **No approximation.** There is no HNSW graph, so there is no `k`/`num_candidates` trade-off and no recall measurement against a brute-force baseline. What you get is what matches. - **Filters compose naturally.** A sparse retrieval clause is a query clause like any other; putting it in a `bool` with `filter` clauses behaves the way every Elasticsearch engineer already expects. There is no pre-filter/post-filter subtlety. - **No graph build cost.** Indexing is ordinary indexing, and segment merges do not rebuild a graph. - **Cost scales with expansion width.** Each expanded token is another postings list to walk. A query expanded into a hundred tokens is a hundred-clause disjunction, and common tokens have long postings lists. This is why token **pruning** exists: the `sparse_vector` query can drop tokens that are very frequent and carry low weight, trading a sliver of relevance for a large latency win. - **Interpretability.** You can look at the expansion. "Why did this match?" has an answer in terms you can read, which is not true of a dense embedding. ## The query surface The `sparse_vector` query is the current way to search these fields. You can hand it a pre-computed set of token weights, or give it query text plus an `inference_id` so Elasticsearch runs the model at query time. An older `text_expansion` query did the same job and was deprecated in 8.15 in favour of `sparse_vector`; on a current cluster, write `sparse_vector`. ## semantic_text — the batteries-included wrapper Wiring inference by hand means an ingest pipeline with an inference processor, a `sparse_vector` field, your own chunking for documents longer than the model's input window, and a query that names the right model. `semantic_text` (introduced in 8.15) collapses that: you map a field with an `inference_id` pointing at an inference endpoint, and Elasticsearch runs inference at ingest, chunks long text automatically, stores the per-chunk representations, and runs query-time inference for the `semantic` query. It works with a sparse model like ELSER and with dense embedding endpoints, so the field type is the abstraction and the endpoint decides which kind of vector is produced. The cost of the abstraction is control: chunking strategy, model choice per field and the exact representation are handled for you, which is exactly right until you need to tune one of them. ## Operational realities ELSER runs as a model deployment on machine-learning nodes. Inference happens on every ingested document and on every query, so ML node capacity becomes part of your search capacity planning, and cold or under-provisioned deployments show up as ingest backpressure and query latency. ELSER v2 is English-only — for other languages you want a multilingual dense model instead. Running the model also requires an appropriate Elastic subscription level rather than being available on every deployment. ## Choosing between them Sparse retrieval tends to be strong out of the box on general English text without domain fine-tuning, and it inherits the operational simplicity of the inverted index. Dense retrieval handles non-English corpora, lets you swap in a domain-tuned model, and supports genuinely non-textual similarity (images, audio, behavioural embeddings). Many production systems run both, plus BM25, and fuse the ranked lists — which is precisely the case reciprocal rank fusion was designed for.