Hybrid search și reranking în RAG: similaritate vs relevanță

Recall@5, MRR, NDCG — dacă ai citit articolul despre evaluarea RAG, știi deja cum se măsoară calitatea unui retrieval. Hybrid search și reranking sunt cele două tehnici care mută efectiv cifrele alea, nu doar teoretic: una lărgește ce prinde sistemul de căutare, cealaltă pune rezultatele în ordinea corectă.

Răspunsul intuitiv la „de ce nu găsește sistemul răspunsul bun" — mai mulți vectori, un embedding mai scump — ajută marginal. Pârghia reală stă în altă parte: în cum combini metodele de căutare între ele și în cum le rescrii ordinea după ce le-ai combinat. Articolul de față tratează separat fiecare tehnică, cu cifre din benchmark-uri reale, nu cu promisiuni generice.

Similaritatea nu e relevanță

O căutare vectorială nu găsește ce e relevant. Găsește ce e apropiat. Cosine similarity măsoară unghiul dintre doi vectori de embedding — o proximă matematică a înțelesului, nu relevanța însăși. Pentru multe interogări, proxima e suficient de bună. Pentru altele, nu.

Termenii rari și exacți sunt punctul unde proxima cedează: un cod de eroare, un SKU, un nume propriu, o referință legală. Un model de embedding antrenat pe limbaj general n-a văzut destule exemple din jurul acelui token specific ca să-l plaseze corect în spațiul vectorial — iar documentul care conține exact termenul căutat poate ieși pe locul 40, nu pe locul 1.

BM25, algoritmul lexical din spatele multor motoare de căutare clasice, rezolvă exact punctul ăsta slab: potrivire exactă de termeni, fără nicio pretenție de „înțelegere" semantică. Diferența dintre cele două metode nu e „care e mai bună", ci ce ratează fiecare când rulează singură. Distincția de bază — ce înseamnă „semantic", cum funcționează de fapt indexul lexical și unde cedează fiecare — e tratată separat în articolul despre ce este semantic search.

Ce ratează fiecare metodă, rulată singură

Ia două interogări concrete. „Eroare ORA-00942" sau „SKU BT-4471" — BM25 le prinde trivial, potrivire exactă de caracter. „De ce nu-mi merge conexiunea la baza de date" — aceeași problemă, formulată în limbaj natural, fără niciun termen exact — aici câștigă vectorul, care recunoaște sinonimia și parafraza chiar și fără suprapunere de cuvinte.

Datele confirmă tiparul, dar nu întotdeauna în direcția pe care ai presupune-o din reputația actuală a vector search-ului. Pe WANDS, un benchmark public de căutare e-commerce, un baseline BM25 și un baseline dense ies practic la egalitate — NDCG în jur de 0,698 pentru BM25, foarte apropiat de varianta densă (cifră publicată de Doug Turnbull, softwaredoug.com). Diferența mare apare abia cu tuning suplimentar peste hybrid — boost pe câmpul de nume al produsului — nu din fuziunea simplă.

Un studiu din 2026 pe documente financiare text-și-tabele (23.088 de întrebări, 7.318 documente cu tabele) arată un tablou mai clar în favoarea BM25 ca prim pas: bate dense retrieval (text-embedding-3-large) pe aproape toate metricile — Recall@5 de 0,644 față de 0,587. Concluzia autorilor: terminologia precisă — nume de companii, coduri de bilanț, perioade fiscale — favorizează potrivirea lexicală, ceea ce contrazice asumpția că retrieval-ul dens domină universal.

Concluzia practică: corpusurile cu terminologie structurată — financiar, tehnic, legal, cataloage de produs — au de câștigat clar din combinarea celor două metode. Corpusurile narative, omogene, câștigă mai puțin. Verifici pe datele tale, nu presupui.

Înainte să intri în mecanica fiecărei piese, uite fluxul complet — de la query, prin cele două ramuri de retrieval, până la rezultatul final reordonat:

Hybrid search: fuziunea cu Reciprocal Rank Fusion

Combinarea listelor de rezultate ridică o problemă tehnică simplă, dar reală: scorul BM25 și cosine similarity nu sunt comparabile ca magnitudine sau distribuție. Nu poți aduna direct un scor BM25 de 12,4 cu o similaritate cosine de 0,87 și să obții ceva coerent.

Reciprocal Rank Fusion (RRF) ocolește problema lucrând pe rang, nu pe scor brut. Formula, din lucrarea lui Cormack, Clarke și Büttcher (SIGIR 2009), e simplă: scorul unui document e suma 1/(k + rang) peste toate listele în care apare, cu k=60 ca valoare implicit-empirică găsită de autori pe date TREC. Fiindcă lucrează pe rang, RRF nu cere normalizare și nu cere niciun tuning ca să funcționeze rezonabil de bine.

De-asta RRF a devenit mecanismul de fuziune implicit în OpenSearch, Elasticsearch, Azure AI Search și Weaviate. Pentru stack-ul Next.js și MongoDB, relevant direct: MongoDB Atlas îl expune nativ prin stage-ul de agregare $rankFusion, disponibil din MongoDB 8.0 — vezi și articolul despre RAG cu Next.js și Vercel AI SDK pentru restul stack-ului.

RRF nu e însă mereu optim matematic — doar implicit sigur. Pe un ablation recent, pe documente financiare text-și-tabele, o combinație convexă cu pondere 0,5/0,5 a bătut ușor RRF implicit (Recall@5 de 0,726 față de 0,695), iar un RRF cu k=10 a bătut RRF cu k=60 (0,716 față de 0,695). RRF rămâne alegerea implicită fiindcă nu cere normalizare sau tuning, nu fiindcă e mereu matematic superior — pe alte seturi de date, câștigul RRF peste cel mai bun retriever individual e uneori doar 1-2 puncte NDCG.

Un avantaj practic: RRF sumează peste oricâte liste, nu doar două. Poți adăuga un al treilea retriever — de exemplu SPLADE, un model sparse învățat — fără să schimbi formula.

De la bi-encoder la cross-encoder: ce face efectiv reranking-ul

Un model de embedding e un bi-encoder: encodează query-ul și fiecare document separat, fiecare devine un vector fix, iar comparația se face apoi prin cosine similarity. E rapid fiindcă vectorii documentelor se calculează o singură dată, în avans, și se indexează.

Un reranker e un cross-encoder: primește query-ul și documentul concatenate, le trece împreună printr-un singur forward pass, iar atenția modelului vede fiecare token din query lângă fiecare token din document. Nu produce un vector reutilizabil — scorează o singură pereche, o singură dată, la momentul interogării. De-asta nu poate fi indexat în avans și de-asta nu se aplică direct la milioane de documente.

Diferența contează concret la interogări cu negație. „Companii care NU au intrat în insolvență" — un bi-encoder nu poate distinge fiabil între un document despre o companie care chiar a intrat în insolvență și unul despre profit record; ambele sunt „apropiate" tematic în spațiul de embedding. Un cross-encoder, cu atenție comună peste toată perechea, prinde negația.

Tehnica vine din „Passage Re-ranking with BERT" (Nogueira și Cho, 2019), lucrarea fondatoare pentru reranking cu cross-encoder pe bază de BERT. Tiparul standard, documentat azi de Hugging Face și sentence-transformers, e „bi-encoder recuperează top-100, cross-encoder rescorează". ColBERT, sau late interaction, e o cale de mijloc — păstrează reprezentări per-token, deci precizie mai apropiată de cross-encoder, dar cu latență apropiată de bi-encoder, în jur de 23ms p50 în benchmark-urile citate; merită reținut ca opțiune, nu ca regulă generală.

Ce alegi azi pentru reranking

Peisajul se mișcă rapid, dar câteva opțiuni sunt stabile ca puncte de plecare.

Pe partea managed: Cohere oferă Rerank 4 Pro la $0,0025/căutare, cu context de 33K tokeni, lansat în aprilie 2026; Rerank v3.5 e mai ieftin, la $0,001/căutare, cu context de 4K; Rerank 4 Fast stă la mijloc. Prețul e per căutare, nu per token — diferit față de embeddings sau generare. Voyage AI, deținut de MongoDB, oferă rerank-2.5 cu primele 200 de milioane de tokeni gratuite per cont, apoi preț calculat ca tokeni query înmulțiți cu numărul de documente, plus suma tokenilor din toate documentele — formula explică direct de ce costul crește cu mărimea pool-ului de candidați, nu doar cu numărul de interogări.

Pentru cine e deja pe MongoDB Atlas, hybrid search și reranking devin config, nu infrastructură nouă: stage-ul $rerank, aplicat după $rankFusion sau $scoreFusion în aceeași pipeline de agregare, rescorează cu un model Voyage AI reranker.

Pe partea self-hosted: BAAI/bge-reranker-v2-m3, licență Apache-2.0, multilingv, arhitectură xlm-roberta, e opțiunea implicită rezonabilă când vrei control complet sau cost zero per interogare. Mixedbread mxbai-rerank-large-v2 e o alternativă, tot Apache-2.0.

Clasamentele publice se schimbă des — un leaderboard independent (Agentset Reranker Leaderboard, instantaneu din 15 februarie 2026) plasa Zerank-2 (ZeroEntropy) și Cohere Rerank 4 Pro foarte aproape în vârf, cu Voyage Rerank-2.5 puțin în urmă. Benchmark-urile publicate de furnizori merită tratate ca marketing, nu ca adevăr independent — verifici prețul și clasamentul curent la momentul deciziei, nu la momentul citirii articolului ăstuia.

Cifrele de mai jos, dintr-un singur studiu pe documente financiare din 2026, arată de ce reranking-ul contează mai mult decât fuziunea simplă:

Ce mișcă efectiv recall, MRR și NDCG

Articolul despre evaluarea RAG a stabilit deja metricile de retrieval: recall@k, precision@k, MRR, NDCG. Nu le reinventezi aici — te legi de ele direct, cu cifre.

Hybrid search își arată efectul mai ales pe recall@k: aduce în pool candidați pe care un singur retriever i-ar fi ratat complet, practic o uniune de seturi. Reranking-ul își arată efectul mai ales pe MRR și NDCG: reordonează un pool deja lărgit, deci mută documentul bun mai sus, nu neapărat îl aduce pentru prima dată în discuție.

Pe studiul financiar citat mai sus, diferența de magnitudine e clară: fuziunea hybrid a mutat MRR@3 cu doar +2,2 puncte peste BM25 singur, dar reranking-ul peste hybrid l-a mutat cu +17,2 puncte — de aproape opt ori mai mult. Recall@5 a urmat un tipar asemănător: +5,1 puncte procentuale pentru fuziune, +12,1 puncte procentuale pentru reranking. Un document bun, îngropat pe poziția 23, reordonat corect, ajunge vizibil în top 5.

Adâncimea pool-ului de candidați e pragul tehnic care decide cât de mult poate câștiga reranking-ul. Pe același studiu: la 20 de candidați, reranking-ul e ineficient — Recall@5 de doar 0,458, fiindcă documentul bun deseori nici nu e în pool. La 50 de candidați, sare la 0,826. La 100, la 0,888. Regula practică „retrage top-50, rerank, întoarce top-10" nu e arbitrară — sub aproximativ 50 de candidați, reranker-ul n-are ce reordona.

Latență și cost: cine plătește pentru reranking

Regula generală, citată consistent în ghiduri de reranking: adaugă sub 200ms pentru un lift NDCG@10 de 5-15 puncte, uneori 20+ pe seturi de date lexical-grele — un cost mic pentru un câștig care nu se obține altfel.

Detaliat pe un buget de latență realist, cu prag p95 de 700ms (sursă: ZeroEntropy): primul pas de retrieval (BM25 plus embedding pe K=100) ia 30-50ms; cross-encoder-ul pe K=100 la batch=8 ia 300-400ms — jumătate din tot bugetul; asamblarea rezultatelor ia 40-80ms; apelul către LLM ia 150-300ms. Reranker-ul e frecvent cea mai mare bucată de latență din request, nu una neglijabilă.

Pârghia practică: jumătate din timpul de reranking e overhead de batching amortizat per apel. Trecerea de la 13 apeluri mici (batch=8) la un singur apel de batch=100 reduce timpul de reranking cu 50-65%, fără nicio schimbare de model.

La scară, costul rămâne administrabil: un studiu a procesat un benchmark de 23.000 de interogări prin Cohere Rerank în aproximativ o oră, la un throughput de circa 300.000 de tokeni pe minut — o ancoră utilă pentru „cât costă real", nu doar prețul per căutare izolat.

Când merită complexitatea

Retrieval-ul slab e una dintre cauzele recurente pentru care sistemele RAG eșuează în producție. Trei praguri decid dacă hybrid search și reranking merită efortul de corectare.

Tipul de corpus contează mai mult decât mărimea lui brută. Corpusuri cu identificatori exacți — coduri, ID-uri, cifre, terminologie de domeniu — au de câștigat clar. Corpusuri narative și omogene câștigă mai puțin, iar RRF simplu poate aduce doar 1-2 puncte NDCG peste cel mai bun retriever individual — verifici pe datele tale înainte să presupui câștigul.

Adâncimea pool-ului de candidați e pragul tehnic: sub aproximativ 50 de candidați, reranking-ul n-are pe ce lucra, indiferent cât de bun e modelul.

Bugetul de latență e pragul operațional. 100-400ms adăugate se justifică ușor unde o halucinație sau un rezultat greșit costă — suport tehnic, legal, medical, conformitate. E mai greu de justificat pentru autocomplete sau chat casual, unde fiecare milisecundă contează mai mult decât precizia marginală.

Pragul de complexitate operațională, nu doar de calitate, s-a mutat în 2026. Pentru cineva deja pe MongoDB Atlas, hybrid search și reranking sunt două stage-uri de agregare — $rankFusion și $rerank — nu un al doilea sistem de căutat plus un API extern de integrat separat. Costul de adopție e mai mic decât acum un an sau doi.

Întrebări frecvente

Ai nevoie de reranking dacă ai deja hybrid search?

Depinde de adâncimea pool-ului și de miza erorii. Hybrid search singur crește recall-ul — aduce candidați buni în joc. Dacă poziția exactă în listă contează (primele 3-5 rezultate, nu primele 20), reranking-ul e cel care mută documentul bun acolo sus; datele arată un lift de câteva ori mai mare pe MRR și NDCG față de fuziunea simplă.

RRF sau normalizare de scor — care e mai bună?

RRF câștigă pe simplitate: nu cere normalizare, nu cere tuning, funcționează rezonabil de bine din prima. O combinație convexă, cu scoruri normalizate corect, poate bate RRF cu câteva puncte pe unele seturi de date — dar cere tuning și mentenanță. Pornești cu RRF; treci la normalizare doar dacă ai date care arată clar că merită.

Câți candidați trebuie să retragi înainte de reranking?

Cel puțin 50, pe cifrele din studiul citat mai sus — sub acest prag, reranker-ul deseori nu are documentul bun în pool, indiferent cât de bun e modelul. Tiparul „retrage top-50, rerank, întoarce top-10" e punctul de plecare rezonabil, nu o cifră arbitrară.

Cât costă un pas de reranking la scară?

Managed, prețul e per căutare, nu per token — de la $0,001 la $0,0025 per căutare la furnizorii mari, în funcție de model și context. Self-hosted, costul devine infrastructură (GPU, throughput), nu preț per apel. La volum mare, batching-ul — apeluri de batch=100 în loc de batch=8 — reduce timpul, și implicit costul de compute, cu 50-65%.

Merită complexitatea pentru un corpus mic?

Rar. Beneficiul hybrid search și reranking crește cu dimensiunea și eterogenitatea corpusului și cu prezența terminologiei exacte — coduri, ID-uri, nume proprii. Pe un corpus mic, omogen, narativ, un retrieval dens simplu, bine ajustat, acoperă majoritatea cazurilor fără complexitatea suplimentară.

Un pipeline RAG care ratează coduri exacte sau îngroapă răspunsul bun pe poziția 23 nu are nevoie de un model mai scump — are nevoie de hybrid search și de un pas de reranking. Vezi și restul seriei RAG în producție pentru chunking, evaluare și securitate, sau explorează serviciile AI/RAG pentru contextul tău.