Home / Hybrid search / Relative Score Fusion vs RRF

Relative Score Fusion vs RRF

Relative score fusion is a way to combine keyword and vector search results by rescaling each list’s scores to a 0 to 1 range and adding them with a weight. In each result list, the highest score becomes 1, the lowest becomes 0, and the rest fall in between in proportion. The two normalised scores are then weighted by alpha and summed. Unlike reciprocal rank fusion (RRF), which keeps only each document’s position, relative score fusion keeps the size of the gaps between scores. A document far ahead on keyword match therefore keeps that lead. In Weaviate it is called relativeScoreFusion and has been the default hybrid fusion method since version 1.24. Weaviate’s internal benchmark on the FiQA dataset showed about 6 percent better recall than its rank-based method. RRF stays useful when score ranges are unstable or when merging many lists.

What is relative score fusion?

Relative score fusion is a score-based fusion method that makes keyword and vector scores comparable by min-max normalising each result list, then blends them with a weight. It is one of two fusion methods in Weaviate’s hybrid search.

Hybrid search runs a keyword search, usually BM25, and a vector search, then merges the two result lists. The scores cannot be added directly. BM25 scores have no fixed upper bound and vary with query length and term rarity. Vector similarities sit in a narrow band that depends on the model. Fusion is the step that puts them on a common footing, as introduced in how hybrid search works.

Relative score fusion does this with a simple rescaling inside each list. It is “relative” because each score is judged against the best and worst scores in the same result set, not against any absolute scale. Weaviate added it in version 1.20 and made it the default in 1.24, replacing its earlier rank-based method.

Written as a formula, the fused score for a document is alpha times its normalised vector score plus 1 minus alpha times its normalised keyword score. Each normalised score is the raw score minus the list minimum, divided by the list maximum minus the minimum. The method needs no training and no tuning beyond alpha, which makes it cheap to adopt and easy to explain.

How does relative score fusion normalise scores?

Relative score fusion normalises scores with min-max scaling: each score minus the list’s minimum, divided by the list’s range, so the top result scores 1 and the bottom result scores 0. The shape of the score distribution is preserved.

Weaviate’s documentation works through five documents. On BM25, document 1 scores 5 and the next best 2.6, a large gap. On vector search, documents 2, 4, 0 and 1 score between 0.594 and 0.6, almost a tie. After normalisation, document 1 keeps its clear keyword lead at 1.000 against 0.511. The four close vector scores stay between 0.990 and 1.000.

That is the key property. A strong signal stays strong and a near tie stays a near tie. Other normalisations, such as z-scores or fixed-range scaling, make different trade-offs, compared in score normalization.

How are the normalised scores combined?

The normalised scores are combined by weighting the vector score by alpha and the keyword score by 1 minus alpha, then adding them for each document. A document missing from one list contributes nothing from that side.

With alpha at 0.5, each side counts equally. Document 1 scores 0.5 times 1.000 plus 0.5 times 0.990, or 0.995, and takes first place. Document 0 follows at 0.752 and document 2 at 0.725. Weaviate’s documented table shows 0.993 for document 1 because it rounds an intermediate value; the order is the same.

Alpha moves the balance. At 0, only keyword scores count; at 1, only vector scores. Weaviate’s GraphQL reference gives a default of 0.75. At that setting document 1 still leads, at about 0.992, because its vector score is close to the top as well. Balancing keyword and vector scores covers choosing alpha.

How does relative score fusion differ from RRF?

Relative score fusion differs from RRF in what it keeps: it uses the normalised scores, while RRF uses only each document’s rank, scoring it as 1 divided by rank plus a constant. The same inputs can produce different winners.

In Weaviate’s rank-based method, called rankedFusion, each document scores 1 divided by its rank plus 60 in each list, following the reciprocal rank fusion formula. In the example, document 2 is first on vector search and third on BM25, and wins with about 0.016398. Document 1 is first on BM25 but fourth on vector, and comes second with 0.016270. RRF cannot see that the vector scores were a near tie, or that document 1’s keyword lead was large.

Neither is always better. Weaviate states that relativeScoreFusion keeps more information from the original searches. Its internal benchmark on the FiQA dataset showed about 6 percent better recall than rankedFusion, and on that basis it became the default. Reciprocal rank fusion covers RRF in depth, and score fusion methods compares the wider family. “RSF vs RRF” is the common shorthand for this comparison.

When does relative score fusion beat rank-based fusion?

Relative score fusion beats rank-based fusion when the size of score gaps carries meaning, such as a clear exact keyword match or a near tie among vector results. It helps most on queries with one standout result.

Exact names, codes and quoted phrases often give one document a much higher BM25 score than the rest. Relative score fusion keeps that lead, while RRF reduces it to “rank 1”, the same credit any first place gets. Vector results often bunch together, and relative score fusion avoids inventing large differences between them.

Weaviate also notes that relative score fusion works with autocut, which cuts a result list at natural jumps in score. Rank-based scores change by tiny, even steps, so they have no jumps to cut at. Using autocut on hybrid queries in Weaviate requires relativeScoreFusion.

When can relative score fusion go wrong?

Relative score fusion can go wrong when one list has very few results, contains outliers, or when every result in it is poor, because min-max scaling always stretches the list to fill 0 to 1. Normalisation hides absolute quality.

If the keyword search returns a single weak match, that match still scores 1 after normalisation. If all vector results are mediocre, the best of them still scores 1. One extreme score can squash the rest of a list towards 0. These effects come from scaling each list on its own, and they are why RRF stays popular when score distributions are unpredictable.

Weaviate reduces some of this by over-searching. Each leg fetches a larger candidate pool before fusion, so normalisation sees a fuller picture of the score range. Test both methods on your own queries: a small set of judged queries, as in the hybrid search tutorial, settles it.

How do you use relative score fusion in Weaviate?

You use relative score fusion in Weaviate by running a hybrid query, which uses relativeScoreFusion by default from version 1.24, or by setting fusion_type explicitly. Alpha sets the balance.

from weaviate.classes.query import HybridFusion, MetadataQuery

response = articles.query.hybrid(
    query="refund annual plan",
    alpha=0.5,
    fusion_type=HybridFusion.RELATIVE_SCORE,   # or HybridFusion.RANKED
    limit=10,
    return_metadata=MetadataQuery(score=True, explain_score=True),
)

Requesting explain_score returns how each result’s score was built from the keyword and vector parts, which helps when tuning alpha. Switch to HybridFusion.RANKED to compare against rank-based fusion on the same queries. Hybrid search is available in many databases, compared in databases that support hybrid search.

A simple way to choose is to run each test query twice, once with each fusion type, and log where the top five differ. Judge only the queries that differ, since identical lists say nothing about the methods. Repeat at two or three alpha values. If relative score fusion wins on most differing queries, keep the default; if rank-based fusion wins, switch and record why. Keep the comparison script, because a new embedding model can shift the answer.

Where does relative score fusion fit in a hybrid search system?

Relative score fusion fits between the two retrieval legs and any reranker: it merges keyword and vector candidates into one list that later stages can refine. It decides which candidates survive.

The fusion choice matters most when hybrid search feeds a language model, because only the top few results reach the prompt. Hybrid search for RAG and hybrid search for enterprise search cover those settings. At scale, candidate pools come from many shards, as in hybrid search on distributed databases, and SQL systems have their own fusion syntax, covered in hybrid search in SQL databases.

Before tuning fusion, confirm hybrid search is needed at all. What is hybrid search, when to use hybrid search and hybrid search vs vector search cover that decision.

Relative score fusion merges keyword and vector results by min-max normalising each list to 0 to 1, weighting by alpha and adding. It keeps the size of score gaps, so a clear keyword winner or a near tie among vector results is respected, unlike reciprocal rank fusion, which keeps only ranks. Weaviate uses it by default from version 1.24 and reported better recall than its rank-based method in an internal test. Watch for small or poor result lists, which normalisation stretches, and compare both methods on your own judged queries.