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

Reranking to drugi etap wyszukiwania w pipelinie RAG: cross-encoder ponownie ocenia najlepszych kandydatów znalezionych przez szybki bi-encoder i sortuje ich według rzeczywistej trafności względem zapytania. Według Anthropic reranking wyraźnie obniża wskaźnik błędów wyszukiwania w porównaniu z samym wyszukiwaniem wektorowym, kosztem wyższej latencji. Reranking nie jest więc opcjonalnym dodatkiem, tylko w systemach produkcyjnych najpewniejszym narzędziem, które oddziela to, co „semantycznie podobne”, od tego, co „faktycznie trafne”.

• Co robi: reranking porządkuje na nowo kandydatów znalezionych w pierwszym wyszukiwaniu, zanim trafią do promptu LLM.
• Dlaczego dwa etapy: szybki bi-encoder zapewnia recall w milionach chunków, a dokładny cross-encoder precyzję w końcowym top-k.
• Konkretny efekt: Anthropic podaje redukcję wskaźnika błędów wyszukiwania top-20 nawet o 67%, gdy Contextual Retrieval łączy się z rerankingiem.

Dlaczego jednoetapowe wyszukiwanie nie wystarcza

Klasyczne wyszukiwanie wektorowe działa w oparciu o bi-encoder. Koduje on z wyprzedzeniem każdy chunk dokumentu w wektor i zapisuje go w indeksie ANN (najczęściej HNSW). W chwili wysłania zapytania jest ono rzutowane w tę samą przestrzeń wektorową, a podobieństwo oblicza się za pomocą odległości kosinusowej. To niezwykle szybkie i skaluje się do milionów wpisów, ale jest tylko przybliżeniem. Zapytanie i dokument nigdy „nie widzą” się nawzajem; model porównuje jedynie dwie niezależnie wygenerowane, skompresowane reprezentacje.

Skutkiem jest typowy antywzorzec: wyniki top-k są semantycznie podobne, ale niekoniecznie trafne dla konkretnego pytania. Właśnie tu wkracza reranking. To etap następujący po wyszukiwaniu, który stosuje dokładniejszy, choć wolniejszy mechanizm do niewielkiego zbioru kandydatów zamiast do całego korpusu.

Bi-encoder vs. cross-encoder: kluczowa różnica

Architektonicznym sednem rerankingu jest przejście od bi-encodera do cross-encodera.

Bi-encoder przetwarza zapytanie i dokument osobno. Każde z nich jest kodowane w osobny wektor, a trafność wynika dopiero z odległości między tymi wektorami. Ponieważ embeddingi dokumentów można obliczyć i zaindeksować z wyprzedzeniem, bi-encoder jest jedynym praktycznym wyborem do wstępnego wyszukiwania w dużych korpusach.

Cross-encoder przetwarza zapytanie i dokument razem w jednym przebiegu (forward pass). Model widzi oba teksty jednocześnie i może uwzględnić interakcje słowo po słowie, negacje oraz subtelne różnice znaczeniowe. Wynikiem jest znacznie precyzyjniejsza ocena trafności, przy czym obliczenia trzeba wykonać dla każdej pary zapytanie-dokument. Dla milionów chunków byłoby to zaporowo drogie; dla 50 do 100 wstępnie przefiltrowanych kandydatów jest akceptowalne.

Pośrodku znajduje się podejście late interaction (ColBERT): przechowuje embeddingi na poziomie tokenów dla każdego dokumentu i oblicza trafność za pomocą operacji MaxSim między tokenami zapytania i dokumentu. Zapewnia to większą dokładność niż klasyczny bi-encoder przy lepszej skalowalności niż pełny cross-encoder, ale wymaga znacznie więcej pamięci na wektory tokenów.

Miejsce w pipelinie i strategia top-k

Reranking to ściśle określony etap ścieżki zapytania. Kanoniczny układ wygląda tak:

```
[Wyszukiwanie hybrydowe, top_k = 50-100]
-> [Cross-Encoder Reranker (Cohere Rerank / BGE / Jina)]
-> [top_k = 5-10]
-> [Prompt + cytowanie źródeł]
-> [LLM]
```

Kluczowa kwestia: reranker wchodzi do gry dopiero po tanim etapie recall z bi-encoderem. Wstępne wyszukiwanie hybrydowe (wyszukiwanie gęste i BM25, połączone metodą Reciprocal Rank Fusion) celowo zwraca obszerną pulę od 50 do 100 kandydatów, aby zmaksymalizować recall. Następnie cross-encoder zawęża tę pulę do 5–10 naprawdę trafnych chunków, które trafiają do promptu.

To zawężenie nie jest wyłącznie kwestią kosztów. Zbyt duże top-k przekazane do LLM prowadzi do efektu „Lost-in-the-Middle”: istotne informacje ze środka długiego kontekstu są gorzej przetwarzane, a koszty tokenów rosną. Standardowym środkiem zaradczym jest reranking w połączeniu z wąskim top-k na poziomie od 5 do 10, z dodatkową wskazówką, by najważniejsze chunki umieszczać na początku promptu.

Przegląd modeli rerankingu (stan na październik 2026)

W europejskich scenariuszach z wymogami suwerenności danych najbardziej oczywistą opcją on-premise jest BGE-Reranker v2-m3: jest dostępny na licencji Apache 2.0, jest wielojęzyczny i można go komercyjnie uruchamiać we własnym centrum danych lub w regionie UE. Starszy bge-reranker-large (licencja MIT) według karty modelu obsługuje tylko chiński i angielski. Jina Reranker v2, v3 i v3.5 (opublikowany 27.07.2026) mają wprawdzie otwarte wagi, ale są objęte licencją CC BY-NC 4.0. Do komercyjnego wdrożenia on-premise potrzebujesz licencji od Jina AI; w przeciwnym razie pozostają API Jina, Elastic Inference Service lub oferty na AWS, Azure i Google Cloud. Jina AI ma siedzibę w Berlinie, ale od października 2025 r. należy do Elastic.

Jeśli akceptujesz API i potrzebujesz wielojęzycznej jakości, także dla niemieckiego, w praktyce sięgniesz po Cohere Rerank. Alternatywa, Voyage, należy od lutego 2025 r. do MongoDB; aktualne modele to rerank-3 i rerank-3-lite. Według wpisu premierowego z 30.09.2026 Voyage przetestował rerank-3 na 95 zbiorach danych z 9 domen, w tym na 51 wielojęzycznych w 31 językach. Podejście LLM-as-Judge (na przykład LLMRanker w Haystack) jest najbardziej elastyczne, ale najdroższe w przeliczeniu na zapytanie i powinno być stosowane tylko tam, gdzie jakość rerankingu jest krytyczna, a budżet latencji duży.

Kompromis między latencją a jakością

Reranking to najdroższy etap w części wyszukiwania ścieżki online (przed generowaniem odpowiedzi przez LLM), ponieważ cross-encoder wykonuje obliczenia dla każdego kandydata. W systemach produkcyjnych łączna latencja wyszukiwania hybrydowego i rerankingu wynosi zwykle od około 100 do 800 milisekund. Tym zakresem można bezpośrednio sterować:

• Wielkość puli wejściowej: reranking 100 kandydatów kosztuje więcej niż 30. W zależności od korpusu często wystarcza mniejsza pula.
• Wybór modelu: rerankery dostępne przez API, takie jak Cohere, są zoptymalizowane pod kątem przepustowości; LLM-as-Judge jest znacznie wolniejszy.
• Sprzęt: samodzielnie hostowane rerankery mocno zyskują na inferencji na GPU; na CPU latencja znacznie rośnie.

Kompromis nie brzmi więc „reranking: tak czy nie”, tylko „ilu kandydatów przy jakim budżecie latencji”. W większości zastosowań korporacyjnych wzrost precyzji jest wart dodatkowej latencji.

Przykład liczbowy: wzrost precyzji

W publikacji „Introducing Contextual Retrieval” (19.09.2024) Anthropic zmierzył konkretne wartości na własnych benchmarkach (kod, beletrystyka, artykuły z ArXiv, nauka); jako reranker posłużył Cohere. Należy to czytać jako ewaluację dostawcy, który ma w tym własny interes, ale udokumentowaną metodologicznie:

• Punkt wyjścia (samo wyszukiwanie): wskaźnik błędów wyszukiwania top-20 wynosi 5,7%.
• Same Contextual Embeddings: redukcja o 35% do 3,7%.
• Contextual Retrieval (embeddingi plus BM25): redukcja o 49% do 2,9%.
• Contextual Retrieval plus reranking: redukcja o 67% do 1,9%.

W praktyce oznacza to: z 1000 trafnych dokumentów na początku w top-20 brakuje 57, a przy pełnym pipelinie już tylko 19. Sam reranking, czyli krok z 2,9 do 1,9%, eliminuje w tym układzie mniej więcej kolejną jedną trzecią pozostałych błędów. W produkcyjnym systemie RAG każdy uniknięty błąd wyszukiwania oznacza o jeden chunk mniej, który mógłby skłonić LLM do błędnej lub niepopartej źródłami odpowiedzi. Właśnie dlatego praktyka RAG wymienia „brak rerankingu” jako wyraźny antywzorzec: top-k są wtedy wprawdzie semantycznie podobne, ale nie trafne.

Dla agencji i decydentów B2B

Jeśli wdrażasz produkcyjny system RAG w Europie, od początku zaplanuj reranking jako stały etap pipeline'u, a nie jako późniejszy tuning. Efekt jest duży, a nakład pracy przy wdrożeniu umiarkowany: dodatkowe wywołanie API (Cohere) albo samodzielnie hostowany reranker z otwartą licencją, taki jak BGE v2-m3, między wyszukiwaniem a LLM. Dla agencji, które budują dla klientów asystentów wiedzy lub wewnętrzne wyszukiwarki, reranking daje najlepszy stosunek wzrostu jakości do nakładu pracy i jest mierzalnym argumentem w pitchu, bo wzrost precyzji da się wykazać we frameworkach ewaluacyjnych takich jak RAGAS (Context Precision). Blck Alpaca projektuje takie dwuetapowe architektury wyszukiwania, łącznie z wyborem modeli zgodnym z wymogami UE i budżetowaniem latencji. Zleć sprawdzenie swojego obecnego pipeline'u RAG pod kątem tego, czy właściwe chunki rzeczywiście trafiają na początek.