How do you combine $search and $vectorSearch results in a single MongoDB pipeline?

## The constraint that shapes everything Hybrid search means asking a lexical engine and a vector engine the same question and merging their answers. In MongoDB the obstacle is structural: `$search` and `$vectorSearch` are each only legal as the first stage of a pipeline. You cannot write one after the other, and `$facet` cannot host them either. The escape hatch is that the rule applies per *pipeline*, and `$unionWith` opens a new one. So the shape is: ```javascript db.articles.aggregate([ { $vectorSearch: { /* ... */ limit: 50 } }, // rank the vector branch, then union in the text branch { $unionWith: { coll: "articles", pipeline: [ { $search: { /* ... */ } }, /* rank */ ] } }, // fuse ]); ``` One server round trip, two independent retrievals, one merged output. ## Ranking each branch before the union The two branches produce scores in different units. `{ $meta: "searchScore" }` is a Lucene relevance value whose magnitude depends on term statistics and the query; `{ $meta: "vectorSearchScore" }` is a similarity value derived from the configured metric. There is no principled constant that puts them on a common scale, and a score that happens to be around 0.8 in both cases means two unrelated things. The practical answer is to convert each branch's ordering into a position and combine positions instead. Inside each branch, sort by that branch's score and assign a rank: ```javascript { $setWindowFields: { sortBy: { vs: -1 }, output: { rank: { $documentNumber: {} } } } } ``` Now each document carries a small integer meaning "3rd best according to this retriever", which is comparable across branches by construction. ## Fusing after the union After `$unionWith`, a document found by both retrievers appears twice, once per branch, each with its own rank. `$group` by `_id` collapses them and collects the per-branch contributions; a computed field turns each rank into a diminishing contribution — the standard reciprocal form weights a rank `r` as `weight / (k + r)` — and sums them. Documents found by both branches accumulate two contributions and rise; documents found by only one still appear, which is the point of hybrid retrieval. A final `$sort` on the fused value and `$limit` produce the response, and a `$lookup` or the fields you carried through the union supply the display data. The per-branch weight is where product judgment enters: weighting the lexical branch higher favours exact terms, part numbers and names; weighting the vector branch higher favours paraphrase and intent. ## Depth of each branch Each branch should retrieve deeper than the number of results you intend to show, because a document ranked 30th lexically and 8th by vector may deserve to be in the final top 10 — but only if both branches went at least that deep. Fetching 50 to 100 per branch to produce 10 final results is a common shape; the cost is bounded because the extra work is one wider search per branch, not a per-document operation. ## The newer stage Recent MongoDB versions provide a dedicated rank-fusion aggregation stage that takes named input pipelines and combines their rankings for you, removing the hand-written `$setWindowFields` and `$group` scaffolding. Where it is available it is the better answer, because it is less code to get subtly wrong. Knowing the manual construction still matters: it is what runs on clusters that do not have the stage, and it is what the built-in is doing. ## Operational notes Both branches hit mongot, so a hybrid query costs roughly two searches plus the merge; capacity planning should assume that. Both branches also read the same eventually-consistent index, so neither leg sees a just-written document earlier than the other. And filters must be pushed into *both* branches — a tenant filter present only on the vector leg leaks other tenants' documents through the text leg. ## What to say in an interview Lead with the first-stage constraint and `$unionWith` as the way around it, explain that scores from the two engines are not comparable so you fuse positions rather than values, and mention that current versions can express the fusion as a single stage.