Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Combine vector and full-text search by running both retrieval methods, then merging their ranked results. Reciprocal rank fusion (RRF) is a practical way to produce one list when the systems’ raw relevance scores use different scales: it uses each document’s position in each list, not the score values themselves.
Why combine vector and full-text search?
Vector search can retrieve content that is conceptually related to a query even when it uses different wording. Full-text search can be especially useful for exact strings such as product codes, names, dates, and specialized jargon. Hybrid search runs both and combines their results. Microsoft describes the two sides as using different ranking functions, including BM25 for text and HNSW or exhaustive K-nearest-neighbor search for vectors (Microsoft Learn: Hybrid Search Overview).
Elastic summarizes its approach as: “Hybrid search runs full-text search and vector search in one request” (Elastic Docs). The general pattern is the same across implementations: retrieve candidates from multiple query lists, fuse their rankings, and return one ordered result list.
How reciprocal rank fusion works
RRF gives a document a contribution based on its rank in every result list where it appears. A common formula is:
#1 Best Overall
score(d) = Σ 1 / (k + rank_q(d))
Here, d is a document, rank_q(d) is its position in a result list, and k is the configurable rank constant. Rank positions start at 1. The contributions are summed across lists; a document absent from a list contributes nothing from that list.
For example, a document ranked highly by both the lexical and vector searches will gain contributions from both. A document appearing in only one list can still rank well if its position there is strong, but it receives no contribution from the other list. The result is a fusion score, not a calibrated probability that the document is relevant. OpenSearch notes that a minimum score depends on the number of query clauses and the rank constant, rather than directly measuring how closely a document matches the query (OpenSearch Documentation: Reciprocal rank fusion).
OpenSearch describes RRF this way: “Reciprocal rank fusion (RRF) combines the results of multiple query clauses using each document’s position in each result list rather than its relevance score” (OpenSearch Documentation).
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
What RRF preserves—and what it discards
RRF does not require raw scores from different retrieval systems to be comparable. That makes it a straightforward starting point when one system returns BM25-like scores and another returns vector-similarity scores with a different range or meaning.
Its trade-off is that it uses rank, not score magnitude. If two documents occupy the same positions in their respective lists, RRF treats those positions the same whether the underlying scores are close together or far apart. Score normalization and combination can retain some of that margin information, depending on the method. OpenSearch documents both a score-based normalization processor and an RRF rank-based score ranker, and notes that RRF loses score-margin information (OpenSearch Documentation: Hybrid search).
What the RRF rank constant changes
The constant k appears in the denominator of each reciprocal-rank contribution. Changing it changes how much rank position affects the contribution and therefore can change the fused ordering. Treat it as a fusion parameter to evaluate on your data, not as a universal setting that guarantees better relevance.
Rank #4
- New
- Mint Condition
- Dispatch same day for order received before 12 noon
- Guaranteed packaging
- No quibbles returns
Do not confuse the RRF rank constant with the k used to request a number of nearest neighbors from vector search. Azure AI Search explicitly distinguishes its RRF rank constant from vector-query k; the former influences fusion, while the latter concerns vector retrieval (Microsoft Learn: Hybrid Search Scoring (RRF)). Where supported, per-list query weights are another control that can influence how much a source ranking contributes.
How to implement hybrid search with RRF
- Run the source searches. Execute a full-text query and a vector query against the same corpus, using representative query text and appropriate retrieval settings for each.
- Collect ranked result lists. Each source produces an ordered list of candidate documents. Decide how many results to retrieve from each source: list count and depth affect which candidates are available to fusion.
- Fuse the rankings. Apply RRF to the lists, summing the reciprocal-rank contributions for each document, and sort by the resulting fusion score.
- Evaluate and tune. Compare the fused output with alternatives using judged queries, relevance metrics, exact-match cases, latency, and compute cost. Adjust the rank constant, supported query weights, and candidate-list depth based on results.
Product implementations differ. OpenSearch documents a hybrid-search pipeline and an RRF ranker; Elasticsearch exposes RRF as a retriever for combining child retrievers; Azure AI Search uses RRF when multiple query executions run in parallel (OpenSearch; Elasticsearch Reference; Azure AI Search).
Best Value
In Azure’s documented simple case, one full-text query and one vector query produce two executions to fuse. Adding vector queries or searching additional vector fields can add ranked lists and change the fusion input (Microsoft Learn).
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.RRF or score normalization?
Use RRF as a practical baseline when the retrieval systems’ score scales are not comparable or you do not have a validated way to normalize them. Consider score-based normalization and combination when the differences between scores within each list carry useful relevance information and your method can handle the scales reliably.
There is no universal winner. OpenSearch reports that, across six BEIR datasets, RRF had 3.86% lower average NDCG@10 than its score-based hybrid pipeline; the documentation says search latency and coordinator-node CPU utilization were comparable. The page does not state a publication year, and this vendor-reported benchmark is not a prediction of results on another corpus (OpenSearch Documentation).
Quick Recap
How to evaluate a hybrid ranking
- Measure relevance. Use representative queries with relevance judgments and a metric suited to the task, such as NDCG@k or recall.
- Check exact matches. Include codes, names, dates, and jargon that lexical retrieval may find more reliably than semantic similarity.
- Compare rank and score behavior. Inspect cases where score margins differ substantially; these expose whether discarding raw score gaps helps or hurts.
- Test fusion controls. Compare rank constants, supported per-list weights, and candidate-list counts and depths.
- Measure operations locally. Record latency and compute use under your deployment’s workload, since the cost depends on how many source searches run and how the service is configured.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
