- Published
- Updated
Semantic Search vs Keyword Search: How to Choose and When to Combine Them
Keyword search uses literal evidence. Embedding-based semantic search bridges vocabulary gaps. Learn where each fails and when hybrid retrieval earns its added complexity.
A user searches a help center for stop paying every month.
The help center has three pages:
- Cancel subscription
- Pause subscription
- Change billing cycle
All three pages relate to the query, but they describe different actions. The query does not say which action the user wants.
Keyword search uses shared terms as evidence. Semantic search can connect a query to pages that use different words.
Both methods can help. Both methods can also return a plausible but incorrect page.
How keyword search finds pages
Use a reverse word map as the basic model for keyword search:
cancel -> Cancel subscriptionpause -> Pause subscriptionmonthly -> Change billing cyclePLAN-4821 -> Change billing cycleKeyword search is also called lexical search. A lexical search system builds this map before users search.
When a query arrives, its terms point to pages with the same indexed terms.
This map is an inverted index . Real lexical systems use more evidence than simple term presence.
They can use the field, term rarity, and term frequency. They can also limit the value of repeated terms.
BM25 is one method for ranking lexical evidence. Keyword ranking starts with text shared by the query and page.
Keyword search is strong when literal text has important meaning:
- Plan IDs such as
PLAN-4821 - Product and model names
- Software versions
- Error codes
- Quoted phrases
- Commands and configuration keys
A search for PLAN-4821 must preserve the identifier. It must not depend only on a model’s idea of a billing concept.
The field and analyzer must keep the identifier intact. A general text analyzer can split or change it.
Keyword search is not the browser Find function
Keyword search does not always require identical character strings.
An analyzer can convert text to lowercase, split punctuation, stem words, or expand synonyms. Other features can correct spelling or permit fuzzy matches.
These features help, but they do not remove every vocabulary gap.
A rule can connect stop paying to cancel subscription. Users can also write end my membership or turn off renewal.
Known rules solve known differences. They become difficult to maintain for many forms of natural language.
Context also changes meaning. Cancel my trial and cancel my order share a verb but need different pages.
Semantic search addresses this vocabulary problem.
How semantic search connects related language
Semantic search uses meaning as search evidence. This article uses similarity between text embeddings as the semantic mechanism.
An embedding model converts each page passage into a numeric representation. It also converts the query into the same type of representation.
The search system compares the query embedding with the page embeddings. It retrieves the closest representations.
One number in an embedding does not represent a label such as “billing.” The complete embedding represents the text in a model-specific comparison space.
The model tries to put related uses near each other.
This article uses text embeddings for semantic retrieval. Vector search can also compare images, audio, and other data.For our query, semantic retrieval can show all three subscription pages. The pages do not need to contain stop paying every month.
The system can match the query to these pages even though they use different words.
However, semantic similarity cannot resolve the missing action. The query does not say whether the user wants to cancel, pause, or change the billing cycle.
Semantic retrieval can supply related candidates. It cannot create missing user intent.
The vector search guide explains embeddings and similarity in more detail.
Chunking defines the retrieval unit
The system must select the text unit before it creates embeddings. Many systems split long pages into passages called chunks.
Assume the cancellation guide contains these sentences:
Open Billing and select Cancel subscription.Cancellation takes effect immediately and removes remaining access.Different chunks can separate the action from its consequence. Search can retrieve the action without the warning.
Small chunks can make retrieval more specific. They can also divide one complete idea.
The system can attach nearby passages after retrieval. It cannot attach a passage that retrieval and context enrichment both omit.
Keyword search and semantic search compared
| Question | Keyword search | Embedding-based semantic retrieval |
|---|---|---|
| Main signal | Shared indexed terms and lexical evidence | Similarity between model-made text representations |
| Strongest uses | Names, IDs, versions, codes, phrases, and known terms | Paraphrases, natural-language descriptions, and vocabulary gaps |
| Possible misses | Useful pages that use different words | Literal details that have weak representation |
| Possible false matches | Pages with shared words but incorrect context | Pages with a related topic but incorrect action |
| Required system | Text analysis, lexical ranking, and usually an inverted index | An embedding model and similarity retrieval; often a vector index and chunks |
| Does a high score prove correctness? | No | No |
The two methods use different evidence. The better method depends on the words and intent in each query.
Similar does not mean correct
Related does not mean correct.Compare these queries:
cancel my subscriptiondo not cancel my subscriptionThe queries share nearly all words, but their requested actions are opposite. Lexical overlap alone does not solve the difference.
An embedding model can also place them near each other because both discuss cancellation.
Missing answers create another problem. Assume the user searches for transfer my subscription to another person.
The help center has no transfer page. Semantic retrieval can still return cancellation or billing pages because they are the nearest topics.
The nearest page is not automatically an answer.
A search experience can need a no-result response or a question for the user. It can also reject candidates below a tested threshold.
Keyword search has a similar failure. An old page can contain more exact terms than the current page.
Strong relevance evidence does not prove that a result is current or permitted. Filters and access controls must define the eligible documents.
Hybrid search uses both signals
Keyword and semantic retrieval fail in different ways. Hybrid search lets both methods supply candidates.
The result lists for our query can look like this:
| Rank | Keyword list | Semantic list |
|---|---|---|
| 1 | Change billing cycle | Cancel subscription |
| 2 | Cancel subscription | Pause subscription |
| 3 | Pause subscription | Change billing cycle |
These lists are examples. They do not describe one production system.
Use this simple model for the merge:
- Put the pages from both lists into one set.
- Remove duplicate pages.
- Give more value to pages near the top of both lists.
- Produce one combined shortlist.
The rule that combines lists is called fusion. A later reranker can examine the merged candidates and change their order.
Keyword and vector scores do not use one common scale. A keyword score of 8 and a vector score of 0.8 measure different things.
A system can combine ranks or normalize scores under a tested configuration. It can also apply weights or rerank the merged set.
Filters have a different purpose. They can define language, version, freshness, workspace, or permissions.
Some filters can operate before retrieval, and others can operate later. Access control must always remain a hard rule.
The system must enforce access control before it exposes a result to an unauthorized user or component.
A reranker cannot restore a page that both retrieval methods missed. A later stage can only reorder the candidates that it receives.Hybrid search can improve coverage, but it adds work:
- Another retrieval path to configure and observe
- A fusion or weighting decision
- More candidates and duplicate pages
- Possible latency, storage, and compute costs
- More query groups to test
The second retrieval path must produce a measured improvement that justifies this extra work.
Our BM25 in RAG article applies the same evidence problem to retrieve-then-generate systems.
When to use keyword search
Start with keyword search when literal text is the main evidence. It also fits collections with controlled terminology.
Keyword search is often a good first choice when:
- Users search for names, identifiers, versions, codes, or quoted text.
- The collection uses consistent terms.
- Synonyms and field rules cover important known gaps.
- Low latency and simple operations are important.
- Tests do not show a large vocabulary gap.
Keyword search can use carefully designed analyzers, fields, filters, and ranking rules.
When to use semantic search
Semantic retrieval helps when users describe a need with different words from the content.
It is useful when:
- Queries are natural-language descriptions.
- Writers and readers use different terms.
- Many phrases can express the same idea.
- A useful passage shares few terms with the query.
- Tests show that lexical retrieval misses useful candidates.
Do not assume that semantic-only retrieval is better than keyword retrieval.
Test exact identifiers, negation, missing answers, chunk boundaries, language coverage, and model changes.
When to use hybrid search
Use hybrid search when the same product receives both types of query.
A help center can receive how do I stop the next charge? and PLAN-4821. The first query benefits from semantic evidence.
The second query needs a preserved identifier.
Use hybrid search when each retrieval path finds useful evidence that the other path misses.
Keep the simpler method when one path already meets the target for the important query mix.
Use this decision rule:
Add another retrieval signal only when it fixes a measured evidence gap. The quality gain must justify the latency, cost, and tuning work.
How to evaluate the methods
Do not choose a search method from a few impressive examples. Build a test set from real query types.
Use three query groups.
1. Paraphrase queries
Use different words for the same need:
stop paying every monthend my plan permanentlypause payments for two months
These queries test vocabulary gaps and different user actions.
2. Exact-evidence queries
Use strings that must keep their literal form:
PLAN-4821- Product and model names
- Versions
- Error codes
- Commands and configuration keys
These queries test whether exact evidence survives retrieval and ranking.
3. Safety and constraint queries
Include these cases:
- Opposite instructions with similar words
- Queries with no answer
- Old-version traps
- Language constraints
- Permission-sensitive documents
- Important warnings near chunk boundaries
Label the useful results for each query. Then measure candidate inclusion and final rank.
This separates two failures:
- Retrieval failure: The useful page does not enter the candidate set.
- Ranking failure: The useful page becomes a candidate but appears too low.
Select metrics that fit the labels:
- Hit@k asks whether at least one required result occurs in the first k positions.
- Recall@k measures how many labeled results occur in those positions.
- Mean Reciprocal Rank gives more value to the first relevant result near the top.
- nDCG supports several results with different relevance grades.
Also measure P95 latency. This is the response time that 95 percent of measured requests do not exceed.
A relevance gain is not useful when the added response time exceeds the product’s latency target.
How to add semantic retrieval safely
Do not replace keyword search only because a semantic demonstration looks better. Start with measured lexical failures.
Use this sequence after tests show a candidate gap:
- Collect queries where keyword retrieval missed useful pages.
- Add semantic retrieval beside the existing lexical path.
- Compare keyword, semantic, and merged candidates for all query groups.
- Keep the second path only when its benefit justifies the measured cost.
A feature flag and a compatible lexical index can make rollback easier.
Do not move every query to semantic search. Preserve the exact and semantic evidence that real queries need.
Frequently asked questions
Is semantic search the same as vector search?
No. Semantic search uses meaning as evidence. Similarity between text embeddings is one common method.
Vector search can also compare images, audio, and other data.
Is keyword search only exact matching?
No. Keyword search can normalize text, use phrases, expand synonyms, and support fuzzy or spelling features.
Exact identifiers still need a field and analyzer that preserve them.
Is hybrid search always better?
No. It can add weak candidates, latency, storage, compute, and tuning work.
Use it when tests show that the second signal recovers enough useful evidence.
Conclusion
Keyword search and semantic search use different evidence.
Keyword search is strongest when literal text matters. Semantic search helps when users and writers use different words for the same need.
Hybrid search combines both signals when real queries need both.
The query stop paying every month has no guaranteed single answer. Better retrieval can show the three useful choices.
The search experience must still handle the ambiguity.
Choose the simplest retrieval method that preserves the necessary evidence. Add another signal only after measured failures show why it is necessary.
Next reads
What Is Vector Search?
Vector search finds related content by comparing embeddings. Learn how vectors, similarity, approximate nearest-neighbor search, and hybrid retrieval work together.
What is BM25? A Plain English Guide
BM25 is a keyword search ranking function that scores documents using term frequency, term rarity, and document length. Learn how it works, where it helps, and how it differs from TF-IDF.
BM25 in RAG: Why Exact Keywords Still Matter
Dense retrieval can miss error codes, identifiers, and exact phrases. BM25 gives RAG systems another path to the source evidence they need.