Elasticsearch Hybrid Search

Elasticsearch maintains separate index structures within a single shard: an inverted index for BM25 sparse retrieval and an HNSW graph index for dense vector kNN search. At query time, both indexes are queried in parallel, and their result sets are merged via RRF.

• Sparse index: Maps terms to document postings lists with TF-IDF statistics for exact lexical matching
• Dense index: Stores dense_vector field types with configurable similarity metrics (cosine, dot_product, L2_norm)
• Concurrency: Both retrieval paths execute simultaneously within the search thread pool, minimizing latency overhead

Elasticsearch allows per-query adjustment of the relative influence of lexical and semantic signals through boost parameters on individual query clauses. This enables dynamic fusion weight tuning without re-indexing.

• Lexical boosting: Apply boost: 2.0 to the match query for queries containing rare product codes or identifiers
• Semantic boosting: Increase the kNN query boost for conceptual or natural language queries
• Implementation: Weights are applied before RRF fusion, scaling each subsystem's contribution to the final reciprocal rank sum

Elasticsearch supports pre-filtering where metadata constraints (date ranges, categories, access control lists) are applied to the HNSW graph traversal before vector similarity is computed. This ensures the kNN search operates only on authorized or contextually valid document subsets.

• Filter application: Filters are pushed down to the Lucene segment level, restricting the vector search graph to qualifying documents
• Contrast with post-filtering: Pre-filtering guarantees exactly k results, whereas post-filtering may return fewer after top-K candidates are pruned
• Performance: Pre-filtering on large indexes may increase latency if the filter eliminates most of the graph; consider num_candidates tuning

Beyond RRF fusion, Elasticsearch supports a multi-stage retrieval pipeline where the fused candidate set is passed to a re-ranking stage. This can include a Cross-Encoder model deployed via Elastic's Learned Sparse Encoder or a custom re-scoring script.

• Stage 1: BM25 + kNN retrieval with RRF fusion to generate a candidate pool of 100-200 documents
• Stage 2: Re-rank top candidates using a more computationally expensive model (e.g., a Cross-Encoder) for precise relevance scoring
• Integration: Re-rankers can be deployed as Elasticsearch inference processors using the Eland client library

Elasticsearch hybrid search can be configured with fallback logic that activates when the primary hybrid pipeline returns zero or low-confidence results. This prevents empty search result pages and ensures graceful degradation.

• Pattern: If RRF-fused results fall below a relevance threshold, the system reverts to a pure BM25 query with query relaxation (e.g., removing optional clauses)
• Implementation: Use a bool query with should clauses and minimum_should_match to define fallback conditions
• Monitoring: Track fallback activation rates via Elasticsearch slow logs to identify queries where semantic search underperforms

Elasticsearch's default lexical scoring function based on the probabilistic Best Match 25 algorithm. It ranks documents by term frequency saturation and inverse document frequency, excelling at exact keyword matching and rare term identification.

• Term saturation: Prevents term frequency from dominating via non-linear tf/(tf + k1) scaling
• Field length normalization: Shorter fields receive a boost via the b parameter
• Strengths: Unmatched precision for product codes, IDs, and exact phrases where semantic drift is undesirable

Elasticsearch's dense retrieval capability that indexes document embeddings and performs approximate nearest neighbor search using HNSW graphs. Queries are encoded into the same vector space, and similarity is computed via cosine or dot product.

• HNSW algorithm: Hierarchical Navigable Small World graphs provide logarithmic search complexity with high recall
• num_candidates: Controls the exploration-vs-speed tradeoff during vector search
• Integration: Vectors can be generated within Elasticsearch via ELSER or uploaded from external models like sentence-transformers

A prerequisite for weighted fusion methods that rescales BM25 and vector similarity scores into a common [0,1] range. Without normalization, raw BM25 scores (which can be unbounded) would dominate cosine similarity scores (bounded [-1,1]) in a linear combination.

• Min-Max: Rescales using observed min and max per query, sensitive to outliers
• Standard Score (Z-score): Centers around mean with unit variance, assumes normal distribution
• Elasticsearch's RRF advantage: Bypasses normalization entirely by operating on ranks rather than scores

A preprocessing stage that analyzes the user's query to dynamically adjust fusion weights. Navigational queries ("login page") benefit from lexical boosting, while informational queries ("how to configure shard allocation") require stronger semantic weighting.

• Lexical indicators: Presence of codes, version numbers, or error strings signals high BM25 weight
• Semantic indicators: Natural language questions or abstract concepts signal high kNN weight
• Implementation: Can be rule-based (regex patterns) or ML-driven using a lightweight classifier model

Two architectural patterns for combining metadata constraints with vector search in Elasticsearch. Pre-filtering applies filters before the kNN search, ensuring the HNSW graph traversal only visits valid documents. Post-filtering retrieves top-K vectors first, then applies filters, risking fewer than K results.

• Pre-filtering: Higher precision, guaranteed result count, but requires efficient filter intersection with the vector index
• Post-filtering: Faster when filters are complex, but may return empty pages if top semantic matches are filtered out
• Elasticsearch default: Uses pre-filtering via filter context within kNN clauses