RAG Query Rewriting: Pareiza sekojošo jautājumu apstrāde mākslīgā intelekta tērzēšanas robotos

Tāds atsevišķs jautājums kā „Un cik ilgi tas ir spēkā?” cilvēkiem bieži vien ir pilnīgi skaidrs. Viņi atceras iepriekš pārrunāto produktu, atrašanās vietu un domāto termiņu. Turpretī zināšanu meklēšanas sistēma sākotnēji redz tikai dažus vārdus. Bez atbilstoša sarunas konteksta tā var neatrast neko vai arī meklēt nepareizu tēmu. RAG Query Rewriting atrisina šo problēmu, pārveidojot no konteksta atkarīgu sekojošo jautājumu par patstāvīgu meklēšanas vaicājumu pirms meklēšanas veikšanas.

Tas izklausās pēc neliela starpposma, taču bieži vien tieši tas izšķir daudzlīmeņu tīmekļa vietnes tērzēšanas kvalitāti. Šī pamācība parāda, kā komandas apstrādā sekojošos jautājumus, kad labāk uzdot papildu jautājumus un kā novērst to, ka pārfrāzēšana meklēšanā ievada jaunus faktus, nepareizas piekļuves tiesības vai novecojušu kontekstu.

Kāpēc sekojošie jautājumi pārslogo zināšanu meklēšanu

Pirmais lietotāja jautājums parasti ir konkrēts: „Kāda garantija attiecas uz modeli A?”. Tam seko īsas frāzes, piemēram, „Un lielākajam variantam?”, „Vai tas attiecas arī uz Austriju?” vai „Kas man tam nepieciešams?”. Vietniekvārdi, izlaisti teikuma priekšmeti un atsauces uz iepriekšējām atbildēm sarunā ir dabiski. Tomēr kā izolēti meklēšanas vaicājumi tie ir vāji.

Klasiskā atslēgvārdu, vektoru vai Hybrid-Search apstrādes ķēde spēj novērtēt tikai to, ko tā saņem kā vaicājumu. Reranking uzlabo esošo rezultātu secību, bet neaizstāj trūkstošo vārdu „tas” vai „tam” nozīmi. Tāpēc Query Rewriting atrodas pirms tā: tas no pašreizējā jautājuma un relevantās vēstures izveido meklējamu, patstāvīgu vaicājumu.

Kas jānodrošina labai pārfrāzēšanai

Labi pārfrāzēts vaicājums ir pietiekami pilnīgs informācijas ieguvei (Retrieval), taču cieši turas pie lietotāja nodoma. Piemēram, „Un uz Austriju?” var kļūt par „Kādi garantijas noteikumi attiecas uz modeli A Austrijā?”, ja modelis A un garantija tika skaidri noteikti tieši iepriekšējā dialogā. Pārfrāzējums vēl nesniedz atbildi uz jautājumu. Tā vienīgais mērķis ir atrast atbilstošos avotus.

Pašreizējās Azure arhitektūras vadlīnijas par Conversational RAG iesaka iekļaut relevantu sarunu vēsturi un pirms informācijas ieguves noformulēt pašreizējo jautājumu kā patstāvīgu vaicājumu ar atrisinātām atsaucēm. Svarīgs ir arī tur redzamais nošķīrums: vēlākajai atbildei tiek saglabāts sākotnējais lietotāja jautājums. Tādējādi sistēma var pārbaudīt, vai atrastie pierādījumi tiešām atbilst uzdotajam jautājumam.

Papildināt, bet neizdomāt

Pārfrāzētājs (Rewriter) drīkst pārņemt skaidri pieejamu informāciju: produktu, versiju, valsti, valodu vai pēdējo minēto procesu. Tomēr tas nedrīkst pievienot trūkstošu klienta numuru, noteikt pieņemtu produkta variantu vai pārvērst nepareģojamu laika norādi konkrētā datumā. Derīga pēc izskata, bet izdomāta precizēšana droši novirzīs meklēšanu nepareizā virzienā.

Piekļuves tiesības paliek ārpus teksta modeļa

Klients, pieteicies lietotājs, pieejamās dokumentu zonas un lomas tiek noteiktas servera pusē. Tām nav jābūt brīvi formulētiem apgalvojumiem pārfrāzēšanas vaicājumā. Backend sistēma iestata atbilstošos metadatu filtrus atsevišķi un nemaināmi. Ne iepriekšējais tērzēšanas ziņojums, ne modeļa pārfrāzējums nedrīkst atvērt plašāku meklēšanas telpu.

Kontekstam ir nepieciešams pārdomāts limits

Visas tērzēšanas vēstures nosūtīšana pārfrāzētājam bez filtrēšanas reti kad ir labs risinājums. Vecas tēmas var aizēnot pašreizējo jautājumu, personas dati var tikt nevajadzīgi nodoti tālāk, un garas vēstures palielina aizturi un izmaksas. Kā praktisku orientieri Microsoft vadlīnijas min divus līdz piecus pēdējos sarunas raundus un vecāka satura kopsavilkumu. Tas nav universāls ierobežojums, bet gan sākumpunkts pašu testiem.

Kompakts konteksta pakotnes komplekts var sastāvēt no šādiem elementiem:

• nemainīta pašreizējā lietotāja jautājuma,
• dažiem tieši relevantajiem lietotāja un asistenta ziņojumiem,
• jau apstiprinātām subjektu vienībām, piemēram, produkta, procesa vai atrašanās vietas,
• valodas/reģiona (Locale) un laika zonas kā tehniskiem laukiem,
• īslaicīga, pārbaudīta vecāku dialoga daļu kopsavilkuma un
• pārfrāzēšanas noteikumu, zināšanu indeksa un ieguves konfigurācijas versijas.

Faktiskās dokumentu piekļuves tiesības paliek no tā nošķirtas. Tāpat pirms pārfrāzēšanas jāaizvāc nevajadzīgas e-pasta adreses, pasūtījumu numuri vai pilnīgas atbildes. Datus taupoša vēsture papildus atvieglo vēlāku kļūdu meklēšanu.

Uzticama gaita sešos soļos

1. Pārbaudīt patstāvību: Skaidru jaunu jautājumu, piemēram, „Kā nomainīt paroli?”, var sūtīt tieši uz meklēšanu. Ne katram ziņojumam ir nepieciešama modeļa pārfrāzēšana.
2. Atpazīt atsauces: Sistēma atzīmē vietniekvārdus, elipses, salīdzinājuma vārdus un atsauces, piemēram, „tur”, „abi” vai „otrā opcija”.
3. Atlasīt relevantu kontekstu: Tiek pārņemti tikai tie ziņojumi, kas ticami atrisina šīs atsauces. Apzināta tēmas maiņa pabeidz veco kontekstu.
4. Izlemt par pārfrāzēšanu vai precizējošu jautājumu: Ja ir tieši viens drošs atrisinājums, tiek izveidots patstāvīgs meklēšanas vaicājums. Ja ir vairākas ticamas nozīmes, tērzēšanas robots uzdod īsu precizējošu jautājumu.
5. Meklēt un, ja nepieciešams, sadalīt: Vaicājums tiek apstrādāts ar atslēgvārdu, vektoru vai Hybrid Search pagalmu. Daudzdaļīgus jautājumus var sadalīt skaidri nosauktos apakšjautājumos.
6. Atbildēt uz oriģinālo jautājumu: Atbilde tiek ģenerēta no atrastajiem avotiem, attiecas uz sākotnējo formulējumu un atklāti norāda uz nenoteiktību vai trūkstošiem pierādījumiem.

Microsoft pārskatā par Agentic Retrieval ir aprakstīta līdzīga gaita: vaicājums un sarunu vēsture tiek izmantota plānošanā, mērķtiecīgi apakšvaicājumi tiek izpildīti paralēli un atrastie rezultāti pēc tam tiek apvienoti. Amazon Bedrock dokumentācijā arī ir aprakstīta plānošana, iteratīvi apakšvaicājumi un pārbaude, vai atrastais saturs ir pietiekams atbildei. Šādas produktu funkcijas var pārņemt daļu no apstrādes ķēdes; tomēr savas lietojumprogrammas kvalitātes un drošības pārbaudes joprojām ir nepieciešamas.

Rewrite, precizējošs jautājums vai Query Decomposition?

Ievade	Atbilstoša reakcija	Pamatojums
„Un vai tas ir spēkā Austrijā?” pēc skaidra garantijas jautājuma	Noformulēt patstāvīgu vaicājumu	Mērķis un atsauce ir nepārprotami.
„Kā ir ar otru?” pēc trim minētiem variantiem	Uzdot īsu precizējošu jautājumu	Ir ticami vairāki atrisinājumi.
„Salīdzini cenu, piegādes laiku un atgriešanu abiem meklētajiem modeļiem”	Sadalīt mērķtiecīgos apakšvaicājumos	Vairākiem neatkarīgiem aspektiem ir nepieciešami uzticami rezultāti.
„Jauna tēma: Kā sasniegt atbalsta dienestu?”	Meklēt bez vecā produkta konteksta	Lietotājs dod signālu par tēmas maiņu.

Līdz ar to Query Decomposition nav tas pats kas Query Rewriting. Rewriting padara atkarīgu jautājumu par patstāvīgu; Decomposition sadala kompleksu jautājumu vairākos meklēšanas uzdevumos. Bedrock dokumentācija par Query Decomposition parāda, ka vairāki apakšvaicājumi var uzlabot pārklājumu. Tomēr katram papildu vaicājumam ir nepieciešams limits, kopējais piekļuves tiesību modelis un izsekojama apvienošana.

Izturēties pret Rewrite izvadēm kā pret kodu

Pat ja rezultāts ir tikai teksts, tam vajadzētu būt stingrai struktūrai. Lietderīgs ir strukturēts objekts ar tādiem laukiem kā standaloneQuery, decision, resolvedReferences un reason. Atļautie lēmumi ir, piemēram, SEARCH_AS_IS, REWRITE, CLARIFY un DECOMPOSE. Backend sistēma pārbauda garumu, valodu un atļautos laukus pirms meklēšanas sākšanas.

Pārfrāzētājs nesaņem nekādus rīkus un neatbild lietotājam tieši. Sistēmas norādes no tērzēšanas vēstures, ievietotie dokumentu teksti vai aicinājumi, piemēram, „Ignorē noteikumus”, paliek dati, nevis vadības komandas. Riska pilnām meklēšanas zonām deterministisks noteikums papildus var nodrošināt, ka produktu, reģiona vai klientu filtri nekad netiek ņemti no brīvā teksta.

Pārbaudīt ar savu sekojošo jautājumu testa kopu

Kvalitāti nevar pierādīt ar atsevišķiem veiksmīgiem paraugdemostrācijām. Papildiniet esošo atbilžu kvalitātes Golden Set ar reāliem vairāku posmu dialogiem. Katram gadījumam tiek fiksēta sākotnējā vēsture, pašreizējais jautājums, paredzamais Rewrite lēmums, atļautās subjektu vienības, aizliegtie papildinājumi un paredzamie avoti.

• Vietniekvārdi un izlaisti teikuma priekšmeti īsos sekojošos jautājumos
• Labojumi, piemēram, „Nē, es domāju modeli B”
• Tēmas maiņa un atgriešanās pie iepriekšējās tēmas
• Daudznozīmīgi varianti, kuriem obligāti nepieciešams precizējošs jautājums
• Reģiona, datuma un laika zonas maiņa
• Neatļauti mēģinājumi mainīt meklēšanas telpu vai klientu
• Garas vēstures ar nerelevantām vecākām detaļām
• Daudzdaļīgi jautājumi, kas tiek sadalīti un atkal apvienoti

Mēriet atsevišķi: Vai pārfrāzējums atbilst lietotāja nodomam? Vai meklēšana atrod paredzētos avotus? Vai patiesas daudznozīmības gadījumā tika uzdots precizējošs jautājums? Vai piekļuves tiesību filtri palika nemainīti? Cik daudz papildu aiztures rada šis solis? NIST AI RMF Core ierindo atkārtotu testēšanu, mērīšanu un dokumentēšanu visā MI dzīves ciklā. Tīmekļa vietņu komandām tas nozīmē: mainīt pārfrāzēšanas noteikumu, modeli vai konteksta atlasi tikai ar regresijas testu un novērojamu ieviešanu.

Kompakta kontrolsaraksts tīmekļa vietņu komandām

• Vai sākotnējais lietotāja jautājums paliek nemainīts līdz atbildes sniegšanai?
• Vai tiek iekļautas tikai relevantas un datus taupošas vēstures daļas?
• Vai pārfrāzētājs spēj skaidri izvēlēties starp pārfrāzēšanu, precizējošu jautājumu un sadalīšanu?
• Vai tas papildina tikai apstiprinātas subjektu vienības un nevis pieņēmumus?
• Vai backend sistēma iestata reģionu, klientu un piekļuves tiesības neatkarīgi no Rewrite?
• Vai katram apakšvaicājumam ir fiksēti apjoma, laika un izmaksu limiti?
• Vai meklēšanas rezultāti tiek vērtēti pret oriģinālo jautājumu?
• Vai vairāku dialogu testa kopa pārklāj atsauces, labojumus un tēmu maiņu?

Secinājums: Vispirms noskaidrot meklēšanas jautājumu, tad atbildēt

RAG Query Rewriting padara dabisko sarunas īsumu par uzticamu meklēšanas vaicājumu. Lielākais ieguvums rodas nevis no iespējami radošām pārfrāzēm, bet gan no skaidrām robežām: pārņemt apstiprināto kontekstu, risināt nenoteiktību ar precizējošu jautājumu, saglabāt piekļuves tiesības servera pusē un joprojām pārbaudīt atbildi pret oriģinālo jautājumu. Sāciet ar divdesmit tipiskiem sekojošiem jautājumiem no jūsu atbalsta dienesta, atzīmējiet paredzēto lēmumu un testējiet katru izmaiņu pret šiem pašiem gadījumiem. Tādējādi daudzlīmeņu tērzēšana kļūst saprotamāka, meklēšanai klusējot neatbildot uz citu jautājumu.

Avoti

• Microsoft Azure Architecture Center: Prompt Engineering priekš RAG
• Microsoft Learn: Agentic Retrieval iekš Azure AI Search
• Amazon Bedrock: Vaicājumu un atbilžu ģenerēšanas konfigurēšana
• Amazon Bedrock: Agentic Retrieval zināšanu bāzēm
• NIST AI Risk Management Framework Core