RAG Query Rewriting: Pravilno razreševanje nadaljnjih vprašanj za AI klepetalnike

Eno samo vprašanje, kot je »In kako dolgo to velja?«, je za ljudi pogosto povsem jasno. Spomnijo se prej obravnavanega izdelka, lokacije in mišljenega roka. Iskanje po bazi znanja pa na začetku vidi le nekaj besed. Brez ustreznega konteksta pogovora morda ne najde ničesar ali pa išče napačno temo. RAG Query Rewriting rešuje to težavo tako, da kontekstualno odvisno nadaljnje vprašanje pred iskanjem pretvori v samostojno iskalno poizvedbo.

To se sliši kot majhen vmesni korak, vendar pogosto odloča o kakovosti večstopenjskega spletnega klepeta. Ta vodnik prikazuje, kako ekipe razrešujejo nadaljnja vprašanja, kdaj je bolje postaviti podvprašanje in kako preprečiti, da bi preoblikovanje v iskanje vneslo nova dejstva, napačna dovoljenja ali zastarel kontekst.

Zakaj nadaljnja vprašanja preobremenjujejo iskanje po znanju

Prvo uporabniško vprašanje je običajno konkretno: »Kakšna garancija velja za model A?«. Temu sledijo kratke besedne zveze, kot so »Kaj pa za večjo različico?«, »Ali to velja tudi v Avstriji?« ali »Kaj potrebujem za to?«. Zaimki, opuščeni osebki in sklicevanja na prejšnje odgovore so v pogovoru naravni. Kot izolirana iskalna poizvedba pa so šibki.

Klasični cevovod za ključne besede, vektorje ali hibridno iskanje lahko oceni le tisto, kar prejme kot poizvedbo. Ponovno razvrščanje (reranking) izboljša vrstni red obstoječih zadetkov, ne nadomesti pa manjkajočega pomena besed »to« ali »za to«. Query Rewriting se zato nahaja pred tem: iz trenutnega vprašanja in ustrezne zgodovine ustvari iskalno, samostojno poizvedbo.

Kaj mora zagotoviti dobro preoblikovanje

Upoševno preoblikovana poizvedba je dovolj popolna za pridobivanje (retrieval), vendar ostaja tesno povezana z namenom uporabnika. Iz »Kaj pa za Avstrijo?« lahko na primer nastane »Kateri garancijski pogoji veljajo za model A v Avstriji?«, če sta model A in garancija v neposredno predhodnem pogovoru jasna. Preoblikovanje še ne odgovori na vprašanje. Služi izključno iskanju ustreznih virov.

Trenutne Azure smernice za arhitekturo pogovornega RAG-a priporočajo vključitev ustrezne zgodovine pogovora in oblikovanje trenutnega vprašanja pred pridobivanjem kot samostojne poizvedbe z razrešenimi sklici. Pomembna je tudi ločitev, ki je tam opazna: za poznejši odgovor se ohrani prvotno uporabniško vprašanje. Tako lahko sistem preveri, ali najdeni dokazi dejansko ustrezajo zastavljenemu vprašanju.

Dopolnjujte, vendar ne izmišljujte

Preoblikovalnik (rewriter) lahko prevzame jasno prisotne podatke: izdelek, različico, državo, jezik ali nazadnje omenjeni postopek. Ne sme pa dodati manjkajoče številke stranke, določiti domnevne različice izdelka ali negotovega časovnega podatka spremeniti v konkreten datum. Koristno zadeveča, a izmišljena natančnost iskanje zanesljivo usmeri v napačno smer.

Dovoljenja ostajajo zunaj besedilnega modela

Najemnik, prijavljeni uporabnik, odobrena območja dokumentov in vloge se določijo na strani strežnika. Ne sodijo v poizvedbo za preoblikovanje kot prosto formulirana trditev. Ozadje (backend) nastavi pripadajoče filtre metapodatkov ločeno in nespremenljivo. Niti prejšnji prispevek v klepetu niti preoblikovanje modela ne smeta odpreti večjega iskalnega prostora.

Kontekst potrebuje premišljen proračun

Pošiljanje celotne zgodovine klepeta v preoblikovalnik brez filtriranja je redko dobra rešitev. Stare teme lahko prekrijejo trenutno vprašanje, osebni podatki se lahko po nepotrebnem prenašają naprej, dolgi poteki pa povečujejo zakasnitev in stroške. Kot praktično usmeritev Microsoftova smernica navaja dve do pet nedavnih pogovornih krogov in povzetek starejše vsebine. To ni univerzalna meja, temveč izhodišče za lastna testiranja.

Kompakten paket konteksta lahko sestavljajo naslednji gradniki:

• nespremenjeno trenutno uporabniško vprašanje,
• nekaj neposredno ustreznih prispevkov uporabnika in asistenta,
• že potrjene entitete, kot so izdelek, postopek ali lokacija,
• lokacija (locale) in časovni pas kot tehnični polji,
• kratek, preverjen povzetek starejših delov pogovora in
• različica pravila za preoblikovanje, indeksa znanja in konfiguracije pridobivanja.

Dejanska dovoljenja za dokumente ostajajo ločena od tega. Prav takovse nepotrebne e-poštne naslove, številke naročil ali popolne odgovore odstranite pred preoblikovanjem. Zgodovina, ki varčuje s podatki, dodatno olajša poznejše odpravljanje napak.

Robusten potek v šestih korakih

1. Preverite samostojnost: Jasno novo vprašanje, kot je »Kako spremenim geslo?«, lahko gre neposredno v iskanje. Vsako sporočilo ne potrebuje modelnega preoblikovanja.
2. Prepoznajte sklice: Sistem označi zaimke, elipse, primerjalne besede in sklice, kot so »tamo«, »oboji« ali »druga možnost«.
3. Izberite ustrezen kontekst: Prevzamejo se le prispevki, ki verjetno razrešujejo te sklice. Namerna sprememba teme konča stari kontekst.
4. Odločite se za preoblikovanje ali podvprašanje: Če je natanko ena razrešitev zanesljiva, nastane samostojna iskalna poizvedba. Če obstaja več verjetnih pomenov, klepetalnik postavi kratko razjasnitveno vprašanje.
5. Iščite in po potrebi razčlenite: Poizvedba poteka skozi iskanje po ključnih besedah, vektorsko ali hibridno iskanje. Večdelna vprašanja se lahko razčlenijo na jasno poimenovana podvprašanja.
6. Odgovorite na izvirno vprašanje: Odgovor se ustvari iz najdenih virov, se nanaša na izvirno besedilo ter odkrito navaja negotovost ali manjkajoče dokaze.

Microsoftov pregled Agentic Retrieval opisuje soroden potek: poizvedba in zgodovina pogovora se vključita v načrtovanje, usmerjena podvprašanja se izvajajo vzporedno, zadetki pa se nato združijo. Dokumentacija Amazon Bedrock prav tako dokumentira načrtovanje, iterativna podvprašanja in preverjanje, ali najdena vsebina zadošča za odgovor. Takšne funkcije izdelkov lahko prevzamejo dele cevovoda; kljub temu pa ostajajo potrebne kontrolne točke za kakovost in varnost vaše lastne aplikacije.

Preoblikovanje, razjasnitveno vprašanje ali Query Decomposition?

n

Vnos	Ustrezna reakcija	Utemeljitev
»Ali to velja tudi v Avstriji?« po jasnem vprašanju o garanciji	Oblikujte samostojno poizvedbo	Predmet in sklic sta jasna.
»Kaj pa z drugo?« po treh navedenih različicah	Postavite kratko razjasnitveno vprašanje	Verjetnih je več razrešitev.
»Primerjaj ceno, rok dostave in vračilo za oba modela«	Razčlenite na usmerjena podvprašanja	Več neodvisnih vidikov potrebuje zanesljive zadetke.
»Nova tema: Kako kontaktiram podporo?«	Iščite brez starega konteksta izdelka	Uporabnik nakazuje spremembo teme.

Razčlenitev poizvedbe (Query Decomposition) torej ni isto kot preoblikovanje poizvedbe (Query Rewriting). Preoblikovanje naredi odvisno vprašanje samostojno; razčlenitev razdeli kompleksno vprašanje na več iskalnih nalog. Bedrockova dokumentacija o Query Decomposition prikazuje, da lahko več podvprašanj izboljša pokritost. Vendar pa vsaka dodatna poizvedba potrebuje omejitev, skupni model dovoljenj in sledljivo združevanje.

Izpise preoblikovanja obravnavajte kot kodo

Čeprav je rezultat le besedilo, mora imeti strogo pogodbo. Smiseln je strukturiran objekt s polji, kot so standaloneQuery, decision, resolvedReferences in reason. Dovoljene odločitve so na primer SEARCH_AS_IS, REWRITE, CLARIFY in DECOMPOSE. Ozadje pred začetkom iskanja preveri dolžino, jezik in dovoljena polja.

Preoblikovalnik ne prejme orodij in ne odgovarja neposredno uporabniku. Sistemska navodila iz zgodovine klepeta, vnesena besedila dokumentov ali pozivi, kot je »Prezri pravila«, ostajajo podatki, ne krmilni ukazi. Za tvegana iskalna območja lahko deterministično pravilo dodatno zagotovi, da filtri izdelkov, lokalizacije ali najemnikov nikoli ne izvirajo iz prostega besedila.

Preverjanje z lastnim testnim naborom za nadaljnja vprašanja

Kakovosti ni mogoče dokazati s posameznimi uspešnimi predstavitvami. Obstoječi Golden Set za kakovost odgovorov dopolnite s pravimi večstopenjskimi pogovori. Za vsak primer se zabeležijo izvirni potek, trenutno vprašanje, pričakovana odločitev o preoblikovanju, dovoljene entitete, prepovedani dodatki in pričakovani viri.

• Zaimki in opuščeni osebki v kratkih nadaljnjih vprašanjih
• Popravki, kot je »Ne, mislil sem model B«
• Sprememba teme in vrnitev na prejšnjo temo
• Večpomenske različice, ki nujno zahtevajo podvprašanje
• Sprememba lokalizacije, datuma in časovnega pasu
• Nedovoljeni poskusi spremembe iskalnega prostora ali najemnika
• Dolgi poteki z nepomembnimi starejšimi podrobnostmi
• Večdelna vprašanja, ki se razčlenijo in znova združijo

Merite ločeno: Ali se preoblikovanje ujema z namenom uporabnika? Ali pridobivanje najde pričakovane vire? Ali je bilo pri pravi večpomenosti postavljeno podvprašanje? Ali so filtri dovoljenj ostali nespremenjeni? Koliko dodatne zakasnitve povzroči ta korak? NIST AI RMF Core uvršča ponavljajoče se testiranje, merjenje in dokumentiranje v celotni življenjski cikel umetne inteligence. Za spletne ekipe to pomeni: pravilo preoblikovanja, model ali izbiro konteksta spreminjajte le z regresijskim testom in sledljivim uvajanjem.

Kratek kontrolni seznam za spletne ekipe

• Ali izvirno uporabniško vprašanje ostane nespremenjeno do odgovora?
• Ali so vključeni le ustrezni deli zgodovine, ki varčujejo s podatki?
• Ali lahko preoblikovalnik jasno izbira med preoblikovanjem, podvprašanjem in razčlenitvijo?
• Ali dopolnjuje izključno potrjene entitete in ne ugibanj?
• Ali ozadje nastavi lokalizacijo, najemnika in dovoljenja neodvisno od preoblikovanja?
• Ali ima vsako podvprašanje določene meje glede količine, časa in stroškov?
• Ali se zadetki pridobivanja ocenjujejo glede na izvirno vprašanje?
• Ali testni nabor z večstopenjskimi pogovori pokriva sklice, popravke in spremembe teme?

Zaključek: Najprej razjasnite iskalno vprašanje, nato odgovorite

RAG Query Rewriting iz naravne pogovorne kratkosti ustvari zanesljivo iskalno poizvedbo. Največja korist ne nastane z čim bolj ustvarjalnimi preoblikovanji, temveč z jasnimi mejami: prevzem potrjenega konteksta, reševanje negotovosti s podvprašanji, ohranjanje dovoljenj na strani strežnika in stalno preverjanje odgovora glede na izvirno vprašanje. Začnite z dvajsetimi tipičnimi nadaljnjimi vprašanji iz vaše podpore, označite pričakovano odločitev in testirajte vsako spremembo glede na iste primere. Tako bo večstopenjski klepet postal bolj razumljiv, ne da bi iskanje tiho odgovorilo na drugo vprašanje.

Viri

• Microsoft Azure Architecture Center: Prompt Engineering za RAG
• Microsoft Learn: Agentic Retrieval v Azure AI Search
• Amazon Bedrock: Konfiguracija poizvedb in generiranja odgovorov
• Amazon Bedrock: Agentic Retrieval za baze znanja
• NIST AI Risk Management Framework Core