Reranking pobranych fragmentów: krok, który większość zespołów pomija

Większość pipeline'ów retrieval augmented generation kończy się na wyszukiwaniu wektorowym i liczy na to, że pięć najwyżej ocenionych chunków to te właściwe. Zwykle nie są. Reranking stoi między pobraniem a generowaniem, przestawia kolejność tego, co wróciło, i po cichu naprawia całą klasę błędnych odpowiedzi, których żadne krążenie wokół promptu nie ruszy. Tani w dołożeniu. Łatwy do pominięcia.

Dlaczego samo wyszukiwanie wektorowe zostawia część odpowiedzi na stole

Wyszukiwanie po embeddingach ściska cały fragment do jednego wektora, więc dopasowuje temat, nie intencję. Pytasz o terminy wypowiedzenia i dostajesz każdy akapit, w którym pada słowo wypowiedzenie. W porządku. Tyle że retriever był strojony pod recall na milionach chunków, a nie pod decyzję, które pięć fragmentów odpowiada na to pytanie. Schemat, na który wciąż trafiam, wygląda tak: właściwy dokument siedzi na dwunastej pozycji, model nigdy go nie widzi, a odpowiedź wychodzi pewna siebie i niepełna. I nie, większe okna kontekstu cię nie uratują. Wepchnij tam dwadzieścia fragmentów, a rozmyjesz sygnał i zatrzesz przypisanie źródła.

Co reranker robi naprawdę inaczej

Cross-encoder przepuszcza zapytanie i fragment przez model razem, więc może zważyć, jak konkretne sformułowanie pytania ma się do konkretnego sformułowania tekstu. Bi-encodery robią odwrotnie: kodują każdą stronę osobno i pozwalają im spotkać się dopiero na podobieństwie kosinusowym. Ta wspólna interakcja jest kosztowna i właśnie dlatego reranking nie zastąpi wyszukiwania. On ocenia kandydatów. Nie przeszukuje korpusu. Dwa etapy: retriever zarzuca szeroką sieć, reranker układa to, co się w niej znalazło.

Gdzie reranking siedzi w pipelinie RAG

Etapy idą po kolei: chunking i indeksowanie, obsługa zapytania, pobranie pierwszego stopnia, reranking, złożenie kontekstu, generowanie, przypisanie źródła. Reranking ląduje po pobraniu, a przed złożeniem promptu, i to właśnie czyni go dokładką - dopinasz go, nie przeindeksowując niczego. Wyostrza też cytowane źródło, bo fragment, na którym oparł się model, ma większą szansę być naprawdę na temat. Hybrydowe pobieranie poszerza pulę kandydatów, reranking ją sprząta. Dobrze się składają.

Wybór rerankera: hostowane API, otwarty model albo nic

• Hostowane API do rerankingu - najszybsze do sprawdzenia, ale fragmenty wychodzą poza twoją infrastrukturę.
• Otwarty cross-encoder uruchamiany lokalnie - pełna kontrola nad danymi, potrzebuje GPU albo godzisz się na opóźnienie na CPU.
• Prompt z LLM w roli rerankera - najbardziej elastyczny, najdroższy w przeliczeniu na zapytanie.

We wdrożeniach żyjących na własnej infrastrukturze klienta otwarty cross-encoder zwykle jako jedyny przechodzi wymogi rezydencji danych, więc rozmiar modelu dobierasz do sprzętu, jaki dostałeś. Korpusy wielojęzyczne potrzebują wielojęzycznego rerankera. Ten uczony na angielskim degraduje się po cichu, zamiast zawieść głośno, a to gorzej.

Wskazówka: najpierw zrób reranking promptem do LLM na garstce testowych zapytań, potwierdź, że w ogóle pomaga na twoim korpusie, a dopiero potem podmień to na dedykowany model pod produkcyjne opóźnienia.

Budżet na opóźnienie i koszt, którego nikt nie planuje

Koszt rerankingu rośnie liniowo z liczbą kandydatów: ocenienie stu to mniej więcej dziesięć razy więcej pracy niż ocenienie dziesięciu, i wszystko to ląduje na ścieżce krytycznej, zanim popłynie pierwszy token. Dźwignie, po które sięgam, w tej kolejności:

1. Zmniejsz pulę kandydatów.
2. Ogranicz długość fragmentu podawanego do cross-encodera.
3. Oceniaj wsadowo na GPU.
4. Cache'uj przerankowane wyniki dla powtarzalnych zapytań.

Odczuwane opóźnienie liczy się bardziej niż całkowite. Generowanie idzie strumieniem, więc ludzie widzą, że coś się dzieje. Reranking tak nie potrafi, więc siedzą i patrzą w ciszę.

Wskazówka: ustaw limit kandydatów per wdrożenie, nie globalnie. Podręcznik na 200 dokumentów i archiwum na 400 000 potrzebują różnych pul.

Jak sprawdzamy, czy to pomogło

Zbuduj mały, oznaczony zbiór ewaluacyjny z prawdziwych pytań użytkowników, z zaznaczonym poprawnym fragmentem źródłowym. Pięćdziesiąt uczciwych przykładów za każdym razem bije syntetyczny tysiąc. Śledź recall przy odcięciu, które faktycznie podajesz do modelu, plus mean reciprocal rank albo NDCG, żeby wyłapać poprawę kolejności, którą recall zasłania. Mierz pobieranie osobno od generowania, bo inaczej zmiana promptu i zmiana rerankera przypiszą sobie nawzajem zasługi. I wypatruj awarii, którą średnie gubią: rerankera, który podnosi ogólne wyniki, a jednocześnie systematycznie spycha w dół typ dokumentu, na którym opierają się twoi użytkownicy.

Kiedy pominięcie rerankingu jest słuszną decyzją

Mały, czysty korpus z jednej dziedziny, w którym retriever i tak zwraca właściwy fragment na pierwszym miejscu? Nie zyskujesz nic poza opóźnieniem i jednym ruchomym elementem więcej. Twarde limity opóźnień, zwłaszcza w interfejsach głosowych, sprawiają, że dodatkowa runda kosztuje więcej, niż zwraca w trafności. Najpierw napraw problemy wcześniej w łańcuchu - złe granice chunków, brakujące filtry po metadanych, nieprzetworzone tabele. Żaden reranker tego nie naprawi, bo właściwy tekst w ogóle nie trafił do puli kandydatów. Twój zbiór ewaluacyjny to uczciwy test. Jeśli liczby nie drgną, odpuść i wróć do tematu, gdy korpus urośnie.

Najczęściej zadawane pytania

Czy większe okno kontekstu sprawia, że reranking jest zbędny?

Nie. Przepuszczanie wszystkiego rozmywa istotny sygnał wśród bliskich trafień, podnosi koszt zapytania i osłabia przypisanie źródła, bo nie da się już powiedzieć, na którym fragmencie odpowiedź faktycznie się oparła.

Czy mogę robić reranking tym samym modelem, który generuje odpowiedź?

Przy małym wolumenie owszem, a utrzymywanie o jeden komponent mniej to realna korzyść. Przy skali koszt tokenów i dodane opóźnienie zwykle uzasadniają dedykowany cross-encoder.

Ilu kandydatów retriever powinien podać rerankerowi?

Zacznij od kilkudziesięciu i dostrój na własnym zbiorze ewaluacyjnym. Nie ma uniwersalnej liczby, jest tylko liniowa zależność między liczbą kandydatów a kosztem.

Podsumowanie: tani etap z niezasłużoną reputacją

Reranking to jedno z niewielu usprawnień RAG, które nie wymaga przeindeksowania ani zmiany w tym, jak dokumenty są dzielone i przechowywane. Rób to po kolei: zbuduj zbiór ewaluacyjny, zmierz obecne pobieranie, dołóż reranking za flagą, porównaj, potem dostrój pulę pod opóźnienie. Wyostrza przypisanie źródła w takim samym stopniu co jakość odpowiedzi, a to zaczyna się liczyć w chwili, gdy użytkownicy zaczynają sprawdzać, skąd wzięła się dana teza. Zespoły to pomijają, bo w demo tego nie widać, a wychodzi dopiero w pytaniach, na które po cichu padają błędne odpowiedzi.