If you are building retrieval for a RAG system, you have probably run into the same wall everyone does. This sits at the heart of RAG retrieval quality. Keyword search is precise but literal. It nails exact product codes, names and rare terms, and misses anything phrased differently. Vector search understands meaning and synonyms, and sometimes sails right past the exact string a user actually typed. MongoDB Atlas hybrid search with $rankFusion exists to close that gap by running both and merging the results intelligently, and it is worth understanding properly before you wire it into production.
MongoDB Atlas hybrid search moved from a hand-rolled pattern to a native aggregation stage. Hybrid search on Atlas went into public preview in September 2025 and is now something you express in one stage rather than assembling yourself. That shift matters, because the old do-it-yourself version was where a lot of subtle relevance bugs lived.
What MongoDB Atlas hybrid search does with $rankFusion
The $rankFusion stage takes several ranked lists and fuses them into one unified ranking. In the common case, one list comes from a $search full-text query and another from a $vectorSearch semantic query, both against the same collection. You can also fuse multiple vector queries, for example the same query run through different embedding models, or across different fields.
The algorithm underneath is Reciprocal Rank Fusion, or RRF. It is deliberately simple, and that simplicity is a feature. For each document in each result list, it takes the document’s rank position, adds a fixed constant of 60, and then takes one divided by that sum. A document ranked first scores 1 divided by 61, a document ranked second scores 1 divided by 62, and so on. Each document’s final score is the sum of these reciprocal ranks across every list it appears in.
Two things fall out of this that are worth internalising. First, a document that shows up in both the text results and the vector results gets both contributions added together, so it naturally floats to the top. That is exactly the behaviour you want: agreement between two independent methods is a strong relevance signal. Second, RRF works on rank position, not on raw scores. It does not care that vector similarity scores and text relevance scores live on completely different scales, because it never compares the scores directly. That is what makes it robust, and it is why merging raw scores from two search engines tends to go wrong.
Why the constant is 60, and why you cannot change it
The rank_constant of 60 is fixed in Atlas and you cannot set it. It exists to smooth the curve so the difference between rank one and rank two is not brutally larger than the difference between rank ten and rank eleven. Without it, the top position would dominate so heavily that the fusion would essentially just return whatever came first in the stronger list. The value 60 is a well-established default from the original RRF research, and MongoDB has chosen to keep it constant rather than give you another knob to misconfigure. In practice this is the right call. The lever you actually want is weighting, not the constant.
Weighting: the knob that matters
Each sub-pipeline in a $rankFusion stage can carry a weight, and the weighted reciprocal rank is simply the weight multiplied by the reciprocal rank. This is where you tune MongoDB Atlas hybrid search to your content and your users.
If your data is full of proper nouns, part numbers or domain jargon that an embedding model was never trained on, lean the weight towards full-text search. If your users ask conceptual, natural-language questions where the exact words rarely match your documents, lean towards vector search. There is no universally correct split. The honest answer is that you set a sensible starting point, then tune against real queries from your own logs. A common failure is to pick weights once, in a demo, and never revisit them against production traffic.
One practical detail from working with this: if you give two pipelines the same weight, documents that appear in only one list can end up with identical, tied scores. If tie-breaking matters for your display order, use slightly different weights for each pipeline so the fusion produces distinct scores.
Seeing why a document ranked where it did
$rankFusion can emit scoreDetails, which you project out through $meta alongside the computed score. This is not a nice-to-have. When a stakeholder asks why a particular document came back third instead of first, scoreDetails is how you answer without guessing. It shows the contribution each pipeline made to the final score. Turn it on while you are tuning, and keep it available in your logging so relevance questions are answerable after the fact rather than a matter of opinion.
Where this fits in a production stack
The genuine advantage of MongoDB Atlas hybrid search as a native stage is that everything runs inside Atlas. Full-text search, vector search and the fusion all execute in one aggregation pipeline against one collection, and you can chain $rankFusion with the ordinary MongoDB stages you already use, such as $match to filter, $sort for a final ordering, or $geoNear where location matters. You are not standing up a separate search service, keeping a second datastore in sync, or writing glue code to reconcile two sets of results in your application layer. For teams already running their operational data on MongoDB, that consolidation is the real win. Fewer moving parts means fewer places for relevance and freshness bugs to hide.
A few things to keep in mind before you commit. You need both a full-text search index and a vector search index on the same collection, which means embeddings have to be generated and stored alongside your documents and kept current as data changes. And hybrid search is not automatically better than a single method for every workload. It shines when your queries genuinely span both precise terms and fuzzy intent. If your traffic is overwhelmingly one or the other, the simpler single-method path may serve you better and cost less to run.
The practical takeaway
MongoDB Atlas hybrid search with $rankFusion is a clean, native answer to a problem RAG teams keep hitting: neither keyword nor vector search alone is enough for real-world queries. The fusion is rank-based and therefore robust across mismatched score scales, the constant is fixed so you have one fewer thing to get wrong, and the weighting is where your judgement goes to work. Treat the weights as something you tune against your own query logs rather than set once, keep scoreDetails available so relevance stays explainable, and be honest about whether your workload actually needs both methods. Get those three things right and you have retrieval that holds up in production rather than just in a demo.
Comments 1