Hybrid search combines keyword search with vector search and merges the two result lists into one ranking. Keyword matching is precise on exact terms, product codes and names; vector matching understands meaning and paraphrase. Each covers the other’s weakness, and combining them usually produces noticeably better retrieval than either alone, especially in RAG systems.
Key takeaways
- Keyword search typically uses BM25 or a similar lexical scoring function.
- Vector search uses embedding similarity.
- Results are combined by score fusion or rank fusion.
- Reciprocal rank fusion (RRF) is a simple, robust default.
- Hybrid search is particularly valuable for technical and product content.
Hybrid search explained in simple terms
Two researchers look for the same answer. One scans for exact phrases; the other reads for meaning. Alone, each misses things. If both hand you a shortlist and you merge them, giving weight to anything both found, you get a better list than either produced.
Why each method fails alone
| Query type | Keyword only | Vector only |
|---|---|---|
| “error code E-4021” | Finds it exactly | May return similar errors |
| “why is my payment failing” | Misses differently worded articles | Finds them |
| “Tally Prime GST export” | Strong on product names | May drift to general GST content |
| Long natural-language question | Poor | Strong |
How results are combined
Reciprocal rank fusion ignores raw scores and uses positions instead. Each result gets a score of 1 ÷ (k + rank) from each list, where k is a constant, often 60, and the scores are summed.
Worked example with k = 60:
| Document | Keyword rank | Vector rank | RRF score |
|---|---|---|---|
| A | 1 | 8 | 1/61 + 1/68 ≈ 0.0311 |
| B | 4 | 2 | 1/64 + 1/62 ≈ 0.0318 |
| C | 2 | 25 | 1/62 + 1/85 ≈ 0.0279 |
Document B wins because it ranks well in both lists, even though it is top of neither. Documents found by both methods rise; documents found by only one still appear, but lower.
The alternative is weighted score fusion: normalise both scores and combine them with a weight, for example 0.6 vector and 0.4 keyword. It allows tuning but requires careful normalisation, since BM25 and cosine scores are on different scales.
Implementation options
- Search engines such as Elasticsearch and OpenSearch support both scoring types natively.
- Several vector databases offer built-in hybrid or sparse-dense search.
- You can run two queries in your application and fuse the results yourself, which is straightforward with RRF.
When hybrid search matters most
- Technical documentation with codes, versions and command names.
- Product catalogues with SKUs and model numbers.
- Legal and regulatory text with specific clause references.
- Multilingual content where some terms stay in English.
- Any corpus where users mix natural language with exact identifiers.
Practical tips
- Retrieve more candidates from each method than you need, then fuse and rerank.
- Start with RRF before tuning weights.
- Evaluate on real queries containing both natural language and identifiers.
- Apply metadata filters consistently to both retrieval paths.
Limitations
- Two retrieval systems to build, tune and maintain.
- Slightly higher latency and cost per query.
- Fusion weights need evaluation data to tune well.
- It cannot fix poor chunking or missing content.