Keyword search finds documents that contain your words. Vector search finds documents that mean something similar. Hybrid search runs both and combines the results. For most product catalogs and document collections, hybrid is the safest choice, because each method fails in a way the other doesn’t. But hybrid costs more to build and tune, and for some data a plain keyword search is enough.
This article explains how each works in plain terms, where each breaks and how to decide. It is the thinking behind the search relevance work on my Search & Discovery page, and the implementation notes apply to OpenSearch and Elasticsearch.
The short version: keep keyword search for exact terms, add vector search for meaning, and test the combination on your own queries before you commit.
How each approach works
Keyword search (lexical, BM25)
The engine looks for the words in the query, scores each document by how often and how rarely those words appear, and ranks by that score. The standard scoring method is BM25. It is fast, cheap, predictable and easy to debug: you can see why a document ranked where it did.
Vector search (semantic)
A model converts text into a list of numbers, called an embedding, so that texts with similar meaning sit close together. Searching means converting the query the same way and finding the nearest documents. It can match “affordable laptop for students” to a listing titled “budget notebook for school” with no shared words.
Hybrid search
Run both, then merge the two ranked lists into one. There are two common ways to merge them:
Score normalization and weighting
Scale each method’s scores to a common range and add them with weights, for example 70% keyword and 30% vector.
Reciprocal rank fusion (RRF)
Ignore the raw scores and combine by rank position, so a document near the top of both lists wins. It needs less tuning and is a common default.
Where each one fails
Here is how the two behave on six typical queries. The pattern matters more than any single row.
“quiet dishwasher”
Keyword: ranks pages that mention “quiet” often, which may include “not quiet.” Vector: understands the idea, and is usually better.
“ZX-4500-B” (a part number)
Keyword: exact match, so it works. Vector: treats it as noise and often returns similar-looking numbers.
“sofa” when the catalog says “couch”
Keyword: misses unless you maintain synonyms. Vector: finds it.
“red shoes not leather”
Keyword: matches “leather” and ranks leather shoes first. Vector: often blurs the negation.
A typo: “samsng”
Keyword: misses unless fuzzy matching is on. Vector: often handles small typos.
“contract that lets us audit the vendor”
Keyword: misses if the clause says “inspect records.” Vector: finds the clause.
The pattern: keyword search is strong on exact tokens (part numbers, brand names, SKUs, quoted phrases) and weak on meaning. Vector search is strong on meaning and weak on exactness and negation. Real queries mix both, which is why hybrid tends to win.
When hybrid is worth the complexity
Use plain keyword search if your queries are short and exact, your catalog titles are clean and consistent, and shoppers or users already find what they need. Don’t add machinery because it’s fashionable.
Move to hybrid when you see:
Natural-language queries returning poor results
“Something warm for a hike in October” finds nothing useful.
Many zero-result queries caused by wording differences
See How to Fix Zero-Result Searches for how to tell which zero-result queries are wording problems.
Document collections where the question and the text differ
Legal and policy documents are typical. I used dense retrieval with a sentence-level re-ranker for contract clauses in Turning a Contract Audit Into a Search Query.
A mix of exact-match needs and descriptive queries
Both kinds arrive in the same search bar.
Pure vector search is rarely the right answer by itself for products or documents with identifiers. It tends to work best as one half of a hybrid.
What hybrid search costs
Indexing
You generate an embedding for every document, and again when the content changes. That means a model call per document and storage for the vectors.
Query time
Each query is embedded too, which adds latency. Nearest-neighbor indexes are fast, but they use more memory than a keyword index.
Tuning
Weights or fusion settings, the choice of embedding model, and matching it to your languages and domain. A general-purpose embedding model can miss domain terms, so test it on your content.
Debugging
Harder. “Why did this rank here?” has a less direct answer with vectors.
Optional re-ranking
A second model re-scores the top results for precision, at the cost of more latency.
Engine support differs by version, so check your version’s documentation before planning. If you run OpenSearch or Elasticsearch, you generally don’t need to replace the engine to add vectors and hybrid queries. If you want a second opinion on the setup, see my OpenSearch consulting page.
How to test it before committing
1. Collect real queries
Take 100 to 200 from your logs, including the failures. Include exact-match ones and descriptive ones.
2. Build a judgment list
For each query, record which results are good. Even a rough three-level rating (good, okay, bad) beats guessing.
3. Score each setup
Run keyword, vector and hybrid against the list and compute a ranking metric such as NDCG@10. Compare them per query type, not just on average.
4. Look at the losses
Read the queries where hybrid did worse than keyword. They tell you which weight or rule to change.
5. Test live
Run an A/B test on conversion or click-through before replacing what you have.
An average improvement can hide a regression on part numbers. Always read the breakdown.
A quick decision guide
Short exact queries, clean data, few complaints
Start with keyword search, tuned.
Lots of natural-language queries and wording mismatches
Hybrid.
Documents with identifiers and descriptive questions (legal, technical)
Hybrid.
Very small catalog
Keyword with synonyms; skip vectors.
Question-answering over documents
Hybrid retrieval feeding an answer step that cites its sources.
Common questions about hybrid search
What is the difference between semantic search and vector search?
They are used almost interchangeably. Semantic search is the goal (match meaning); vector search is the usual technique (compare embeddings).
Is hybrid search better than vector search?
Usually, for catalogs and documents with identifiers, because vector search is weak on exact terms. For pure meaning-based tasks such as finding similar text, vector search alone can be enough.
Do I need to replace Elasticsearch or OpenSearch?
Generally no. Both can store vectors and run hybrid queries in current versions. The move is a configuration and data change, not a replacement.
How much does hybrid search improve results?
It depends on your data and queries, so I don’t quote a figure. Measure on your own judgment list before you decide.
Is BM25 outdated?
No. It is still the right tool for exact terms and a strong baseline. Hybrid search keeps it.
Can you set this up for us?
Yes. I work with e-commerce, legal and compliance teams on search relevance. See Search & Discovery for how I work.
