Reranker w RAG on-prem: kiedy poprawia trafność, a kiedy tylko zjada budżet GPU

Czas czytania: ok. 9 min. Autor: Fryderyk

Reranker poprawia trafność top-k w RAG wtedy, gdy retriever pierwszego stopnia zwraca dużo kandydatów słabo uporządkowanych, a zapytania są długie i niejednoznaczne. W krótkich, faktograficznych zapytaniach nad dobrze pociętą bazą zysk z rerankingu bywa w granicach szumu, a koszt jest realny: dodatkowy model, dodatkowe opóźnienie i dodatkowy VRAM. Werdykt jest prosty. Najpierw zmierz jakość samego retrievera, dopiero potem dokładaj cross-encoder. Reranker nadrabia słaby retrieval tylko częściowo i nigdy za darmo.

Poniżej rozkładamy to na liczby: co reranker realnie zmienia w metrykach, ile kosztuje w opóźnieniu i pamięci, oraz w jakich konfiguracjach naiwne wpięcie cross-encodera się wykłada.

Spis treści

1. Dwa stopnie retrievalu, jeden powód istnienia rerankera
2. Co reranker zmienia w metrykach (tabela)
3. Koszt: opóźnienie i VRAM (tabela)
4. Dlaczego naiwna konfiguracja się wykłada
5. Kiedy reranker się opłaca, a kiedy nie
6. Czego tu nie pokrywam
7. Disclosure i biases
8. Powiązane

Dwa stopnie retrievalu, jeden powód istnienia rerankera

Klasyczny pipeline RAG ma dwa stopnie. Pierwszy stopień (retriever) przeszukuje całą bazę i zwraca kilkadziesiąt kandydatów. Działa szybko, bo porównuje wektory zapytania i dokumentów (dense), albo dopasowuje terminy (BM25, sparse). Drugi stopień (reranker) bierze tę krótką listę i przelicza każdy kandydat razem z zapytaniem w jednym przebiegu modelu, po czym układa listę od nowa.

Różnica jest architektoniczna. Retriever dense koduje zapytanie i dokument osobno (bi-encoder), więc można policzyć embeddingi dokumentów raz i trzymać w indeksie. Reranker to cross-encoder: wkłada zapytanie i dokument do modelu razem, więc nie da się nic policzyć z wyprzedzeniem. Stąd cała ekonomia tej decyzji. Reranker widzi interakcję słowo-w-słowo między pytaniem a tekstem, której bi-encoder nie widzi, ale płaci za to przebiegiem modelu na każdą parę.

Wniosek operacyjny: reranker ma sens jako wąskie, drugie sito nad listą, którą pierwszy stopień już zawęził do kilkudziesięciu pozycji. Puszczanie cross-encodera po całej bazie nie wchodzi w grę kosztowo.

Co reranker zmienia w metrykach

Mierzymy zwykle nDCG@10 (jak dobrze uporządkowana jest dziesiątka) i Recall@k (ile trafnych dokumentów w ogóle weszło do top-k). Reranker poprawia przede wszystkim porządek, czyli nDCG, a nie samo Recall. Jeśli trafny dokument nie wszedł do listy kandydatów z pierwszego stopnia, reranker go nie wyczaruje.

Poniższe wartości to typowe rzędy wielkości, jakie obserwowaliśmy w testach na bazie dokumentów technicznych w języku polskim i angielskim. Twoje liczby będą zależeć od domeny i jakości chunkingu, więc traktuj je jako kierunek, nie obietnicę.

Konfiguracja	nDCG@10	Recall@20	Uwaga
Dense sam (bi-encoder)	bazowy	bazowy	szybki, słabszy na niejednoznacznych zapytaniach
BM25 sam	nieco niżej na semantyce	porównywalny na nazwach własnych	mocny na kodach, symbolach, identyfikatorach
Hybryda (dense plus BM25)	plus 5 do 10 pkt proc.	plus 5 do 12 pkt proc.	najlepszy stosunek zysku do kosztu
Hybryda plus reranker	dodatkowe plus 6 do 15 pkt proc. nDCG	bez istotnej zmiany	zysk głównie w porządku top-5

Najważniejsza obserwacja z tabeli: reranking dokłada się do nDCG, prawie nie rusza Recall. Jeżeli problemem jest to, że trafne dokumenty w ogóle nie wpadają do listy, reranker jest nie tym narzędziem. Wtedy pracujesz nad chunkingiem, hybrydą i progiem k pierwszego stopnia.

Koszt: opóźnienie i VRAM

Cross-encoder przelicza parę zapytanie-dokument w pełnym przebiegu modelu. Koszt rośnie liniowo z liczbą kandydatów i z długością tekstu. To jest dokładnie ta zmienna, którą najłatwiej przeoczyć na demie (gdzie k jest małe), a która boli na produkcji (gdzie k bywa duże).

Poniżej rzędy wielkości dla rerankera klasy small lub base, uruchamianego on-prem na jednej karcie. Liczby zależą od długości chunków i precyzji (fp16 vs int8), więc są orientacyjne.

Parametr	Reranker small (ok. 20 do 30 M)	Reranker base (ok. 100 do 300 M)
VRAM w fp16	rzędu setek MB	rzędu 1 do 2 GB
Opóźnienie na 50 par, krótkie chunki	kilkanaście do kilkudziesięciu ms	kilkadziesiąt do ponad 100 ms
Opóźnienie na 50 par, długie chunki	rośnie 2 do 4 razy	rośnie 2 do 4 razy
Czułość na długość chunku	wysoka	wysoka

Dwie rzeczy warto zapamiętać. Po pierwsze, opóźnienie skaluje się z k razy długość, więc kontrola obu tych liczb jest tańsza niż większa karta. Po drugie, reranker zwykle mieści się w VRAM obok modelu embeddingowego, ale na jednym boxie współdzielonym z LLM do generacji łatwo o konkurencję o pamięć. To planuje się z góry, nie odkrywa po wdrożeniu.

Dlaczego naiwna konfiguracja się wykłada

Najczęstsze błędy, które zamieniają reranker z poprawy w obciążenie:

1. Reranking zbyt długiej listy. Puszczanie cross-encodera po 200 kandydatach zamiast po 30 do 50 mnoży opóźnienie bez proporcjonalnego zysku jakości. Górne pozycje i tak rzadko się zmieniają poniżej pewnego k.
2. Reranker nad słabym pierwszym stopniem. Jeżeli Recall@k pierwszego stopnia jest niski, reranker układa ładnie listę, w której brakuje właściwego dokumentu. Wygląda lepiej, odpowiada gorzej.
3. Za długie chunki. Cross-encoder ma limit kontekstu i koszt rośnie z długością. Chunki na granicy limitu są obcinane (tracisz sygnał) albo drogie (płacisz za każdy token w każdej parze).
4. Brak pomiaru przed i po. Wpięcie rerankera „bo tak się robi", bez offline eval na własnym zbiorze pytań, to zgadywanie. Często okazuje się, że hybryda bez rerankera daje 80 procent zysku za 20 procent kosztu.
5. Reranking po stronie zapytania bez cache. Te same lub bardzo podobne zapytania liczone od zera za każdym razem. Prosty cache wyników na poziomie zapytania bywa tańszy niż optymalizacja modelu.

Kiedy reranker się opłaca, a kiedy nie

Reranker zwykle się opłaca, gdy: zapytania są długie i opisowe, baza jest duża i tematycznie gęsta (wiele dokumentów podobnych), a koszt błędnej odpowiedzi jest wysoki (dokumentacja techniczna, procedury, compliance). W tych warunkach poprawa porządku top-5 przekłada się wprost na jakość odpowiedzi LLM, bo do generacji trafia mniej szumu.

Reranker zwykle się nie opłaca, gdy: zapytania są krótkie i jednoznaczne, baza jest mała lub dobrze pocięta, a budżet opóźnienia jest napięty (interaktywny asystent z twardym SLA na czas odpowiedzi). Tu lepszy zwrot daje porządna hybryda dense plus BM25 i praca nad chunkingiem.

Reguła kciuka: najpierw hybryda i dobry chunking, zmierz nDCG i Recall, a reranker włącz jako świadomy trade-off jakość-za-opóźnienie, nie jako domyślny element pipeline'u.

// co tu nie pokrywamCzego tu nie pokrywam

• Konkretne nazwy modeli rerankujących i ich licencje (osobny przegląd vendorów modeli open-weight).
• Fine-tuning rerankera na własnej domenie (osobny temat, inny profil ryzyka i kosztu).
• Late interaction (np. architektury typu multi-vector) jako alternatywa dla klasycznego cross-encodera.
• Ewaluacja end-to-end jakości odpowiedzi LLM (RAG eval), w odróżnieniu od jakości samego retrievalu.
• Sizing GPU pod generację LLM, który omawiamy osobno.

// disclosure i biasesDisclosure i biases

Piszemy z perspektywy wdrożeń on-prem dla regulowanej produkcji, więc naturalnie kładziemy nacisk na kontrolę kosztu, przewidywalność opóźnienia i brak zależności od zewnętrznego API. Liczby w tabelach to rzędy wielkości z naszych testów na bazach dokumentów technicznych PL i EN, nie publikowany benchmark. Twoja domena, język i jakość chunkingu mogą dać inne wyniki. Traktuj to jako ramę decyzyjną, nie jako gotowe wartości do skopiowania do business case.

Powiązane

• RAG on-prem: architektura, chunking, retrieval i co naprawdę wpływa na jakość
• GPU sizing dla Llama 3.1 70B inference: liczby z benchmarków
• AI on-prem w europejskiej produkcji 2026: kompletny przewodnik architektoniczny