Przepisywanie zapytań i HyDE

Jakość wyszukiwania jest ograniczona przez zapytanie. Surowe zapytania użytkowników są często krótkie, niejednoznaczne, pełne zaimków lub sformułowane inaczej niż dokumenty. Transformacja zapytania zmienia zapytanie przed wyszukiwaniem, aby zwiększyć recall i precision.

To jedno z najtańszych ulepszeń o największym wpływie w porównaniu z naiwnym RAG: poprawa zapytania przynosi korzyści każdemu kolejnemu etapowi.

Najprostsza transformacja: LLM przepisuje zapytanie użytkownika na jaśniejszą, samodzielną i przyjazną wyszukiwaniu formę. Poprawia literówki, rozwija skróty i usuwa konwersacyjny szum.

Jest to szczególnie ważne w rozmowie wieloturowej, w której najnowsza wiadomość jest niezrozumiała bez kontekstu (A co z drugim?).

W chatowym RAG należy skondensować dialog i nową turę do jednego samodzielnego pytania. Bez tego zaimki i wielokropki sprawiają, że embedding staje się bezwartościowy, a wyszukiwanie przestaje działać.

Należy przekazać poprzednie tury, aby moduł przepisujący mógł zamienić określenia „to”, „tamto” i „poprzedni” na jawne encje, które wyszukiwarka będzie mogła dopasować.

Rozszerzanie generuje synonimy, powiązane terminy lub alternatywne sformułowania, aby poszerzyć pokrycie leksykalne i semantyczne. Pomaga przezwyciężyć niezgodność słownictwa: dokument mówi „invalidate”, a użytkownik „revoke”.

Zapytanie należy rozszerzać na potrzeby wyszukiwania, a następnie wyszukiwać na podstawie połączenia wyników; nie należy wyświetlać użytkownikowi rozszerzonej formy. Należy uważać na nadmierne rozszerzanie, które może przyciągać wyniki niezwiązane z tematem.

Należy wygenerować kilka różnorodnych przeformułowań, wyszukać wyniki dla każdego z nich i połączyć listy wyników (reciprocal rank fusion). Różne sformułowania ujawniają różne trafne fragmenty; łączenie wyników wykorzystuje ich mocne strony i stabilizuje recall.

Rozwiązanie to wymaga dodatkowych wywołań wyszukiwania, ale zwiększa odporność na pojedyncze nieudane sformułowanie.

Złożone pytania wieloetapowe wymagają dekompozycji na pytania składowe, z których każde jest wyszukiwane osobno, a następnie całość jest składana. Na pytanie „Który dyrektor generalny firmy przejętej przez X jest starszy od...” nie można odpowiedzieć na podstawie jednego wyszukiwania.

Należy podzielić pytanie, wyszukać informacje dla każdego pytania składowego i pozwolić generatorowi połączyć zebrane dowody.

HyDE (Hypothetical Document Embeddings, Gao et al., 2022) odwraca to podejście. Zamiast osadzać krótkie zapytanie, prosi LLM o wygenerowanie hipotetycznego dokumentu z odpowiedzią, a następnie osadza ten dokument i na jego podstawie wyszukuje wyniki.

Hipotetyczny dokument jest napisany w takim samym rejestrze jak rzeczywiste dokumenty, więc jego embedding znajduje się bliżej prawdziwych odpowiedzi, co naprawia niezgodność między zapytaniem a dokumentem.

Pytanie i jego odpowiedź są sformułowane inaczej, natomiast pytanie i fałszywa, lecz wiarygodna odpowiedź są sformułowane podobnie do rzeczywistej odpowiedzi. HyDE wykorzystuje prior generatywny LLM-a, aby wypełnić tę lukę, nawet jeśli hipotetyczny dokument zawiera błędy faktograficzne.

Poprawność hipotetycznego dokumentu nie ma większego znaczenia: musi on jedynie zawierać właściwe słownictwo i strukturę, aby znaleźć się blisko prawdziwych dokumentów w przestrzeni embeddingów.

HyDE dodaje generowanie przez LLM przed wyszukiwaniem, zwiększając opóźnienie i koszt, a także może halucynować hipotetyczny dokument odbiegający od tematu. Pogarsza to recall w przypadku niszowych zapytań lub zapytań spoza rozkładu danych, o których model nic nie wie.

Można temu przeciwdziałać, łącząc wyszukiwanie na podstawie wektora HyDE z wyszukiwaniem na podstawie surowego zapytania, tak aby błędny dokument hipotetyczny nie mógł całkowicie zniszczyć recall.

Te transformacje wzajemnie się uzupełniają. Należy używać kondensowania w rozmowach, rozszerzania/wielu zapytań w przypadku luk w słownictwie, dekompozycji w przypadku pytań wieloetapowych oraz HyDE w przypadku niezgodności rejestru pytania i dokumentu. Wiele produkcyjnych stosów najpierw kondensuje zapytanie, następnie stosuje HyDE, łączy wyniki z wynikami surowego zapytania, a na końcu wykonuje reranking.

Każda dodatkowa transformacja kosztuje jedno wywołanie LLM, dlatego należy uruchamiać je zależnie od typu zapytania, a nie zawsze stosować wszystkie.

Należy ocenić każdą transformację na podstawie jej wpływu na recall@k w retrievalu i dokładność końcowej odpowiedzi w porównaniu z surowym zapytaniem, korzystając ze zbioru wolnego od wycieków danych. Należy śledzić dodatkowe opóźnienie i koszt LLM, aby zachować tylko te transformacje, których korzyści przewyższają koszty.

Uwaga: transformacja, która poprawia recall, ale dodaje rozpraszające wyniki, może obniżyć dokładność odpowiedzi, jeśli nie zostanie połączona z rerankingiem i kompresją.

Proszę przeanalizować, dlaczego HyDE działa mimo niedoskonałych hipotez.

Najważniejsze wnioski:

• Możliwości retrievalu ogranicza zapytanie; jego transformacja to niedrogie ulepszenie RAG o dużym wpływie.
• Przepisywanie/kondensacja sprawia, że zapytania czatowe stają się samodzielne, a ekspansja i multi-query uzupełniają braki w słownictwie.
• Dekompozycja obsługuje pytania wieloetapowe, pobierając dane dla każdego podzapytania.
• HyDE osadza hipotetyczną odpowiedź, aby zniwelować różnicę rejestru między pytaniem a dokumentem; poprawność hipotezy nie jest wymagana.
• Należy łączyć transformacje zależnie od typu zapytania, scalać je z surowym zapytaniem dla większej odporności oraz oceniać recall, dokładność odpowiedzi, opóźnienie i koszt.