4 OpenSearch Hybrid Search Technique, Tutorial, and Best Practices

What Is OpenSearch Hybrid Search?

OpenSearch Hybrid Search combines traditional keyword-based retrieval with semantic search techniques within the OpenSearch ecosystem. Instead of relying only on lexical matching, such as exact keyword or phrase occurrence, hybrid search uses both lexical methods and neural or vector-based retrieval. This allows it to capture literal matches and contextual similarities between queries and documents, returning more relevant results.

By integrating multiple retrieval strategies, hybrid search in OpenSearch addresses the limits of single-method systems. Lexical search is fast and works well for precise queries, but it struggles with synonyms, paraphrasing, or conceptual similarity. Semantic search, enabled by machine learning models, fills these gaps by interpreting intent and meaning. OpenSearch Hybrid Search coordinates these methods, using scoring and combination techniques to deliver results that are accurate and contextually relevant.

OpenSearch hybrid search techniques at a glance:

The following table summarizes the key hybrid search techniques. We explore them in more detail below.

Why Hybrid Search Matters in OpenSearch

Hybrid search improves search quality by combining the strengths of different retrieval methods. It helps OpenSearch return relevant results for both exact keyword queries and natural language searches, making it suitable for a wide range of applications.

• Higher relevance: Combines lexical and semantic retrieval to produce more accurate search results.
• Better query understanding: Matches documents based on exact terms and intended meaning.
• Support for synonyms and variations: Finds relevant content even when different words or phrases are used.
• Improved user experience: Increases the likelihood that users find needed information on the first search.
• Flexible relevance tuning: Lets you adjust how lexical and semantic scores are combined.
• Broader search coverage: Retrieves documents that keyword search or semantic search alone might miss.
• Suitable for modern search applications: Works well for enterprise search, knowledge bases, ecommerce catalogs, documentation, and customer support systems.

How OpenSearch Hybrid Search Works: Key Techniques

1. Lexical Search with BM25

Lexical search is OpenSearch’s traditional full-text retrieval method and uses the BM25 ranking algorithm by default. BM25 evaluates documents based on term frequency, inverse document frequency, and document length to determine how closely they match a query. 

OpenSearch automatically applies BM25 to full-text queries such as match and multi_match, while also supporting structured queries like term and range. Developers can further improve relevance through field boosting, assigning greater importance to matches in fields such as titles or product names.

Pros:
BM25 is fast, scalable, and delivers low query latency because it relies on indexed terms. It performs well for exact keyword searches, making it a good fit for product catalogs, technical documentation, enterprise search, and other applications where users know the terminology they are looking for.

Cons:
Lexical search matches words rather than meaning. It may miss relevant documents that use synonyms, different phrasing, or related concepts, making it less effective for conversational or natural language queries.

2. Semantic Search with Vectors or Neural Search

Semantic search retrieves documents based on meaning instead of exact keywords. During indexing, machine learning models generate dense vector embeddings that capture the semantic content of documents and store them in vector fields. When a query is submitted, OpenSearch generates a matching embedding and performs a k-nearest neighbor (k-NN) search to find the most semantically similar documents using similarity metrics such as cosine similarity or inner product.

Pros:
Semantic search understands synonyms, related concepts, and natural language queries, allowing it to retrieve relevant documents even when they share few or no keywords with the search query. This improves search quality for conversational applications and knowledge discovery.

Cons:
Semantic search may overlook exact matches that are critical for identifiers, product codes, legal terms, or other precise queries. It also requires embedding models, vector indexes, and additional infrastructure compared to traditional lexical search.

Related content: Read our guide to OpenSearch vector search.

3. Score-Based Normalization

Hybrid search runs lexical and semantic searches independently, but their scores cannot be compared directly because they use different scoring systems. Score-based normalization converts both sets of scores to a common scale before combining them into a final relevance score. OpenSearch supports techniques such as min-max normalization, L2 normalization, and z-score normalization, followed by combination methods such as weighted arithmetic mean.

Pros:
Score-based normalization gives developers fine-grained control over relevance by adjusting normalization methods and weighting lexical and semantic contributions. This makes it easier to tune search behavior for different workloads.

Cons:
Finding the right normalization technique and score weights often requires experimentation and continuous evaluation. Poorly chosen settings can reduce search relevance instead of improving it.

4. Rank-Based Normalization

Rank-based normalization combines search results according to their positions in each result list rather than their raw scores. The most common implementation is reciprocal rank fusion (RRF), which rewards documents that consistently rank near the top of both lexical and semantic search results. This approach avoids direct comparison of incompatible scoring systems.

Pros:
Rank-based normalization is simple to configure, resists score outliers, and works well when lexical and semantic scoring distributions differ significantly. It also eliminates the need for manual score calibration.

Cons:
Because it ignores score magnitude, rank-based normalization provides less control over how much each retrieval method influences the final ranking. It may also overlook meaningful differences in document relevance reflected by the original scores.

Common Use Cases for OpenSearch Hybrid Search

Enterprise Knowledge Search

Hybrid search works well in enterprise knowledge management scenarios, where employees need to find information across documents, wikis, emails, and other sources. Lexical search retrieves precise matches, such as document titles or policy names, while semantic search uncovers related content that uses different terminology.

For example, an employee searching for “remote work guidelines” might find a document titled “Work from Home Policy” through semantic matching, even if the exact phrase is not present.

Ecommerce and Catalog Search

In ecommerce, hybrid search improves product discovery by handling specific and vague queries. Lexical search ensures that product codes, names, or SKUs return accurate matches, while semantic search enables shoppers to find items using broader descriptions or synonyms.

For instance, a customer searching for “running shoes” might also see results for “trainers” or “athletic footwear” due to semantic matching.

Retrieval-Augmented Generation (RAG)

Retrieval-augmented generation (RAG) uses hybrid search to fetch relevant documents or passages that inform generative AI systems such as chatbots or summarization tools. The lexical component retrieves documents with direct keyword matches, while the semantic layer includes conceptually related materials.

This approach supports scenarios where accurate, current information is needed for responses.

Log and Observability Search

Hybrid search is useful for log analytics and observability, where engineers correlate logs, metrics, and traces using structured queries and natural language. Lexical search pinpoints logs with specific error codes or phrases, while semantic search uncovers related incidents described differently.

For example, searching for “database connection issues” might retrieve logs mentioning “timeout errors” or “failed handshake,” even if the exact query terms are not used.

Tutorial: Configuring Hybrid Search in OpenSearch

This tutorial is adapted from the official OpenSearch documentation. 

Automated Workflow

The fastest way to configure hybrid search is to use OpenSearch’s built-in workflow. It automatically creates the components needed for hybrid search:

• An ingest pipeline for generating embeddings
• A vector index
• A search pipeline for combining lexical and semantic scores

To create the workflow, send a request to the Flow Framework API and provide the ID of the embedding model:

If your embedding model uses a different vector dimension than the default configuration, update the workflow parameters accordingly before provisioning.

The response contains a workflow ID:

 Use the workflow ID to monitor provisioning:

 When the workflow reaches the COMPLETED state, OpenSearch has created:

At this point, you can index documents and start running hybrid search queries.

Manual Setup

Manual configuration provides complete control over each part of the hybrid search pipeline. The process consists of creating an ingest pipeline, creating an index, configuring a search pipeline, indexing documents, and finally executing hybrid search queries.

Step 1: Create an Ingest Pipeline

The ingest pipeline generates vector embeddings during indexing using the text_embedding processor. In this example, the article_text field is converted into embeddings and stored in article_vector.

Step 2: Create a Vector Index

Next, create an index that enables k-NN search and uses the ingest pipeline by default. The vector field must use the knn_vector type, and its dimension must match the output dimension of your embedding model.

Step 3: Configure a Search Pipeline

Hybrid search combines results from multiple queries. Because BM25 and vector search use different scoring scales, configure a search pipeline with a normalization processor to normalize and merge the scores.

The following example uses min-max normalization and combines scores using a weighted arithmetic mean, assigning 30% weight to lexical search and 70% to semantic search.

Step 4: Index Documents

With the ingest pipeline configured, documents automatically receive vector embeddings during indexing.

Index a few sample documents:

As each document is indexed, the article-embedding-pipeline generates an embedding from article_text and stores it in the article_vector field.

Step 5: Run a Hybrid Search Query

A hybrid query can combine traditional keyword search with semantic search. In the following example, a match query and a neural query are executed together, and the search pipeline merges their scores.

OpenSearch Hybrid Search Best Practices

1. Start with Real Search Queries

Hybrid search should be tuned with real search behavior, not isolated examples created by developers. Query logs show how users actually search, including abbreviations, misspellings, vague wording, product names, part numbers, and natural language questions. These patterns are difficult to predict without production data.

Start by collecting a representative set of queries and expected results. Include short keyword queries, long natural language queries, identifier searches, and ambiguous searches. This gives you a balanced benchmark for testing lexical search, semantic search, and hybrid search.

Evaluate the results using metrics such as precision at k, recall at k, mean reciprocal rank, or normalized discounted cumulative gain. These metrics make relevance tuning repeatable and reduce guesswork. Also review failed searches. Queries with no clicks, frequent refinements, or no results often reveal missing synonyms, weak embeddings, poor field mappings, or overly strict filters.

2. Normalize Scores Before Combining Results

BM25 and vector search scores are not directly comparable. BM25 scores depend on term frequency, inverse document frequency, and field length. Vector scores depend on the embedding model, similarity metric, and vector distribution. Combining raw scores can produce misleading rankings.

Always normalize scores before combining lexical and semantic results. OpenSearch search pipelines let you define how scores should be normalized and combined after each retrieval method returns results.

Use higher lexical weights when exact terms matter. This is common for SKUs, error codes, policy names, legal clauses, customer IDs, and technical commands. Use higher semantic weights when users search with broad descriptions, questions, or domain concepts.

Min-max normalization works well when scores are reasonably distributed. If score distributions vary widely across queries, test other normalization methods such as L2 or z-score normalization. For collections with unstable score ranges, rank-based methods such as Reciprocal Rank Fusion can be more reliable because they combine result positions instead of score values.

3. Use Filters for Structured Constraints

Hybrid retrieval should find relevant documents. Filters should enforce structured constraints. Keep these responsibilities separate. This makes queries easier to debug and prevents business rules from interfering with relevance scoring.

Use filters for values such as tenant ID, user permissions, language, region, product category, publication status, date range, and availability. These fields should usually be mapped as keyword, date, boolean, or numeric types.

Pre-filtering reduces the number of candidate documents before scoring. This improves performance and avoids returning documents the user should not see. It is especially important for permission-aware search and multi-tenant applications.

Use post_filter only when you need aggregations to be calculated on the unfiltered result set while filtering the returned hits. This is common in ecommerce faceted search. Avoid putting structured constraints into free-text fields. For example, do not search for "published true region us" in a text query. Use filters so OpenSearch can apply exact matching and caching more efficiently.

4. Tune Embedding Models for the Domain

The embedding model controls how semantic similarity is represented. A generic model may work well for common language, but it can fail on specialized terminology. Technical documentation, legal records, medical content, financial reports, code, and product catalogs often require domain-aware embeddings.

Evaluate embedding models with your own queries and documents. A model that performs well on a public benchmark may not perform well on internal content. Look for failures where semantically related documents are missed or where broadly similar but incorrect documents are ranked too highly.

For long documents, avoid embedding the entire document as one vector. Split content into smaller passages, sections, or chunks. This improves retrieval because the vector represents a focused topic instead of a large document with many unrelated concepts. When tuning embeddings, compare models using the same evaluation set. Track which model returns the correct document in the top 3, top 5, or top 10 results. Also test edge cases such as acronyms, internal product names, error messages, and domain-specific synonyms.

5. Use a Managed OpenSearch Solution for Production Workloads

Hybrid search adds operational complexity compared with standard keyword search. You need to manage vector indexes, embedding models, ingest pipelines, search pipelines, memory usage, shard sizing, scaling, monitoring, backups, and security. These concerns become more important as data volume and query traffic grow.

A managed OpenSearch service can reduce this burden by handling infrastructure operations such as provisioning, patching, high availability, scaling, snapshots, and cluster health monitoring. This allows teams to spend more time improving relevance and less time maintaining the search platform.

Managed deployments are also useful for security-sensitive search. Enterprise search often requires encryption, authentication, authorization, audit logging, and tenant isolation. These controls are easier to operate when they are part of the managed platform.

For production, also define resource limits and monitoring alerts. Vector search can be memory-intensive, especially with large embeddings and high k values. Track latency, heap usage, disk usage, rejected requests, and indexing failures so problems are detected before users experience degraded search.

Running Hybrid Search in Production with Instaclustr for OpenSearch

Hybrid search adds real operational overhead: vector indexes, embedding models, ingest and search pipelines, scaling, monitoring, backups, and security all have to be managed alongside relevance tuning. Instaclustr for OpenSearch is a fully managed, 100% open source service that removes that burden, letting your team focus on search quality instead of infrastructure. It comes with integrated vector search and AI capabilities directly within OpenSearch, so you can build the ingest, vectorization, and search pipelines that hybrid search depends on, all on a platform optimized, secured, and maintained for you.

Key capabilities of Instaclustr for OpenSearch:

• AI-powered search pipelines: Deploy a pipeline to ingest, vectorize, and search your data, supporting semantic search, retrieval-augmented generation (RAG), and chatbot use cases that pair naturally with hybrid queries.
• Integrated vector search: Vector search and AI capabilities are built directly into OpenSearch, providing the semantic half of a hybrid search setup without bolt-on infrastructure.
• Fast, flexible deployment: Spin up production-ready clusters in minutes using the console, API, or Terraform provider, running in your cloud account or Instaclustr’s across AWS, GCP, Azure, on-prem, or hybrid environments.
• Dynamic scaling and performance: Adapt to fluctuating workloads with dynamic scaling, special purpose node types, and configurations tuned from years of operating tens of millions of node hours.
• High availability SLAs: Up to 99.999% availability SLA and up to 99% latency SLAs, backed by built-in redundancy and automatic failover.
• Enterprise-grade security and compliance: Encryption at rest and in transit, strict access controls, and Private Network Clusters, meeting SOC2, ISO27001, ISO27018, PCI-DSS, and HIPAA requirements.
• Data protection: Hourly backups of all OpenSearch data plus searchable snapshots that let you query snapshot data in remote storage without a full restore.
• Proactive monitoring and 24/7 support: Built-in monitoring and round-the-clock support from seasoned OpenSearch professionals.
• Plugin framework and dashboards: Enable OpenSearch plugins at any time through the console, API, or Terraform, and add OpenSearch Dashboards nodes to visualize and navigate your data.

Ready to run hybrid search without managing the underlying platform? Learn more about Instaclustr for OpenSearch and how it can power your search and AI workloads at scale.You can also try OpenSearch AI search for free today, no credit card required.