Reranking v RAG: Cross-Encoder vs. Bi-Encoder

Reranking je druhý stupeň retrievalu v RAG pipeline: Cross-Encoder opätovne ohodnotí top kandidátov nájdených rýchlym Bi-Encoderom a zoradí ich podľa skutočnej relevancie voči query. Podľa Anthropic reranking výrazne znižuje chybovosť retrievalu oproti čistému vektorovému retrievalu – za cenu vyššej latencie. Reranking tým nie je voliteľné nice-to-have, ale v produkčných systémoch najspoľahlivejšia páka medzi „sémanticky podobné" a „skutočne relevantné".

• Čo robí: Reranking preusporiada kandidátov nájdených prvým retrievalom skôr, než sa dostanú do LLM promptu.
• Prečo dva stupne: Rýchly Bi-Encoder zabezpečuje recall cez milióny chunkov, presný Cross-Encoder precision na finálnych top-k.
• Konkrétny efekt: Anthropic uvádza redukciu chybovosti top-20 retrievalu až o 67 percent, keď sa Contextual Retrieval skombinuje s rerankingom.

Prečo jednostupňový retrieval nestačí

Klasický vektorový retrieval pracuje s Bi-Encoderom. Ten vopred zakóduje každý dokumentový chunk do vektora a uloží ho v ANN indexe (väčšinou HNSW). V čase dopytu sa query premietne do toho istého vektorového priestoru a podobnosť sa počíta pomocou cosine vzdialenosti. To je extrémne rýchle a škáluje na milióny záznamov – ale je to aproximácia. Query a dokument sa nikdy „nevidia" spoločne; model porovnáva iba dva nezávisle vytvorené zhustené reprezentácie.

Dôsledkom je typický anti-pattern: top-k zásahy sú sémanticky podobné, ale nie nevyhnutne relevantné pre konkrétnu otázku. Práve tu nastupuje reranking. Je to post-retrieval stupeň, ktorý aplikuje presnejší – ale pomalší – mechanizmus na malú množinu kandidátov, namiesto na celý korpus.

Bi-Encoder vs. Cross-Encoder: kľúčový rozdiel

Architektonickým jadrom rerankingu je prechod z Bi-Encodera na Cross-Encoder.

Bi-Encoder spracúva query a dokument oddelene. Oba sa zakódujú každý do vektora, relevancia vznikne až následne zo vzdialenosti týchto vektorov. Keďže embeddingy dokumentov sa dajú vopred vypočítať a indexovať, Bi-Encoder je jediná praktická voľba pre úvodný retrieval cez veľké korpusy.

Cross-Encoder spracúva query a dokument spoločne v jednom jedinom forward-passe. Model vidí oba texty spolu a dokáže zohľadniť interakcie slovo za slovom, negácie a jemné významové rozdiely. Výsledkom je výrazne presnejšie ohodnotenie relevancie – musí sa však počítať pre každý pár query-dokument. Cez milióny chunkov by to bolo prohibitívne drahé; cez 50 až 100 predfiltrovaných kandidátov je to únosné.

Medzi nimi leží Late-Interaction prístup (ColBERT): ukladá token-level embeddingy na dokument a počíta relevanciu pomocou MaxSim operácie medzi tokenmi query a dokumentu. To ponúka vyššiu presnosť než klasický Bi-Encoder pri lepšej škálovateľnosti než plný Cross-Encoder, stojí však výrazne viac pamäte pre token vektory.

Pozícia v pipeline a stratégia top-k

Reranking je pevne definovaný stupeň v query ceste. Kanonické usporiadanie vyzerá takto:

```
[Hybrid Retrieval, top_k = 50-100]
-> [Cross-Encoder Reranker (Cohere Rerank / BGE / Jina)]
-> [top_k = 5-10]
-> [Prompt + citovanie zdrojov]
-> [LLM]
```

Rozhodujúci bod: reranker prichádza až po nákladovo úspornom Bi-Encoder recalle. Úvodný hybrid retrieval (dense plus BM25, fúzovaný cez Reciprocal Rank Fusion) zámerne dodá veľkorysý pool kandidátov 50 až 100 záznamov, aby sa maximalizoval recall. Cross-Encoder potom tento pool zredukuje na 5 až 10 skutočne relevantných chunkov, ktoré sa dostanú do promptu.

Toto zúženie nie je len otázka nákladov. Príliš veľké top-k odovzdané LLM vedie k efektu „Lost-in-the-Middle": relevantné informácie v strede dlhého kontextu sa spracúvajú horšie a náklady na tokeny rastú. Reranking plus tesné top-k 5 až 10 je štandardné protiopatrenie – s dodatočným odporúčaním umiestniť najdôležitejšie chunky vpredu v prompte.

Prehľad reranking modelov (stav 2026)

Pre DACH scenáre s požiadavkou na suverenitu sú relevantné Open-Source možnosti BGE-Reranker a v Berlíne vyvinutý Jina Reranker v2, keďže sa dajú prevádzkovať On-Prem alebo v EU regiónoch. Kto akceptuje API a potrebuje multilingual kvalitu vrátane nemčiny, siahne v praxi po Cohere Rerank. LLM-as-Judge prístup (napríklad LLMRanker v Haystacku) je najflexibilnejší, ale na dopyt najdrahší a mal by sa nasadzovať len tam, kde je kvalita rerankingu kritická a latenčný rozpočet veľkorysý.

Tradeoff latencia/kvalita

Reranking je najdrahší jednotlivý stupeň v online ceste, pretože Cross-Encoder počíta na každého kandidáta. V produkčných systémoch sa celková latencia z hybrid retrievalu plus rerankingu typicky pohybuje okolo 100 až 800 milisekúnd. Toto rozpätie sa dá priamo ovládať:

• Veľkosť vstupného poolu: rerankovať 100 kandidátov stojí viac než 30. Podľa korpusu často stačí menší pool.
• Voľba modelu: API rerankery ako Cohere sú optimalizované na priepustnosť; LLM-as-Judge je výrazne pomalší.
• Hardvér: Open-Source rerankery výrazne profitujú z GPU inferencie; na CPU latencia citeľne rastie.

Tradeoff teda neznie „reranking áno alebo nie", ale „koľko kandidátov pri akom latenčnom rozpočte". Pre väčšinu enterprise use-casov za nárast presnosti dodatočná latencia stojí.

Numerický príklad: nárast precision

Anthropic v publikácii „Introducing Contextual Retrieval" (19.09.2024) nameral konkrétne čísla cez vlastné benchmarky (Code, Fiction, ArXiv-Papers, Science). Treba ich čítať ako vendor-eval s vlastným záujmom, ale metodicky zdokumentovaný:

• Báza (čistý retrieval): chybovosť top-20 retrievalu 5,7 percenta.
• Contextual Embeddings samostatne: redukcia o 35 percent na 3,7 percenta.
• Contextual Retrieval (Embeddings plus BM25): redukcia o 49 percent na 2,9 percenta.
• Contextual Retrieval plus Reranking: redukcia o 67 percent na 1,9 percenta.

Konkrétne to znamená: z pôvodných 57 chýb na 1 000 dopytov zostáva s plnou pipeline už len 19. Reranking samotný – ako krok z 2,9 na 1,9 percenta – v tomto setupe eliminuje zhruba ďalšiu tretinu zvyšných chýb. Pre produkčný RAG systém znamená každá odvrátená chyba retrievalu o jeden chunk menej, ktorý zvádza LLM k nesprávnej alebo nepodloženej odpovedi. Práve preto RAG prax uvádza „žiadny reranking" ako jasný anti-pattern: top-k sú potom síce sémanticky podobné, ale nie relevantné.

Pre agentúry a B2B rozhodovateľov

Kto v DACH nasadzuje produkčný RAG systém, mal by reranking od začiatku plánovať ako pevný stupeň pipeline – nie ako následné ladenie. Páka je veľká, implementačná náročnosť zvládnuteľná: jeden dodatočný API-call (Cohere) alebo vlastne hostovaný Open-Source reranker (BGE, Jina) medzi retrievalom a LLM. Pre agentúry, ktoré stavajú znalostných asistentov alebo interné vyhľadávania pre klientov, je reranking najlepším pomerom medzi nárastom kvality a námahou – a merateľným argumentom v pitchi, pretože nárast precision sa dá doložiť v evaluačných frameworkoch ako RAGAS (Context Precision). Blck Alpaca koncipuje takéto dvojstupňové retrieval architektúry vrátane EU-konformnej voľby modelu a rozpočtovania latencie. Nechajte si svoju existujúcu RAG pipeline preveriť, či správne chunky skutočne prichádzajú vpredu.