Spraw, by ponowna klasyfikacja znalazła swoje miejsce w twoim pipeline RAG.
Przegrupowanie wyników powinno znaleźć miejsce w procesie RAG: należy dodać informacje, których brakowało pierwszemu systemowi rankowania, zachować oryginalne dowody oraz przewyższyć bazowy model oparty wyłącznie na wyszukiwaniu w analizowanych danych.
Dodanie narzędzia do ponownego rankowania wydaje się prostym ulepszeniem: pobiera się szeroki zbiór fragmentów, przeprowadza dokładniejszą weryfikację istotności i wysyła najlepsze wyniki do modelu.
Taka architektura może być przydatna. Może jednak również powodować opóźnienia i pogarszać jakość dostępnych dowodów. Kluczowe pytanie brzmi, jakie informacje dostarcza druga faza.
W jednym opublikowanym studium przypadku krok ponownego rankowania wykorzystywał metodę embeddingów z fazy pobierania danych, jednocześnie skracając teksty kandydatów. Dlatego druga analiza oceniała gorszą wersję materiału. Wniosek jest jasny: komponent zwany narzędziem do ponownego rankowania nie zapewnia automatycznie lepszego sygnału istotności.
Zrozum ograniczenia zbioru kandydatów
Narzędzie do ponownego rankowania porządkuje otrzymane dokumenty. Nie przeszukuje reszty kolekcji w poszukiwaniu brakujących dowodów.
Jeśli odpowiedni fragment nie znajduje się na liście krótkiej, sprawdź mechanizmy wyszukiwania, filtry lub graniczne punkty fragmentów. Zwiększenie złożoności algorytmu oceny nie sprawi, że pojawi się niezauważony fragment.
Dlatego też hybrydowe wyszukiwanie kandydatów oraz ponowna klasyfikacja powinny być oceniane oddzielnie. Pierwszy etap ma na celu uwzględnienie przydatnych dowodów, natomiast drugi – wybór i uporządkowanie tych dowodów w ramach bardziej ograniczonego budżetu.
Zapytaj, co widzi drugi algorytm oceny
Kodownik wielofunkcyjny przetwarza zapytanie i kandydatów razem, co umożliwia ocenę trafności inną niż ta uzyskiwana poprzez porównywanie niezależnie obliczonych reprezentacji. Ta dodatkowa interakcja jest jednym z powodów, dla których warto rozważyć jego użycie przy tworzeniu listy krótkiej.
Jednakże skorer nadal ma ograniczenie ilości danych wejściowych. Jeśli przetwarzanie wstępne usunie zdanie, które odpowiada na pytanie, model nie będzie mógł go odzyskać. Zapisuj rzeczywisty tekst przekazany do skorera, a nie tylko oryginalny fragment przechowywany wcześniej.
W przypadku długich tekstów sprawdź, gdzie znajdują się istotne szczegóły. Stałe prefiksy mogą zachować język wprowadzający, pomijając jednocześnie kluczową zasadę, przykład kodu lub wyjątek. Rozważ krótsze, spójne opcje lub okna istotne dla zapytania i przetestuj wynikowe zachowanie, zamiast zakładać, że polityka skracania jest bezpieczna.
Porównaj stan przed i po na identycznych kandydatach
Zapisz bazową ranking dla każdego pytania oceniającego. Uruchom narzędzie do ponownego rankowania na tym samym zestawie kandydatów, a następnie porównaj kolejność i ostateczny wybór.
Niech system śledzi, czy wymagane dowody pozostają w końcowym kontekście, czy ich pozycja się poprawia, oraz które pytania ulegają pogorszeniu. Jeden łączny wynik może ukryć utratę kluczowego fragmentu tekstu dla danej kategorii zapytań.
Należy również mierzyć opóźnienie i koszt od początku do końca procesu. Poprawa rankingu może być korzystna w przypadku szczegółowego procesu badawczego, ale zbyt droga przy interaktywnych sugestiach wyszukiwania. Akceptowalny kompromis zależy od rodzaju aplikacji, którą tworzysz.
Przewodnik oceny wyjaśnia, jak trzymać te sprawdzenia rankingu oddzielnie od jakości generowanej odpowiedzi.
Celowo zdefiniuj plan awaryjny
Dla aplikacji interaktywnej ustal termin dla etapu ponownego rankowania. Jeśli upłynie on bez rezultatu, wyraźnie zdecyduj, czy zwrócić podstawowe wyniki, pokazać błąd, czy kontynuować pracę asynchronicznie.
Zwracanie wyników bazowych może być rozsądne, gdy już spełniają one twoje wymagania jakościowe. Zapisz fakt wystąpienia rozwiązania awaryjnego, aby poprawa opóźnienia przypadkowo nie wyglądała jak udany eksperyment z ponownym rankowaniem.
Podobnie, upewnij się, że mechanizm ponownego rankowania można łatwo wyłączyć. Komponent nie powinien stać się obowiązkowy tylko dlatego, że kod poniżej zakłada jego istnienie.
Zachowaj prostszy system, gdy przewyższa on inne
Zrób te same testy z włączonym i wyłączonym ponownym rankowaniem. Przeanalizuj zarówno poprawy, jak i niepowodzenia, włączając przykłady z bliskimi granicami długości danych wejściowych.
Jeśli druga faza nie potrafi pokazać przydatnej korzyści w ramach twoich ograniczeń, jej usunięcie jest słusznym rozwiązaniem inżynieryjnym. Celem jest odpowiedź poparta odpowiednimi dowodami przy akceptowalnej cenie. Bardziej złożony diagram jest przydatny tylko wtedy, gdy pomaga to osiągnąć ten cel.
Literatura pokrewna
- Rola mostu TypeScript 6 w drodze do natywnego kompilatora TS 7 — Dowiedz się, w jaki sposób TypeScript 6 aktualizuje domyślne konfiguracje, rozwiązywanie modułów oraz składnię importu, aby przygotować bazy kodowe na szybszy kompilator TypeScript 7 oparty na języku Go.