In this article
RRF combines child rankings, while linear retrieval normalizes and weights child scores under an explicit versioned configuration.
Elasticsearch RRF and linear retrievers combine signals through different contracts: rank positions versus normalized weighted scores. Compare those mechanisms with the same child retrievers before treating either configuration as a generic hybrid-search upgrade.
Keep the combination rule explicit
The RRF retriever reference describes fusion of child result rankings. Original score magnitudes do not supply the same information as positions. The linear retriever, by contrast, normalizes and weights scores from its children. A large score gap can matter to that calculation even when rank order is unchanged. Neither mechanism can restore evidence that never reached a child result window.
Separate windows from final size
A child result window and the final response size are different limits. Preserve both in the experiment, along with dense candidate settings. The kNN guide defines the vector-search stage that supplies one branch. Increasing its candidate population while changing fusion confounds two decisions. Export branch IDs and scores so a recovered document can be attributed to candidate generation or final combination.
Define normalization before weights
The current linear reference documents per-retriever normalizers and version-sensitive inheritance from a top-level normalizer. Check the installed release rather than assuming that one request means the same thing in every version. A weight applied to an unnormalized lexical score may dominate another branch for scale reasons. That is not necessarily evidence that lexical retrieval is genuinely more useful for the query class.
| Fusion choice | Information primarily retained |
|---|---|
| RRF | Positions in child rankings |
| Linear with normalization | Normalized score magnitudes and weights |
| Candidate-window change | Which evidence reaches fusion at all |
Use a disagreement fixture
Prepare illustrative queries mixing exact error codes and paraphrased descriptions. Include a case where lexical search has a clear leading document and another where its top scores are close. Judge passages against the source before tuning. Keep filters identical and verify how they apply to each child. An apparently improved ranking can otherwise include documents outside the intended eligible population.
Inspect explanations for losing cases
When an aggregate relevance score rises, retain examples that became worse. Determine whether the useful passage was absent, normalized differently or outweighed during combination. Do not interpret a final hybrid score as a corpus-independent probability. Its scale and meaning depend on the chosen retrieval configuration. A threshold migrated from another index therefore requires its own labeled comparison rather than automatic reuse.
Preserve the API and entitlement boundary
Record server version, supported retriever syntax and relevant feature prerequisites before publishing an executable request. Documentation for a current API does not establish every older installation or license configuration. Keep the final fixture with query bodies, windows, normalizers and weights. The defensible result identifies an implementation that improved defined evidence tasks, including its remaining failures, rather than announcing a universally best fusion method.
Related reading: A local RAG server: placing components around the GPU; Reranking in RAG: how many candidates should you rescore?.