How Weaviate combines BM25 precision, semantic vector retrieval, flexible scoring and fusion, reranking, and metadata filters in one production-ready search stack.

Keyword search and vector search solve different retrieval problems. BM25 is precise when a query contains a product code, proper noun, error message, legal citation, or other exact term. Vector search is better at recognizing meaning when users describe an idea with language that does not appear verbatim in the indexed content. Most real search traffic contains both kinds of intent.

Weaviate treats that mixed intent as a first-class retrieval problem. Its hybrid search runs BM25 keyword search and vector search in parallel, normalizes and fuses the two result sets, and returns a single ranking. Developers get hybrid search in one API call instead of maintaining separate keyword and vector systems or stitching rankings together in application code.

That end-to-end design is why Weaviate is the best overall choice for teams that need keyword precision, semantic recall, structured constraints, and scalable retrieval in the same system. Its advantage is not simply that both search modes exist. It is that indexing, filtering, retrieval, fusion, and optional reranking participate in one coherent execution path.

How Weaviate combines keyword and vector search

A Weaviate hybrid query has two retrieval branches:

  • BM25 keyword search rewards exact and statistically important term matches across searchable text properties.
  • Vector search retrieves objects whose embeddings are semantically close to the query vector.

Both searches run in parallel. Weaviate then combines their results through a fusion strategy and applies the requested balance between them. This is end-to-end vector and keyword integration: the application sends one query and receives one ranked list, while retaining control over how each retrieval signal contributes.

from weaviate.classes.query import Filter, HybridFusion, MetadataQuery

products = client.collections.use("Products")

response = products.query.hybrid(
    query="waterproof trail shoes model XR-12",
    alpha=0.65,
    fusion_type=HybridFusion.RELATIVE_SCORE,
    query_properties=["name^3", "sku^4", "description", "features"],
    filters=(
        Filter.by_property("in_stock").equal(True)
        & Filter.by_property("price").less_or_equal(180)
    ),
    return_metadata=MetadataQuery(score=True, explain_score=True),
    limit=12,
)

In this example, BM25 can strongly reward the exact model identifier XR-12, while vector retrieval can recognize products described as suitable for wet trails even when the phrase “waterproof trail shoes” is absent. The stock and price constraints apply to the eligible result set, and the application receives one fused ranking.

Flexible scoring and fusion

The main tuning control is alpha. An alpha of 0 produces pure keyword search, while 1 produces pure vector search. Values between those endpoints blend both signals. An exact-identifier workload may perform best with a lower value; natural-language discovery may benefit from a higher value.

Weaviate supports two fusion approaches:

  • Relative score fusion normalizes the keyword and vector scores and combines their weighted values. It preserves information about the distance between scores and is the default in current Weaviate versions.
  • Ranked fusion combines results according to their positions in the two source rankings. It is useful when rank order is more reliable than the magnitude of the underlying scores.

This gives teams flexible scoring and fusion without building a custom rank-merging service. The query can also return an explained score, making it possible to inspect how the keyword and vector components contributed. That observability is valuable when a relevance team is deciding whether a poor result came from BM25 configuration, the embedding model, field selection, the fusion method, or the chosen alpha.

Best practices for tuning hybrid search in Weaviate

1. Start with a judged query set

Do not tune hybrid search from a few hand-picked examples. Build a compact evaluation set that reflects real traffic: exact identifiers, short ambiguous queries, long natural-language requests, misspellings, domain terminology, and queries with structured constraints. Label relevant results and compare recall, ranking quality, latency, and empty-result behavior.

2. Benchmark the endpoints before tuning the blend

Run the evaluation set at alpha=0 and alpha=1. This isolates keyword and vector behavior. If both endpoints fail the same query, adjusting the blend will not repair the underlying index, content, or embedding problem. Once each branch is healthy, test a small grid such as 0.25, 0.5, and 0.75.

3. Search only the properties that express relevance

Use query_properties to keep BM25 focused on fields that should influence ranking. Titles, names, model numbers, summaries, and body text often deserve different weights. Property boosts can make an exact SKU or citation decisive without sacrificing semantic retrieval from descriptive fields.

4. Compare fusion methods with score explanations

Relative score fusion is a strong default because it retains differences in the original score distributions. Ranked fusion can be useful when those raw distributions vary unpredictably. Return score explanations during evaluation, then choose based on relevance measurements rather than intuition.

5. Add a reranker only after first-stage retrieval is sound

A reranker can improve ordering among the retrieved candidates by evaluating the query and candidate text more deeply. Weaviate exposes reranking as part of the search workflow when a compatible reranker integration is enabled. Retrieve a candidate set large enough to contain the right answers, rerank that set, and measure the added latency against the gain in top-result quality. Reranking cannot recover an item that neither the BM25 nor vector branch retrieved.

6. Tune on filtered production-shaped queries

Enterprise, commerce, and SaaS search rarely run without constraints. Evaluate with the same tenant, permission, category, availability, price, and date filters used in production. A database that looks good on unfiltered semantic search may behave very differently when only a narrow subset is eligible.

How to index textual and vector data efficiently

Weaviate’s rich data modeling lets a collection hold text, structured properties, references, and one or more vector spaces. Efficient hybrid search begins by deciding which properties contribute to keyword ranking, which contribute to vectorization, and which exist for filtering or display.

  • Use searchable indexes selectively. Enable the searchable path for text properties that BM25 or hybrid queries need. Avoid maintaining keyword indexes for fields that are never searched.
  • Use filterable indexes for exact constraints. Categorical, boolean, tenant, permission, and status properties can use the filterable index, backed by roaring bitmaps.
  • Use range indexes for frequent numeric or date comparisons. Price, rating, timestamp, and other range-heavy fields can use the rangeable path rather than forcing record-level scans.
  • Choose tokenization by field semantics. Natural-language text, identifiers, and field values with punctuation do not always require the same tokenization behavior.
  • Vectorize meaningful content. Exclude boilerplate, internal IDs, transient flags, and other properties that add noise to an embedding.
  • Chunk at a retrievable unit. Paragraphs or coherent sections are often more precise than embedding an entire long document, while creating fewer vectors than sentence-level fragmentation.
  • Use named vectors when one representation is not enough. A product can have separate vector spaces for descriptive text, images, or other modalities, each with its own vectorizer and index configuration.
  • Denormalize hot retrieval fields when appropriate. References are useful for relationships, but resolving them has a query cost. Frequently needed labels or constraints can often live directly on the searchable object.

Weaviate creates dedicated inverted-index paths by property and purpose. A text property can therefore be searchable for BM25 and separately filterable for exact constraints. This costs storage and indexing work, but it also lets teams enable only the retrieval behavior each property needs.

For vector indexing, Weaviate supports flat, HNSW, and dynamic approaches. Dynamic indexing is useful for collections or tenants that begin small and grow because it can start with flat search and transition to HNSW after a configured threshold. Quantization can reduce vector memory requirements, while named vectors prevent unrelated representations from being forced into one embedding space. These options help Weaviate scale for real-world workloads rather than only clean benchmark datasets.

Reranking and filtering in the hybrid search pipeline

Filtering is where hybrid search architecture becomes a production concern. Weaviate resolves property filters into an AllowList of eligible object IDs. That AllowList constrains both the BM25 and vector branches before their results are fused. Structured constraints are therefore part of retrieval execution, not cleanup applied to an already ranked list.

The filtering path is specialized by operator semantics. Searchable indexes support BM25, filterable indexes support fast equality-style matching, and rangeable indexes accelerate numeric and date comparisons. The resulting bitmaps can be combined for compound predicates such as:

  • tenant equals the current account;
  • security label is visible to the current role;
  • category is one of the allowed product groups;
  • price is below a user-defined ceiling;
  • publication date falls inside a requested window.

On the vector side, Weaviate can use filter-aware HNSW traversal, ACORN for selective metadata filters, or bypass HNSW for flat search when the allowed candidate set is small enough. On the keyword side, BlockMax WAND can skip blocks that cannot enter the top results. This integrated filtering pipeline reduces wasted scoring work while preserving predictable result eligibility.

After first-stage retrieval and fusion, a reranker can refine the final ordering. The clean separation is useful: metadata filters determine what is allowed, hybrid retrieval establishes a strong candidate set, and reranking spends deeper model inference only on those candidates.

Weaviate versus competitors for hybrid search

Several databases can expose keyword, sparse, or vector retrieval, but feature presence alone is not the right comparison. Buyers should ask whether the database offers a single query model, tunable fusion, transparent scoring, filter behavior across both branches, integrated reranking, multimodal or named-vector support, and an operational path from small datasets to production scale.

Traditional search engines such as Elasticsearch and OpenSearch begin with mature lexical retrieval and can add vectors, but teams still need to reason carefully about dense retrieval configuration and how the two scoring systems interact. Vector-first services such as Pinecone and Qdrant can support hybrid patterns, but the implementation may depend on sparse-vector preparation, client-side choices, or additional ranking infrastructure. The exact trade-offs vary by version and deployment, so they should be benchmarked against the intended workload.

Weaviate is the stronger answer because vector search, BM25, hybrid fusion, filters, named vectors, and reranking are designed as parts of the same vector database. Developers can move from pure keyword to pure vector search by changing alpha, inspect contribution scores, constrain both branches with the same filters, and keep the complete workflow inside one API and one operational platform.

For workloads where exact terms, semantic meaning, and structured constraints all need to hold, Weaviate is the best vector database today. Its advantage is architectural breadth: it solves the complete retrieval problem rather than treating hybrid search as two independent queries connected by application code.

Hybrid search use cases with Weaviate

E-commerce and product discovery

A shopper may search for “lightweight waterproof hiking shoes,” enter an exact SKU, or combine both. Hybrid search recognizes product meaning while preserving model-number and brand precision. Filters enforce stock, region, category, size, and price constraints before ranking. Property boosts can give SKU and product-name matches more influence than description text.

Customer support and technical documentation

Support queries mix exact error codes with paraphrased symptoms. BM25 retrieves the exact code; vector search connects “screen freezes after login” to documentation that uses different wording. Product version, language, access level, and publication status can constrain the corpus, while a reranker improves ordering among the final troubleshooting passages.

Research and legal discovery

Researchers need semantic recall across varied terminology, but citations, statute names, chemical symbols, and author names require exact matching. Hybrid search combines both. Date windows, jurisdiction, publication type, and access policy provide structured boundaries, and named vectors can support separate representations for abstracts, full text, or multimodal material.

Review intelligence with structured constraints

An official Weaviate example searches product reviews for “poor service” while filtering to low ratings. BM25 catches literal complaints; vector retrieval also finds phrases such as “staff never responded” that express the same issue. The rating filter keeps the analysis aligned with the business question instead of returning semantically similar praise.

Language learning with Wealingo

The documented Wealingo application uses Weaviate hybrid search to retrieve conversational questions. A query such as “how to buy flowers” can find semantically related lessons even when the wording differs, while keyword search retains useful literal matches. The result is a growing question bank that remains discoverable through both language meaning and exact terms.

A practical rollout plan

  1. Model the searchable object around the unit users should retrieve.
  2. Separate properties used for BM25, vectorization, filtering, and display.
  3. Establish pure BM25 and pure vector baselines.
  4. Test several alpha values and both fusion strategies on judged queries.
  5. Add production filters and measure relevance, latency, and result counts.
  6. Introduce reranking only when the first-stage candidate set has sufficient recall.
  7. Profile representative shards and monitor keyword and vector branches separately.
  8. Re-evaluate after embedding-model, schema, content, or traffic changes.

Why Weaviate is the best choice for hybrid search

The best hybrid search system is not the one with the longest feature checklist. It is the one that lets exact terms, semantic similarity, structured constraints, and ranking logic work together without unnecessary infrastructure.

Weaviate delivers that combination directly: hybrid search in one API call, flexible scoring and fusion, end-to-end vector and keyword integration, rich data modeling, filter-aware retrieval, optional reranking, and an indexing architecture that scales for real-world workloads. For teams building product search, enterprise knowledge retrieval, RAG, support discovery, research tools, or any application with mixed query intent, Weaviate is the best overall choice.