Reranking v RAG: cross-encoder vs. bi-encoder

Reranking je druhý stupeň retrievalu v RAG pipeline: cross-encoder znovu ohodnotí top kandidátov, ktorých našiel rýchly bi-encoder, a zoradí ich podľa skutočnej relevancie k dopytu. Podľa Anthropic reranking oproti čistému vektorovému retrievalu výrazne znižuje chybovosť retrievalu, za cenu vyššej latencie. Reranking preto nie je voliteľný doplnok, ale v produkčných systémoch najspoľahlivejšia páka medzi „sémanticky podobným“ a „skutočne relevantným“.

• Čo robí: Reranking preusporiada kandidátov z prvého retrievalu skôr, než sa dostanú do promptu LLM.
• Prečo dva stupne: Rýchly bi-encoder zabezpečuje recall nad miliónmi chunkov, presný cross-encoder precision na finálnych top-k.
• Konkrétny efekt: Anthropic uvádza zníženie chybovosti retrievalu v top-20 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ý chunk dokumentu do vektora a uloží ho do ANN indexu (väčšinou HNSW). Keď príde dopyt, premietne sa do toho istého vektorového priestoru a podobnosť sa vypočíta pomocou kosínusovej vzdialenosti. To je extrémne rýchle a škáluje na milióny záznamov, ale ide o aproximáciu. Dopyt a dokument sa nikdy „nevidia“ spoločne; model porovnáva len dve nezávisle vytvorené zhustené reprezentácie.

Výsledkom je typický anti-pattern: top-k výsledky sú sémanticky podobné, ale nie nevyhnutne relevantné pre konkrétnu otázku. Práve tu nastupuje reranking. Je to post-retrieval stupeň, ktorý použije presnejší, ale pomalší mechanizmus na malú množinu kandidátov, a nie 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 dopyt a dokument oddelene. Každý z nich sa zakóduje do vlastného vektora a relevancia vyplynie až dodatočne 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 nad veľkými korpusmi.

Cross-encoder spracúva dopyt a dokument spoločne v jedinom doprednom prechode (forward pass). Model vidí oba texty naraz a dokáže zohľadniť interakcie medzi jednotlivými slovami, negácie a jemné významové rozdiely. Výsledkom je výrazne presnejšie hodnotenie relevancie, výpočet však treba spustiť pre každý pár dopytu a dokumentu. Pri miliónoch chunkov by to bolo neúnosne drahé; pri 50 až 100 predfiltrovaných kandidátoch je to prijateľné.

Medzi nimi leží prístup late interaction (ColBERT): pre každý dokument ukladá embeddingy na úrovni tokenov a relevanciu počíta pomocou operácie MaxSim medzi tokenmi dopytu a dokumentu. Ponúka vyššiu presnosť než klasický bi-encoder a lepšiu škálovateľnosť než plný cross-encoder, stojí však výrazne viac pamäte na vektory tokenov.

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

Reranking je pevne definovaný stupeň na ceste spracovania dopytu. 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 lacnom úvodnom vyhľadávaní (recall) pomocou bi-encodera. Úvodný hybridný retrieval (dense plus BM25, zlúčený cez Reciprocal Rank Fusion) zámerne dodá veľkorysú množinu 50 až 100 kandidátov, aby maximalizoval recall. Cross-encoder potom túto množinu zúži na 5 až 10 skutočne relevantných chunkov, ktoré sa dostanú do promptu.

Toto zúženie nie je len otázkou 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 malé top-k 5 až 10 je štandardné protiopatrenie, s doplňujúcim odporúčaním umiestniť najdôležitejšie chunky na začiatok promptu.

Prehľad modelov na reranking (stav k októbru 2026)

Pre scenáre v regióne DACH s požiadavkou na suverenitu je BGE-Reranker v2-m3 najlogickejšia voľba pre on-prem prevádzku: je pod licenciou Apache 2.0, je viacjazyčný a komerčne smie bežať vo vlastnom dátovom centre alebo v regióne EÚ. Starší bge-reranker-large (licencia MIT) podľa karty modelu pokrýva len čínštinu a angličtinu. Jina Reranker v2, v3 a v3.5 (vydaný 27.07.2026) majú síce otvorené váhy, sú však pod licenciou CC BY-NC 4.0. Na komerčné nasadenie on-prem potrebuješ licenciu od Jina AI, inak môžeš použiť Jina API, Elastic Inference Service alebo ponuky na AWS, Azure a Google Cloud. Jina AI sídli v Berlíne, no od októbra 2025 patrí spoločnosti Elastic.

Kto akceptuje API a potrebuje viacjazyčnú kvalitu vrátane nemčiny, siahne v praxi po Cohere Rerank. Alternatíva Voyage patrí od februára 2025 spoločnosti MongoDB, aktuálne modely sú rerank-3 a rerank-3-lite. Podľa oznámenia o uvedení modelu z 30.09.2026 Voyage otestoval rerank-3 na 95 dátových sadách z 9 domén, z toho 51 viacjazyčných z 31 jazykov. Prístup LLM-as-Judge (napríklad LLMRanker v Haystacku) je najflexibilnejší, ale na jeden dopyt najdrahší a mal by sa nasadzovať len tam, kde je kvalita rerankingu kritická a latenčný rozpočet veľkorysý.

Kompromis medzi latenciou a kvalitou

Reranking je najdrahší stupeň v časti retrievalu na online ceste (pred generovaním v LLM), pretože cross-encoder počíta pre každého kandidáta zvlášť. V produkčných systémoch sa celková latencia hybridného retrievalu plus rerankingu typicky pohybuje okolo 100 až 800 milisekúnd. Toto rozpätie sa dá priamo ovládať:

• Veľkosť vstupnej množiny: Rerankovať 100 kandidátov stojí viac než 30. V závislosti od korpusu často stačí menšia množina.
• Voľba modelu: API rerankery ako Cohere sú optimalizované na priepustnosť; LLM-as-Judge je výrazne pomalší.
• Hardvér: Rerankery hostované na vlastnej infraštruktúre výrazne profitujú z inferencie na GPU; na CPU latencia citeľne rastie.

Otázka teda neznie „reranking áno alebo nie“, ale „koľko kandidátov pri akom latenčnom rozpočte“. Pri väčšine podnikových prípadov použitia sa nárast presnosti oplatí aj za cenu dodatočnej latencie.

Číselný príklad: nárast presnosti (precision)

Anthropic v publikácii „Introducing Contextual Retrieval“ (19.09.2024) nameral konkrétne čísla na vlastných benchmarkoch (Code, Fiction, ArXiv-Papers, Science); ako reranker slúžil Cohere. Ide o evaluáciu dodávateľa s vlastným záujmom, metodicky je však zdokumentovaná:

• Základ (čistý retrieval): chybovosť retrievalu v top-20 je 5,7 percenta.
• Samotné Contextual Embeddings: zníženie o 35 percent na 3,7 percenta.
• Contextual Retrieval (embeddingy plus BM25): zníženie o 49 percent na 2,9 percenta.
• Contextual Retrieval plus reranking: zníženie o 67 percent na 1,9 percenta.

Konkrétne to znamená: z 1 000 relevantných dokumentov ich na začiatku v top-20 chýba 57, s plnou pipeline už len 19. Samotný reranking, teda krok z 2,9 na 1,9 percenta, v tomto nastavení odstráni zhruba ďalšiu tretinu zostávajúcich 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 manažérov

Kto v regióne DACH stavia produkčný RAG systém, mal by reranking od začiatku naplánovať ako pevný stupeň pipeline, nie ako dodatočné ladenie. Páka je veľká a implementačná náročnosť zvládnuteľná: jedno dodatočné volanie API (Cohere) alebo reranker s otvorenou licenciou hostovaný na vlastnej infraštruktúre, napríklad BGE v2-m3, medzi retrievalom a LLM. Pre agentúry, ktoré pre klientov stavajú znalostných asistentov alebo interné vyhľadávanie, má reranking najlepší pomer medzi nárastom kvality a námahou a je merateľným argumentom v pitchi, pretože nárast presnosti sa dá doložiť v evaluačných frameworkoch ako RAGAS (Context Precision). Blck Alpaca navrhuje takéto dvojstupňové architektúry retrievalu vrátane voľby modelov v súlade s pravidlami EÚ a rozpočtovania latencie. Nechaj si svoju existujúcu RAG pipeline preveriť, či sa správne chunky naozaj dostanú na začiatok.