RAG Query Rewriting: Przepisywanie pytań uzupełniających dla chatbotów AI

Pojedyncze pytanie, takie jak „A jak długo to obowiązuje?”, jest dla ludzi często jednoznaczne. Pamiętają oni wcześniej omawiany produkt, lokalizację i odpowiedni termin. Tymczasem wyszukiwarka wiedzy widzi na początku tylko kilka słów. Bez odpowiedniego kontekstu rozmowy może nie znaleźć niczego lub szukać niewłaściwego tematu. RAG Query Rewriting rozwiązuje ten problem, przekształcając zależne od kontekstu pytanie uzupełniające w samodzielne zapytanie przed rozpoczęciem wyszukiwania.

Brzmi to jak niewielki krok pośredni, ale często decyduje o jakości wieloetapowego czatu na stronie internetowej. Ten przewodnik pokazuje, jak zespoły rozwiązują pytania uzupełniające, kiedy lepiej dopytać i jak zapobiec wprowadzaniu przez parafrazę nowych faktów, błędnych uprawnień lub nieaktualnego kontekstu do wyszukiwania.

Dlaczego pytania uzupełniające przerastają wyszukiwarkę wiedzy

Pierwsze pytanie użytkownika jest zazwyczaj konkretne: „Jaka gwarancja dotyczy Modelu A?”. Po nim następują krótkie sformułowania, takie jak „A co z większym wariantem?”, „Czy to obowiązuje również w Polsce?” lub „Czego do tego potrzebuję?”. Zaimki, opuszczone podmioty i odniesienia do wcześniejszych odpowiedzi są w rozmowie naturalne. Jednak jako izolowane zapytania wyszukiwania są słabe.

Klasyczny potok wyszukiwania słów kluczowych, wektorowego lub Hybrid Search może ocenić tylko to, co otrzymuje jako zapytanie. Reranking poprawia kolejność istniejących wyników, ale nie zastępuje brakującego znaczenia słów „to” lub „do tego”. Query Rewriting znajduje się przed tym procesem: przekształca aktualne pytanie i istotną historię w samodzielne zapytanie gotowe do wyszukiwania.

Co musi zapewnić dobre przepisywanie zapytań

Udana parafraza jest wystarczająco pełna dla procesu retrieval, ale pozostaje blisko intencji użytkownika. Z pytania „A w Polsce?” może powstać na przykład „Jakie warunki gwarancji obowiązują dla Modelu A w Polsce?”, jeśli Model A i gwarancja zostały jednoznacznie określone w bezpośrednio poprzedzającym fragmencie dialogu. Przepisanie nie odpowiada jeszcze na pytanie. Służy wyłącznie odnalezieniu odpowiednich źródeł.

Aktualny przewodnik po architekturze Azure dotyczący Conversational RAG zaleca uwzględnienie istotnej historii rozmowy i sformułowanie aktualnego pytania przed procesem retrieval jako samodzielnego zapytania z rozstrzygniętymi odniesieniami. Ważne jest wyraźne podział, który tam również widać: dla późniejszej odpowiedzi zachowuje się pierwotne pytanie użytkownika. Dzięki temu system może sprawdzić, czy znalezione źródła faktycznie pasują do zadanego pytania.

Uzupełniać, ale nie wymyślać

Moduł do przepisywania może przejąć jednoznacznie obecne informacje: produkt, wersję, kraj, język lub ostatnio wymienioną procedurę. Nie może jednak uzupełniać braku numeru klienta, ustalać domniemanego wariantu produktu ani zamieniać niepewnej informacji o czasie w konkretną datę. Użytecznie brzmiące, ale wymyślone doprecyzowanie niezawodnie skieruje wyszukiwanie w złym kierunku.

Uprawnienia pozostają poza modelem tekstowym

Najemca (tenant), zalogowany użytkownik, udostępnione obszary dokumentów i role są określane po stronie serwera. Nie powinny trafiać do parafrazowanego zapytania jako swobodnie sformułowane twierdzenie. Backend ustawia odpowiednie filtry metadanych osobnie i w sposób nienaruszalny. Ani wcześniejsza wypowiedź na czacie, ani przekształcenie przez model nie mogą odblokować szerszego obszaru wyszukiwania.

Kontekst wymaga przemyślanego budżetu

Wysyłanie całej historii czatu do modułu przepisywania bez filtrowania rzadko jest dobrym rozwiązaniem. Stare tematy mogą przesłonić aktualne pytanie, dane osobowe mogą być niepotrzebnie przekazywane dalej, a długie historie zwiększają opóźnienia (latency) i koszty. Jako praktyczną wskazówkę wytyczne Microsoftu wymieniają od dwóch do pięciu ostatnich tur rozmowy oraz podsumowanie starszych treści. Nie jest to uniwersalny limit, ale punkt wyjścia do własnych testów.

Kompaktowy pakiet kontekstowy może składać się z następujących elementów:

• niezmienionego, aktualnego pytania użytkownika,
• kilku bezpośrednio istotnych wypowiedzi użytkownika i asystenta,
• już potwierdzonych encji, takich jak produkt, procedura lub lokalizacja,
• locale i strefy czasowej jako pól technicznych,
• krótkiego, zweryfikowanego podsumowania starszych części dialogu oraz
• wersji reguł rewrite, indeksu wiedzy i konfiguracji retrieval.

Właściwe uprawnienia do dokumentów pozostają od tego oddzielone. Przed przepisaniem pytania należy również usunąć niepotrzebne adresy e-mail, numery zamówień czy pełne odpowiedzi. Dbałość o oszczędność danych w historii ułatwia ponadto późniejsze debugowanie.

Niezawodny proces w sześciu krokach

1. Sprawdzenie samodzielności: Jasne, nowe pytanie, takie jak „Jak zmienić hasło?”, może trafić bezpośrednio do wyszukiwarki. Nie każda wiadomość wymaga przepisywania przez model.
2. Rozpoznanie odniesień: System zaznacza zaimki, elipsy, słowa porównawcze i odniesienia, takie jak „tam”, „oba” lub „druga opcja”.
3. Wybór istotnego kontekstu: Uwzględniane są tylko te wypowiedzi, które w wiarygodny sposób wyjaśniają te odniesienia. Świadoma zmiana tematu kończy stary kontekst.
4. Decyzja: Rewrite czy pytanie doprecyzowujące: Jeśli istnieje dokładnie jedna wiarygodna interpretacja, powstaje samodzielne zapytanie. Jeśli istnieje kilka prawdopodobnych znaczeń, chatbot zadaje krótkie pytanie doprecyzowujące.
5. Wyszukiwanie i ewentualny podział: Zapytanie przechodzi przez wyszukiwanie słów kluczowych, wektorowe lub Hybrid Search. Złożone pytania można rozbić na jasno nazwane podzapytania.
6. Odpowiedź na oryginalne pytanie: Odpowiedź jest generowana ze znalezionych źródeł, odnosi się do pierwotnego brzmienia i otwarcie sygnalizuje niepewność lub brak dowodów.

Przegląd Agentic Retrieval firmy Microsoft opisuje pokrewny proces: zapytanie i historia rozmowy wpływają na planowanie, skondensowane podzapytania są wykonywane równolegle, a wyniki są następnie łączone. Dokumentacja Amazon Bedrock również opisuje planowanie, iteracyjne podzapytania oraz weryfikację, czy znalezione treści są wystarczające do udzielenia odpowiedzi. Takie funkcje produktów mogą przejąć części potoku (pipeline); jednak bramki jakości i bezpieczeństwa własnej aplikacji pozostają niezbędne.

Rewrite, pytanie doprecyzowujące czy Query Decomposition?

Dane wejściowe	Odpowiednia reakcja	Uzasadnienie
„A czy to obowiązuje w Polsce?” po jednoznacznym pytaniu o gwarancję	Sformułowanie samodzielnego zapytania	Przedmiot i odniesienie są jednoznaczne.
„A co z tą drugą?” po wymienieniu trzech wariantów	Zadanie krótkiego pytania doprecyzowującego	Prawdopodobnych jest kilka interpretacji.
„Porównaj cenę, czas dostawy i zwroty dla obu modeli”	Rozbicie na ukierunkowane podzapytania	Kilka niezależnych aspektów wymaga wiarygodnych wyników.
„Nowy temat: Jak skontaktować się z działem wsparcia?”	Wyszukiwanie bez starego kontekstu produktu	Użytkownik sygnalizuje zmianę tematu.

Query Decomposition nie jest więc tym samym co Query Rewriting. Rewriting czyni pytanie zależne samodzielnym; Decomposition dzieli złożone pytanie na kilka zadań wyszukiwania. Dokumentacja Bedrock dotycząca Query Decomposition pokazuje, że wiele podzapytań może poprawić pokrycie informacji. Każde dodatkowe zapytanie wymaga jednak limitu, wspólnego modelu uprawnień i przejrzystego łączenia wyników.

Traktuj wyniki rewrite jak kod

Nawet jeśli wynikiem jest tylko tekst, powinien on posiadać ścisły kontrakt. Sensem jest strukturyzowany obiekt z polami takimi jak standaloneQuery, decision, resolvedReferences i reason. Dopuszczalne decyzje to na przykład SEARCH_AS_IS, REWRITE, CLARIFY oraz DECOMPOSE. Backend waliduje długość, język i dozwolone pola przed rozpoczęciem wyszukiwania.

Moduł do przepisywania nie otrzymuje żadnych narzędzi i nie odpowiada bezpośrednio użytkownikowi. Instrukcje systemowe z historii czatu, wklejone teksty dokumentów czy polecenia typu „Ignoruj zasady” pozostają danymi, a nie poleceniami sterującymi. W przypadku wrażliwych obszarów wyszukiwania reguła deterministyczna może dodatkowo wymusić, aby filtry produktu, locale czy najemcy nigdy nie pochodziły z tekstu swobodnego.

Weryfikacja za pomocą własnego zestawu testowego dla pytań uzupełniających

Jakości nie da się udowodnić pojedynczymi, udanymi prezentacjami demo. Uzupełnij istniejący Golden Set dla jakości odpowiedzi o rzeczywiste, wieloetapowe dialogi. Dla każdego przypadku rejestruje się pierwotną historię, aktualne pytanie, oczekiwaną decyzję rewrite, dozwolone encje, niedozwolone uzupełnienia i oczekiwane źródła.

• Zaimki i opuszczone podmioty w krótkich pytaniach uzupełniających
• Korekty, takie jak „Nie, chodziło mi o Model B”
• Zmiany tematu i powrót do wcześniejszego wątku
• Wieloznaczne warianty, które bezwzględnie wymagają pytania doprecyzowującego
• Zmiany locale, daty i strefy czasowej
• Niedozwolone próby zmiany obszaru wyszukiwania lub najemcy
• Długie historie z nieistotnymi, starszymi szczegółami
• Wieloczęściowe pytania, które są dzielone, a następnie ponownie scalane

Mierz czynniki oddzielnie: Czy parafrazowanie zgadza się z intencją użytkownika? Czy retrieval znajduje oczekiwane źródła? Czy przy rzeczywistej wieloznaczności zadano pytanie doprecyzowujące? Czy filtry uprawnień pozostały niezmienione? Ile dodatkowych opóźnień generuje ten krok? NIST AI RMF Core wpisuje powtarzalne testowanie, mierzenie i dokumentowanie w cały cykl życia AI. Dla zespołów zajmujących się stronami internetowymi oznacza to: zmieniamy regułę rewrite, model lub wybór kontekstu tylko po teście regresyjnym i z kontrolowanym wdrażaniem.

Kompaktowa lista kontrolna dla zespołów webowych

• Czy pierwotne pytanie użytkownika pozostaje niezmienione aż do momentu udzielenia odpowiedzi?
• Czy uwzględniane są tylko istotne i oszczędne pod względem danych części historii?
• Czy moduł rewrite może wyraźnie wybierać między parafrazą, pytaniem doprecyzowującym a podziałem zapytania?
• Czy uzupełnia on wyłącznie confirmed encje, a nie domysły?
• Czy backend ustawia locale, najemcę i uprawnienia niezależnie od procesu rewrite?
• Czy każde podzapytanie posiada stałe limity ilościowe, czasowe i kosztowe?
• Czy wyniki retrieval są oceniane w odniesieniu do pierwotnego pytania?
• Czy zestaw testowy wieloetapowych dialogów obejmuje odniesienia, korekty i zmiany tematu?

Podsumowanie: Najpierw doprecyzuj zapytanie, potem odpowiadaj

RAG Query Rewriting przekształca naturalne, skrótowe wypowiedzi w niezawodne zapytanie wyszukiwania. Największa korzyść nie wynika z jak najbardziej kreatywnego parafrazowania, ale z jasnych granic: przejmowanie potwierdzonego kontekstu, rozstrzyganie niepewności za pomocą pytań doprecyzowujących, utrzymywanie uprawnień po stronie serwera i stałe weryfikowanie odpowiedzi pod kątem oryginalnego pytania. Zacznij od dwudziestu typowych pytań uzupełniających z Twojego działu wsparcia, zaznacz oczekiwaną decyzję i testuj każdą zmianę na tych samych przypadkach. W ten sposób wieloetapowy czat stanie się bardziej zrozumiały, bez ryzyka, że wyszukiwarka po cichu odpowie na zupełnie inne pytanie.

Źródła

• Microsoft Azure Architecture Center: Prompt Engineering dla RAG
• Microsoft Learn: Agentic Retrieval w Azure AI Search
• Amazon Bedrock: Konfiguracja zapytań i generowania odpowiedzi
• Amazon Bedrock: Agentic Retrieval dla baz wiedzy
• NIST AI Risk Management Framework Core