top of page

Vector Search in Ecommerce: The Limits of Dense Vectors and What Works Within Them

Writer: Ondrej Nespor
Ondrej Nespor
Oct 25
27 min read

Updated: 3d

Written by Ondřej Nešpor, CTO at Raventic


Semantic search silent failure in e-commerce: the query "yellow hoodie, not blue" returns a full page of blue products with 200 OK and 0 errors.

In Part 1, we looked at the limits of full-text search. It’s fast, predictable, and auditable, but it matches characters rather than meaning - meaning every patch you apply adds to a mountain of permanent maintenance. So, the obvious question is: does swapping literal string matching for a machine learning model break through that ceiling?




Why we're writing this — Raventic builds search and product discovery for e-commerce catalogs. Part 1 ended on a tempting question: could a model just learn everything we'd been hand-maintaining? This chapter is our honest answer: where dense vectors genuinely earn their place, and where they fail so quietly that a full page of confident, wrong products never trips a single alarm.



Series navigation

Part 2:   Vector Search in Ecommerce: The Limits of Dense Vectors (you’re here)

Part 3:   The Limits of Hybrid Search

Part 4:   The Constraint Satisfaction Paradigm in Ecommerce Search



TL;DR

  • Dense (neural) search gives you synonyms, grammar inflections, and cross-language matching essentially for free, but it swaps loud, debuggable text bugs for a new class of silent failures.


  • Indexing a tokenizer's subword fragments instead of running the model is a dead end: fragments compress text, they don't carry meaning - so car matches carpet, vůz/vozu share nothing, and brands and specs (Sennheiser, IPX7) dissolve into generic pieces.


  • Dense vectors fail where e-commerce lives: a bare baterie averages into a useless centroid, short queries starve the model of context, ASCII-folding routes rám into English RAM, and filters fight the ANN graph (pre-filter breaks recall, post-filter empties the page). Negation and typos break too - silently.


  • Learned sparse retrieval (SPLADE) is the best bridge: a model picks a document's vocabulary terms for a standard inverted index, keeping exact filters, facets, and readable, debuggable expansions. Still not a silver bullet — web-corpus noise, brand bias, broken negation, fuzzy specs, and no public model for most languages (Czech included).


  • The real lesson: semantic search doesn't remove manual work, it moves it from query-side dictionaries to document-side text engineering. No single engine wins — dense and sparse fail in complementary ways, which is why you run both and merge them (Part 3).



Yes and no. Neural search solves some of the hardest problems we detailed in Part 1. But when you evaluate neural search against the brutal requirements of real-world e-commerce — rather than simple top-k ranking accuracy in a paper — you find a whole new set of structural failure modes. Worse, many of these vector failures are silent and much harder to debug than the raw text bugs they replace.



A quick note on terminology — “semantic search” is a problem, not a specific technology. It’s the challenge of finding products that don’t literally match the search text. Most of this chapter covers the most common solution: encoding documents as a single dense vector. But we will end by looking at learned sparse retrieval — a different approach that runs inside a standard inverted index and recovers the best parts of full-text search.



What semantic search actually solves


Dense retrieval does a great job of wiping out the biggest maintenance headaches of full-text search:


  1. Instant morphological and synonym coverage: Instead of maintaining a complex web of stemming dictionaries ("boty", "botami") and custom synonym rules ("obuv", "sandály"), dense embedding models map related concepts to nearby regions in a vector space by default.


  2. Generalization to new queries: Vector spaces capture relationships geometrically, famously illustrated by vector math.


Vector for Berlin minus vector for Germany plus vector for France approximately equals vector for Paris.

  1. Cross-language and cross-modal alignment: Multilingual models map different languages into a shared vector space, and multimodal models align text and images without needing manual tags.


These features make vector search incredibly powerful. But we have to separate a model’s ranking quality on a clean benchmark dataset from its ability to return correct results under real-world filters, facets, and business rules.



Tokenization: a tempting shortcut that fails


Before digging into vector failures, let’s look at how text actually enters a neural model. The pipeline is simple: split text into tokens, feed those tokens to the model, and let the model output something a search engine can index. That “something” is the core of this article, but the first step - how we tokenize - constrains everything that follows.


Vocabularies must be finite


Models can’t read raw characters. They ingest integer token IDs that index rows in a fixed embedding matrix (Devlin et al., 2019; Mielke et al., 2021). This matrix has a pre-determined size because every row adds parameters. Storing every word across multiple languages isn’t just expensive — it’s impossible. E-commerce catalogs constantly generate new strings: model numbers, brand names, typos, and compounds.


To solve this, models use subword tokenization. The tokenizer learns a fixed vocabulary of word fragments from a training corpus. Any new string — even one never seen before — is broken down into these fragments. In the worst case, a word is simply spelled out letter-by-letter, meaning nothing is ever “out of vocabulary.” The most popular algorithms are WordPiece (Schuster & Nakajima, 2012; Wu et al., 2016), Byte-Pair Encoding (BPE) (Sennrich et al., 2016), and Unigram segmentation (Kudo, 2018), typically packaged via SentencePiece (Kudo & Richardson, 2018).



Here is the catch: these fragments are chosen to compress text efficiently, not to make linguistic sense. Bostrom & Durrett (2020) confirmed that BPE splits rarely align with actual word roots or grammatical boundaries. They merely resemble them, and that resemblance leads to trouble.


The shortcut


This subword decomposition inspires an elegant, tempting idea: if a tokenizer already breaks compounds and inflections into repeating fragments, why not index those fragments directly in an inverted index and skip the expensive deep learning model entirely?


It’s a smart idea. Look at how bert-base-multilingual-cased splits the Czech noun forms that gave us so much trouble in Part 1:


bota      ->  bot  ##a
boty      ->  bot  ##y
botami    ->  bot  ##ami
botách    ->  bot  ##ách

Every form shares the bot fragment. If we index these fragments, a search for "boty" will match "botami" automatically. We get morphological matching with no stemmers, no dictionaries, and zero per-language config. It seems to work for German compound words, too: a tokenizer splits Kaffeemaschine at the boundary, allowing a search for Kaffee to match the compound.


Architecturally, this is brilliant. Every advantage of full-text search remains intact. You still use a standard inverted index. BM25 still handles the scoring. Filters and facets remain 100% accurate. Debugging is simple because you can read the indexed fragments. A single tokenizer replaces a complex stack of language-specific stemmers, dictionaries, and compound splitters.


This is the promise: semantic-like generalization at virtually zero performance or operational cost. But in production, it completely falls apart.


Why the shortcut fails


1. Fragments ignore meaning, causing bad matches. Because segmentation is driven by file compression stats rather than semantics, fragments end up in weird places. The tokenizer that cleanly splits bot ##a also splits these:


Subword tokenization false matches in e-commerce search: "car" matches carpet, "note" matches notebook, Czech "bat" groups baterie (battery) with batoh (backpack).

Suddenly, a search for “car” matches carpets, “note” matches laptops, and in Czech, batteries and backpacks are grouped together under bat. These aren’t obscure edge cases — they are everyday catalog words.


2. Word prefixes break matching. WordPiece distinguishes continuation fragments (like ##bal) from starting fragments (bal). A prefixed word like Czech přebalit (pře ##bal ##it) puts the root in a continuation token, but an unprefixed search for "balit" (bal ##it) uses a starting token. Since these are entirely different IDs, the system fails to match them. The same thing happens with English words like unbutton (un ##but ##ton).


3. It fails on the same root shifts that break stemmers. We established in Part 1 that middle-vowel shifts (internal alternations) limit stemmer accuracy. Fragment tokenizers can’t handle them either:


vůz   ->  v    ##ů  ##z          (car, nominative)
vozu  ->  voz  ##u               (car, genitive)

dům   ->  dům                    (house, nominative)
domu  ->  domu                   (house, genitive)

The two forms of vůz share absolutely no fragments. dům and domu are treated as completely unrelated tokens. The shortcut handles basic suffixes but fails on the complex root mutations that motivated us to look beyond basic stemmers in the first place.


4. It breaks compound matching. German compound splitting is highly imperfect under a subword tokenizer. Often, a compound and its base word share no common fragments:


Herrenschuhe  ->  Herren  ##sch  ##uh  ##e
Schuhe        ->  Sc      ##hu   ##he

There’s no overlap. Searching for the standalone word won’t find the compound — which is the entire point of decompounding. Dedicated splitters succeed because they force splits to be real dictionary words (Koehn & Knight, 2003); subword tokenizers have no such guardrails. Other times, the splits are outright silly: Kaffeemaschine splits into Ka ##ffe ##ema ##schi ##ne, where ##ema straddles the boundary. And Waschmaschine (washing machine) starts with Was (German for “what”), matching query noise.


5. Splits are arbitrary and unstable. These fragment boundaries aren’t linguistic rules; they are just snapshots of a specific training run. If you use a different tokenizer like BGE-M3’s SentencePiece Unigram vocabulary, the results change and become even less consistent:


bota    ->  ▁bota
boty    ->  ▁bo    ty
botami  ->  ▁bota  mi
botách  ->  ▁bot   ách

Here, boty splits on ▁bo, sharing no common fragment with bota. It’s highly irregular and changes on a word-by-word basis. Case sensitivity makes it worse: Schuhe splits into Sc ##hu ##he, but lowercase schuhe becomes s ##chu ##he. Any minor tokenizer or model update invalidates your entire index and forces a complete rebuild.


6. It breaks BM25 scoring statistics. BM25 assumes terms are meaningful words. It uses document frequency to judge importance and doc length to normalize scores fairly (Robertson & Zaragoza, 2009; Singhal et al., 1996). Subwords break these math assumptions. Common fragments like ##er or ##ny show up everywhere, acting as noisy, invisible stopwords. Long words break into multiple fragments, falsely inflating a document’s length and messing up BM25’s length normalization.


7. Bag-of-fragments loses word structure. An inverted index records which subwords exist, not the order they were assembled in. Words made of similar fragments become impossible for the engine to tell apart once their unique lexical identity is stripped.


8. Important technical terms and brands dissolve. High-precision search terms like model numbers and brand names fragment aggressively:


Sennheiser  ->  Sen  ##nh  ##eis  ##er
Kärcher     ->  K    ##är  ##cher
Zanussi     ->  Za   ##nus  ##si
IPX7        ->  IP   ##X   ##7
65W         ->  65   ##W

A premium brand becomes a handful of generic, low-information fragments. A waterproofing rating becomes IP, ##X, and a digit. A power supply becomes a number and a letter shared with every other charger. You lose exact-match precision on technical specifications — the one thing lexical search was perfect at.


The verdict



Fragment indexing gives you the illusion of stemming without any of the linguistic intelligence. When a dictionary stemmer fails, it fails predictably — a missing word you can easily add.

Fragment tokenizers fail silently, creating bad matches based on random statistical correlations in a training set. You gain a little recall at the cost of massive, unpredictable precision loss.


The shortcut is a dead end. But the core intuition is still valuable.


The reason it fails is simple: a file-compression algorithm chose the vocabulary fragments to save space, not to understand meaning. An inverted index over vocabulary terms isn’t a bad architecture. If a machine learning model selected which vocabulary terms to activate for a document — and weighted them appropriately — we could keep the speed and precision of an inverted index while gaining true semantic matching. That system exists: it’s called learned sparse retrieval, and we’ll look at it at the end of this chapter. But first, let’s look at what happens when we use dense vectors instead.



What is a dense embedding?


Before we look at where dense vectors fail, we need a clear picture of what they actually are and how we search with them.


A dense embedding is simply a list of real numbers (a vector) of a fixed size — typically 768 or 1024 dimensions. When we pass a product description or a search query through an embedding model, the model compresses the text’s semantic meaning into these coordinates.


Imagine it as a map. On a standard 2D map, two cities with similar climates or locations sit close together. A dense embedding space is just a 1024-dimensional map. Words and phrases with similar meanings (like "shoes" and "sneakers") are projected to nearby points in this high-dimensional space, even if they share zero characters.


Scoring and geometry


To search, we embed our product catalog once and store the vectors in a database. When a user types a query, we embed their search query on the fly and compare it against our product vectors.


We score relevance using geometric distance — usually cosine similarity or inner product (dot product). If the angle between the query vector and a product vector is small, they point in the same direction, meaning they are semantically similar.


With this foundation in place, let’s look at how this geometric approach runs into trouble.



Polysemy and query ambiguity


Lexical engines match characters; vector models try to match intent. But when users search using short queries, double meanings (polysemy) create massive confusion.


Take the Czech word "baterie". It means two entirely different things: an electrical battery (like AA cells or power banks) and a plumbing mixer tap (faucets for kitchens and bathrooms). (Another fun one is "kohoutek", which has three meanings: a rooster, a plumbing valve, and a gun trigger.)


In natural language, the surrounding words make the meaning clear. A query like "baterie do koupelny" (bathroom mixer tap) has plenty of context for a vector model. But a bare search for "baterie" has no context at all. The embedding model is forced to output a vector that sits right in the middle of these unrelated product categories — a useless average centroid.


Dense vector search ambiguity: the bare query "baterie" lands in a useless centroid between electrical batteries and mixer taps, while "baterie do koupelny" adds context.

Why short queries hurt vector search


For decades, search engines trained users to think in short keywords. This lack of context is a major problem for dense vector search. Real-world studies confirm that typed searches remain short, 2-word fragments across all age groups. Spoken or conversational queries provide rich context, but standard typed inputs don’t give the model enough signal to figure out which “baterie” the user wants.



Long, conversational queries are great for dense vector models — they provide the context needed to resolve ambiguity.Short keyword queries are the worst-case input for vector search, offering zero clues to resolve overlapping meanings.


You can patch this by wrapping your search engine in external personalization layers, click-stream tracking, or session history. But these are external band-aids, not features of the vector space itself.



Multilingual search: capacity, costs, and collisions


Multilingual models promise search across languages without needing explicit translation. But in production, they introduce three serious architectural trade-offs.


1. The curse of multilinguality


First identified in XLM-R (Conneau et al., 2019), the Curse of Multilinguality states that sharing a fixed model size across $N$ languages degrades the quality of each individual language. In e-commerce, this means the model loses the ability to distinguish subtle product attributes, technical specs, or color variants.


Benchmarks show a clear performance penalty:


  • On a Eurostat-provided dataset of ~112k multilingual job ads, a de-duplication study found that translating text to English first and then embedding with a monolingual model easily beat a native multilingual model (82% vs. 60% F1), especially on smaller languages.


  • Retrieval benchmarks on Amharic showed that the top multilingual model fell 23% short of the strongest monolingual model, and fine-tuning couldn’t close the gap.


  • Chang et al. (EMNLP 2024) confirmed that even high-resource languages suffer a retrieval penalty when trained in shared multilingual models compared to dedicated monolingual baselines.


2. Large models and slow queries


The only way to fight this quality loss is to use much larger models. But larger models require more memory and introduce higher search latency. Teams are forced into a tough trade-off: accept lower search accuracy or pay for expensive GPU-heavy infrastructure to keep queries fast.


3. Shared vocabularies and homograph collisions


Multilingual models share a single vocabulary across every language they support. If two languages spell different words exactly the same way, the tokenizer treats them as the exact same token ID.


This is a fundamental issue. Unlike subword fragmentation, these are real, whole words that share spelling across languages. They are indexed as a single token in almost all vocabularies:


Czech

Meaning

English homograph

police

shelf

police (law enforcement)

plot

fence

plot (story / land)

led

ice

LED (lighting)


Grammar forms don’t help much either. The plural Czech form of fence (ploty) tokenizes to plot ##y, meaning the English word plot still collides with the Czech root.


The led example is especially tricky because it affects single-language stores too. Czech stores sell led (ice) and LED lights, so both appear in their catalogs. While capitalization can distinguish them, most search pipelines lower-case text before matching (Devlin et al., 2019). Once collapsed, a search for light strips vs. ice packs becomes completely indistinguishable to the model.


4. Normalization creates brand new collisions


Lowercasing and stripping accents (ASCII folding) make things worse. In Part 1, we saw that stripping diacritics collapses different Czech words like pas (passport) and pás (belt), creating ambiguity. In a multilingual space, folding creates silent misdirection.


Take these three everyday Czech catalog nouns and watch what happens when you strip diacritics:


ASCII folding in multilingual vector search: Czech rám, trám and míč become ram, tram and mic and match computer RAM, a model tram and a microphone.

Before folding, they are distinct. ASCII folding creates the collision.


The consequence is worse than simple ambiguity. Instead of showing a mixed result list, the model gets confident about the wrong meaning. Because English is heavily over-represented in multilingual training data (English has 43 times more tokens than Czech in Google’s mC4 corpus (Xue et al., 2021)), the English meaning wins.



The query vector completely moves to the English cluster: picture frames show up next to computer RAM, wooden beams next to model trains, and footballs next to microphones. Lowercasing and diacritic folding are not “free” cleanups. They are lossy changes that construct brand new collisions — and in vector search, these failures happen silently.


Additionally, catalogs change constantly. Re-embedding large product inventories to keep vector indexes fresh adds a permanent, heavy compute cost to your data pipelines.



Multimodal alignment and the “modality gap”


Multimodal models (like CLIP) project text and images into a shared vector space. This lets users search for visual styles (like patterns or cuts) without needing manual descriptive tags.


While this sounds perfect, real-world retail deployments run into two major walls.


1. Customers don’t search with images


While retail executives love the idea of visual search, actual shopper behavior shows almost zero organic adoption. Customers rarely upload images during standard browsing sessions; they type text.


2. The modality gap and ranking bias


Even when text and images share a vector space, they don’t truly mix.


  • Separation in space: Liang et al. (2022) showed that image vectors and text vectors naturally group into separate, non-overlapping regions — a problem known as the modality gap that exists even in untrained models.


  • Alignment errors: Jina AI points out that an image of an orange in a CLIP model is often closer to an image of an apple than to the text phrase "a fresh orange".


  • Ranking bias: Li & Zhang (2025) proved that this gap causes models to prioritize matching the query’s input type. An image query will favor image matches over hghly relevant text descriptions, breaking mixed search results.



The query-document length mismatch


Search queries and product pages are completely different shapes:


  • Over 75% of e-commerce queries are under four words (Constructor.com).

  • Product pages contain long descriptions, detailed specifications, and shipping policies.


If you feed both short queries and long descriptions into a single, symmetric model, you get a density mismatch. A 3-word query vector has very little information, while a 150-word product description vector is an average of twenty different features. The specific product details get washed out in the averaged vector.


The standard solution is an Asymmetric Dual-Encoder Architecture (like Facebook’s DPR, Karpukhin et al., 2020), which uses separate encoder networks for queries and documents. However, these systems require complex alignment training to map the two networks together (SamToNe, 2023). If you use a standard symmetric encoder out-of-the-box, you inherit this averaged-out mismatch by default.



Facets, filters, and the ANN conflict


At scale, looking up exact vector matches is too slow. Vector databases use Approximate Nearest Neighbor (ANN) index graphs (like HNSW or IVFFlat) to find nearby vectors quickly.


But when you mix these fuzzy spatial graphs with strict database filters (like brand, price range, or stock status), you get a major architectural clash:


Vector database filtering in e-commerce search: pre-filtering strands the HNSW graph search, post-filtering leaves an empty or tiny result page.

1. Pre-filtering breaks the graph


Pre-filtering filters your catalog metadata first, then runs the vector search on the matching items. But as filters get narrow (like looking for a specific size or price range), you delete nodes from the HNSW graph. This breaks the graph’s connections (Curator, 2026). The vector database’s search algorithm gets stranded in a disconnected subgraph, failing to find highly relevant products that are structurally unreachable.


2. Post-filtering shrinks results


Post-filtering runs the vector search first to get the top 100 results, then applies the filters. But if the top 100 matching products don’t pass your filters (e.g., they are out of stock or out of the price range), you end up with almost no results. OpenSearch’s documentation warns that post-filtering regularly returns empty or undersized result pages under common metadata filters.


3. The limits of filtered graph traversal


Comprehensive benchmarks of vector filtering (arXiv:2602.11443) prove that no single filtering strategy maintains both fast search speeds and high recall across all filtering ranges. Advanced systems — like Qdrant’s filterable HNSW, ACORN, and UNIFY — trade high indexing times and massive memory footprints to preserve graph edges, but the tension between strict database rules and fuzzy graphs remains a fundamental challenge.


Because e-commerce interfaces rely on facets and sorting, metadata filtering exposes a severe structural limit of vector databases.



Why typos break vector search


Vector search is great at finding synonyms, but terrible at handling typos. The reason goes back to subword tokenization.


Traditional text search matches characters directly, so a 1-character typo causes a small, predictable change in search score. Subword tokenization has no such safety net: it looks up fragments in a fixed vocabulary. A single misspelled letter completely changes how the word is segmented:


Why typos break vector search: misspelled "notebok" and "Senheiser" split into new subword tokens that share nothing with notebook and Sennheiser.

A single missing letter changes the entire fragment sequence. The model gets fed fragments that belong to completely unrelated contexts, and the query vector shifts to an entirely unrelated region of the vector space. The penalty is highest on brand names and technical specs — exactly where users make typos most often.



This is the exact same failure as the false-match problem, just in reverse. Subword tokenizers make completely unrelated words look similar, and make slightly misspelled words look completely different.



EMNLP Findings 2024 documents that subword tokenizers consistently split misspelled words into random, low-frequency fragments across major LLM families.


While pre-training techniques like BPE-Dropout (Provilkov et al., 2020) help, they must be built into the model from day one. You can’t configure them after the fact as a search engineer. Traditional edit-distance math remains structurally more robust than subword tokenizers — making it one of the few areas where the lexical index isn’t just cheaper, but genuinely better.



Deep vector information loss


The fundamental limits of dense vector search come down to three structural ways it loses information.


Dense vector information loss: cosine similarity squashes 1024 dimensions into one score, embeddings ignore NOT, and ANN graphs miss 10–27% of nearest neighbours.

1. Vector math squashes detail (cosine similarity)


Calculating cosine similarity takes thousands of dimensions of meaning and squashes them into a single decimal number between -1 and 1:


cosine similarity of u and v equals u dot v divided by the length of u times the length of v.

This projection deletes feature details. You get a single final score but have no idea which features drove the match, or whether the score represents a confident semantic match or just noisy background alignment.


Because of this, there is no single “golden threshold” score to filter out bad matches across a catalog. Walmart’s research team (Rossi et al., 2024) proved that flat cosine thresholds fail to filter out irrelevant products because vector density varies wildly across product categories. Their fix — a learned “Cosine Adapter” — requires training another model to predict query boundaries, trading recall to save precision. Additionally, cosine normalization throws out vector magnitude (arXiv:2504.16318), discarding density signals hidden in the length of the vectors.


2. Models can’t understand “not” (negation)


Vector embeddings represent the presence of attributes. They have no natural way to represent exclusion or Boolean NOT operations.


If you search for "yellow hoodie, not blue", contrastive models (like CLIP) often fail to push the blue items away. As Ngan et al. (2025) show with their SemCLIP model, contrastive training prioritizes token co-occurrence over logic, keeping "not X" closely grouped next to "X". While common phrases like "lactose-free" are learned as single concepts, unobserved negative queries ("wool-free blanket", "bra without underwire") fail to exclude attributes without an upstream parsing rule.



3. Approximate graphs miss matches


ANN search trades accuracy for speed. Benchmarks by OpenSourceConnections (2025) show that under typical production settings, graph traversal misses 10% to 27% of your true nearest neighbors entirely.


Silent failures are hard to debug


Text search fails loudly: a missing synonym or mismatched filter returns an empty page — a clear signal that something needs fixing.


Vector search fails silently: a squashed similarity score, ignored negation, or truncated graph search returns a full page of professional-looking but completely wrong products, raising zero system errors.


Full-text search fails loudly with 0 results for "obuv", while vector search fails silently with a full page of wrong products and no errors.


The hidden operational tax: document engineering


Moving to vector search doesn’t get rid of manual work — it just moves it from query-side dictionary tuning to document-side text engineering.



Most semantic-search guides talk about similarity thresholds and vector tuning as if the vectors simply exist. They ignore where the vectors come from. But the vector is the document as far as the search engine is concerned. If you feed the model bad text, no amount of advanced reranking or hybrid fusion can recover what was never encoded in the first place.


Building the vector requires a complex data pipeline: extract text from products, decide what fields to include, generate the vectors, and keep them in sync as products update. You can’t just throw raw data at the model:


  • Short titles (“Nike Air Max”) lack the detail needed to generate a rich, unique vector representation.


  • Long descriptions introduce noisy marketing copy, shipping details, or unrelated cross-sells that pull the vector away from the product’s actual category.


  • JSON metadata concatenation (joining brand, title, and specs) requires careful formatting and prompt engineering to make sure the model weights key attributes correctly.


The claim that vector search eliminates manual rule curation ignores the work needed to clean and prepare catalog text. Embedding quality is capped by catalog quality: real-world product data is riddled with incomplete titles, noisy marketing copy, and inconsistent attributes — especially across multi-merchant marketplaces — and a model retrieves only as well as the text it was fed. Instacart found that naively training an embedding search model on this kind of noisy real-world data actively degraded relevance, forcing a data-quality-aware training pipeline to recover it (Xie et al., 2022).


Unlike text synonym lists, vector text quality has no simple debug log, making embedding pipelines harder to verify. But the trade-off is clear: vector search replaces never-ending manual synonym updates with an upfront, automated data cleaning pipeline. Designing and validating your catalog embeddings is highly rigorous, but it is a one-time schema setup rather than a permanent operational tax.



Learned sparse retrieval: SPLADE


This chapter opened with a subword tokenization shortcut that failed for a very specific reason: the vocabulary was chosen by a file-compression algorithm to save disk space, not to represent meaning. This caused unrelated words to collide and ruined scoring math.



The failure was in how the subwords were chosen, not in the idea of indexing vocabulary entries. Learned sparse retrieval replaces the file compressor with a neural model. The model reads the full text, then decides which vocabulary terms the document should occupy and how much weight they should get. The output is a sparse vector over a fixed vocabulary, stored in a standard inverted index, and scored via a simple dot product over posting lists.


From compression to selection


SPLADE (Formal et al., 2021; v2, 2021) achieves this by reusing a standard Transformer module: the masked-language-model (MLM) head. It projects each word’s representation onto the model’s entire vocabulary (typically around 30,000 dimensions). It applies a ReLU function to drop negative weights, dampens dominant terms with a logarithm, and pools weights across the sentence:

w sub j equals the maximum over all tokens i of the log of 1 plus ReLU of logits i j

This creates two critical benefits. First, the output spans the entire vocabulary, not just words in the input. The model can assign weights to terms that never appeared in the text. This is term expansion, and it’s what the simple token shortcut could never do. Second, a sparsity penalty during training (Paria et al., 2020) forces most of these weights to exactly zero, leaving a tiny set of activated terms that fit perfectly into standard search engine posting lists.


Because the active dimensions are real vocabulary words, the index remains completely human-readable. The weights below were produced by running the public checkpoint naver/splade-cocondenser-ensembledistil (Formal et al., 2021); bracketed terms are expansions added by the model.


What learned sparse retrieval recovers



1. Semantic, readable expansion. Instead of matching based on letter overlap, expansions are chosen by semantic relationships:


Dense vector vs. learned sparse retrieval (SPLADE): readable term expansion for "bathroom mixer tap" and visible ambiguity for "led".

A faucet search automatically activates posting lists for “bath”, “shower”, “wash”, and “spray”. There are no manual synonym tables; the terms are placed directly in the index, where the search engine can match them.


2. True morphological grouping. Instead of relying on compression fragments, the model unifies plurals, prefixes, and root-shifted inflections naturally because they share meaning: shoes → [shoe], running → [run], battery → [batteries]. It links roots natively without breaking on mutations like vůz/vozu.


3. Clear, legible ambiguity. This is the biggest difference between sparse and dense models: when a sparse model gets confused, the failure is visible. Take the ambiguous word led (past-tense verb vs. lighting technology).


Both meanings are present with different weights. The model hasn’t completely resolved the conflict, but an engineer can inspect the posting list, see that a lighting query activated lead and leader, and adjust it. In a dense model, this confusion is locked inside an unreadable high-dimensional coordinate space. Learned sparse retrieval restores the debugging transparency that teams value in text engines.


4. Simple index architecture. Because this runs on a standard inverted index, we escape the limitations of dense vector databases. There is no ANN graph, which means the pre-filtering/post-filtering conflict disappears. Metadata filters are 100% exact, facets compute over the full candidate set, and technical specs keep their precise tokens. Furthermore, its zero-shot search quality beats dense models on standard out-of-domain benchmarks like BEIR, where dense models tend to struggle (Formal et al., 2021; Thakur et al., 2021).


For enterprise e-commerce search, this is a much better starting point than dense retrieval. But it is still not a complete solution.


Where SPLADE breaks


1. Public training models pollute the catalog. Off-the-shelf models expand words based on web text, not product catalogs. Look at what a general model does to a simple product query:


Out-of-the-box SPLADE expansion for "battery": 8 of the top 11 terms are personal names from web text, so fine-tuning on the product catalog is required.

Eight of the top eleven expansions are personal names. Because the model was trained on MS MARCO (a web text dataset) (Bajaj et al., 2016), “battery” is closely linked to historic figures (Benjamin Franklin), battery-related names, and baseball terms. A generic product search for picture frame behaves the same way, expanding to [parker], [clark], and [turner]. Out of the box, public models will fill your index with irrelevant web noise. Fine-tuning on actual e-commerce data isn’t an option; it’s a hard requirement.


2. Category queries favor specific brands. This has major commercial consequences. Generic searches expand to specific brands: running shoes expands to nike at 0.56 and jordan at 0.47; smartphone expands to apple at 0.77.



Because search engines score based on shared terms, adding “nike” to a generic query boosts Nike products above all competitors, even though the user didn’t ask for a brand. The model is essentially handing a competitive advantage to one brand based on web frequency — and inconsistently: searching for "trainers" instead of "sneakers" produces no brand expansions at all, making these biases incredibly hard to predict or audit.


SPLADE brand bias in e-commerce search: "running shoes" expands to Nike and Jordan, "smartphone" to Apple, while "trainers" expands to no brands.

3. Negative constraints are inverted. Just like dense models, sparse expansion cannot handle logical negation:


Negation in sparse retrieval: in "wool-free blanket", "shoes without laces" and "yellow hoodie not blue", the excluded word gets one of the highest weights.

The exact word the shopper wants to exclude ends up with the highest weight in the entire representation. Studies show that essentially all neural retrieval methods — dense, sparse, and cross-encoders alike — perform at or below a random baseline when distinguishing documents based on negation (Weller et al., 2023). Handing logical exclusion to the retrieval index is a mistake; it must be handled by an upstream parser.


4. Numeric specs get fuzzy. Sparse models treat numbers as vocabulary terms. A search for a specific spec expands to neighboring values: 65w usb-c charger activates [45=1.51], and ddr5 32gb activates [33=0.82]. The model is asserting that a 45W charger is a close semantic match for a 65W search. This fuzziness makes technical specs and numeric constraints impossible to handle using sparse embeddings alone.


5. Query times slow down on short inputs. Expansion makes retrieval work, but it’s expensive. A 1-word query expands to 57 active posting lists, while a long 23-word description yields about 90.


This direction is painful. Short queries expand the most, yet short queries represent 75% to 90% of all e-commerce traffic. A simple search for “shoes” suddenly hits fifty different posting lists rather than one, many of them incredibly long lists that your engine now has to traverse. Newer models try to optimize this by putting all expansion on the index side and leaving queries unexpanded (SPLADE-v3, 2024), trading query speed for massive index sizes.


The models don’t exist for most languages


While dense multilingual models are abundant, public sparse models are incredibly rare. A survey of the Hugging Face Hub in August 2026 found only a handful of language-specific sparse models (for French, Polish, and Japanese). Most are research prototypes with single-digit download counts.


OpenSearch’s neural sparse model is the only one with meaningful adoption, and its downloads sit three orders of magnitude below standard dense models. For Czech, there is no public sparse model at all. Training a sparse model from scratch is a major machine learning project, requiring massive in-language datasets, negative mining pipelines, and validation systems.


Late interaction models: ColBERT


A third approach sits between dense and sparse search. ColBERT-style models keep separate vectors for every token in a document rather than compressing them into a single vector, calculating relevance using “late interaction” (Khattab & Zaharia, 2020; ColBERTv2, 2022).


This preserves token-level details, solving the query-document length mismatch: a 3-word query matches its individual words against a 150-word description perfectly. The trade-off is index size and query complexity. Storing a separate vector for every single token dramatically increases storage costs, even with ColBERTv2’s advanced compression. And because it still relies on vector geometry, it inherits dense search’s issues with negation, filters, and facets.


One model, three output shapes: BGE-M3


BGE-M3 (Chen et al., 2024) is a unique multilingual model that outputs all three representations from a single backbone: a dense vector, a late-interaction multi-vector, and a sparse representation. For engineering teams, this simplifies infrastructure dramatically.


But its sparse output is not SPLADE-style term expansion. Instead of projecting tokens onto the entire vocabulary, BGE-M3 computes lexical weights by projecting token states down to a single score (Chen et al., 2024, §3.1) — one weight per input token. It cannot assign weights to words that weren’t in the original text because it has no vocabulary projection.


This is learned term weighting, a smart replacement for BM25’s raw word counts, but it doesn’t solve the vocabulary mismatch problem. If a query says “obuv” and the catalog says “sandály”, BGE-M3’s sparse branch won’t connect them. Connecting them falls entirely to the dense branch, inheriting all the dense vector limits we’ve detailed.


Using one model for all three branches also means you are locked into a single tokenizer, a single quality profile, and a single training distribution. And combining these three scores into a single ranking page introduces its own set of challenges, which we’ll cover in Part 3.



Summary


Dense retrieval solves the core problems of full-text search. Synonyms, grammar inflections, and languages map together naturally without needing massive manual dictionaries. This is a massive step forward, and no e-commerce team should ignore it.


But it doesn’t eliminate manual operational work — it just changes its nature. Full-text search failures are loud and explicit: a missing synonym or misspelled term returns an empty page, telling you exactly what to fix. Vector search failures are silent and fuzzy. An ambiguous query averages into a centroid between unrelated categories. Similarity scores are compressed into a single decimal number, making it impossible to explain why a product matched. Negated terms return the very items they tried to exclude. Database filters break graph paths, hurting recall. ASCII folding silently redirects queries into another language’s domain. In every case, the system returns a populated, professional-looking page of completely incorrect products. You trade a predictable text maintenance tax for a silent, un-debuggable vector failure surface.


Learned sparse retrieval (like SPLADE) is the most promising bridge between these two worlds. By using models to select vocabulary terms for a standard inverted index, it restores exact database filtering, accurate facets, and legible, human-readable posting lists. You can read the expansions directly, making failures visible and easy to debug. It works incredibly well for English, but it is still not a silver bullet. Expansion introduces web-corpus noise and unfair brand biases, negation still fails, specs get fuzzy, and models simply do not exist for most languages.



Full-text search matches letters without understanding meaning. Dense search approximates meaning but loses exact boundaries. Sparse search restores boundaries but struggles with context and logic. Neither engine is sufficient on its own, and they fail in completely complementary ways. This is why the standard industry answer is to run both and merge their results.



Next in this series — In Part 3, we’ll look at the math and realities of combining these two engines, and explore whether hybrid search truly blends their strengths or simply stacks their failures behind a wall of complex hyperparameters.



Sources

 
 
bottom of page