TL;DR: Hybrid search runs a keyword search and a vector search on the same query, then merges the two ranked lists into one. Keyword matching catches exact strings like part numbers and names; vector matching catches rephrasings and synonyms. Together they cover each other's blind spots, which is why most production retrieval is hybrid.
How it works
Every query goes down two paths at once. The keyword path uses a traditional inverted index and a scoring function such as BM25, rewarding documents that contain the query's literal terms. The vector path embeds the query and asks the vector index for the nearest neighbors by meaning, exactly as semantic search does on its own. Each path returns its own ranked list of candidates.
The interesting part is the merge. The two lists score on incompatible scales - BM25 scores are unbounded, cosine similarities live between -1 and 1 - so you cannot simply add them. The most common fix is reciprocal rank fusion (RRF), which ignores raw scores and combines documents by their positions in each list: an item ranked highly by either path rises, and an item ranked well by both rises furthest. Alternatives include normalizing scores and taking a weighted blend, where the weight becomes a tuning knob between precision and recall.
Consider a support query like "error 4042 when canceling my plan". Vector search understands "canceling my plan" but treats "4042" as noise; keyword search nails the literal "4042" but knows nothing about billing phrasing. Hybrid retrieval surfaces the article that mentions the exact code and discusses cancellation, which neither path reliably finds alone. Many teams then hand the merged list to a reranking model for a final ordering pass.
Hybrid search costs more than either path alone - two indexes to build, two queries to run, one fusion step to tune. The usual advice is to start hybrid anyway: the failure cases of pure vector search (codes, names, jargon) are exactly the queries users remember, and the keyword half is cheap insurance against them.
Where it sits in the AI stack
Hybrid search is a retrieval strategy, not a separate store. It sits at query time, in front of both indexes, and its fused list is what downstream consumers - a results page or a RAG pipeline - actually see:
Because fusion happens after both retrievals, you can adopt it incrementally: keep an existing keyword engine, add a vector index beside it, and merge.
Key tools and implementations
-
Postgres with pgvector
Full-text search and vector similarity in one database, fused with a few lines of SQL.
-
Elasticsearch and OpenSearch
Mature keyword engines with built-in vector fields and native RRF-style hybrid queries.
-
Weaviate
A vector database with hybrid search as a first-class query type and a tunable blend weight.
-
Qdrant
Supports sparse and dense vectors side by side, enabling hybrid retrieval in one engine.
Related entries
- Semantic search Search that ranks results by meaning, using embeddings, so matches do not require the exact words.
- Reranking A second scoring pass that reorders retrieved candidates so the most relevant results come first.
- Vector database A database that stores embeddings and finds nearest neighbors fast, powering semantic search and RAG.
- RAG (retrieval augmented generation) Fetching relevant documents at query time so a language model can answer from your data instead of memory alone.