Przepisywanie zapytań w RAG (query rewriting)

Przepisywanie zapytań, po angielsku query rewriting, to kontrolowana transformacja pytania przed etapem wyszukiwania w systemie RAG. Użytkownik może napisać „jak ogarnąć follow-up po callu?”, podczas gdy firmowa baza używa pojęć „rozmowa sprzedażowa”, „kwalifikacja leada” i „wiadomość podsumowująca”. Warstwa rewrite rozpoznaje intencję i tworzy wersję, która lepiej trafia w dokumenty. Nie odpowiada jeszcze na pytanie i nie tworzy nowych faktów. Jej zadaniem jest zwiększyć szansę, że wyszukiwarka poda właściwe fragmenty modelowi, który dopiero później przygotuje odpowiedź.

W RAG jakość odpowiedzi zależy najpierw od tego, co system odnajdzie. Nawet dobry model nie zacytuje procedury, której nie dostał w kontekście. Rewrite jest przydatny zwłaszcza przy krótkich pytaniach, skrótach branżowych, literówkach, rozmowach wieloturowych i języku potocznym. Może rozwinąć skrót, dopisać nazwę produktu znaną z kontekstu rozmowy albo stworzyć kilka wariantów wyszukiwawczych. Nie powinien natomiast dopowiadać cech klienta, dat, cen ani reguł biznesowych, których użytkownik nie podał. Taka „pomoc” zamienia poprawę retrievalu w cichą halucynację.

Najprostszy przepływ wygląda tak: zachowujesz oryginalne pytanie, generujesz propozycję wyszukiwawczą, wysyłasz ją do indeksu, a następnie zapisujesz oba teksty wraz z wynikami. W bardziej wymagającym systemie tworzy się kilka krótkich zapytań dla różnych aspektów pytania i łączy wyniki. Przykładowo „jak przygotować ofertę po konsultacji?” może zostać rozbite na „szablon oferty po konsultacji”, „kryteria kwalifikacji klienta” i „follow-up po rozmowie”. Liczba wariantów musi mieć limit, bo każdy dodatkowy wynik zwiększa koszt, opóźnienie i ryzyko wciągnięcia nieistotnych dokumentów.

Praktyczny przykład: ekspert ma bazę procedur sprzedażowych, ofert i nagrań z konsultacji. Klient pyta w czacie: „co wysłać komuś, kto mówi że wróci po urlopie?”. System rozpoznaje, że potrzebuje materiałów o follow-upie po odroczeniu decyzji, a nie ogólnej porady o urlopie. Tworzy zapytanie „follow-up do leada po odroczeniu decyzji zakupowej” i zachowuje oryginał. Wyszukiwarka zwraca zatwierdzony szablon, zasady częstotliwości kontaktu i fragment oferty. Model przygotowuje szkic odpowiedzi wyłącznie z tych źródeł, a system pokazuje cytowane materiały oraz nie wysyła wiadomości automatycznie.

Przepisywanie zapytania nie jest tym samym co wyszukiwanie hybrydowe ani reranking. Wyszukiwanie hybrydowe łączy zwykle dopasowanie słów z dopasowaniem wektorowym. Reranking układa już odnalezione dokumenty w lepszej kolejności. Query rewriting działa wcześniej: poprawia lub rozwija samo pytanie. Te techniki można łączyć, ale każda odpowiada na inny problem. Gdy dokumenty są nieaktualne, źle podzielone albo niedostępne dla użytkownika, rewrite niczego nie naprawi. Najpierw sprawdź jakość źródła prawdy, uprawnienia i podstawowe wyniki wyszukiwania.

Bezpieczny prompt do rewrite powinien mieć wąskie zadanie: zachowaj intencję, nie odpowiadaj użytkownikowi, nie dodawaj faktów, zwróć ograniczoną liczbę zapytań i podaj je w ustrukturyzowanym formacie. Warto przekazać do niego tylko potrzebny fragment historii rozmowy, a nie cały czat z danymi klientów. Po stronie aplikacji waliduj długość i liczbę zapytań oraz odrzucaj wynik, który zawiera instrukcję narzędziową, adres URL, sekret lub podejrzanie odległe pojęcie. Pytanie użytkownika jest danymi, a nie zaufaną komendą. To ważne, gdy RAG pracuje na treści z internetu lub plikach od zewnętrznych osób.

Mierz rewrite na realnym zestawie pytań, nie na pojedynczym udanym demie. Przy każdym przykładzie zapisz: oryginalne pytanie, wersję po rewrite, oczekiwany dokument, dokumenty zwrócone przez wyszukiwarkę i końcową odpowiedź. Porównaj odsetek przypadków, w których właściwy materiał trafia do pierwszych wyników, oraz koszt i czas odpowiedzi. Dodaj przypadki graniczne: bardzo krótkie pytanie, niejednoznaczny skrót, pytanie o aktualną cenę, brak dokumentu w bazie i próba wymuszenia instrukcji przez treść. Jeśli rewrite pogarsza wyniki dla części pytań, używaj go warunkowo albo wracaj do oryginału.

Ograniczenie jest proste: system może brzmieć mądrzej, a mimo to wyszukiwać gorzej. Model czasem zbyt mocno zawęzi pytanie, zmieni termin na błędny synonim lub zgubi ważny warunek. Dlatego przechowuj oryginał, pokazuj źródła odpowiedzi i utrzymuj możliwość wyszukania po obu wersjach. Dla soloprzedsiębiorcy rozsądny start to jeden konkretny use case, na przykład pytania do materiałów szkoleniowych. Zbuduj listę 20 prawdziwych pytań, sprawdź wyniki przed i po rewrite, a dopiero potem dodawaj wielozapytaniowość, automatyczną klasyfikację lub kolejny model.