Start with the query types your corpus actually contains

Before combining retrieval methods, identify the language patterns users bring to the system. Natural-language questions such as “how do I rotate credentials?” may benefit from dense similarity because relevant documents can use different wording. Queries such as “ERR_CONN_RESET”, “ISO 27001”, or a specific API field name often depend on lexical overlap.

This distinction is especially important in technical, support, and enterprise corpora. Those collections commonly contain both explanatory prose and high-value tokens that should not be treated as interchangeable semantic concepts.

  • Use dense retrieval for meaning-oriented queries and paraphrases.
  • Use BM25 for exact phrases, identifiers, product names, and rare terminology.
  • Keep the original query text available for sparse retrieval; do not reduce every query to an embedding alone.
  • Review search logs for zero-result queries, repeated reformulations, and queries containing quoted or code-like terms.

Generate candidates from both retrieval paths

A robust hybrid pattern is to retrieve a bounded candidate set from each path: dense candidates from vector search and sparse candidates from BM25. Talqora’s architecture pairs regional S3 Vectors for dense search with Quickwit BM25 for sparse search, aligning these two retrieval signals with the kinds of content they address.

The important engineering choice is to treat these result lists as inputs to ranking, not as competing declarations of a single truth. A document found by both paths is often a strong candidate, while a document found by only one path can still be valuable when the query has a clear semantic or lexical character.

  • Choose a candidate depth for each path that preserves useful recall while keeping later work bounded.
  • Deduplicate candidates by a stable document or chunk identifier.
  • Record which path retrieved each candidate so ranking behavior can be inspected later.
  • Apply metadata filters consistently to both paths when a query is scoped to a tenant, collection, language, or document type.

Make fusion observable and tune it with real queries

Dense similarity scores and BM25 scores are not inherently on the same scale, so directly adding raw scores can produce unstable results. Instead, use a deliberate fusion method, such as rank-based fusion or a normalized score approach, and evaluate it against a labeled query set. The right method is the one that improves relevance for the queries users actually ask.

Observability turns fusion from a one-time formula into an engineering loop. For each query, retain the candidate ranks, retrieval source, applied filters, and final ordering. When a result looks wrong, this record helps distinguish embedding coverage issues from lexical matching issues or ranking decisions.

  • Use rank-based fusion when score scales are difficult to compare across retrieval systems.
  • Build a small evaluation set that includes semantic questions, exact-term lookups, and mixed queries.
  • Measure outcomes separately by query class rather than relying on one aggregate relevance number.
  • Inspect cases where one retrieval path finds the desired result and the other does not; they reveal where each signal adds coverage.