What hybrid search is
Keyword and vector search fail on different queries. BM25 finds sarv_sk_ or v2.11.162 without fail and misses a paragraph that answers the question in other words. Vector search finds the paraphrase and misses the literal. Hybrid search runs both and merges the results, so the union of two different failure modes is much smaller than either one.
Published numbers agree. On the WANDS e-commerce benchmark, plain reciprocal rank fusion scores 0.7068 NDCG against 0.6983 for BM25 alone and 0.6953 for pure kNN, and a tuned hybrid reaches 0.7497.
Hybrid search is a common choice for production RAG retrieval, because real query logs mix both kinds of question: descriptions in natural language and literal strings copied from an error message or a config file.
How it works
- Send the query to both legs, ideally in one round trip (Elasticsearch
msearch, for example). - Get a ranked list from each: BM25 over text fields, kNN over embeddings.
- Fuse the lists. The standard method is reciprocal rank fusion, which ignores raw scores and adds
1 / (k + rank)from each list. - Post-process: filter junk, cap how many chunks come from one page, and truncate.
Adding normalised scores instead of ranks is tempting and fragile. A BM25 score and a cosine similarity are not the same kind of number, and the BM25 range shifts with corpus and query length.
Weighting is the main tuning knob. A query that is a short literal, a quoted phrase or an id should lean on the keyword leg; a long descriptive question should lean on vectors. Neither weight should drop to zero, because the other leg still finds useful neighbours.
Common pitfalls
- A silently empty keyword leg. A strict multi-term match returns zero BM25 hits when one word is absent from the corpus, and fusion still returns vector results, so nobody notices. Scale
minimum_should_matchwith query length. - Fuzzy matching on identifiers. Fuzziness forgives typos in words and matches the wrong version, id or date. Turn it off for tokens containing digits or separators.
- Asking each leg for only the final count. Fusion needs a candidate pool larger than the answer.
- Failing the whole query when one leg errors. Degrade to the other leg instead.
- Five chunks from one page. Cap chunks per page so the result has more than one source.
Neither leg is a better search engine than the other. They fail on different queries, which is the only reason running both is worth it.
How SarvCrawl handles it
Every SarvCrawl knowledge base supports keyword search and semantic search, and GET /api/kb/:id/search/embed returns the hybrid. Both legs go out in one msearch, fusion is reciprocal rank fusion with k = 60 done in the application, and leg weights shift with the shape of the query: short, quoted or digit-bearing queries lean on BM25, descriptive questions on vectors, and neither weight drops to zero.
After fusion, at most two chunks per page are kept for five or fewer results and three otherwise, chunks under 100 tokens are excluded, and low_confidence is set when nothing matched on keywords and the best cosine is under 0.25. Search is on paid plans. The constants and reasoning are in hybrid search in production.
Frequently asked questions
Is hybrid search better than vector search?
On mixed real-world queries, usually yes, because it keeps vector search's handling of paraphrase and adds exact matching for codes, names and versions. The gain comes from the two methods failing on different queries.
How are keyword and vector results combined?
Most systems use reciprocal rank fusion, which sums 1 divided by (k plus rank) from each list and ignores raw scores. That avoids normalising two incompatible score scales.
Does hybrid search need two databases?
No. Elasticsearch, OpenSearch and Postgres with pgvector can hold a keyword index and a vector index together, so both legs run against one engine in one request.