Hybrid retrieval combines results from different search methods, commonly lexical keyword search and dense-vector semantic search, into one ranked candidate list. For a quant searching filings, this can preserve a specific instrument identifier while also finding a passage that describes the same exposure in different words. It is a retrieval method; it does not by itself verify a financial claim or generate an answer.
Two routes to the same evidence
Consider the fictional query “Issuer QX7 refinancing risk”. A lexical retriever can reward the actual identifier and the words “refinancing risk”. A dense semantic retriever might also surface a paragraph about debt falling due when access to funding deteriorates, even if that paragraph uses neither phrase. These are complementary ways to find candidates, not guarantees that either passage answers the question. This lexical-plus-vector pairing is the common hybrid-search workflow described in Elastic’s documentation.
| Retrieval signal | What it compares | Where care is needed |
|---|---|---|
| Lexical, often BM25 | Query tokens against indexed text; BM25 weights term frequency, document frequency and document length | Tokenisation and stemming can alter identifiers. Exact issuer, instrument or date requirements need appropriate fields and filters. |
| Dense semantic | A query vector against passage vectors produced by a text embedding model | Similar subject matter can include the wrong issuer, period or direction of a claim. |
“Lexical” does not necessarily mean exact character matching: full-text search commonly analyses text first. Semantic retrieval is also broader than dense embeddings; learned sparse representations are another option. Here, the semantic branch means dense-vector similarity. See Elastic’s full-text explanation and semantic-search overview for these distinctions.
A rank-fusion calculation
The two branches need a rule for merging their results. Reciprocal rank fusion (RRF) uses positions in the lists rather than their raw relevance scores. With ranks starting at one and an offset , its equal-weight score is
Here is the returned candidate list from retriever , and is the candidate’s position in that list. A candidate absent from a returned list contributes zero for that list; it does not receive rank zero. Cormack, Clarke and Büttcher introduced the method with in their 2009 paper. Their empirical results concern their tested collections, not a guarantee for financial documents.
For an illustrative pair of candidates, stipulate these ranks:
| Candidate | Lexical rank | Semantic rank |
|---|---|---|
| A | 1 | 3 |
| B | 2 | 1 |
Other candidates occupy unshown positions, including semantic rank two. These ranks are inputs to an arithmetic example, not measured retrieval performance. With ,
B ranks ahead of A. Their shared rank-one contribution cancels; B’s other contribution is , greater than A’s . This comparison says nothing about an unshown candidate’s fused position or either passage’s factual accuracy.
Figure: Each bar adds the two rank contributions. B’s slightly larger total wins this pairwise comparison; the lists and ranks are fictional.
The offset controls how sharply contribution falls with rank. It is separate from a retrieval “top-k” count, which controls how many candidates a branch returns, and from the final number of passages retained. A cutoff can remove a candidate’s contribution before fusion. Elastic’s RRF reference separates the rank constant from the candidate window; Azure’s explanation explicitly distinguishes the offset from nearest-neighbour count.
Fusion, reranking and checking the source
RRF discards score gaps: first and second place contribute according to rank whether their original scores were close or far apart. Weighted score fusion instead combines relevance scores, usually after a specified normalisation. The scales matter: adding an unnormalised lexical score to a vector similarity can let one branch dominate. Elastic’s linear-retriever reference documents normalised weighted score fusion.
A subsequent reranker can assess the query and candidate text together to reorder the shortlist. That adds another relevance judgement; it cannot recover a passage excluded from every candidate list. Elastic’s reranking overview distinguishes this later stage from initial retrieval and fusion.
In a financial research workflow, keep three checks separate:
- Retrieval relevance: compare lexical, semantic and hybrid results on held-out questions with judged relevant passages. Include identifiers and paraphrases; inspect misses as well as the first result. More branches do not automatically mean better retrieval.
- Information available as of the research date: retain publication and availability timestamps and the relevant document version. A highly ranked amended filing published later cannot support what was knowable earlier. Apply the intended date and access restrictions consistently across branches.
- Citation accuracy: open the cited passage and check issuer, period, units and qualification. Similarity and rank do not show that a passage supports the specific sentence attributed to it.
Hybrid retrieval can supply evidence to retrieval-augmented generation, but the quality of the eventual answer also depends on how that evidence is interpreted and cited.
For the vector-geometry background, the Embeddings lesson explains distributed representations, document aggregation and task-specific validation. The public page is a preview; the full lesson requires membership. It supplies background for the semantic branch rather than a hybrid-search implementation.
Sources
- Cormack, G. V., Clarke, C. L. A., and Büttcher, S. (2009). Reciprocal Rank Fusion outperforms Condorcet and individual Rank Learning Methods, SIGIR, pp. 758–759. Formula and original evaluation.
- Elastic. Hybrid search, How full-text search works and Semantic search. Retrieval branches and representations.
- Elastic. Reciprocal rank fusion, Linear retriever and Semantic reranking. Fusion, candidate windows and later ranking stages.
- Microsoft Learn. Relevance scoring in hybrid search using RRF. Offset versus nearest-neighbour count. Living documentation checked 1 November 2026.