Vector Search vs Keyword Ranking on a Store: What Each One Misses
Add vector search to a store and the demo is always magical: a query with none of the catalogue's words returns the right products. Run it for a month on real traffic and the other half of the story arrives: model numbers that return vibes instead of the exact part, brand searches that wander, and a ranking nobody on the team can explain or tune. Keyword and vector search fail in opposite directions, which is why serious stores run both.
What keyword search is genuinely good at
Exact things. SKUs, model numbers, brand names, sizes, and the specific nouns a catalogue uses: a customer typing the words printed on the box should get that product first, instantly, every time. Keyword ranking is also debuggable. When the wrong product wins, an engineer can see the token match and the field weights and fix it before lunch.
Its failure is vocabulary mismatch. The customer writes sofa, the catalogue says couch. The customer describes a use, gifts for a dad who grills, and no product title contains those words at all. Synonym lists patch the common cases one by one and never catch up with how people actually describe what they want.
What vector search adds, and its blind spots
Embeddings map queries and products into a space where meaning, not spelling, sets distance. Use based queries, synonyms nobody listed, and cross category discovery all improve, sometimes dramatically, on catalogues with rich descriptions for the model to read.
The blind spots are exactness and control. A vector index can rank a near identical wrong model above the right one because the descriptions are semantically close, and it will do so confidently. Sparse catalogues with thin, templated product copy give the model almost nothing to embed, and results degrade into a popularity sort wearing a lab coat.
Blending is an engineering decision, not a toggle
Working setups typically run both retrievers and merge: keyword results guaranteed for exact matches, vector results filling the semantic gaps, with a reranker ordering the union. The merge weights are where the store's judgement lives, and they differ by query type, which means query classification, navigational versus exploratory, has to happen before retrieval, not after.
Someone has to own the failure log. Zero result searches and reformulated queries reviewed weekly will tell you which retriever is failing on your catalogue's actual language, which no vendor benchmark can.
Judge it on your hardest queries
Do not evaluate search on your top fifty queries. Those work under any system. Build the test set from the long tail: the misspellings, the use cases, the model numbers, the gift descriptions, the queries that returned nothing last quarter.
That is where the money is hiding, and where each technology's real character shows.
Keep reading
Related guides on this site: Search Synonyms: The Quiet List That Decides Whether Your Store Search Understands Anyone Seasonal Boosts in Search Ranking: Turning Them On Is Easy, Expiring Them Is the Job Practical answers about personalization.
Frequently asked questions
What is vector search in ecommerce?
Search that matches meaning instead of exact words, using embeddings of queries and product text. It handles synonyms and use based queries well, but can be imprecise on exact identifiers like model numbers.
Should a store replace keyword search with vector search?
Rarely. The two fail in opposite ways, so most effective setups blend them: keyword retrieval guarantees exact matches while vector retrieval covers vocabulary gaps, merged by a reranker.
How should search quality be tested?
On the hard long tail: misspellings, zero result queries, model numbers, and descriptive use case searches from real logs, not on top queries that every system answers well.