AnswersHybrid Search & Ranking

How Should You Weight Hybrid Scores?

How do you dynamically adjust the weights of dense and sparse scores in a hybrid system when user query length and shape vary wildly?

2 min readJuly 2026

The short answer

There is no single right weight, because the right balance is a property of the query, not the corpus. A two-word, entity-heavy query ("A17-B manual") is a lexical query, where exact-token evidence should dominate. A twenty-word natural-language question is a semantic query, where dense similarity should dominate.

You have three options, in order of effort: use rank-based fusion (RRF) and skip weights entirely; set weights per query class from cheap features like token count and term rarity; or learn the weighting function from labeled data.

If you can't measure quality yet, use RRF. If you can, condition the weights on the query.

Why does one static weight fail?

A static weight is one answer to two different questions. Tune α on your verbose queries and short identifier lookups drown in semantic noise; tune it on the lookups and paraphrased questions go blind. When query shape varies wildly, any fixed blend is wrong for a large fraction of traffic. No single value can fix that, because a constant is the wrong type for a query-dependent quantity.

The right blend is a property of the query, not the corpus.

Short, entity-heavy query

A17-B manual

Rare tokens carry the intent

Lean lexical

Weight sparse higher

Long, natural-language query

How do I return a damaged item?

Meaning carries the intent

Lean dense

Weight dense higher

What per-query signals actually work?

Cheap, computable-at-query-time features carry most of the signal: length (short queries lean lexical, long ones lean dense), rare-token presence (IDs, codes, camelCase, and digits push lexical, since rare tokens are what embeddings blur away), and quote or operator syntax (explicit exact-match intent). A handful of if-then rules over these features (three query classes, three weight profiles) captures most of the win before any learning is involved.

When should you learn it instead?

When you have labeled relevance data and enough traffic diversity that hand rules visibly leave quality behind. Bruch et al. (2022) show that tuned convex score combinations generally beat untuned rank fusion, which is the case for learning weights once you can measure. Then per-class constants become a small model predicting weights from query features. Don't start here: learned fusion adds training, serving, and drift-monitoring costs that only pay off after the simple version is measurably insufficient.

Where does the engine matter?

Per-query weighting is only cheap if the scores meet in one place. In a two-engine setup, changing the blend means re-normalizing two incompatible score distributions in application code (RRF vs score fusion vs true hybrid). In a true-hybrid engine the blend is a ranking expression evaluated inside the query. In TopK it's literally 0.7 * dense_score + 0.3 * sparse_score in the query itself, so query-conditional weighting is a per-request parameter change, not a pipeline rebuild.

TopK's BEIR case study (July 2025) measured this score-aware, tunable approach at 4.58% higher nDCG@10 on average than RRF's fixed rank fusion.

Keep reading

RRF vs Score Fusion vs True Hybrid: Which Should You Use?RRF merges lists by position, score fusion tunes weighted scores, and true hybrid scores every signal in one query. Start with RRF; move up as you measure.When Do You Need Hybrid Search?Use hybrid search when queries mix natural language with exact tokens like names and codes. Vectors blur exact terms; keywords miss paraphrases.Do You Still Need a Reranker?Add a reranker when the right documents reach your top 100 but not your top 5. With a multi-vector first stage, measure first: it may be redundant.