Jak głębokość rerankera wpływa na opóźnienie prywatnego wyszukiwania?

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

How Does Reranker Depth Affect Private Search Latency? - Zima Store Online

Głębokość rerankera zwiększa opóźnienie prywatnego wyszukiwania mniej więcej proporcjonalnie do liczby ocenianych kandydatów, choć grupowanie, długość sekwencji, architektura modelu i sprzęt sprawiają, że krzywa nie jest liniowa.

Retriever pierwszego etapu może zwrócić 20, 100 lub 500 fragmentów kandydackich, zanim cross-encoder albo lokalny LLM zmieni ich kolejność. Większa głębokość rerankingu daje trafnemu fragmentowi więcej szans na przetrwanie słabego początkowego uporządkowania, ale każdy kandydat zwiększa nakład pracy związany z tokenizacją i wnioskowaniem. Gdy odtwarzanie trafnych dokumentów osiągnie plateau, dalsze zwiększanie głębokości głównie zużywa zasoby obliczeniowe i może wydłużać najwolniejsze interaktywne zapytania.

Głębokość to liczba kandydatów wchodzących do drugiego etapu

Głębokość rerankera różni się od końcowego top-k. Potok może ocenić sto kandydatów i zwrócić pięciu, więc opóźnienie zależy od stu porównań zapytanie-dokument, mimo że model językowy widzi tylko kilka. Długość tekstu kandydata określa liczbę tokenów przetwarzanych w każdym porównaniu.

Eksperyment firmy Elastic dotyczący głębokości rerankingu mierzy jakość wyszukiwania przy różnych głębokościach rerankingu i przedstawia wskazówki zależne od modelu. Wyniki pokazują, że użyteczna głębokość zależy od retrievera pierwszego etapu i rerankera, a nie od jednej stałej wartości. Efekt ten powinien pozostać mierzalny przy docelowym obciążeniu domowego serwera.

Słaby pierwszy etap może wymagać większej głębokości, aby uwzględnić odpowiedź, podczas gdy silny retriever hybrydowy może wcześniej przedstawić dobre kandydatury. Głębokość rerankera nie może więc zrekompensować braku kandydatów, którzy nigdy nie zostali pobrani. To rozróżnienie ma znaczenie, gdy kilka etapów potoku korzysta z tego samego budżetu pamięci masowej i pamięci operacyjnej.

Koszt wnioskowania rośnie wraz z liczbą kandydatów i ich tokenów

Cross-encodery przetwarzają wspólnie zapytanie i każdego kandydata, więc podwojenie głębokości w przybliżeniu podwaja liczbę ocenianych par, zanim uwzględni się efekty grupowania. Większe grupy mogą poprawić wykorzystanie akceleratora, ale wymagają też więcej pamięci i mogą opóźnić pierwszy ukończony wynik do czasu zakończenia całej grupy.

Badanie dotyczące rerankingu par wykazuje duże redukcje opóźnień dzięki ograniczeniu zbioru rerankowanych elementów, wyborowi mniejszych modeli, obniżeniu precyzji i kontroli nakładu pracy związanego z generowaniem. Pokazuje, że głębokość jest jednym z kilku mnożnikowych wyborów dotyczących obsługi. Tę granicę należy przetestować na reprezentatywnych danych domowych, a nie zakładać jej z góry.

Reranking na CPU może wykazywać niemal liniową krzywą, podczas gdy krzywe dla GPU mogą zawierać wydajne plateau, po których następują gwałtowne pogorszenia związane z pamięcią lub kolejkowaniem. Opóźnienie ogona również rośnie, gdy długości kandydatów są różne, ponieważ długie fragmenty dominują pracę grupy. Efekt ten powinien pozostać mierzalny przy docelowym obciążeniu domowego serwera.

Zyski jakościowe osiągają plateau wcześniej niż koszty

Zwiększanie głębokości pomaga tylko wtedy, gdy trafne dowody znajdują się poniżej bieżącego limitu, a reranker potrafi je rozpoznać. Gdy odtwarzanie trafnych elementów przez pierwszy etap osiągnie nasycenie, dodatkowi kandydaci zwiększają liczbę rozpraszaczy i koszty, a czasami zmniejszają stabilność rankingu w przypadku niejednoznacznych zapytań.

Kontrolowana ocena kompleksowa porównuje konfiguracje retrievera i rerankera pod względem skuteczności, jakości generowania, kosztu i opóźnienia. Uzasadnia to wybór głębokości na podstawie kompleksowego kompromisu, zamiast optymalizowania samych wyników rankingu. To rozróżnienie ma znaczenie, gdy kilka etapów potoku korzysta z tego samego budżetu pamięci masowej i pamięci operacyjnej.

Granica błędu pojawia się, gdy głębokość wybiera się na podstawie średniego opóźnienia dla rozgrzanych, jednorodnych zapytań. Zimne modele, długie fragmenty, równoczesni użytkownicy i odczyty z NAS mogą podnieść p95 lub p99 znacznie powyżej mediany, nawet gdy średnia trafność poprawia się nieznacznie.

-15% OFF

ZimaBoard 2 – Mini serwer domowy dla Twojego wielkiego pomysłu

Single board computer zimaboard2

FAQ dotyczące głębokości kandydatów rerankera

Czy reranking 100 kandydatów jest dwa razy wolniejszy niż 50?

Praca związana z ocenianiem może zbliżyć się do dwukrotności, ale czas całkowity może być krótszy lub dłuższy, zależnie od wykorzystania grupowania, długości tokenów, limitów pamięci i kolejkowania. Zmierz wdrożony model, zamiast zakładać idealnie liniowy stosunek.

Czy większe końcowe top-k wymaga większej głębokości rerankera?

Zwykle pula kandydatów powinna być większa niż liczba końcowych wyników, ale wymagany mnożnik zależy od odtwarzania trafnych elementów przez pierwszy etap i różnorodności wyników. Zwracanie większej liczby fragmentów nie uzasadnia automatycznie oceniania setek słabych kandydatów. Tę granicę należy przetestować na reprezentatywnych danych domowych, a nie zakładać jej z góry.

Czy buforowanie wyników rerankera może zmniejszyć opóźnienie?

Buforowanie pomaga w przypadku powtarzających się par zapytanie-kandydat lub stabilnych, znormalizowanych zapytań, ale prywatne wyszukiwanie często obejmuje unikalne sformułowania i zmieniające się dokumenty. Unieważnianie pamięci podręcznej musi uwzględniać wersje dokumentów i zmiany modelu, aby uniknąć nieaktualnego uporządkowania. Efekt ten powinien pozostać mierzalny przy docelowym obciążeniu domowego serwera.

Znajdź najmniejszą głębokość na plateau jakościowym

Utwórz oznaczony zbiór zapytań obejmujący dokładne terminy, parafrazy, niejednoznaczne nazwy i trudne negatywne przykłady. Przetestuj głębokości rerankera, takie jak 10, 25, 50, 100 i 200, mierząc odtwarzanie trafnych elementów przez pierwszy etap, końcowe nDCG lub MRR, pokrycie cytowaniami, czas pracy CPU lub GPU, pamięć oraz opóźnienia p50, p95 i p99.

Porównaj krzywą z czynnikami decyzyjnymi opisanymi w artykule czynniki decydujące o wyborze rerankera. Utrzymuj stałe generowanie kandydatów przez pierwszy etap, długość fragmentów, model rerankera, końcowe top-k, współbieżność i stan pamięci podręcznej, aby głębokość była jedyną zmienną. To rozróżnienie ma znaczenie, gdy kilka etapów potoku korzysta z tego samego budżetu pamięci masowej i pamięci operacyjnej.

Wybierz najmniejszą głębokość, przy której jakość jest statystycznie nieodróżnialna od plateau, a opóźnienie ogona spełnia cel interaktywny. Przekieruj badania wykonywane w tle do głębszego profilu tylko wtedy, gdy dodatkowe odtwarzanie trafnych elementów ma zmierzoną wartość. Tę granicę należy przetestować na reprezentatywnych danych domowych, a nie zakładać jej z góry.