What is Hybrid Search?

Why It Matters

Every retrieval method has a blind spot. Keyword search misses paraphrase: ask about “ending the agreement” and it will not find “termination clause.” Vector search misses exactness: ask for error code E-4021 and it returns semantically similar errors instead.

Users write both kinds of query in the same search box, usually in the same session. Hybrid search exists because no single method covers the way people actually ask.

How It Works

Two retrievals run in parallel: a keyword index (BM25 or similar) ranks by term matching, and a vector index ranks by embedding similarity. The two ranked lists then get fused, commonly with reciprocal rank fusion, which combines positions rather than raw scores, so neither method’s scale dominates.

The fused candidate set goes to the reranker for the precision pass. The pattern is recall by committee: let each method bring what it is good at, then let a better model decide.

Where It Breaks

The first break is half-hybrid: a system that technically runs both but weights one so heavily the other is decoration, usually because nobody measured which queries needed which leg. The second is fusion done naively: concatenating top-k lists instead of ranking them together, so duplicates and ordering artifacts leak into the candidate set.

Hybrid also adds a tuning surface: the keyword/vector weighting is corpus-dependent, and a fusion tuned on a generic benchmark can underperform either method alone on your actual documents.

How Flytebit Handles It

Hybrid is the default retrieval shape in our RAG work, and the fusion weighting is tuned against the client’s corpus, measured with eval questions from real user queries, not assumed from benchmarks. Retrieval configuration lives in the versioned manifest, so a weighting change is a scored event rather than an invisible one.