Semantic Search vs. Keyword Search
Keyword search finds text; semantic search finds meaning. When to use each, how to combine them and what it means for the UX of search results.
What does each one do?
Keyword search, also called lexical search, scores documents by how the query terms appear in them. A classic algorithm of this kind is BM25, which combines three ideas: how many times the term appears in the document, how rare that term is across the whole collection (rare terms weigh more), and the length of the document (so a long text does not win just for having more words). It treats text as a bag of words: word order and meaning are ignored. Many search engines add rules to tolerate variants, such as plurals or verb forms, but a completely different synonym is left out.
Semantic search uses vector representations, that is, embeddings, to compare the query with documents. If a user types “how to make an app feel fast while it loads”, it can find an article titled “perceived performance and skeletons” even though the two share almost no words.
How does semantic search find results?
A model turns each document, or each fragment of a document, into a list of numbers: a vector. Texts with similar meaning end up with nearby vectors. When a query arrives, it is converted with the same model and the system returns the closest vectors, usually measured with cosine similarity. Those vectors are stored in an index, sometimes in a vector database. It is also the first half of a RAG system: before the model answers, the relevant fragments are retrieved.
Two consequences matter for design:
- There are always “the closest ones”. Even when the query has nothing to do with the content, the system can return the ten least distant vectors. Without a similarity threshold, users get results that look like an answer when nothing relevant exists.
- The result depends on the model. A model trained on little Spanish, or with no knowledge of your domain, can mix terms that your users see as very different. Results change if you change the model.
Why does this matter to a designer?
Because search is an interface, and the way it finds results changes what users expect:
- Natural language. People type the way they talk. Semantic search tolerates that style better than a search that demands exact words.
- Surprising results. A result without the typed word can be a hit or noise. If there is no way to see why it appeared, users doubt the system.
- Names and codes. A user who searches “SKU-4471” wants that exact item. Semantic search may return “similar” products, which is exactly what they do not want.
- Filters and facets. Neither replaces filters when users know precisely what they want.
When should you use each one?
| What the person is looking for | Better option | Why |
|---|---|---|
| A code, an order number, a proper name | Keyword | It has to match literally |
| An error or an exact technical term | Keyword | The query already contains the right words |
| A question in natural language | Semantic or hybrid | The content may use other words |
| A vague topic, “something about…” | Semantic or hybrid | Meaning matters, not the term |
| Not known in advance | Hybrid | Covers both cases |
When NOT to use semantic search?
When exact precision is the requirement: finding a contract by number, an email by sender, an error code in a log. In those cases keyword search is more predictable, cheaper to maintain and easier to explain. Adding embeddings without need brings indexing costs and a new source of errors.
What is hybrid search and how do you show it?
In practice, many products combine both. They run a lexical search and a semantic one, then merge the results with a ranking rule. A widely used rule is reciprocal rank fusion (RRF): each document gets a score of 1 divided by a constant plus its position in each list, and the scores are added up. Because it works with positions and not with the original scores, there is no need to compare scales that are not comparable. Elasticsearch and OpenSearch both document it, and in Elasticsearch the constant defaults to 60.
The benefit is that exact identifiers rank at the top while natural-language queries still find related content.
As a designer, the product question is how that merge is shown. Are results split into “exact matches” and “related”? Is the reason explained, for example by highlighting the words that matched or showing the fragment? A simple label usually prevents a lot of confusion. It is also worth deciding what happens when nothing is close enough: an honest “no results” message is better than ten doubtful results. The same problem comes back in AI search and its impact on UX and in conversational search.
Example
Illustrative example: a support knowledge base has 2,000 articles. With keyword-only search, a user who types “the code never reaches my email” does not find the article titled “email account verification”, because they share no terms. With hybrid search, it appears. But if someone searches “error 4031”, they want that exact code; the team decides codes are always searched lexically, and semantic results appear below under “Related topics”.
Common mistakes
- Replacing keyword search with semantic search without checking what happens to codes and names.
- Evaluating quality with queries the team already knows by heart, instead of real user queries.
- Showing semantic results without indicating why they appear.
- Setting no similarity threshold, so results always show even when they are not relevant.
- Forgetting that semantic search must reindex when content changes.
- Assuming “semantic” means “understands”. It is an approximate comparison of meanings.