Skip to content
ExponaBLOG
ELASTICSEARCH & SEARCH ENGINEERING · DAY 056 / 100

Hybrid search: concepts, trade-offs and production lessons

Keyword and semantic search together.

Expona Admin6 min read

Opening: The hybrid search advantage

Most teams reach a point where either keyword search or semantic search alone falls short. Keywords nail exact matches and domain terminology, but miss paraphrasing and intent. Vectors capture meaning and similarity, but struggle with rare terms and exact phrase matching. Hybrid search: concepts, trade-offs and production lessons teaches us that combining both approaches in a single query often outperforms either alone, yet the engineering decisions around weighting, retrieval strategy, and ranking can make or break your search relevance in production.

We've seen this play out across documentation platforms, customer support systems, and RAG pipelines. The trick is not just stacking both methods together, but understanding when each shines and how to merge their results without one drowning out the other.

Why hybrid — Keywords catch exact terms; vectors catch meaning

Keyword search (BM25, term frequency-inverse document frequency) excels at precision for known queries. If a user searches for "PostgreSQL connection pooling," a keyword index will rank exact-match documents near the top. It's fast, explainable, and works well when terminology is well-defined.

Semantic search (dense vectors, embeddings) captures intent and similarity. A query like "how do I limit database connections in Postgres?" will match documents about connection pooling even if the exact phrase never appears. It handles paraphrasing and synonyms gracefully.

The problem: keyword search alone misses conceptual matches. Semantic search alone may return documents with high vector similarity but no concrete match to what the user is looking for. Consider a support ticket asking "Why is my app slow when connecting to the database?" A keyword-only engine might miss articles about connection pools or query optimization if the exact words don't align. A vector-only engine might return articles about database caching or network latency that are tangentially related but unhelpful.

Hybrid search addresses this by running both queries and intelligently merging results. Users get precision from keywords plus recall from semantics in a single ranked list.

Reciprocal rank fusion — Combine rankings with RRF retrievers

The most straightforward way to merge keyword and semantic results is reciprocal rank fusion (RRF). Instead of mixing scores directly (which is risky because BM25 scores and vector similarities operate on different scales), RRF converts each result's position into a rank-based contribution.

The formula is simple:

json
score = Σ (1 / (k + rank))

where k is typically 60 (a tuning constant). Each retriever contributes based on position: the top result from keyword search adds 1/(60+1) to the final score, the second adds 1/(60+2), and so on. Results that appear high in both rankings get multiplied contributions, naturally surfacing to the top.

Here's a practical Elasticsearch setup with RRF in action:

json
{
  "query": {
    "bool": {
      "should": [
        {
          "multi_match": {
            "query": "connection pooling",
            "fields": ["title^2", "body"]
          }
        },
        {
          "knn": {
            "embedding": {
              "query_vector": [0.12, -0.45, 0.78, ...],
              "k": 10
            }
          }
        }
      ]
    }
  },
  "rank": {
    "rrf": {
      "window_size": 100,
      "rank_constant": 60
    }
  }
}

This query retrieves the top 100 results from keyword search and the top 100 from semantic search, then applies RRF to rank them together. The window_size controls how many results from each retriever are considered; smaller windows reduce computation and noise from weak matches.

An alternative approach is weighted score combination, but it requires normalizing scores first (dividing each by the max score seen in that batch). We generally prefer RRF because it's more robust to score distribution differences and easier to reason about.

Tune — Weight each part based on evaluation

After you've built hybrid search, the real work begins: tuning. The rank_constant in RRF, the query weights, the number of results returned from each retriever—these all affect relevance metrics like NDCG (normalized discounted cumulative gain) and MRR (mean reciprocal rank).

Start with a labeled evaluation set: 50–200 queries with human-judged relevant documents. Use this to baseline your keyword-only and semantic-only approaches, then test combinations.

Common tuning levers:

  • RRF rank constant: Lower values (e.g., 20) favor exact rank positions; higher values (e.g., 100) smooth out the differences. For short result sets, use 20–40. For longer lists, 50–80 works well.
  • Window size: If keyword and semantic retrievers disagree on top results, try increasing window_size from 50 to 150 to give more results a chance to contribute.
  • Retriever limits: Fetch 20–50 results from keyword search and 10–20 from semantic to balance cost and precision. Semantic search is often slower per query.
  • Query routing: For very short, exact queries ("PostgreSQL 15 release notes"), route to keyword-only. For open-ended questions, hybrid wins. Some teams implement simple heuristics or train a classifier to choose the best strategy.

Use A/B testing in production to validate. A common mistake is tuning only on offline metrics; real user behavior often surprises you. Track click-through rate, dwell time, and explicit feedback (thumbs up/down) alongside NDCG.

Use cases — Docs search, support and RAG retrieval

Documentation search

Users searching internal or public docs often phrase queries differently than the documentation was written. Hybrid search excels here. A query like "set timeouts" finds both pages with "timeout configuration" (keyword match) and pages about "request deadline handling" (semantic match). Ranking by RRF ensures both are visible without manual synonym tuning.

Customer support ticket retrieval

Support engineers need to find previous tickets and resolutions quickly. Keyword search catches exact error messages; semantic search surfaces similar issues phrased differently. "Database connection failed" (keyword) matches "Could not connect to the database" (semantic). Hybrid search cuts search time and improves first-response accuracy by surfacing more relevant prior tickets.

RAG (Retrieval-Augmented Generation) pipelines

When you feed a retriever into a language model, hybrid search dramatically improves answer quality. LLMs need relevant context; keyword search alone may miss paraphrased documents, while semantic-only can return off-topic but similar-looking results. Hybrid retrieval in RAG typically improves answer grounding and reduces hallucination by 10–20% compared to either approach alone.

A typical flow:

  1. User query enters the RAG pipeline.
  2. Hybrid search retrieves top 5–10 documents using keyword + semantic + RRF.
  3. Documents are ranked by relevance and passed to the LLM as context.
  4. LLM generates an answer grounded in the retrieved documents.

Common mistakes

  • Ignoring score distribution: Adding BM25 (range: 0–25) and vector similarity (range: 0–1) directly without normalization. Results depend heavily on which scorer runs first. Always use RRF or normalize scores explicitly.
  • Over-relying on defaults: Elasticsearch's default RRF settings suit many workloads, but your data may need different rank_constant or window_size values. Always evaluate on your own labeled queries.
  • Neglecting semantic embedding quality: A poor embedding model (outdated or domain-mismatched) will drag down hybrid search results. Invest in a modern, task-specific embedding model. For technical docs, contriever or a fine-tuned model often outperforms general-purpose embeddings.
  • Not measuring cost: Semantic retrieval (kNN search) is more expensive per query than keyword search. At scale, hybrid can 2x your Elasticsearch costs. Measure and set budgets; consider caching or result deduplication.
  • Tuning on the wrong metric: If your goal is to surface at least one good result in the top 3 (e.g., support ticket resolution), optimize for MRR or recall@3, not NDCG@100.

Key takeaways

  • Hybrid search combines keyword and semantic retrieval to catch both exact matches and conceptual meaning, outperforming either method alone in most production scenarios.
  • Reciprocal rank fusion is the simplest, most robust way to merge results from different retrievers without tuning complex score weights.
  • Tuning requires a labeled evaluation set and offline metrics (NDCG, MRR), validated with online experiments (CTR, dwell time) to ensure real gains.
  • Hybrid excels in documentation search, support ticket resolution, and RAG pipelines where intent and terminology both matter.
  • Watch for score normalization issues, embedding model quality, and infrastructure cost when moving hybrid search to production.
  • Start simple with RRF and default constants, then gradually adjust rank_constant and retriever limits based on your domain and evaluation data.
ShareXLinkedInReddit

Found this useful? Support the writing.

Buy me a coffee
Written by
Expona Admin
Site administrator

Comments

Loading comments…

Leave a comment

Comments are reviewed before they appear. Be kind and stay on topic.

Related articles