Mastering Hybrid Search in OpenSearch: The Best of Both Worlds

OpenSearch hybrid search runs a lexical (BM25) query and a semantic (vector) query in a single request, then uses a search pipeline to put their scores on a common scale and combine them into one ranking. You get the precision of keyword matching and the intent-awareness of embeddings without stitching two result lists together in your application.

For a long time, you had to choose between the two. On one side is keyword search, the backbone of search engines for decades: precise, exact, and great at finding specific terms. On the other is semantic search, which understands context and intent even when the exact words do not match. Hybrid search lets you have both.

What is hybrid search?

Hybrid search is not just a buzzword; it is a practical architecture that combines the precision of lexical search with the understanding of semantic search.

Imagine a user searches for "warm winter coat."

• Lexical search looks for the exact words "warm," "winter," and "coat." It might miss a "thermal parka" because the words do not match.
• Semantic search understands that a "thermal parka" is a type of "warm winter coat" and retrieves it.

By combining these two, you get results that are both keyword-accurate and contextually relevant.

How does hybrid search work in OpenSearch?

Implementing hybrid search involves a few key steps:

1. Ingestion: You index your data into OpenSearch. During this process, you use an ingest pipeline to generate vector embeddings for your text fields. These embeddings are numeric representations of the text's meaning.
2. Querying: When a user searches, a single hybrid query carries two sub-queries: a standard BM25 query (lexical) and a neural or knn query (semantic).
3. Score normalization: Lexical queries and vector queries produce scores on very different scales. A BM25 score is unbounded, while a vector similarity score sits in a narrow range. You cannot just add them up, so you normalize them first.
4. Combination: Once normalized, the scores are combined (often using a weighted average) to produce a final ranking.

Steps 3 and 4 happen in a search pipeline, between the query and fetch phases, on the coordinating node.

Which normalization and combination techniques can you use?

The normalization-processor (introduced in OpenSearch 2.10) normalizes each sub-query's scores independently and then combines them:

• Normalization: min_max (the default), l2, and z_score. Z-score normalization was added in the 3.x line and works only with the arithmetic_mean combination technique.
• Combination: arithmetic_mean, geometric_mean, and harmonic_mean, with optional per-query weights.

One subtlety worth knowing: normalization statistics come from the results each sub-query returns, not from the whole index, so the number of results each clause returns can change the final scores.

What does the score ranker processor do?

The score ranker processor (score-ranker-processor, introduced in OpenSearch 2.19) takes a different approach: reciprocal rank fusion (RRF). Instead of rescaling scores, it scores each document by the reciprocal of its rank in each sub-query's results and adds those up. Because only ranks matter, the raw scores never need to be on comparable scales. You can tune the rank_constant (default 60) and give each sub-query a weight.

PUT /_search/pipeline/rrf-pipeline
{
  "description": "Post processor for hybrid RRF search",
  "phase_results_processors": [
    {
      "score-ranker-processor": {
        "combination": {
          "technique": "rrf"
        }
      }
    }
  ]
}

Which one should you pick? Score-based normalization keeps more information about how strongly each document matched; RRF is more robust when the two score distributions behave very differently. We compare both, with measured scores, in Hybrid search scoring, explained.

What changed in OpenSearch 3.x?

The 3.x line (3.9 is the current release as of this update) brought several changes that touch hybrid search:

• OpenSearch 3.0 moved to Lucene 10 and added z-score normalization for hybrid search.
• OpenSearch 3.1 added a semantic field type that streamlines setting up semantic search.
• OpenSearch 3.3 introduced system-generated search processors, which OpenSearch attaches automatically for features such as maximal marginal relevance (MMR) reranking and semantic highlighting. See our guide to search pipelines for details.

How do you write a hybrid query?

Here is a simplified example of a hybrid query in OpenSearch:

POST /my-index/_search?search_pipeline=hybrid_search_pipeline
{
  "query": {
    "hybrid": {
      "queries": [
        {
          "match": {
            "text": {
              "query": "warm winter coat"
            }
          }
        },
        {
          "neural": {
            "embedding": {
              "query_text": "warm winter coat",
              "model_id": "your_embedding_model",
              "k": 10
            }
          }
        }
      ]
    }
  }
}

In this setup, the hybrid_search_pipeline holds either a normalization-processor or a score-ranker-processor, which handles the normalization and combination logic and keeps your application code clean.

Conclusion

Hybrid search bridges the gap between what users say and what they mean. OpenSearch gives you two well-supported ways to combine the signals, score normalization and RRF, both configured in a search pipeline rather than in your application. Start with the defaults, measure relevance on your own queries, and tune weights from there.

Ready to implement hybrid search? Check out our OpenSearch Consulting services to get expert help.

Sources

• OpenSearch documentation, Normalization processor
• OpenSearch documentation, Score ranker processor
• OpenSearch documentation, System-generated search processors
• OpenSearch documentation, Version history