Hybrid search

A hybrid query runs two retrievers, normally in parallel: a lexical retriever scoring with BM25 over an inverted index, and a dense retriever doing approximate nearest-neighbour search over embeddings. Each returns its own top-k candidates, commonly somewhere between 20 and a few hundred, and a fusion step merges them. The two signals fail differently. BM25 is precise on identifiers, rare terms, names and exact phrases and robust on unseen domains; the BEIR benchmark (Thakur et al., 2021) showed BM25 to be a strong zero-shot baseline that several dense retrievers failed to beat out of domain. Dense retrieval handles paraphrase, synonyms and cross-lingual matches but blurs codes and numbers.

Reciprocal Rank Fusion (Cormack, Clarke and Büttcher, 2009) is the most common fusion method: RRF(d) = Σ_r 1 / (k + rank_r(d)), summed over the result lists in which document d appears, with k = 60 as the constant proposed in the paper. Because it uses only ranks, it needs no score calibration, and a document ranked highly by both retrievers rises to the top. The alternative is a convex combination of normalised scores, s = α · ŝ_dense + (1 − α) · ŝ_lexical, with min-max or z-score normalisation per query. This is necessary because BM25 scores are unbounded and vary with query length and corpus statistics, whereas cosine scores sit in a narrow band. Bruch, Gai and Ingber (2023) argued that a tuned convex combination generally outperforms RRF and needs only a small labelled set to tune α; RRF remains the safer default without labelled data.

Most search engines now implement both. Elasticsearch offers an RRF retriever, OpenSearch a hybrid query with a normalisation processor in a search pipeline, and Weaviate a hybrid operator whose alpha parameter runs from pure keyword (0) to pure vector (1); in PostgreSQL the same pattern can be written in SQL combining full-text search on tsvector with pgvector. Learned sparse models such as SPLADE provide a third option: vocabulary-weighted vectors served from an inverted index, which capture some semantics while keeping exact-term behaviour.

Implementation pitfalls are mostly about consistency. Access-control and metadata filters must be applied identically in both branches, or one branch will leak documents the other excluded. Both indexes must be updated and deleted in step. Pagination over fused results is unstable unless each branch retrieves deep enough. For Danish, the lexical branch needs a Danish analyser with stemming and ideally decompounding, since compounds such as "sygedagpengeloven" otherwise never match "sygedagpenge"; without that, the hybrid gains little on Danish text. Quality should be measured with recall@k and nDCG@10 on labelled queries, and the fused list is typically passed to a reranker.