Hybrid search

How it works

Keyword search, usually scored with the BM25 algorithm, is precise on names, codes and rare terms. Semantic search is good at paraphrase. Hybrid search sends the query to both, then combines the 2 ranked lists. A common way to combine them is reciprocal rank fusion (opens in a new tab) (Elastic's documentation shows it merging a BM25 query with a vector query), which rewards documents that rank well in either list and does not need the 2 scoring systems to share a scale. Some systems weight one side more, for example favoring keywords when a query looks like an order number.

A reranker often comes next: a model that reads the query with each of the top candidates and puts them in final order.

Elasticsearch, OpenSearch, Weaviate, Qdrant and Postgres (full-text search plus pgvector) can all run hybrid search, so it rarely needs an extra product.

How businesses use it

Hybrid search is our default retrieval setup for RAG knowledge systems, because business documents mix plain language with exact identifiers:

• Support content full of product names, error codes and version numbers
• Contracts where a clause number matters as much as the topic
• Parts catalogs, with SKUs next to free-text descriptions
• Policies that use internal acronyms nobody outside the company would recognize

Where it goes wrong

Hybrid search adds tuning work. The keyword side needs sensible text processing for your language and field, and the weighting between the 2 sides has to be tested on real queries from your logs. Rerankers add latency and a per-query cost, so use them where answer quality matters more than speed.

The bigger risk is skipping measurement. Without a test set of real questions and the documents that should answer them, nobody can tell whether a change helped or hurt. We build that test set before tuning anything, and it stays with you after handover so your team can rerun it.