In this article
The normalization processor combines normalized clause scores, whereas the score-ranker processor applies rank-based RRF.
OpenSearch score normalization and reciprocal rank fusion belong to different search-pipeline configurations. Establish which processor actually handles the hybrid query before interpreting a final relevance score or changing the embedding model.
Locate the combination stage
The normalization-processor reference places its work between query and fetch phases. It combines scores from query clauses after normalizing their values. This is not the same operation as normalizing document embeddings before indexing. Preserve the distinction in configuration names and diagnostics. A vector-normalization change can alter candidates, while a search-phase score processor changes how retrieved branch results are combined.
Distinguish ranks from score values
The score-ranker reference describes rank-based RRF at that search phase. Its input interpretation differs from score normalization, so copying weights or thresholds between the two designs is not a meaningful unchanged baseline. The checked documentation labels normalization as introduced in 2.10 and score-ranker in 2.19. Those are feature-introduction boundaries, not a statement that every current installation has identical defaults or supported options.
Prove that the intended pipeline applies
Keep the actual search request together with the selected pipeline definition. A named configuration existing on the server does not prove that a particular query used it. For a diagnostic run, preserve the effective request path and inspect returned behavior on a deliberately simple fixture. Do not conclude that a fusion algorithm failed when the request bypassed the processor whose behavior was supposed to be evaluated.
| Configuration layer | What to preserve |
|---|---|
| Hybrid clauses | Their order and individual retrieval settings |
| Search pipeline | Processor type and parameters |
| Request | Which pipeline applies to this execution |
Use branches with conflicting scales
Create an illustrative query where lexical and vector branches return partly overlapping documents with different score scales. Save their original ranks and values. Compare a score-normalized configuration against RRF using those same branch settings. The RRF documentation explains the rank-combination route. Judge useful source evidence rather than expecting the displayed numbers to remain comparable across the two methods.
Separate candidate shortages from fusion
If the needed passage is absent from every branch, the processor cannot add it. Preserve candidate depth and filters while changing only the combination stage. A larger candidate window may help a question independently of fusion. Likewise, a clause-order mistake can attach a weight to the wrong signal in a configured combination. Save an explanation for each changed result so a metric average cannot conceal a configuration mismatch.
Publish a versioned retrieval result
Retain the installed release, processor definition, request fixture and judgments. Compare final relevance and execution cost without converting a vendor example into a local benchmark. After adding a branch or changing an analyzer, revalidate the affected input and its combination. The accepted result should identify the pipeline actually exercised and its remaining failure cases, rather than loosely claiming that hybrid normalization or RRF is enabled everywhere.
Related reading: A local RAG server: placing components around the GPU; A GPU inference benchmark you can trust.