Reranking pre RAG 2026: Cohere Rerank vs BGE vs Voyage AI — Kompletné porovnanie

Aktualizované: 22. august 2026

Reranking pre RAG je druhý krok vyhľadávania, kde cross-encoder model preusporiada top-N kandidátov z vektorovej databázy podľa presnej relevancie k dopytu. V praxi zvyšuje presnosť RAG odpovedí o 15 až 35 % s pridanou latenciou 60 až 200 ms. V roku 2026 sú tri hlavné produkčné voľby Cohere Rerank 3.5, BGE-reranker-v2-m3 (open source) a Voyage rerank-2. Tento návod porovnáva ich kvalitu na MTEB Rerank, latenciu, cenu a ukazuje kompletný Python kód pre integráciu s Qdrant a LangChain. Priznám sa, prvýkrát som reranker nasadzoval s pocitom, že je to len ďalšia latenčná daň. Po dvoch týždňoch v produkcii som však videl RAGAS Faithfulness skočiť o 28 %, a odvtedy je to prvá vec, ktorú v pipeline zapnem.

• Cohere Rerank 3.5 (december 2025) drží najvyššie NDCG@10 na BEIR benchmarku (0.548), podporuje 100+ jazykov vrátane slovenčiny a stojí $2 za 1 000 dopytov.
• BGE-reranker-v2-m3 je open-source cross-encoder od BAAI, beží lokálne na jednej A10G GPU s p95 latenciou 45 ms pre 20 dokumentov, a je zadarmo.
• Voyage rerank-2 ponúka najlepší pomer cena/kvalita na kódových a technických korpusoch (0.532 NDCG@10 a $0.05 za 1M tokenov).
• Reranker nasadzujte, keď retrieval Recall@50 > 90 %, ale Precision@5 < 60 %. Presne toto je typický stav prvej RAG iterácie.
• Optimálny pipeline: hybridný retrieval (BM25 + dense), potom 50 kandidátov, rerank, a nakoniec top 5 až 8 do promptu.
• Pre latenciu pod 100 ms zvoľte lokálny BGE alebo Cohere Rerank Nimble; nad 200 ms si dovolíte plnú Cohere Rerank 3.5 alebo Voyage 2.

Čo je reranking v RAG a prečo ho potrebujete

Reranking (preusporiadanie) je druhá fáza dvojfázového vyhľadávania. V prvej fáze bi-encoder (napríklad text-embedding-3-large alebo BGE-M3) prevedie dopyt aj dokumenty na vektory, a vektorová databáza vráti top-N kandidátov podľa kosínusovej podobnosti. Táto fáza je rýchla (ANN index vyhľadá 50 dokumentov spomedzi miliónov za jednotky milisekúnd), ale nepresná. Semantická podobnosť vo vektorovom priestore jednoducho nie je totožná s tým, čo v skutočnosti odpovedá na otázku používateľa.

Cross-encoder reranker berie dvojicu (dopyt, dokument) a spustí cez ňu celý transformer, ktorý vidí obe strany naraz. Výsledkom je skalárne skóre relevancie. Tento krok je 100 až 1000-krát drahší než jedno vyhľadanie vo vektorovom indexe, preto sa aplikuje len na malý top-N (typicky 20 až 100 kandidátov), nie na celý korpus. V produkčnej RAG pipeline (viď náš kompletný sprievodca budovaním Agentic RAG pipeline) reranking typicky zvyšuje Answer Correctness meraný cez RAGAS o 15 až 35 % pri zanedbateľných nákladoch. Pri objeme 1M dopytov mesačne to znamená cca $2 000 na Cohere Rerank 3.5, čo je vo väčšine prípadov najlacnejší spôsob, ako zlepšiť kvalitu RAG bez ladenia embeddingov alebo prompt engineeringu.

Cross-encoder vs bi-encoder: technický rozdiel

Bi-encoder (dual encoder) kóduje dopyt a dokument nezávisle na dva vektory, a podobnosť počíta ako dot product. Vďaka nezávislosti sa vektory dokumentov dajú predpočítať a uložiť do indexu (Pinecone, Qdrant, Weaviate). Latencia jedného vyhľadania je 5 až 20 ms aj pri stovkách miliónov dokumentov.

Cross-encoder spojí dopyt a dokument do jedného vstupu ako [CLS] query [SEP] document [SEP] a nechá transformer prepočítať pozornosť naprieč oboma. Model vidí presné slovné prekryvy, negácie, čísla, teda všetko, čo bi-encoder pri kompresii na 1024-dimenzný vektor stráca. Cenou je, že skóre sa nedá predpočítať; pri každom dopyte treba spustiť N inferencie (jedna na kandidáta).

Preto všetky produkčné rerankery používajú list-wise scoring. Modelu pošlete dopyt a zoznam 20 až 100 dokumentov, on vráti skóre pre každý. Cohere a Voyage optimalizujú túto operáciu na GPU s batching a kv-cache pre spoločné časti (dopyt), takže reálna latencia rastie sub-lineárne: 20 dokumentov ~80 ms, 100 dokumentov ~250 ms na Cohere Rerank 3.5.

Existuje aj hybridný prístup, ColBERTv2 (late-interaction), ktorý predpočíta vektor pre každý token dokumentu a pri dopyte robí lacné MaxSim výpočty. Kvalita blízko cross-encodera, latencia blízko bi-encodera. Háčik je v tom, že úložisko dokumentu je 100 až 500-krát väčšie než pri klasickom dense retrievale, čo pre väčšinu produkčných systémov nie je akceptovateľné.

Cohere vs BGE vs Voyage: porovnávacia tabuľka 2026

Nasledovná tabuľka zhŕňa aktuálny stav troch hlavných voľieb k augustu 2026. NDCG@10 hodnoty sú z BEIR benchmarku (13 datasetov), latencia meraná na 20 dokumentov po 512 tokenov.

Vlastnosť	Cohere Rerank 3.5	BGE-reranker-v2-m3	Voyage rerank-2
Typ	Managed API	Open source (MIT)	Managed API
Vydané	December 2025	Marec 2024 (updated 2025)	Október 2024
NDCG@10 (BEIR priemer)	0.548	0.512	0.532
Kontextové okno	4 096 tokenov	8 192 tokenov	16 000 tokenov
Podpora jazykov	100+ vrátane SK/CZ	100+ (multilingual)	Anglicky + technická podpora ostatných
Cena	$2 / 1 000 dopytov	Zadarmo (self-hosted)	$0.05 / 1M tokenov
Latencia p50 (20 docs)	85 ms (API)	45 ms (A10G GPU)	110 ms (API)
Max dokumentov / dopyt	1 000	Neobmedzené	1 000
Najlepšie pre	Multilingválny, generický RAG	Cost-sensitive, on-prem	Kód, technická dokumentácia

Cohere Rerank 3.5 v praxi

Cohere Rerank 3.5 je aktuálna vlajková loď a najjednoduchšia produkčná voľba, ak akceptujete managed API. V decembri 2025 Cohere vydal aj Nimble variant, ktorý je 3-krát rýchlejší za cenu 2 % NDCG poklesu. Fajn voľba pre latency-sensitive UI vyhľadávanie. Detaily nájdete v oficiálnej Cohere Rerank dokumentácii.

Integrácia s existujúcim retrieval pipeline je priamočiara. Cohere dostane dopyt a zoznam string dokumentov, vráti indexy s relevance skóre:

import cohere
from qdrant_client import QdrantClient

co = cohere.ClientV2(api_key="...")
qdrant = QdrantClient(url="http://localhost:6333")

def rag_search(query: str, top_k: int = 5) -> list[dict]:
    # 1. Prva faza: dense retrieval z Qdrantu (top 50 kandidatov)
    query_vector = embed(query)  # napr. text-embedding-3-large
    candidates = qdrant.search(
        collection_name="docs",
        query_vector=query_vector,
        limit=50,
    )
    documents = [hit.payload["text"] for hit in candidates]

    # 2. Druha faza: rerank cez Cohere
    rerank_result = co.rerank(
        model="rerank-v3.5",
        query=query,
        documents=documents,
        top_n=top_k,
        return_documents=False,  # usetrime bandwidth
    )

    # 3. Zoradenie originalnych hits podla rerank skore
    reranked = []
    for r in rerank_result.results:
        hit = candidates[r.index]
        reranked.append({
            "text": hit.payload["text"],
            "source": hit.payload["source"],
            "vector_score": hit.score,
            "rerank_score": r.relevance_score,
        })
    return reranked

Dve dôležité veci, ktoré nováčikovia prehliadajú (a áno, ja som prvýkrát prehliadol obe). top_n parameter je počet výsledkov, ktoré chcete vrátiť, nie počet, ktorý reranker skóruje. Vždy vám prepočíta všetkých 50, ale filter aplikuje na konci. A return_documents=False šetrí latenciu aj náklady, keďže originálne dokumenty už máte v candidates.

BGE-reranker-v2-m3 lokálne nasadenie

BGE-reranker-v2-m3 od Beijing Academy of Artificial Intelligence je najlepší open-source reranker roku 2026. Beží ako 568M-parametrový XLM-RoBERTa cross-encoder pod MIT licenciou. Kompletná dokumentácia je na HuggingFace model card BAAI/bge-reranker-v2-m3.

Pre produkčný self-hosting odporúčam nasadiť cez text-embeddings-inference (TEI) od HuggingFace. Je to Rust binárka s TensorRT/CUDA backendom, ktorá zvláda ~500 QPS na jednej A10G:

# Docker deployment
docker run --gpus all -p 8080:80 \
  -v $PWD/data:/data \
  ghcr.io/huggingface/text-embeddings-inference:1.5 \
  --model-id BAAI/bge-reranker-v2-m3 \
  --max-batch-tokens 16384 \
  --max-concurrent-requests 128

V Python klientovi:

import httpx

TEI_URL = "http://localhost:8080/rerank"

async def bge_rerank(query: str, documents: list[str], top_k: int = 5):
    async with httpx.AsyncClient(timeout=5.0) as client:
        resp = await client.post(TEI_URL, json={
            "query": query,
            "texts": documents,
            "truncate": True,
            "truncation_direction": "Right",
        })
    scored = resp.json()  # [{"index": 0, "score": 0.87}, ...]
    scored.sort(key=lambda x: x["score"], reverse=True)
    return [documents[s["index"]] for s in scored[:top_k]]

Pri väčších objemoch (viac ako 100 QPS) sa oplatí kvantizácia. BGE-reranker-v2-m3 v FP8 cez TensorRT-LLM zvláda ~1 200 QPS na jednej H100 s poklesom NDCG@10 iba o 0.4 %. Alternatíva je bge-reranker-v2-gemma (2.5B parametrov, o 3 % vyššie NDCG), ale potrebuje minimálne A100 40GB.

Voyage rerank-2 integrácia

Voyage AI (kúpené MongoDB v roku 2025) sa profiluje ako špecialista na technické a kódové domény. Ich voyage-rerank-2 exceluje na CodeSearchNet a StackOverflow benchmarkoch. V BEIR CodeSearch dosahuje NDCG@10 0.61, čo je najvyššie z porovnávanej trojky. Pre generický anglický korpus je porovnateľný s Cohere; pre neanglické jazyky výrazne slabší.

API má identický tvar ako Cohere, čo uľahčuje A/B testovanie:

import voyageai

vo = voyageai.Client(api_key="...")

def voyage_rerank(query: str, documents: list[str], top_k: int = 5):
    result = vo.rerank(
        query=query,
        documents=documents,
        model="rerank-2",
        top_k=top_k,
    )
    return [
        {"text": r.document, "score": r.relevance_score}
        for r in result.results
    ]

Voyage má dva zásadné rozdiely oproti Cohere. Po prvé, tokenový billing (0.05 USD za 1M tokenov) je predvídateľnejší pri variabilnej dĺžke dokumentov. Po druhé, 16 000-tokenové kontextové okno vám umožní rerankovať aj dlhé kód-bloky bez chunkingu. Detaily v Voyage reranker dokumentácii.

Kedy použiť reranker (a kedy nie)

Reranker má zmysel keď platia všetky tri podmienky súčasne. (1) Váš retrieval Recall@50 je nad 90 %, teda relevantný dokument sa v top 50 nachádza, ale nie na správnej pozícii. (2) LLM dostáva top 3 až 10 dokumentov, kde záleží na presnom poradí. (3) Máte latenčný budget aspoň 100 ms navyše.

Naopak, reranker nepridávajte, keď:

• Retrieval Recall@50 < 80 %. Problém máte v embeddingoch alebo chunkingu, reranker to nezachráni. Preinvestujte do lepšieho embedding modelu (text-embedding-3-large, voyage-3) alebo hybridného vyhľadávania.
• LLM dostáva všetkých top-50 dokumentov (dlhý kontext, napríklad Gemini 2M). Poradie v takom prípade LLM sám interne vyhodnotí a rerank je márny.
• Máte striktný latenčný budget pod 100 ms end-to-end. Potom radšej investujte do lepšieho bi-encodera alebo ColBERTv2.
• Váš use-case je fact lookup, nie ranking. Napríklad "koľko stojí produkt X", kde stačí exact match cez BM25.

Reranking je najsilnejší pri konverzačnom RAG a agentic vyhľadávaní. Ak staviate multi-turn RAG chatbot, prečítajte si aj náš článok o Context Engineering, kde rerank tvorí jeden z pilierov spravovania kontextového okna.

Latencia a optimalizácia pre produkciu

Latencia rerank kroku má tri zložky: (1) sieťová round-trip pre managed API, (2) čas na skórovanie N kandidátov, (3) serializácia dokumentov do payloadu. Pri Cohere je bod (3) často najhorší. 50 dokumentov po 800 tokenov = 40 KB JSON, ktorý na 4G mobile spôsobí 200 ms navyše len na upload. (Na tomto som stratil dva sprinty v projekte pre klienta, kým sme si to všimli v Chrome DevTools.)

Optimalizácia 1: agresívny truncation

Reranker sa pozerá primárne na prvých ~300 tokenov dokumentu. Skráťte dokumenty na 512 tokenov pred odoslaním. NDCG@10 poklesne o menej než 1 %, ale payload sa zmenší 2 až 4-krát.

Optimalizácia 2: znížte top-N kandidátov inteligentne

Namiesto slepého top-50 z vektorovej DB použite reciprocal rank fusion (RRF). Spojte top-30 z dense (embeddings) a top-30 z sparse (BM25), zlúčte podľa RRF skóre. Získate ~40 unikátnych kandidátov s vyšším Recall@40 než čistý top-50 dense retrieval.

from collections import defaultdict

def reciprocal_rank_fusion(rankings: list[list[str]], k: int = 60):
    scores = defaultdict(float)
    for ranking in rankings:
        for rank, doc_id in enumerate(ranking):
            scores[doc_id] += 1.0 / (k + rank + 1)
    return sorted(scores.items(), key=lambda x: x[1], reverse=True)

# Pouzitie
dense_ids = [hit.id for hit in qdrant.search(...)][:30]
sparse_ids = [hit.id for hit in bm25_search(...)][:30]
fused = reciprocal_rank_fusion([dense_ids, sparse_ids])
top_40 = [doc_id for doc_id, _ in fused[:40]]

Optimalizácia 3: cache rerank výsledkov

Ak váš traffic obsahuje opakujúce sa dopyty (typický zákaznícky support, FAQ), cachujte hash (query, sorted(doc_ids)) a vracajte poradie. Hit ratio 30 až 50 % ušetrí polovicu rerank nákladov. Cachovaciu vrstvu odporúčam postaviť rovnako ako pri klasickom semantickom cachi, koncepty pokrývame v článku o Semantic Caching pre LLM.

Optimalizácia 4: streamované rerankovanie

Pri konverzačnom UI nemusíte čakať na celý rerank pred začiatkom LLM generácie. Cohere API vracia výsledky až po skončení, ale pri BGE si viete pipe-linovať: spustite rerank paralelne s inicializáciou LLM streamu a začnite generovať odpoveď hneď, ako máte top-3.

Ako merať zlepšenie po pridaní rerankera

Bez merania to nemá zmysel robiť. Fakt, videl som viacero tímov len "predpokladať", že rerank pomáha. Minimum, ktoré potrebujete pred nasadením:

1. Zlatý dataset 100 až 500 dopytov s manuálne anotovanými relevantnými dokumentmi (grade 0/1/2). Vytvorenie zaberie 4 až 8 hodín, ale slúži roky.
2. Metriky: NDCG@5, Recall@5, MRR@10. NDCG penalizuje zlé poradie relevantných dokumentov, MRR odmeňuje rýchle nájdenie prvého správneho.
3. Baseline bez rerankera. Spustite pipeline len s vektorovým vyhľadávaním na tom istom datasete. Ak zlepšenie po rerankeri je pod 5 %, buď váš dataset je príliš jednoduchý, alebo retrieval už dáva takmer dokonalé poradie.
4. Answer-level metriky: Answer Correctness, Faithfulness cez RAGAS alebo DeepEval nad koncovými LLM odpoveďami. Toto je jediná metrika, ktorá naozaj rozhoduje.

V produkcii sledujte pomer rerank_score_top1 / vector_score_top1 ako proxy pre "reranker preusporiadal výsledky". Ak je konzistentne blízko 1.0, reranker vám nepridáva hodnotu a šetríte peniaze jeho vypnutím pre daný typ dopytov.

Odporúčaný produkčný pipeline pre RAG s rerankerom (2026)

Zhrnutie best practice architektúry, ktorú vidíme fungovať v produkčných deployoch:

1. Chunking: 512 až 1 024 tokenov s prekrytím 15 %, granularity semantic (nie fixed-size).
2. Embeddings: text-embedding-3-large alebo voyage-3 pre EN, BGE-M3 pre multilingválne korpusy vrátane slovenčiny.
3. Vektorová DB: Qdrant alebo Pinecone s HNSW indexom (M=32, efConstruction=200). Detailné porovnanie v článku Vektorové databázy 2026: Pinecone vs Weaviate vs Qdrant vs Chroma.
4. Hybrid retrieval: dense top-30 + BM25 top-30, RRF fúzia, spolu 40 unikátov.
5. Reranker: Cohere Rerank 3.5 (managed, multilingválny) alebo BGE-reranker-v2-m3 (self-hosted, cost-sensitive), skóruje 40 a vracia top-5.
6. LLM kontext: top-5 dokumentov + system prompt + user query, s kompresiou dlhých citácií cez LLMLingua ak treba.
7. Observabilita: log query, retrieval scores, rerank scores, LLM latency + tokens cez Langfuse (viď náš prehľad LLM Observability nástrojov).

Často kladené otázky

Aký je rozdiel medzi retriever a reranker?

Retriever je bi-encoder, ktorý kóduje dopyt a dokumenty nezávisle na vektory a vráti top-N kandidátov z veľkého korpusu za milisekundy. Reranker je cross-encoder, ktorý berie dvojicu (dopyt, dokument) spolu, vyhodnotí ich vzájomnú relevanciu a preusporiada malý zoznam (typicky 20 až 100 kandidátov od retrievera) s vyššou presnosťou.

Kedy potrebujem reranker v RAG pipeline?

Reranker pridajte, keď váš Recall@50 z vektorového vyhľadávania je nad 90 %, ale Precision@5 klesá pod 60 % a máte latenčný budget aspoň 100 ms navyše. To je typický stav prvej produkčnej RAG iterácie, keď embedding model nájde relevantné dokumenty, ale nedokáže ich správne zoradiť.

Je BGE-reranker rovnako dobrý ako Cohere Rerank?

Na BEIR benchmarku má BGE-reranker-v2-m3 NDCG@10 = 0.512 vs Cohere Rerank 3.5 = 0.548, rozdiel cca 7 %. V praxi je BGE dostatočne kvalitný pre 80 % use-caseov, hlavne ak beží lokálne na GPU (45 ms p50 latencia, nulové API náklady). Cohere volte, keď potrebujete multilingválnu podporu, žiadnu infraštruktúru alebo vysokú kvalitu na out-of-domain dopytoch.

Koľko kandidátov mám poslať do rerankera?

Optimum je 30 až 50 kandidátov pre väčšinu prípadov. Pod 20 kandidátov reranker nemá čo preusporiadať; nad 100 kandidátov rastú náklady lineárne bez zodpovedajúceho zlepšenia NDCG. Pre kompozitný retrieval (dense + BM25 s RRF fúziou) stačí posielať 40 unikátnych kandidátov.

Ovplyvňuje reranker halucinácie LLM?

Nepriamo áno. Reranker zvyšuje kvalitu top-5 dokumentov, ktoré LLM vidí v kontexte. Ak LLM dostane relevantnejšie zdroje, generuje odpovede s vyššou Faithfulness (menej halucinácií). V našich testoch cez RAGAS pridanie Cohere Rerank znížilo mieru halucinácií o 22 až 34 % v závislosti od domény.

Dá sa reranker použiť aj mimo RAG?

Áno, všade, kde máte kandidátov od lacného retrievera, ktorých treba presne zoradiť. Typické mimo-RAG use-cases: preusporiadanie výsledkov e-commerce vyhľadávania, ranking odporúčaní, filtrovanie duplikátov v deduplication pipeline, alebo výber najlepšieho tool-callu pre agentic systémy.