RAG Query Rewriting: Ispravno razrešavanje potpitanja za AI chatbote

Pojedinačno pitanje poput „A koliko to vrijedi?“ ljudima je često sasvim jasno. Sjećaju se prethodno spomenutog proizvoda, lokacije i roka o kojem je riječ. Sustav za pretraživanje znanja, s druge strane, u početku vidi samo nekoliko riječi. Bez odgovarajućeg razgovornog konteksta možda neće pronaći ništa ili će pretraživati pogrešnu temu. RAG Query Rewriting rješava ovaj problem tako što kontekstualno ovisno potpitanje prije pretraživanja pretvara u samostalni upit.

To zvuči kao mali među-korak, ali često odlučuje o kvaliteti višestupanjskog chata na web stranici. Ovaj vodič pokazuje kako timovi razrešavaju potpitanja, kada je bolje postaviti dodatno pitanje i kako spriječiti da preoblikovanje u pretraživanje unese nove činjenice, pogrešna ovlaštenja ili zastarjeli kontekst.

Zašto potpitanja opterećuju pretraživanje znanja

Prvo korisničko pitanje obično je konkretno: „Koje jamstvo vrijedi za Model A?“. Nakon toga slijede kratke fraze poput „A za veću varijantu?“, „Vrijedi li to i u Hrvatskoj?“ ili „Što mi je potrebno za to?“. Zamjenice, izostavljeni subjekti i upućivanje na prethodne odgovore prirodni su u razgovoru. Međutim, kao izolirani upiti za pretraživanje, oni su slabi.

Klasični cjevovod za ključne riječi, vektorsko ili Hybrid Search može procijeniti samo ono što primi kao upit. Reranking poboljšava redoslijed postojećih pogodaka, ali ne nadomješta nedostajuće značenje riječi „to“ ili „za to“. Query Rewriting se stoga nalazi ispred njega: od trenutnog pitanja i relevantnog tijeka razgovora oblikuje samostalni upit koji se može pretraživati.

Što mora proizaći iz dobrog preoblikovanja

Uspješno preoblikovani upit dovoljno je potpun za dohvaćanje (retrieval), ali ostaje usko povezan s namjerom korisnika. Primjerice, iz „A za Hrvatsku?“ može nastati „Koji jamstveni uvjeti vrijede za Model A u Hrvatskoj?“, ako su Model A i jamstvo jasno utvrđeni u neposredno prethodnom dijalogu. Preoblikovanje još ne odgovara na pitanje. Ono služi isključivo za pronalaženje odgovarajućih izvora.

Trenutne Azure smjernice za arhitekturu Conversational RAG-a preporučuju uključivanje relevantne povijesti razgovora i formuliranje trenutnog pitanja prije dohvaćanja kao samostalnog upita s razriješenim referencama. Važna je i tamo vidljiva razdioba: za kasniji odgovor zadržava se izvorno korisničko pitanje. Na taj način sustav može provjeriti odgovaraju li pronađeni dokazi doista postavljenom pitanju.

Dopuniti, ali ne izmišljati

Preoblikovač (rewriter) smije preuzeti jednoznačno postojeće podatke: proizvod, verziju, državu, jezik ili zadnje spomenuti postupak. Međutim, ne smije dopunjavati korisnički broj koji nedostaje, određivati pretpostavljenu varijantu proizvoda niti pretvarati nesigurnu vremensku oznaku u konkretan datum. Preciziranje koje zvuči korisno, ali je izmišljeno, pouzdano šalje pretraživanje u pogrešnom smjeru.

Ovlaštenja ostaju izvan tekstualnog modela

Korisnički račun, prijavljeni korisnik, odobrena područja dokumenata i uloge određuju se na strani poslužitelja. Oni ne pripadaju u preoblikovani upit kao proizvoljno formulirane tvrdnje. Pozadinski sustav (backend) postavlja pripadajuće filtre metapadataka odvojeno i nepromjenjivo. Niti raniji unos u chatu niti preoblikovanje modela ne smiju otključati veći prostor pretraživanja.

Kontekst zahtijeva promišljen proračun

Slanje cjelokupne povijesti chata preoblikovaču bez filtriranja rijetko je dobro rješenje. Stare teme mogu potisnuti trenutno pitanje, osobni podaci mogu se nepotrebno prenositi dalje, a dugački tijekovi povečavaju latenciju i troškove. Kao praktičnu smjernicu, Microsoftove upute navode dvije do pet nedavnih razmjena poruka i sažetak starijeg sadržaja. To nije univerzalno ograničenje, već početna točka za vlastita testiranja.

Kompaktni paket konteksta može se sastojati od sljedećih elemenata:

• neizmijenjenog trenutnog korisničkog pitanja,
• nekoliko neposredno relevantnih unosa korisnika i asistenta,
• već potvrđenih entiteta poput proizvoda, postupka ili lokacije,
• lokalizacije (locale) i vremenske zone kao tehničkih polja,
• kratkotrajnog, provjerenog sažetka starijih dijelova dijaloga i
• verzije pravila preoblikovanja, indeksa znanja i konfiguracije dohvaćanja.

Stvarna ovlaštenja nad dokumentima ostaju odvojena od toga. Jednako tako, nepotrebne adrese e-pošte, brojeve narudžbi ili potpune odgovore treba ukloniti prije preoblikovanja. Tijek razgovora sa štedljivim korištenjem podataka dodatno olakšava kasnije pronalaženje pogrešaka.

Pouzdan proces u šest koraka

1. Provjera samostalnosti: Jasno novo pitanje poput „Kako mogu promijeniti svoju lozinku?“ može ići izravno u pretraživanje. Ne treba svaka poruka preoblikovanje pomoću modela.
2. Prepoznavanje referenci: Sustav označava zamjenice, elipse, riječi za usporedbu i upućivanja poput „tamo“, „obojica“ ili „druga opcija“.
3. Odabir relevantnog konteksta: Preuzimaju se samo oni unosi koji uvjerljivo razrešavaju te reference. Namjerna promjena teme završava stari kontekst.
4. Odluka o preoblikovanju ili razjašnjenju: Ako je točno jedno razjašnjenje pouzdano, stvara se samostalni upit za pretraživanje. Ako postoji više mogućih značenja, chatbot postavlja kratko pitanje za razjašnjenje.
5. Pretraživanje i eventualno rastavljanje: Upit prolazi kroz Keyword, Vector ili Hybrid Search. Višedijelna pitanja mogu se rastaviti na jasno imenovana podpitanja.
6. Odgovaranje na izvorno pitanje: Odgovor se generira iz pronađenih izvora, odnosi se na izvorni tekst i otvoreno navodi nesigurnost ili nedostatak dokaza.

Microsoftov pregled Agentic Retrievala opisuje srodan proces: upit i povijest razgovora ulaze u planiranje, usmjereni podupiti izvode se paralelno, a pogoci se potom spajaju. Amazon Bedrock dokumentacija također bilježi planiranje, iterativne podupite i provjeru jesu li pronađeni sadržaji dovoljni za odgovor. Takve značajke proizvoda mogu preuzeti dijelove cjevovoda; no vrata kvalitete i sigurnosti vlastite aplikacije i dalje ostaju nužna.

Rewrite, pitanje za razjašnjenje ili Query Decomposition?

Unos	Odgovarajuća reakcija	Obrazloženje
„A vrijedi li to u Hrvatskoj?“ nakon jasnog pitanja o jamstvu	Formulirati samostalni upit	Predmet i referenca su jednoznačni.
„Što je s drugom?“ nakon tri spomenute varijante	Postaviti kratko pitanje za razjašnjenje	Više razjašnjenja je uvjerljivo.
„Usporedi cijenu, rok isporuke i povrat za oba modela“	Rastaviti na usmjerene podupite	Više neovisnih aspekata zahtijeva pouzdane pogotke.
„Nova tema: Kako mogu kontaktirati podršku?“	Pretraživati bez starog konteksta proizvoda	Korisnik signalizira promjenu teme.

Query Decomposition stoga nije isto što i Query Rewriting. Rewriting čini ovisno pitanje samostalnim; Decomposition dijeli složeno pitanje na više zadataka pretraživanja. Bedrock dokumentacija o Query Decompositionu pokazuje da više podupita može poboljšati pokrivenost. Međutim, svaki dodatni upit zahtijeva ograničenje, zajednički model ovlaštenja i sljedivo spajanje.

Tretirajte izlaze preoblikovanja poput koda

Čak i ako je rezultat samo tekst, trebao bi imati strogo definiran ugovor. Koristan je strukturirani objekt s poljima kao što su standaloneQuery, decision, resolvedReferences i reason. Dopuštene odluke su, primjerice, SEARCH_AS_IS, REWRITE, CLARIFY i DECOMPOSE. Pozadinski sustav validira duljinu, jezik i dopuštena polja prije početka pretraživanja.

Preoblikovač ne dobiva alate i ne odgovara izravno korisniku. Sustavske upute iz tijeka chata, umetnuti tekstovi dokumenata ili zahtjevi poput „Zanemari pravila“ ostaju podaci, a ne upravljačke naredbe. Za rizične prostore pretraživanja, determinističko pravilo može dodatno osigurati da filtri za proizvod, lokalizaciju ili korisnički račun nikada ne potječu iz slobodnog teksta.

Testirajte s vlastitim skupom testova za potpitanja

Kvaliteta se ne može dokazati pojedinačnim uspješnim demonstracijama. Nadopunite postojeći Golden Set za kvalitetu odgovora stvarnim višestrukim dijalozima. Za svaki slučaj bilježe se izvorni tijek, trenutno pitanje, očekivana odluka o preoblikovanju, dopušteni entiteti, zabranjene dopune i očekivani izvori.

• Zamjenice i izostavljeni subjekti u kratkim potpitanjima
• Ispravci poput „Ne, mislio sam na Model B“
• Promjene teme i povratak na raniju temu
• Višeznačne varijante koje obavezno zahtijevaju dodatno pitanje
• Promjene lokalizacije, datuma i vremenske zone
• Nedopušteni pokušaji promjene prostora pretraživanja ili korisničkog računa
• Dugački tijekovi s irelevantnim starijim detaljima
• Višedijelna pitanja koja se rastavljaju i ponovno spajaju

Mjerite odvojeno: Odgovara li preoblikovanje namjeri korisnika? Pronalazi li dohvaćanje očekivane izvore? Je li postavljeno dodatno pitanje u slučaju stvarne višeznačnosti? Jesu li filtri ovlaštenja ostali nepromijenjeni? Koliko dodatne latencije uzrokuje ovaj korak? NIST AI RMF Core svrstava ponovljeno testiranje, mjerenje i dokumentiranje u cjelokupni životni ciklus AI-ja. Za timove koji rade na web stranicama to znači: mijenjajte pravila preoblikovanja, model ili odabir konteksta samo uz regresijsko testiranje i nadzirano uvođenje.

Sažeti kontrolni popis za timove web stranica

• Ostaje li izvorno korisničko pitanje nepromijenjeno sve do generiranja odgovora?
• Uključuju li se samo relevantni i podacima štedljivi dijelovi tijeka razgovora?
• Može li preoblikovač jasno birati između preoblikovanja, dodatnog pitanja i rastavljanja?
• Dopunjava li on isključivo potvrđene entitete, bez pretpostavki?
• Postavlja li backend lokalizaciju, korisnički račun i ovlaštenja neovisno o preoblikovanju?
• Ima li svaki podupit fiksna ograničenja količine, vremena i troškova?
• Ocenjuju li se pogoci dohvaćanja u odnosu na izvorno pitanje?
• Pokriva li skup testova za višestruke dijaloge reference, ispravke i promjene tema?

Zaključak: Prvo razjasnite upit za pretraživanje, a zatim odgovarajte

RAG Query Rewriting pretvara prirodnu kratkoću razgovora u pouzdan upit za pretraživanje. Najveća korist ne dolazi od što kreativnijih preoblikovanja, već od jasnih granica: preuzeti potvrđeni kontekst, riješiti nesigurnost dodatnim pitanjem, zadržati ovlaštenja na strani poslužitelja te odgovor i dalje provjeravati u odnosu na izvorno pitanje. Započnite s dvadeset tipičnih potpitanja iz vaše podrške, označite očekivanu odluku i testirajte svaku promjenu u odnosu na te iste slučajeve. Tako višestupanjski chat postaje razumljiviji, a da pretraživanje tiho ne odgovori na potpuno drugo pitanje.

Izvori

• Microsoft Azure Architecture Center: Prompt Engineering za RAG
• Microsoft Learn: Agentic Retrieval u Azure AI Searchu
• Amazon Bedrock: Konfiguracija upita i generiranja odgovora
• Amazon Bedrock: Agentic Retrieval za baze znanja
• NIST AI Risk Management Framework Core