NVIDIANVIDIA-Certified Professional: Agentic AI2026-106.1 Implement retrieval pipelines (RAG, embedded search, hybrid approaches).
Fuse lexical and semantic retrieval ranks
Completed by the knowledge check
Learning objective
Compare dense, sparse (BM25), and hybrid retrieval with rank fusion.
Core idea
Choose a retrieval method by the kind of mismatch between the question and the relevant passage. Dense retrieval helps when different words express related meanings. Sparse lexical retrieval helps when the words themselves matter: an error code, part number, or exact product term. Hybrid retrieval collects both signals and combines their candidate lists.
Combining lists requires a fusion rule. Dense similarity and a BM25 score are different quantities; adding their raw values does not establish a meaningful balance. Reciprocal Rank Fusion (RRF) combines ranking positions instead. It is a useful baseline when you want both retrieval routes to contribute without first calibrating their score scales.
How it works
Separate semantic similarity from lexical matching
Dense retrieval embeds the question and searches document vectors for semantic similarity. It can find a passage about “lost connectivity” for a question about a “network disconnect.” Its useful generalization can also become a weakness: passages about related failures can outrank the one containing the exact error identifier.
BM25 is a sparse lexical method. NVIDIA’s hybrid-search documentation identifies it as a keyword-matching alternative to dense semantic representations. In Milvus, a text field with enable_analyzer=True supplies terms to a FunctionType.BM25 function, which generates a SPARSE_FLOAT_VECTOR representation. Analyzer choice therefore affects what counts as a lexical match: inspect how it splits technical identifiers before blaming the ranking stage. Treat lexical matching as a signal about the analyzed text rather than proof that a passage answers the question. A release note can mention an error code repeatedly while the actual remediation appears in a short runbook paragraph.
Hybrid retrieval runs both routes and fuses their results. It helps when the corpus and workload contain both natural-language descriptions and domain-specific terminology. It also adds work: another retrieval route, another candidate list, and a fusion stage. It earns that cost when the routes recover relevant passages the other route misses.
Fuse ranks rather than raw scores
Milvus documents RRF as a strategy that combines ranking positions instead of raw similarity scores. Each retrieved document receives a contribution of 1 / (k + rank) from each list in which it appears; the contributions are summed. Here k is the smoothing parameter, not the number of documents returned.
For an illustrative k=60, a passage ranked second by dense retrieval and third by lexical retrieval scores approximately 1/62 + 1/63 = 0.0320. A passage appearing only at lexical rank one scores approximately 1/61 = 0.0164. Agreement between the two lists can therefore outweigh first place in one list. That does not prove the agreed passage is correct: correlated retrieval mistakes can agree too.
Keep three quantities distinct: the number of candidates fetched by each route, the fusion smoothing parameter, and the number of fused candidates retained. A relevant document absent from both input lists receives no rescue from RRF. Increasing only the final output count does not recover a document that neither initial search found.
Configure both ingestion and serving
For the NVIDIA RAG Blueprint’s documented Milvus path, set APP_VECTORSTORE_SEARCHTYPE="hybrid" in both ingestion and RAG services. Its Helm examples put the same setting under the RAG server’s envVars and ingestor-server.envVars. Serving and ingestion must agree about the representation being searched.
The Blueprint uses RRF by default for hybrid fusion. Weighted fusion is an alternative: APP_VECTORSTORE_RANKER_TYPE="weighted", with APP_VECTORSTORE_DENSE_WEIGHT and APP_VECTORSTORE_SPARSE_WEIGHT controlling the relative contributions. The documented starting weights are 0.5 and 0.5. Tune them against the actual question mix rather than assuming equal weights or a dense-heavy setting is always best.
For Milvus, preexisting collections created for dense search do not work after you only change the search type to hybrid. Create a new collection and upload the documents again, as the Blueprint documentation directs. Restarting a RAG server changes its configuration; it does not rebuild the collection’s representations.
There is also a backend boundary: the Blueprint documentation says RRF requires an Elasticsearch commercial license. With open-source Elasticsearch, use the weighted ranker. Do not carry the Milvus RRF deployment choice into another backend without checking that backend’s requirements.
Keep fusion separate from model reranking
Fusion determines how search routes contribute candidates. A model reranker then reads the query and candidate passages to estimate their relevance; see 6.1.3. Milvus calls RRF a ranker, while the Blueprint’s context reranker is an additional model stage. The shared word does not make the mechanisms interchangeable.
The Blueprint exposes vdb_top_k for retrieval candidates and reranker_top_k for retained context after model reranking. If exact-code answers never enter the retrieved pool, first inspect the lexical route and fusion. If they enter the pool but disappear before generation, inspect model reranking and its retained count. This localizes the remedy instead of changing the embedding model for every failure.
Dense and lexical retrieval join at rank fusion, and the model reranker then reads the candidates in the retrieved pool.
Key distinctions and trade-offs
The following choices optimize different signals:
| Option | Deciding condition | Mechanism | Cost or failure risk |
|---|---|---|---|
| Dense | Questions paraphrase the source | Embedding similarity search | Semantic neighbors can obscure exact identifiers |
| Sparse BM25 | Exact terminology distinguishes the right source | Lexical retrieval over sparse representations | Different wording can hide relevant passages |
| Hybrid with RRF | Both routes provide useful, differently scored candidates | APP_VECTORSTORE_SEARCHTYPE, rank-position fusion | More retrieval work; relevant results still need to enter the lists |
| Weighted hybrid | The workload justifies an explicit route preference | APP_VECTORSTORE_RANKER_TYPE, dense and sparse weights | Requires workload-specific tuning and regression checks |
The retrieval owner selects the route and fusion policy. The database owner provisions compatible collections and backend capabilities. A change to ranking settings cannot substitute for a missing ingestion representation.
Architecture / decision scenario
A telecom support assistant handles both error-code questions and conversational descriptions of outages. Its candidate-retrieval budget is 300 ms at the 95th percentile. In an illustrative matched trial, dense retrieval includes the relevant passage in 92% of paraphrase cases but 68% of exact-code cases; BM25 reaches 73% and 96%. Hybrid RRF reaches 94% and 97% at 240 ms.
The tempting proposal is dense-only retrieval followed by a stronger model reranker. The retrieval engineer rejects it for the code slice: a reranker cannot select a remediation passage missing from its input. The hybrid candidate pool satisfies the latency budget and improves both slices, so the team selects Milvus hybrid search with RRF as the first deployment candidate.
The database owner creates a separate hybrid collection and reingests the runbooks rather than switching the dense collection in place. Before promoting it, the retrieval engineer compares RRF with a sparse-heavy weighted alternative on both question slices. They also test the fused candidates separately from the final answer, so improved generation cannot hide lexical regressions. If the organization instead chooses open-source Elasticsearch, the team changes the candidate to weighted fusion because the Blueprint’s RRF license requirement changes the feasible choice.
Common exam traps
- Treating BM25 scores and dense similarity as interchangeable scales.
- Confusing RRF’s smoothing parameter with a top-k candidate count.
- Assuming hybrid search always beats either route on every workload.
- Enabling hybrid serving against an unchanged dense Milvus collection.
- Calling model reranking a remedy for candidates never retrieved.
- Assuming a fusion method has identical backend licensing requirements.
Where the exam guide differs
The study guide says “embedded search.” Read that phrase in a retrieval question as embedding-based dense vector retrieval: the Blueprint calls this search type dense. Its “hybrid approaches” correspond to APP_VECTORSTORE_SEARCHTYPE="hybrid", combining dense and sparse results through RRF or weighted fusion. Use the product identifiers when selecting a configuration.
What to remember
Dense retrieves by semantic similarity, BM25 by lexical matching, and hybrid combines their strengths. RRF uses positions to avoid direct comparison of incompatible raw scores. Validate candidate coverage by question type, configure ingestion and serving together, and keep fusion distinct from model reranking.
Knowledge check
A telecom support assistant uses dense retrieval only. Paraphrased outage questions work well, but for questions that quote an error code such as E-4471, the passage holding that code’s remediation is missing from the candidate list entirely. Nobody has calibrated a lexical score against the dense similarity scale. Which change addresses this failure?
A Blueprint deployment on Milvus has served dense search for months. The team sets APP_VECTORSTORE_SEARCHTYPE="hybrid" for both the RAG server and the ingestor server and restarts them, but hybrid retrieval against the existing collection does not work. What should they do next?
weighted with equal dense and sparse weightsdense and keep hybrid on the RAG serverdense search lacks the sparse representation hybrid search needs, and NVIDIA’s documentation directs creating a new collection and re-uploading the documents. Restarting a service changes its configuration, not the collection; a ranker setting cannot substitute for a missing representation; and serving and ingestion must agree on the search type.A platform team must run the NVIDIA RAG Blueprint’s hybrid search on open-source Elasticsearch, and the lexical route must stay because questions cite exact part numbers. Which fusion configuration should they deploy?
k for the sparse routeweighted ranker and tune its dense and sparse weightsAPP_VECTORSTORE_RANKER_TYPE="weighted" , with the dense and sparse weights tuned against the real question mix. Changing k does not lift the license requirement, and dropping the sparse route gives up the exact-term matching the workload depends on.