Hybrid search: BM25 + vektory + reranking

Vektorový retrieval je v 2026 de facto štandard pre RAG nasadenia. Väčšina tímov nastaví embedding model, naplní Qdrant alebo pgvector a pustí do produkcie. Funguje — kým nepríde dotaz ako „§ 271 ods. 2 Zákonníka práce" alebo „HMI model 7NF-420-C". Dense embedding si s tým nevie rady: komprimuje dokument do jedného vektoru a presný reťazec sa v sémantickej norme stratí. Práve tu nastupuje hybrid search — kombinácia keyword retrieval (BM25) a vektorového vyhľadávania, s rerankerom navrchu.

Tento článok ide hlbšie ako téma RAG pipeline — 3 nastavenia kvality, kde sme reranker spomínali iba v kontexte pipeline-u. Tu sa sústredíme výlučne na search vrstvu: prečo samotné vektory nestačia, ako hybrid funguje mechanicky, čo je RRF fusion, kedy reranker naozaj pomáha a ako to celé nastaviť v praxi.

Prečo samotné vektory nestačia

Dense embedding model (napr. BGE-M3 alebo text-embedding-3-large) prevádza text na vektor v priestore stoviek alebo tisícov dimenzií. Vektory blízko pri sebe majú podobný sémantický obsah. Výborné pre otázky ako „aké sú podmienky ukončenia pracovného pomeru", kde záleží na zmysle.

Problém nastáva pri lexikálne špecifických dotazoch:

• Čísla noriem a zákonov: § 63, EN ISO 12100, EÚ nariadenie 2016/679
• Kódy produktov a dielov: SKF-6204-2RS, Siemens SIMATIC S7-1500
• Mená, skratky, akronymy: BOZP, NBS, FFT analýza
• Presné hodnoty: 230 V AC, IP67, UL 508A

V týchto prípadoch embedding zlyháva z jediného dôvodu: model nenatrénoval na tom, že „SKF-6204-2RS" a „SKF-6205-2RS" sú fundamentálne odlišné položky. Vektory môžu byť blízko, pretože zdieľajú prefix. Presný match sa stratí.

BM25 (Best Matching 25) tento problém nemá. Je to klasická TF-IDF variantná štatistická metóda z roku 1994, ktorá explicitne ohodnotí výskyt každého tokenu v dokumente voči korpusu. Pre presné reťazce je BM25 stále lepší ako akýkoľvek embedding — a to platí v 2026 rovnako ako v 2014.

Z orientačných benchmark testov na syntetických korporusoch:

• BM25 samotné: ~58 % precíznosť
• Dense vektory samotné: ~79 %
• Hybrid (BM25 + dense): ~85–88 %
• Hybrid + cross-encoder reranker: ~88–91 %

Reálne zlepšenie závisí od dátovej sady, jazyka a typu dotazov. Pre priemyselné dokumentácie s kódmi a normami vidíme v praxi posun hybrid vs. dense okolo 8–12 percentuálnych bodov precision@5.

Ako BM25 funguje

BM25 je štatistický model. Pre každý dokument a dotaz vypočíta skóre ako vážený súčet TF-IDF (term frequency — inverse document frequency) pre každý token v dotaze. Parametre:

• k1 — ovláda saturáciu term frekvencie (typicky 1,2–2,0). Vyšší = lineárnejší vzťah medzi frekvenciou a skóre.
• b — normalizácia dĺžky dokumentu (0 = žiadna, 1 = plná). Default 0,75.

BM25 nevyžaduje GPU ani špeciálny hardware — je deterministický, rýchly a funguje na CPU. Knižnica rank_bm25 v Pythone, alebo natívna podpora v Weaviate, OpenSearch, Elasticsearch a Qdrant (cez sparse vectors).

Obmedzenie: BM25 nerozumie synonymám ani parafrázi. Dotaz „ukončenie pracovného pomeru" nenájde dokument, ktorý hovorí iba o „výpovedi z práce". Na to sú práve vektory.

Reciprocal Rank Fusion — ako spojiť dva výsledky

Keď máme dva samostatné rankingy (BM25 a dense vektory), treba ich spojiť do jedného. Najčastejší prístup v 2026 je RRF (Reciprocal Rank Fusion).

Mechanika je jednoduchá. Pre každý dokument vypočítame:

RRF_score(d) = sum( 1 / (k + rank_i(d)) )

kde rank_i(d) je poradie dokumentu v i-tom rankingu a k je vyhladzovací parameter (typicky 60). Dokumenty, ktoré sa objavujú vysoko v oboch rankingoch, dostanú najvyššie skóre. Dokument, ktorý jeden systém nezná, ale druhý rankuje na 1. mieste, stále dostane slušné skóre.

Prečo nie weighted average skóre? BM25 skóre a embedding cosine similarity sú na rôznych škálach — priamočiara váha by preferovala jeden zo systémov. RRF pracuje iba s poradím, takže škála nehrá rolu.

Alternatíva k RRF: DBSF (Distribution-Based Score Fusion) — normalizuje skóre pred fúziou, vhodné keď sú oba systémy kalibrované. V praxi väčšina implementácií štartuje s RRF a DBSF skúša až pri problémoch s distribúciou.

Parameter alpha v niektorých frameworkoch (napr. Weaviate) jednoducho ovláda pomer BM25 vs. dense — alpha=0 = čistý BM25, alpha=1 = čistý dense, alpha=0.5 = rovnaký príspevok oboch. Default 0,5 je dobrý štartovací bod, ale pre obsah s vysokou hustotou kódov a noriem skúste alpha=0,3–0,4 (väčší príspevok BM25).

Reranker — prečo retrieval nestačí

Hybrid search výrazne zlepšuje recall — pravdepodobnosť, že správny dokument je medzi top-K kandidátmi. Ale precision@5 (koľko z prvých 5 je naozaj relevantných) závisí od toho, aké dobre sú kandidáti zoradení.

Tu vstupuje reranker (cross-encoder model). Mechanika:

1. 1.Hybrid retrieval vráti top-K dokumentov (typicky K = 20–50). Rýchly.
2. 2.Reranker dostane každý z K dokumentov spolu s dotazom, spracuje ich spoločne a pridelí presné relevantné skóre. Pomalší, ale presnejší.
3. 3.Top-N (typicky N = 5) s najvyšším reranker skóre ide do LLM kontextu.

Prečo je reranker presnejší ako embedding? Bi-encoder embedding komprimuje dokument a dotaz každý zvlášť do vektoru — interakcia medzi nimi sa vyhodnocuje iba kosínusovou vzdialenosťou. Cross-encoder vidí dotaz a dokument súčasne, čo mu umožňuje zachytiť jemné token-level interakcie, ktoré bi-encoder stratí.

Typický nárast precision@5 po pridaní rerankeru: 7–12 percentuálnych bodov. Latencia navyše: 50–200 ms pre top-20 reranking.

Aktuálne best-in-class:

• Cohere Rerank 3.5 — managed API, výborný pre multilingual content vrátane strednej Európy, ľahká integrácia
• BGE-reranker-v2-m3 — open-weight, self-hosted, multilingual, výborný pomer výkon/náklady
• ms-marco-MiniLM-L-6-v2 — malý, rýchly, anglický prototyping

Pre výber embedding modelu platí podobný princíp: multilingual EU content zaslúži multilingual reranker.

Kedy hybrid výrazne pomôže (a kedy nie)

Hybrid search výrazne pomôže, keď:

• Obsah obsahuje kódy, číslice, skratky, normy, produktové označenia
• Používateľ kladie presné dotazy (copy-paste z dokumentu, kód dielu z objednávky)
• Jazyk nie je výlučne anglický — BM25 nepotrebuje jazykový model, funguje pre slovenčinu rovnako dobre
• Recall je problémom — „relevantný dokument sa nenašiel" je bežná sťažnosť
• Korpus obsahuje tematicky veľmi podobné dokumenty (napr. 5 000 podobne štruktúrovaných technických listov)

Hybrid search menej pomôže, keď:

• Dotazy sú výlučne konverzačné, parafráze-based (FAQ chatbot, HR odpovede)
• Korpus je malý (pod 500 dokumentov) — latencia a komplexita navyše sa neoplatí
• Latencia je kritická — na každej strane sa pridáva BM25 scoring (typicky +10–30 ms) a potenciálne reranker (+50–200 ms)
• Obsah je primárne anglický a embeddingy sú kvalitné — dense vektory sa priblížia výsledkom hybridného retrieval

Videli sme u klienta z výroby náhradných dielov: korpus 18 000 technických listov s kódmi SKF, NSK, FAG. Čistý dense retrieval, precision@5 = 0,63. Po prechode na hybrid s alpha=0,35 a BGE-reranker-v2-m3: precision@5 = 0,84. Hlavný dôvod — presný match na kóde dielu z dotazu zákazníka.

Praktické nastavenie — stack 2026

Qdrant (odporúčaný pre B2B priemyselné nasadenia)

Qdrant podporuje natívny hybridný search cez sparse + dense vektory v jednej kolekcii. Sparse vektory na BM25 generujeme cez BM25Encoder z fastembed knižnice.

# inicializácia sparse encoder
from fastembed import SparseTextEmbedding
sparse_model = SparseTextEmbedding("Qdrant/bm25")

# pri indexácii
sparse_vec = sparse_model.embed(text)
dense_vec = embedding_model.embed(text)

# query: hybrid search s RRF fusion
results = client.query_points(
    collection_name="documents",
    prefetch=[
        Prefetch(query=sparse_vec, using="sparse", limit=20),
        Prefetch(query=dense_vec, using="dense", limit=20),
    ],
    query=FusionQuery(fusion=Fusion.RRF),
    limit=5
)

Konfigurácia kolekcie: dva vector indexy — dense (dimenzia podľa embedding modelu, cosine) a sparse (sparse index, dot). Qdrant zvláda oba v jednom prechode.

Weaviate

Weaviate má hybrid search ako prvotriednú funkciu — BM25 + dense vektory + RRF fusion v jednom API volaní. Konfigurácia alpha priamo v query:

results = collection.query.hybrid(
    query="§ 63 Zákonník práce výpoveď",
    alpha=0.4,  # väčší príspevok BM25
    limit=20
)

Potom reranker cez Cohere alebo lokálny cross-encoder na top-20 výsledkov.

Reranking vrstva

Bez ohľadu na vektorovú DB, reranker je separátny krok. Odporúčané nastavenie:

• K = 20–30 kandidátov z hybridného retrieval
• Reranker na K kandidátoch → N = 5 výsledkov pre LLM
• Pre self-hosted: BGE-reranker-v2-m3 na GPU; na CPU zvládne ~500 ms/query pre top-20
• Pre cloud: Cohere Rerank 3.5 API, EU endpoint

Pridanie rerankeru k existujúcemu hybridnému retrieval je zvyčajne 20–40 riadkov kódu. Keď hovoríme o evaluácii RAG pipeline cez RAGAS, práve tento krok by mal mať vlastnú precision@5 metriku pred a po.

Latencia: čo pridáva každá vrstva

Typické latencie pri 10 M vektoroch, RTX 4090 GPU (orientačné):

• BM25 scoring na CPU: 10–30 ms
• Dense vector search (Qdrant): 5–15 ms
• RRF fusion: pod 5 ms
• Reranker cross-encoder top-20 (GPU): 80–150 ms
• Reranker cross-encoder top-20 (CPU): 400–800 ms
• Cohere Rerank 3.5 API (network): 100–200 ms

Celková pipeline: hybrid retrieval + GPU reranker = typicky 200–400 ms end-to-end search vrstva. Pre interaktívne chatboty je to zvyčajne akceptovateľné. Pre systémy s požiadavkou pod 150 ms zvážte reranker len pri nízkej latencii siete alebo vymenenie za jednoduchší bi-encoder resorting.

Detailnejšie porovnanie vektorových databáz a ich QPS parametrov nájdete v článku Vektorové databázy — Qdrant, Weaviate, pgvector, Milvus.

Časté otázky

Musím od začiatku navrhnúť systém s hybridným retrieval, alebo môžem pridať BM25 neskôr?

BM25 index je nezávislý od embedding indexu a dá sa pridať k existujúcemu korpusu kedykoľvek. V Qdrant stačí pridať sparse vector index ku kolekcii a reindexovať dokumenty — dense indexy zostávajú nedotknuté. Weaviate, Milvus aj pgvector majú podobný postup. Čas reindexácie závisí od veľkosti korpusu, ale pre typický B2B knowledge base (do 1 M dokumentov) ide o hodiny, nie dni.

Čo je lepšie pre slovenský obsah: BM25 alebo dense embedding?

Záleží od charakteru dotazov. BM25 funguje pre slovenčinu rovnako dobre ako pre angličtinu — je to štatistický model bez jazykovej závislosti. Pre sémantické otázky (parafrázie, synonymá) je lepší multilingual dense embedding ako BGE-M3 alebo Qwen3-Embedding-8B. V praxi pre slovenské B2B korpusy: hybrid s alpha=0,4–0,5 dáva najlepší výsledok.

Kedy reranker nepomôže?

Reranker reorduje iba dokumenty, ktoré retrieval vrátil. Ak správny dokument nie je v top-K kandidátoch, reranker ho nezachráni. To znamená: najprv treba opraviť recall (hybridný retrieval, väčšie K), potom pridávať reranker. Ak precision@5 stagnuje aj po rerankeri, problém je väčšinou v recall — správny dokument jednoducho nie je v kandidátoch.

Aký je rozdiel medzi hybrid search a agentic RAG?

Hybrid search je technika na úrovni retrieval vrstvy — zlepšuje, ktoré dokumenty sa dostanú do kontextu LLM. Agentic RAG je architektonický vzor, kde agent aktívne rozhoduje, čo a ako vyhľadávať — iteratívne dotazovanie, rôzne zdroje, sub-queries. Hybrid search a agentic RAG sa nevylučujú: dobrý agent používa hybridný retrieval pod kapotou.

Dá sa hybrid search nasadiť on-prem bez cloudových závislostí?

Áno. Qdrant aj Weaviate sú open-source a bežia self-hosted. BGE-reranker-v2-m3 je open-weight model, ktorý beží lokálne na GPU. BM25 nevyžaduje žiadny externý servis. Celý stack — hybrid retrieval + reranker — môže bežať kompletne on-prem, čo je dôležité pre regulované odvetvia. Viac o téme on-prem LLM pre regulované odvetvia.

---

*Ak váš RAG systém naráža na to, že presné kódy, normy alebo produktové označenia sa nenachádzajú spoľahlivo, problém je takmer vždy v chýbajúcej keyword vrstve. Pomáhame firmám navrhnúť a nasadiť hybridný retrieval stack — od výberu databázy a embeddingovho modelu po nastavenie rerankeru a meranie zlepšenia.*