Vector Search vs. Keyword Search vs. Hybrid Search: Which Retrieval Method Should You Use?

Keyword search ranks documents by matching the words in the query, usually with the BM25 scoring function. Vector search ranks documents by the similarity of their embeddings to the query's embedding, capturing meaning rather than exact words. Hybrid search combines both, typically by running each search and merging the ranked lists, so it handles exact terms and paraphrased questions well.

Comparison

How hybrid search merges results

Reciprocal rank fusion (RRF)

Reciprocal rank fusion, described by Cormack, Clarke, and Buettcher, scores each document by summing 1 / (k + rank) across the result lists, where k is a constant (commonly 60). It needs no score normalization, which makes it simple and robust.

Weighted score fusion

Normalize the keyword and vector scores, then combine them with a weight, such as Weaviate's alpha parameter. This allows tuning toward keyword or semantic results, but needs careful normalization.

Learned sparse retrieval

Models such as SPLADE produce sparse vectors that behave like smarter keyword matching, and can be combined with dense vectors in databases that support both.

Add a reranker

A reranker, usually a cross-encoder model, reads the query and each candidate passage together and scores relevance more precisely than either first-stage method. Retrieve 20 to 50 candidates with hybrid search, rerank, and keep the top 3 to 8 for the LLM. This improves answer quality in RAG systems and reduces token costs.

Implementation options

• Weaviate: built-in hybrid queries with an alpha parameter.
• Qdrant: sparse and dense vectors with fusion in the Query API.
• Pinecone: sparse-dense vectors for hybrid queries.
• PostgreSQL: pgvector for vectors plus full-text search, fused with RRF in SQL or application code.
• Elasticsearch and OpenSearch: BM25 and k-NN vector search in one engine.

How to evaluate retrieval

1. Collect real queries, including exact-term queries and natural-language questions.
2. Label the relevant documents for each.
3. Measure recall at k and mean reciprocal rank for keyword-only, vector-only, and hybrid retrieval, with and without reranking.
4. Choose the simplest configuration that meets your target.

The full process is in our production RAG guide.

Why keyword search still matters

Vector search transformed retrieval by matching meaning rather than exact words, but it has well-known blind spots. Embedding models compress text into a fixed number of dimensions, and rare tokens such as product codes, part numbers, error messages, legal clause references, people's names, and new terminology are often poorly represented. A query for "error E4021" may return passages about other errors that are semantically similar but useless to the user. Keyword algorithms such as BM25 score documents by how often query terms appear, weighted by how rare those terms are across the collection, so exact identifiers rank highly. Keyword search also behaves predictably and is easy to explain, which matters in regulated domains. The weaknesses are the mirror image: keyword search misses synonyms, paraphrases, and questions phrased differently from the documents. Hybrid search exists because each approach covers the other's gaps.

How reciprocal rank fusion works

Reciprocal rank fusion (RRF) is the most common way to merge keyword and vector results because it needs no score calibration. Each retriever returns a ranked list. For every document, RRF adds up a score of one divided by a constant plus its rank in each list; the constant, often 60, reduces the influence of small differences near the top. A document ranked first by vector search and fifth by keyword search scores higher than one that appears in only one list. Because RRF uses ranks rather than raw scores, it works even though BM25 scores and cosine similarities are on completely different scales. Weighted variants let you favor one retriever. Score-based fusion, which normalizes and blends raw scores using a weight such as alpha, is an alternative that some databases offer and can perform better when tuned on your data.

Sparse vectors and learned sparse retrieval

Hybrid search does not have to mean running two separate systems. Sparse vectors represent text as weights over a large vocabulary, with most values zero, so they behave like keyword matching inside a vector database. Classic sparse vectors are built from term statistics similar to BM25. Learned sparse models, such as SPLADE-style approaches, use a neural network to assign weights and can expand a document with related terms it does not literally contain, combining some of the precision of keywords with some semantic generalization. Databases including Qdrant, Pinecone, and others support storing sparse and dense vectors together and fusing results in one query, which simplifies architecture and keeps filters consistent across both retrieval methods.

Query routing and per-query weighting

Not every query needs the same balance. Short queries that look like identifiers, such as "INV-20931" or "ORA-00942", benefit from strong keyword weighting. Long natural-language questions benefit from more semantic weighting. A simple classifier or a few rules can detect query type and adjust weights, for example increasing keyword influence when a query contains digits mixed with letters or quoted phrases. Some systems go further and send structured questions, such as "orders shipped last week", to a database query instead of a search index. Measure each routing rule on your evaluation set; a rule that seems obviously sensible can still reduce overall recall.

Latency and cost of hybrid pipelines

A full hybrid pipeline runs a keyword search, a vector search, fusion, and often a reranker. Run the two searches in parallel rather than one after the other, so total latency is close to the slower of the two. Rerankers are the most expensive step because they score each candidate against the query with a larger model; limit them to a sensible number of candidates, such as 20 to 50, and measure how many are really needed for good results. Cache embeddings for frequent queries and cache full results for popular searches where content changes slowly. For interactive search boxes, aim for a total latency that feels instant to users; for RAG pipelines, retrieval latency is usually small compared with language model generation, so a reranker that improves answer quality is often worth its cost.

Example: hybrid search for a support knowledge base

A software company's help center search fails in two ways: customers pasting exact error messages get unrelated articles from the semantic search, and customers describing problems in their own words get nothing from the old keyword search. The team indexes each article section with BM25 and a dense embedding, runs both in parallel, merges results with reciprocal rank fusion, and reranks the top 30 with a cross-encoder. Product and version filters apply to both retrievers. Using 300 real queries from support tickets with known correct articles, they measure recall at five for each configuration. Keyword-only and vector-only each miss a large share of queries in different ways; hybrid with reranking finds the correct article in the top five far more often. Support ticket deflection rises, and the same retrieval service is later reused by the company's AI assistant.

Common hybrid search mistakes

• Adding raw scores together from BM25 and cosine similarity without normalization, so one retriever dominates.
• Applying filters to only one retriever, letting restricted or irrelevant documents through the other.
• Tuning weights on a handful of examples instead of a representative evaluation set.
• Ignoring tokenization, so keyword search splits codes and identifiers in unhelpful ways.
• Reranking too few candidates, so the correct passage never reaches the reranker.
• Reranking too many, adding cost and latency with no quality gain.
• Treating hybrid as finished rather than reviewing failed queries and adjusting over time.

Monitoring search quality in production

Offline evaluation sets tell you whether a change is safe to ship; production signals tell you how search performs for real users. Track the share of searches with no results, the share with no clicks, how often users rephrase a query immediately, the position of clicked results, and, for RAG systems, user feedback on answers and how often the assistant says it cannot answer. Review the worst queries weekly. Many fixes are content fixes, such as adding a missing article or synonyms, rather than algorithm changes. Add failed queries with their correct answers to your evaluation set, so the system steadily improves on exactly the questions users ask.

Summary

Keyword search finds exact terms, vector search finds meaning, and hybrid search combines them to handle the mix of identifiers and natural language that real users type. Run both retrievers in parallel with the same filters, merge them with reciprocal rank fusion or tuned score blending, rerank a sensible number of candidates, and measure every change against an evaluation set built from real queries. For the databases that support hybrid search natively, see our guides to Weaviate and Qdrant; for how retrieval fits into AI assistants, see RAG explained and our production RAG guide.

Building a hybrid search evaluation set

A good evaluation set for hybrid search deliberately mixes query types, because that mix is exactly what hybrid search is meant to handle. Collect real queries from search logs, support tickets, chat transcripts, and sales conversations, then group them into categories: exact identifiers such as SKUs, error codes, and invoice numbers; names of people, products, and places; short keyword phrases; long natural-language questions; misspelled queries; and queries in other languages if you serve them. For each query, have someone who knows the content mark the documents or passages that should appear at the top. Aim for at least a few dozen queries per category, so you can see where each retriever is strong and weak. Report recall at k and mean reciprocal rank per category as well as overall: a configuration that improves natural-language questions while quietly breaking identifier lookups will look fine on an average but frustrate the users who rely on exact matches. Keep the set versioned, add new failure cases from production regularly, and rerun it automatically before any change to tokenization, embedding models, fusion weights, or reranking reaches users. Over time, this set becomes the most reliable description of what good search means for your organization, and it lets you adopt better models or databases quickly because you can prove an improvement before switching.

Where to start

If you already have keyword search, add vector retrieval alongside it rather than replacing it, merge the two with reciprocal rank fusion, and compare the result with your current search on an evaluation set. If you are starting from scratch, choose a database that supports both dense and sparse or BM25 retrieval natively, so you can tune weights without operating two systems. Add a reranker once the basic pipeline is measured, and keep improving with real queries from production. Small, measured steps beat a large redesign every time.

Good retrieval is earned query by query, and measured at every step along the way.

Improve your search with Vertex Cyber Tech

We design hybrid retrieval and reranking pipelines for site search, support assistants, and enterprise knowledge bases. See our vector database capabilities and AI/ML services, or book a search audit.

Sources and further reading

• Cormack, Clarke, and Buettcher, "Reciprocal Rank Fusion" (SIGIR 2009)
• Formal et al., "SPLADE: Sparse Lexical and Expansion Model"
• Weaviate: Hybrid search
• pgvector