Part 1 ended with two search methods and two opposite blind spots. Lexical search finds the exact bid number and misses the paraphrase. Semantic search finds the paraphrase and loses the bid number. The obvious answer is to use both, and most serious retrieval platforms now support doing exactly that.
The less obvious part is how. Two searches return two ranked lists, scored on scales that have nothing to do with each other. Merge them carelessly and one method quietly dominates the other, and you are back to the single blind spot you were trying to escape. This part explains hybrid search without the mathematics getting in the way, and is honest about what it does not solve.
Bergvliet Engineering is fictional, and its systems and figures are illustrative. Its Bid Library assistant, introduced in Part 1, failed on questions that named a specific bid. The platform team's first fix was hybrid search.
The library analogy
Picture a good reference library and a librarian you trust.
- Lexical search is asking for every book that contains an exact phrase. Ask for "BE-T-2024-0219" and you get exactly the books that mention it, in order of how prominently they do.
- Semantic search is asking for books about an idea. Ask about "keeping trenches dry" and you get books on dewatering, groundwater control and wet-season earthworks, even if none uses your words.
- Hybrid search is asking both questions at once and combining the two lists into one.
- Reranking is the librarian taking the combined pile, reading the first page of each book against your actual question, and putting the ones that answer it on top.
Each step does a different job. Retrieval casts the net. Fusion merges the catches fairly. Reranking applies judgement to a short list. Most of the quality problems in production come from collapsing these jobs into one, or skipping one.
Why you cannot just add the scores
The tempting merge is arithmetic: take each document's lexical score, add its semantic score, sort. It does not work, because the numbers are not on the same scale.
In Azure AI Search, for example, a BM25 score has no upper limit, while a cosine-similarity vector score sits between roughly 0.33 and 1.0 (Microsoft's hybrid ranking documentation, checked on 14 October 2026). A keyword match scoring 14.2 and a vector match scoring 0.86 cannot be meaningfully added. Whichever method produces the larger numbers wins, regardless of which result is better. You can normalise the scores first, and some platforms offer that, but normalisation has its own sensitivities to outliers and to how many results each method returned.
Reciprocal rank fusion, worked through
The method most platforms use by default ignores scores entirely and looks only at positions. It is called reciprocal rank fusion, or RRF, and it comes from a short 2009 SIGIR paper by Gordon Cormack, Charles Clarke and Stefan Büttcher, titled, with some confidence, "Reciprocal rank fusion outperforms Condorcet and individual rank learning methods".
The rule is simple. For each list a document appears in, it earns 1 divided by (k + its rank in that list). Add up the earnings across lists. Sort by the total. The constant k dampens the advantage of the very top positions so that a document ranked highly by two methods can beat one ranked first by only one. The paper used k = 60, a value its authors fixed in a pilot and did not tune further, and 60 has become the common default: Azure AI Search describes 60 as a good small value, and OpenSearch's RRF processor, added in version 2.19, defaults its rank constant to 60.
Work through Bergvliet's illustrative example. The engineer asks about dewatering commitments on BE-T-2024-0219. The standard dewatering procedure, SP-031, ranks second in both lists and finishes first. The bid's own method statement ranks first lexically but only fourth semantically, and finishes a close second. A lessons-learnt note that only semantic search found still makes the list, lower down. The bid's cover letter, which mentions the number but says nothing about dewatering, finishes last.
That is the useful behaviour of RRF: it rewards agreement. A document both methods consider good beats a document only one method loves. It also means nothing is lost; a document one method missed completely can still surface on the strength of the other.
Note what RRF did not do. It did not put the bid's own method statement first, which is what the engineer actually wanted. Fusion produces a fairer candidate list, not a final answer. That is the reranker's job.
What the reranker adds
Retrieval methods score documents and questions separately. The question becomes one representation, each document another, and the engine compares them. That is what makes retrieval fast enough to search tens of thousands of documents in milliseconds, and it is also why it is approximate.
A reranker reads the question and each candidate together and scores how well that candidate answers that question. This is slower and more expensive per document, so it runs only on the short list fusion produced. Azure AI Search's semantic ranker, for instance, reranks at most the top 50 results of a keyword or hybrid query, and scores each from 0 to 4 for relevance (semantic ranking overview, checked on 14 October 2026). Open-source cross-encoder models do the same job in self-hosted stacks.
With a reranker in place, the bid's own method statement moved to the top of Bergvliet's list for that question, because the reranker could see that a document explicitly about BE-T-2024-0219 and dewatering answers the question better than a general dewatering procedure. Part 6 looks at what the reranker costs and how many candidates it should see.
Where you will find hybrid search
Hybrid retrieval is no longer specialist infrastructure. Checked on 14 October 2026:
- Azure AI Search runs a keyword query and one or more vector queries in parallel and merges them with RRF, with optional semantic reranking afterwards.
- OpenSearch supports hybrid queries with either score normalisation or RRF through a search pipeline processor. Its own benchmark notes report RRF averaging slightly lower nDCG@10 than its score-based hybrid method on six BEIR datasets, a useful reminder that the default is a reasonable starting point, not a guaranteed best.
- PostgreSQL with pgvector can combine vector search with Postgres full-text search, and the pgvector project documents both RRF and cross-encoder reranking as ways to merge the results.
The mechanics differ; the pattern is the same. Pick the platform that fits your estate and skills, then spend your effort on the decisions around it.
Practical choices that matter more than the algorithm
Make identifiers findable on purpose. Bergvliet's analyser was splitting BE-T-2024-0219 into fragments, so lexical search matched any document containing "2024". The fix was a dedicated field for bid numbers, procedure codes and clause references, indexed as exact keywords and boosted. Extracting identifiers from the question and searching them directly did more for precision than any fusion setting.
Check your analysers per language. Lexical search stems words, removes common ones and handles compound words differently per language. If part of the corpus is Afrikaans, confirm what the platform's analyser does with it rather than assuming English rules apply.
Weight the methods deliberately. Most platforms let you favour one list over the other. Start equal, then adjust only on the evidence of an evaluation set, never on a handful of demo questions.
Keep the lists long enough. Fusion can only promote what retrieval returned. If each method returns ten candidates, a relevant document ranked eleventh by both is gone.
Hybrid search is a pattern, not an architecture
After hybrid search and a reranker, Bergvliet's answers on identifier questions improved sharply. Then a commercial manager asked about night-work rates and was given a restricted rate schedule, which commercial staff are allowed to see. A site engineer asked the same question and was given the same schedule, which site engineers are not.
Hybrid search makes retrieval more relevant. It does nothing about who may see the result, whether the document is still current, whether the chunk contains the whole clause, or whether anyone can tell later what evidence the answer used. Part 3 lays out the full pipeline those questions belong to.
Key points
Hybrid search runs two searches and merges them. Lexical for exact tokens, semantic for meaning.
Raw scores cannot be added. They sit on different scales, so one method silently wins.
Rank fusion rewards agreement. RRF uses positions, not scores, with a constant commonly set to 60.
A reranker applies judgement to a short list. It reads the question and each candidate together, and costs more per document.
Identifier handling beats algorithm tuning. A dedicated, exact field for codes and numbers often matters most.
Next: Part 3, The retrieval pipeline, end to end. All parts are on the series page.
How CloudNala can help
We help teams move a vector-only pilot to hybrid retrieval on the platform they already run, whether that is Azure AI Search, OpenSearch or PostgreSQL. The work starts with real questions and expected documents, so every change to fusion, weighting, analysers or reranking is judged on measured retrieval quality rather than on how the demo felt.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book a RAG Production Review or write to us at consult@cloudnala.co.za