How hybrid search finds the right passage

Imagine your question goes to two librarians at once. The first files pages by meaning (the one you met in Semantic Search): ask about "recovering a forgotten login" and it finds pages about password resets, whatever words they use. The second is a stickler for exact terms: ask for "ACME-1234" or "section 409A" and it goes straight to the pages containing precisely that string, something meaning-based search can blur past.

Each librarian returns a ranked shortlist. Neither is right all the time, so your node merges the two lists with a simple, robust rule: a page earns credit for ranking high on either list, and a page both librarians rank highly beats a page only one of them loves. The technique is called Reciprocal Rank Fusion, and it only compares positions, never raw scores, so the two very different scoring systems never need to be reconciled.

Then comes the judge. The top of the merged list goes to a third model, a cross-encoder, that does what neither librarian can: it reads your question and each candidate passage together, and scores how well that passage actually answers you. Passages that merely resemble your question sink; passages that answer it rise. The judge isms-marco-MiniLM-L-6-v2, an open-source (Apache-2.0) model that runs as a compact, quantized artifact on ordinary CPUs inside your node.

Meaning-based search and exact-term search fail in opposite ways. Embeddings compress a passage into a fingerprint of its meaning, which is exactly what you want until the answer hinges on a part number, a statute id, or a function name that the compression treats as noise. Keyword search never misses the exact string, but has no idea that "reset my password" and "recover my login" are the same request. Running both legs and fusing them means each covers the other's blind spot, and the reranking judge cleans up whatever ambiguity survives the merge.

This is also how your node's chat answers get their context. When you ask a question, the passages that ground the answer are chosen by this full pipeline, and each kept passage must clear the judge's relevance bar, not just sit near your question in fingerprint space.

The reranker gets the same treatment as the embedder: it is pinned to one exact version, its checksum is recorded in the platform source code, and every process re-verifies the model file before serving a single request. A swapped or corrupted model refuses to load. And if the model is unavailable, search does not fail: your node serves the merged two-librarian ordering and notes the degradation in its logs.

The judge reads at most 512 tokens of question and passage combined, so very long passages are trimmed before scoring. It was trained on English web-search relevance: it is weaker on other languages and is a generalist, not a legal, financial, or medical specialist. Its scores order passages well but are not universal probabilities, and the second model pass adds a small amount of latency to each search, bounded by only re-reading the top of the merged list. The judge is part of the Pro and Enterprise intelligence tier: Personal nodes serve the merged two-librarian ordering, and Pro nodes can skip the judge on any request if raw fused ordering is all you need.