A customer types "my package never showed up". Your help centre has a page called "Lost or missing deliveries". It contains none of those words.
Keyword search finds nothing. Semantic search finds it immediately. That one example is why meaning-based search took over, and it is also only half the story, because the next customer types a SKU.
Four queries, two engines
What each one is actually doing
Keyword search compares strings. It builds an index of which documents contain which words, ranks by how unusual a word is and how often it appears, and returns documents that literally contain what you typed. It has no idea that a parcel and a package are the same thing.
Semantic search compares meaning. Every passage is turned into a list of numbers that encodes what it is about, the question gets the same treatment, and the system returns the passages whose numbers sit closest to the question's. Nothing is matched literally, which is the whole point and the whole risk.
The last row is underrated. A keyword search that fails fails visibly, with nothing on the page. A semantic search always returns its closest matches, so a failure arrives looking like a result. That is what people mean when they say a vector search "confidently returned the wrong thing".
Where meaning-based search genuinely changes the job
Three things stop being your problem.
Vocabulary mismatch: customers say "it broke", your docs say "fault diagnosis", and the gap no longer needs a synonym list somebody maintains forever. Phrasing: eleven ways to ask about refunds all land on the same page. And language: a question typed in Spanish can find a passage written in English, which is why a multilingual assistant does not need eleven translated knowledge bases to be useful on day one.
That last one is the biggest practical win for anybody selling across borders, and the one most comparisons leave out.
Where it breaks, and what to do
The failures are predictable, which makes them manageable.
- Identifiers. Order numbers, SKUs, error codes, part numbers. Meaning does not apply to them, so they need literal matching.
- Proper nouns that look like other proper nouns. Two product lines with similar names end up near each other in meaning space.
- Negation and exclusions. "Not covered by the warranty" and "covered by the warranty" are close in meaning and opposite in fact.
- Numbers and thresholds. "Free over $80" and "free over $150" look almost identical to a model that is reading them as meaning.
Writing helps with three of the four: state the subject, keep the rule and its exception in the same passage, and write numbers with their unit and condition. The first one is not a writing problem at all, which brings us to how real systems solve this.
Which is why serious systems run both
The practical answer is not to choose. Run keyword and semantic retrieval together, then merge the two result lists so a passage that both methods liked ranks above one only a single method liked.
That is hybrid retrieval, and it exists because of the four queries above: you need the engine that finds "lost or missing deliveries" from "my package never showed up", and you need the engine that finds exactly RG-2201-BLK. A system with only one of them is wrong in a way its owner cannot see until a customer reads a code aloud.
Type an exact code from your catalogue and then type a paraphrase of a common question. If the code works and the paraphrase does not, you have keyword search. If the paraphrase works and the code returns four similar products, you have vector search alone. If both work, somebody did the hybrid work.
Questions people ask
Run the two-query test on whatever search you have today. It takes a minute, and it tells you which half of your customers' questions you are currently answering by accident.
welcomeai.devWhat is RAG? Retrieval-augmented generation explained
