Reranking: jak podnieść jakość wyszukiwania w RAG

Większość zespołów zatrzymuje się na wektorowym top-k i pyta, czemu asystent myli się co piąty raz. Odpowiedź jest prawie zawsze ta sama: wyszukiwanie zwróciło fragmenty podobne do zapytania, ale nie te, które odpowiadają na pytanie. Reranking rozwiązuje właśnie ten problem, i to bez przebudowy całego pipeline'u.

Embedding zamieniając tekst w wektor, zgniata informację do jednej liczby na wymiar. Model embeddingów nigdy nie widzi pytania i fragmentu razem — osadza je osobno, a podobieństwo mierzy się potem geometrycznie. To jest szybkie i skalowalne, ale ma cenę.

Przykład, który regularnie widać w produkcji: baza wiedzy firmy zawiera dwa dokumenty. Jeden opisuje „procedurę reklamacji dla klientów indywidualnych", drugi „procedurę reklamacji dla klientów biznesowych". Oba mają bardzo zbliżone embeddingi, bo większość słów jest wspólna. Pytanie „jak złożyć reklamację jako firma" wektorem też jest blisko obu. Wyszukiwanie ANN zwraca obydwa z podobnym score'em. Model generatywny dostaje oba fragmenty i ma szansę pomylić ścieżki.

Cross-encoder reranker widzi całość inaczej: dostaje jednocześnie pytanie i każdy z kandydatów jako parę, wylicza relevance score z uwzględnieniem wzajemnego kontekstu. Fragment o klientach biznesowych dostaje wyższy score. Trafność rośnie bez zmiany indeksu wektorowego.

To też powód, dla którego hybrid search i reranking są naturalnie parą: hybryda zwiększa pokrycie kandydatów (BM25 + ANN), reranker podnosi precyzję z tej puli.

Cross-encoder to model transformerowy (zazwyczaj wariant BERT lub podobny) trenowany na parach (pytanie, fragment) z etykietą trafności. Podczas inferencji:

1. Pytanie i fragment są konkatenowane jako jeden ciąg wejściowy ze specjalnym tokenem separatora.
2. Model przetwarza tę parę przez wszystkie warstwy uwagi jednocześnie, przez co każdy token pytania może „patrzeć" na każdy token fragmentu.
3. Wyjście to jeden skalar: relevance score tej konkretnej pary.
4. Pipeline oblicza score dla każdego kandydata z top-k, sortuje malejąco i oddaje top-n do modelu generatywnego.

Koszt: inferencja cross-encodera dla każdego kandydata z osobna. Przy top-20 kandydatach to 20 forward passów modelu reranking zamiast jednego. Dlatego reranker przetwarza tylko kandydatów z wyszukiwania, nie cały indeks.

Bi-encoder skaluje się na miliony dokumentów. Cross-encoder nie skaluje się na miliony, bo musiałby porównywać każde pytanie z każdym fragmentem. Dlatego wzorzec produkcyjny to zawsze: szybkie wyszukiwanie kandydatów, potem drogi reranker na małym zbiorze.

Nie każdy pipeline potrzebuje reranking od pierwszego dnia. Warto go dodać, gdy:

Baza wiedzy ma dokumenty o podobnym brzmieniu i różnej treści. Procedury dla różnych grup klientów, regulaminy w kilku wersjach, instrukcje na różne modele urządzeń. Embedding traktuje je prawie tak samo, reranker odróżnia.

Pytania są wieloaspektowe lub niejednoznaczne. „Jak anulować subskrypcję jeśli byłem na urlopie i nie zdążyłem w terminie" ma wiele składowych. Bi-encoder upraszcza do jednego wektora. Cross-encoder czyta całość.

Pipeline odpowiada po angielsku na polskie pytania lub odwrotnie. Modele wielojęzyczne mają gorsze embeddingi dla mieszanych języków. Cross-encoder, trenowany na parach wielojęzycznych, radzi sobie lepiej z trafnością kontekstową.

Masz długie fragmenty (powyżej 512 tokenów). Bi-encoder zgniata długi fragment do jednego wektora, tracąc szczegóły. Cross-encoder przetwarza cały kontekst pary.

Jeśli twoja baza jest mała (do kilkuset dokumentów), pytania są krótkie i precyzyjne, a odpowiedzi są zadowalające, reranking może nie dać mierzalnej poprawy. Zawsze sprawdzaj wyniki na zestawie testowym przed wdrożeniem.

Wybór modelu reranking wpływa na jakość, latencję i to, czy dane opuszczają infrastrukturę. Podstawowa zasada: jeśli baza wiedzy zawiera dane wrażliwe lub osobowe, reranker musi działać lokalnie. Fragment dokumentu przesyłany do zewnętrznego API reranking = dane opuszczają sieć firmową.

Korzystamy z modeli reranking uruchamianych lokalnie. Praktyczne opcje w 2026:

Przy polskiej bazie wiedzy bge-reranker-v2-m3 jest pierwszym wyborem: wielojęzyczny, mieści się na standardowym serwerze CPU, latencja na poziomie kilkudziesięciu milisekund na parę. Przy 20 kandydatach to niecałe 700 ms dodatkowego czasu, co w większości scenariuszy asystenta firmowego jest akceptowalne.

Self-hosting modelu reranking ma jeszcze jeden wymiar zgodności z RODO: fragment dokumentu nigdy nie opuszcza infrastruktury, nawet tymczasowo podczas oceny trafności. To istotne przy bazach wiedzy zawierających procedury, umowy lub dane klientów.

Kompletny pipeline wygląda następująco. Każdy krok ma jedno zadanie i produkuje jasno zdefiniowane wyjście.

Krok 1: Indeksowanie. Każdy dokument jest dzielony na fragmenty (zwykle 256-512 tokenów z nakładką 64 tokenów). Każdy fragment jest osadzany modelem BGE-M3 i zapisywany w bazie wektorowej (Qdrant) z metadanymi: kategoria, data, dział, typ dokumentu.

Krok 2: Wyszukiwanie hybrydowe. Na zapytanie użytkownika uruchamiane są równolegle BM25 (Postgres FTS lub Elasticsearch) i ANN (Qdrant). Wyniki są scalane przez Reciprocal Rank Fusion (RRF) do puli 20-50 kandydatów. Ten krok trwa zwykle poniżej 100 ms.

Krok 3: Reranking. Każdy kandydat jest oceniany cross-encoderem jako para (zapytanie, fragment). Wyniki są sortowane malejąco. Do modelu generatywnego trafia top-3 do top-5 fragmentów.

Krok 4: Generowanie z kontekstem. Model generatywny dostaje pytanie i wybrane fragmenty przez router LLM. Guardrails sprawdzają wyjście przed oddaniem użytkownikowi. Jeśli żaden fragment nie przekroczył progu trafności, system odpowiada „nie wiem" i kieruje do człowieka (patrz: human-handoff).

Krytyczny szczegół: próg trafności reranking. Jeśli najwyższy score w puli wynosi poniżej 0.3 (skala 0-1), fragment jest niewystarczająco powiązany z pytaniem. Lepiej wtedy nie generować odpowiedzi niż generować z nisko trafnym kontekstem. Ta logika wprost ogranicza halucynacje.

Reranking dodaje czas. Pytanie, czy ten czas jest akceptowalny, zależy od kontekstu.

W asystencie firmowym z odpowiedzią poniżej 3 sekund reranking na 20 kandydatach i CPU zajmuje 600-800 ms. To 20-30% całkowitego czasu odpowiedzi. W większości scenariuszy obsługi klienta i wsparcia wewnętrznego jest to do przyjęcia.

Jeśli pipeline musi być szybszy, kilka optymalizacji:

• Zmniejsz pulę kandydatów. Top-10 zamiast top-20 to dwukrotnie szybszy reranker przy nieznacznej stracie pokrycia.
• Buforuj wyniki rerankingu dla powtarzających się pytań (z TTL 24h). Pytania FAQ powtarzają się w 30-50% w systemach obsługi klienta.
• Użyj mniejszego modelu reranking. MiniLM jest 5x szybszy od bge-reranker-large przy akceptowalnej stracie trafności dla prostszych baz wiedzy.
• Filtruj metadanymi przed rerankingiem. Jeśli kategoria dokumentu jest znana z kontekstu (np. użytkownik jest w sekcji „produkty"), ogranicz pulę do tej kategorii już na etapie ANN.

Throughput i latencja to wymiary, które mierzyliśmy przy każdym wdrożeniu. Szczegóły o monitorowaniu pipeline'u opisuje artykuł monitoring jakości agenta AI.

Nie dodawaj rerankingu bez zestawu testowego. Bez pomiaru nie ma pewności, że coś poprawiłeś.

Minimalny zestaw ewaluacyjny to 50-100 par (pytanie, oczekiwany fragment). Możesz zbudować go z logów produkcyjnych (pytania użytkowników + feedback od konsultantów) lub ręcznie dla najważniejszych obszarów bazy wiedzy.

Metryki, na które warto patrzeć:

• MRR (Mean Reciprocal Rank) — jak wysoko trafny fragment pojawia się na liście. MRR@10 mierzy to na pierwszych 10 wynikach.
• NDCG (Normalized Discounted Cumulative Gain) — ważona miara, gdzie wyżej = bardziej trafne.
• Precision@k — ile z top-k fragmentów jest rzeczywiście trafnych.
• Czas odpowiedzi p50/p95 — przed i po rerankingu.

Benchmark AB przed/po rerankingu na tym samym zestawie testowym daje konkretną odpowiedź. W typowych projektach z różnorodną bazą wiedzy reranking podnosi MRR@5 o 15-30% względem samego ANN. To przekłada się na mniej eskalacji do ludzi i wyższy containment rate.

Poniższy sandbox uruchamia pipeline z rerankingiem na Twoim tekście. Wklej fragment dokumentu, zadaj pytanie. System wyszuka, oceni kandydatów cross-encoderem i wygeneruje odpowiedź. PII maskowane przed modelem, zero retencji.

Wyszukiwanie wektorowe oblicza podobieństwo embeddingów pytania i fragmentów osobno, bez ich wzajemnego porównania. Reranking przetwarza każdą parę (pytanie, fragment) razem przez model cross-encoder, który rozumie kontekst wzajemny. Wynik: wyszukiwanie wektorowe jest szybkie i dobrze skaluje się na milionach dokumentów, reranker jest wolniejszy, ale znacznie trafniej ocenia, który z kandydatów faktycznie odpowiada na pytanie.

Nie. Przy małej, spójnej bazie wiedzy (do kilkuset dobrze ustrukturyzowanych dokumentów) i precyzyjnych pytaniach samo wyszukiwanie semantyczne często wystarcza. Reranking jest opłacalny, gdy baza jest duża lub niejednorodna, pytania są wieloaspektowe albo masz dokumenty o podobnym brzmieniu i różnej treści. Zanim dodasz reranking, zmierz MRR i Precision@k na zestawie testowym bez niego, a potem porównaj wyniki po dodaniu. Dane decydują, nie intuicja.

Tylko jeśli używasz API reranking (np. Cohere Rerank). Przy lokalnym modelu (bge-reranker-v2-m3 przez Ollama) wszystkie fragmenty i pytania są przetwarzane na własnym serwerze. Dla baz wiedzy zawierających dane wrażliwe lub objęte RODO zawsze wybieramy lokalne modele. Obowiązki firmy przy przetwarzaniu danych osobowych w AI opisuje artykuł AI Act i RODO 2026.

Jeśli pipeline RAG już działa, dodanie rerankingu to zazwyczaj dni, nie tygodnie. Krok wyszukiwania rozszerza się o model cross-encoder (pobranie i uruchomienie lokalnie), logikę sortowania po nowym score i opcjonalnie próg minimalnej trafności. Większy nakład pracy to zestaw ewaluacyjny i benchmark, które potwierdzają, że zmiana poprawiła jakość. Bez nich nie wiesz, co naprawdę zyskałeś.

Tu reranking pomaga, ale efektywniejszy jest hybrid search jako krok poprzedzający. BM25 precyzyjnie wyłapuje numery umów, SKU czy unikalne nazwy produktów, których embeddingi nie obsługują dobrze. Reranker ocenia potem, który z kandydatów (i BM25, i ANN) faktycznie odpowiada na pytanie. Łączenie obu mechanizmów daje najlepsze wyniki na zróżnicowanych bazach wiedzy, co opisujemy szerzej w artykule wyszukiwanie semantyczne i embeddingi w firmie.