Wyszukiwanie hybrydowe: dwie dobre listy nie dają automatycznie dobrej odpowiedzi

Dokument A jest pierwszy na jednej liście i trzeci na drugiej. Dokument B zajmuje miejsca drugie i pierwsze. Po połączeniu list B wygrywa. Jeśli pytanie wymagało właśnie dokumentu A, dodatkowa metoda wyszukiwania nie poprawiła pierwszej pozycji. To mały, syntetyczny przykład, którego wynik można przeliczyć bez kupowania platformy i bez pytania modelu, czy bardzo się starał.

Wyszukiwanie hybrydowe łączy różne sposoby odnajdywania materiału, często dopasowanie słów i podobieństwo znaczenia. Odbiór powinien objąć obie listy oraz wynik ich połączenia. Dopiero później oceniamy odpowiedź przygotowaną przez AI na znalezionych źródłach. Inaczej płynny akapit może zasłonić fakt, że właściwa instrukcja wypadła z zestawu jeszcze przed pracą modelu.

Nie ma tu jednej sprzeczności do rozstrzygnięcia hasłem „słowa kontra wektory”. Różne pytania wymagają różnych informacji. W katalogu części kod może wskazywać jeden wariant, a opis problemu prowadzić do kilku materiałów pomocniczych. Zadaniem oceny jest ustalenie, kiedy połączenie pomaga, kiedy przeszkadza i z czego wynika ta różnica.

Cztery dokumenty wystarczą, żeby zobaczyć mechanizm

W naszym własnym przykładzie katalog zawiera cztery fikcyjne dokumenty. A opisuje dokładny kod części podany w pytaniu. B jest instrukcją całej rodziny produktów. C dotyczy starszego wariantu o podobnym oznaczeniu, a D opisuje zastosowanie innymi słowami. Dla tego jednego pytania przyjmujemy z góry, że właściwym wynikiem jest A.

Listy także są umowne, przygotowane do wyjaśnienia: wyszukiwanie po słowach daje kolejno A, B, C; wyszukiwanie według podobieństwa daje B, D, A. Nie są to wyniki uruchomienia rzeczywistego modelu embeddingowego ani indeksu dostawcy. Rzeczywiście wykonano tylko obliczenie ich połączenia według wskazanego wzoru. Ta granica ma znaczenie: ilustracja mechanizmu nie jest pomiarem jakości konkretnego produktu.

Jedną z metod połączenia jest RRF, czyli Reciprocal Rank Fusion. Korzysta z pozycji dokumentów na listach. Zamiast porównywać surowe punkty dwóch różnych wyszukiwarek, nadaje wkład zależny od miejsca, a potem łączy wkłady tego samego dokumentu. Nie musimy zakładać, że liczba 12 w jednej metodzie oznacza tyle samo co 0,8 w drugiej.

Microsoft opisuje w Azure AI Search sumowanie wkładów RRF obliczanych jako 1 podzielone przez sumę pozycji i stałej. Rozróżnia tę stałą od parametru określającego liczbę sąsiadów wyszukiwania wektorowego. To dwa różne ustawienia mimo podobnej nazwy.

Przyjmijmy do ilustracji stałą 60 i równe znaczenie obu list. Dla A sumujemy wkład pozycji pierwszej i trzeciej; otrzymujemy około 0,032266. Dla B sumujemy pozycję drugą i pierwszą; wynik to około 0,032522. B trafia przed A. D oraz C mają po jednym wkładzie i zajmują dalsze miejsca. Liczby wynikają z własnego przeliczenia przyjętych list.

Stała 60 nie jest tu zaleceniem optymalnej konfiguracji twojego katalogu. Przykład pokazuje konkretną własność: dokument dobrze umieszczony w obu metodach może wyprzedzić dokument najlepszy w jednej. Czasami właśnie tego chcemy. W pytaniu o dokładny kod może to jednak wymagać dodatkowej reguły. Algorytm poprawnie połączył listy, ale sam nie ustalił, która cecha pytania ma być obowiązkowa.

Oryginalna praca Cormacka, Clarke’a i Büttchera z 2009 roku przedstawia RRF oraz ocenę na określonych zbiorach TREC i LETOR. Wyniki tych eksperymentów nie są dowodem przewagi w dowolnym firmowym katalogu. Własna ocena nadal potrzebuje właściwych pytań i źródeł.

Przy kodach i embeddingach ustalamy, co wymaga dokładnej zgodności. Przy fuzji sprawdzamy dodatkowo, czy ten warunek przetrwał łączenie list. Można potrzebować osobnej ścieżki dla rozpoznanego kodu albo weryfikacji wariantu po wyszukaniu kandydatów. Wybór powinien wynikać z zadania, nie z ogólnej ambicji używania zawsze dwóch metod.

Właściwy dokument mógł zniknąć, zanim zaczęło się łączenie

Zachowaj listy wejściowe dla tego samego pytania. Jeśli A nie występuje w żadnej, problem jest wcześniejszy niż fuzja. Może nie znajdować się w indeksie, mieć niewłaściwie przygotowany tekst albo zostać wykluczony przez filtr. Zmienianie proporcji połączenia nie odzyska materiału, który nie dotarł do tego etapu.

Ważny jest również zakres listy. System może odnaleźć A dopiero na dalszej pozycji, podczas gdy do fuzji trafia jedynie krótki początek wyników. Wtedy wydłużenie końcowego widoku nie musi niczego zmienić. Zapisz, ilu kandydatów dostarczyła każda metoda, a ilu użytkownik zobaczył po ich połączeniu.

Dokumentacja Elastic rozdziela rozmiar okna kandydatów i wielkość końcowego wyniku RRF. Opisuje też przycinanie wyników wyszukiwania wektorowego do okna. Zmiana liczby końcowych pozycji nie jest tym samym co zwiększenie materiału wejściowego.

Odbiór kompletności pobranej listy pomaga tu uniknąć mylenia domyślnego ograniczenia z całą odpowiedzią narzędzia. Nie oznacza to, że wyszukiwarka musi zwracać wszystko. Powinna dostarczać uzgodniony zakres, a raport ma pokazać, który limit rzeczywiście działał w próbie.

W powtórzeniu zachowaj również to samo pytanie oraz te same ograniczenia zbioru. Jeśli lista tekstowa obejmuje tylko aktualne części, a lista podobieństwa również wycofane, porównujesz jednocześnie metodę i inne zasady dopuszczenia materiału. Przy każdej liście zapisz warunki wejściowe. Dopiero potem sprawdzaj, czy w obu mechanizmach obowiązywały te same warunki dopuszczenia dokumentu. Nie trzeba do tego zrzutu wszystkich ustawień platformy: raport ma ujawnić warunki, które mogły zmienić tę konkretną odpowiedź.

Porównuj także tę samą wersję zbioru. Jeśli podczas oceny jednej metody zaktualizowano instrukcję, a druga nadal korzysta ze starszej reprezentacji, wyniki nie opisują wyłącznie różnicy sposobów szukania. Zachowaj identyfikatory dokumentów i wersji. Dwa podobne tytuły nie potwierdzają, że oba mechanizmy otrzymały ten sam materiał.

Przed porównaniem ustal, czym jest jedna pozycja. Może nią być cały dokument, jego fragment albo karta produktu. Jeżeli jedna ścieżka zwraca dokument, a druga kilka fragmentów tego samego pliku, nie zakładaj automatycznie wspólnej tożsamości. Sprawdź, co dokładnie jest łączone i jak wynik prowadzi do źródła. Trzy wycinki jednej instrukcji nie muszą odpowiadać trzem niezależnym podstawom odpowiedzi.

Podobnie nazwa „hybrydowe” nie mówi jeszcze, ile list połączono i jakie miały znaczenie. Dwa pola wektorowe oraz wyszukiwanie tekstu mogą tworzyć inny układ niż jedna lista tekstowa i jedna wektorowa. Raport powinien odtworzyć rzeczywistą konfigurację. Nie wystarczy narysować dwóch strzałek prowadzących do jednego prostokąta.

W przeglądzie wyszukiwania w Aeneia Audit punktem wyjścia może być pytanie, spodziewany dokument oraz wynik, który go zastąpił. Taki materiał pozwala odróżnić brak w źródłach, za krótki zakres kandydatów i niekorzystne przestawienie listy. Każdy z tych wyników prowadzi do innego zadania dla wykonawcy.

Trzy rodzaje pytań, trzy okazje do pomyłki

Zbiór kontrolny powinien obejmować pytanie z dokładnym kodem, opis innymi słowami i rzadką nazwę. To nie są trzy warianty tej samej literówki. Każdy przypadek sprawdza inną przewagę lub słabość metod. Zapisz oczekiwany materiał przed obejrzeniem wyników, z osobą znającą rzeczywiste zastosowanie katalogu.

Dla kodu ustal dopuszczoną normalizację. Jeżeli łącznik jest obojętny, wariant bez łącznika może nadal oznaczać tę samą część. Jeśli zero na początku jest istotne, nie wolno usunąć go przy wygodnym przygotowaniu pytania. Sama lepsza pozycja podobnej nazwy nie potwierdza spełnienia tego warunku.

Przy swobodnym opisie pytanie powinno rzeczywiście używać innego słownictwa niż źródło. Inaczej porównanie może nie pokazać powodu zastosowania podobieństwa znaczenia. Odbiorca opisujący problem nie musi znać nazwy używanej w instrukcji. Poprawnym wynikiem może być materiał wyjaśniający zastosowanie, a nie karta o największej liczbie wspólnych słów.

Rzadka nazwa może natomiast występować w kilku dokumentach o różnych funkcjach. Jednym jest aktualna instrukcja, drugim notatka z rozmowy, trzecim wycofany katalog. Oceń nie tylko obecność nazwy. Ustal, który dokument odpowiada na pytanie o bieżącą czynność i czy zasady wyboru wersji zadziałały w obu ścieżkach oraz po połączeniu.

Dodaj pytanie bez właściwej podstawy w zbiorze. Celem nie jest uzyskanie zawsze pustej listy: czasem podobne materiały są użyteczne. Powinny jednak pozostać kandydatami, a nie potwierdzeniem brakującego kodu. Metoda zwracająca zawsze atrakcyjną pozycję może wyglądać znakomicie podczas prezentacji, na której wszystkie pytania przygotowano do istniejących kart.

Uzgodnij także głębokość, na której oceniamy wynik. Czy właściwy dokument ma być pierwszy, w pierwszych trzech, czy ma znaleźć się w zestawie przekazywanym modelowi? W naszym przykładzie A przegrywa pierwszą pozycję po fuzji, ale nadal mieści się w pierwszych dwóch. Te dwa kryteria dają różne oceny tego samego wyniku. Wybór powinien odpowiadać dalszemu użyciu listy.

Wynik po fuzji też jest tylko etapem

Jeżeli po RRF działa kolejny mechanizm zmieniający kolejność, zachowaj wynik przed nim i po nim. Nie przypisuj fuzji błędu, który powstał później. Analogicznie odnalezienie właściwej instrukcji nie gwarantuje, że model wiernie zachowa jej warunki w odpowiedzi. Etapy mogą poprawiać i pogarszać wynik niezależnie od siebie.

Microsoft opisuje semantic ranking jako etap wykonywany po połączeniu RRF, z osobno raportowaną oceną. Liczby pochodzące z różnych etapów mają różne znaczenie. Wysoki wynik rankingu nie jest procentem pewności, że odpowiedź spełnia wymagania firmy.

W odbiorze RAG rozdziel więc znalezienie źródła i wniosek na jego podstawie. Dobry tekst odpowiedzi nie powinien poprawiać oceny wyszukania błędnego materiału. Z kolei ostrożna odmowa po trafieniu do niepełnej instrukcji może być właściwym zachowaniem modelu, mimo że baza wymaga uzupełnienia.

Do próby regresji wyszukiwania i odpowiedzi zachowaj także pytania, przy których połączenie pogorszyło wynik. Po zmianie okna albo proporcji uruchom ponownie zarówno te przypadki, jak i wcześniejsze trafienia. Naprawienie kodu A kosztem wszystkich opisów zastosowania byłoby zamianą problemów, nawet gdy pokaz poprawki wygląda przekonująco. W raporcie wskaż konkretnie, które oczekiwania wróciły do normy, a które przestały być spełnione.

Ostatnia decyzja może dotyczyć rozdzielenia ścieżek. Rozpoznany kod prowadzi do dokładnej karty, swobodny opis do listy kandydatów. Taki układ wymaga osobnego przypadku granicznego: pytania zawierającego kod i opis jednocześnie. Zapisz, co ma wtedy pierwszeństwo i dlaczego. Sam fakt obecności dwóch metod nie ustala kolejności reguł produktu.

Po porównaniu pokaż wyniki osobno dla grup pytań. Jedna łączna liczba potrafi ukryć poprawę swobodnych opisów i pogorszenie dokładnych kodów. Wybór sposobu agregacji ocen AI rozstrzyga, jaką wagę otrzymują te grupy w podsumowaniu. Najpierw jednak zachowaj konkretne przypadki zmiany pozycji, aby średnia nie zastąpiła diagnozy.

Wróć do pytania z dokumentem A. Jeśli zadanie wymaga dokładnego kodu, zaakceptowanie B na pierwszym miejscu potrzebuje uzasadnionej reguły lub poprawki. Jeśli odbiorca ma porównać dwa materiały, lista B–A może spełniać inny uzgodniony cel. Decyzja o wdrożeniu powinna wskazać właśnie ten cel i wynik próby: czy obowiązuje dokładna zgodność kodu na pierwszym miejscu, czy wystarcza obecność właściwej instrukcji w zestawie przekazanym dalej.