RAG Query Rewriting: Cum să rezolvi corect întrebările de urmărire pentru chatbot-urile AI

O întrebare izolată precum „Și cât timp este valabil?” este adesea clară pentru oameni. Ei își amintesc produsul discutat anterior, locația și termenul la care se face referire. În schimb, un sistem de căutare de informații vede inițial doar câteva cuvinte. Fără contextul de conversație potrivit, s-ar putea să nu găsească nimic sau să caute un subiect greșit. RAG Query Rewriting rezolvă această problemă prin transformarea unei întrebări de urmărire dependente de context într-o interogare de căutare autonomă, înainte de a efectua căutarea.

Acest lucru sună ca un pas intermediar minor, dar decide frecvent calitatea unui chat de pe un site web derulat în mai mulți pași. Acest ghid arată cum pot echipele să rezolve întrebările de urmărire, când este mai bine să ceară clarificări și cum să prevină situațiile în care o reformulare introduce fapte noi, permisiuni incorecte sau un context învechit în căutare.

De ce întrebările de urmărire suprasolicită o căutare de informații

Prima întrebare a utilizatorului este de obicei concretă: „Ce garanție se aplică pentru modelul A?”. Apoi urmează formulări scurte precum „Și pentru varianta mai mare?”, „Este valabil și în Austria?” sau „De ce am nevoie pentru asta?”. Pronumele, subiectele omise și referințele la răspunsurile anterioare sunt naturale într-o conversație. Totuși, ca interogări de căutare izolate, ele sunt slabe.

Un flux clasic de căutare bazat pe cuvinte cheie, vectori sau Hybrid Search poate evalua doar ceea ce primește ca interogare. Reranking-ul îmbunătățește ordinea rezultatelor existente, dar nu înlocuiește sensul lipsă al cuvintelor „asta” sau „pentru asta”. De aceea, Query Rewriting se plasează înaintea acestui proces: el transformă întrebarea curentă și istoricul relevant într-o interogare autonomă, ușor de căutat.

Ce trebuie să ofere o reformulare bună

O interogare reformulată cu succes este suficient de completă pentru căutare (retrieval), dar rămâne strâns legată de intenția utilizatorului. De exemplu, „Și pentru Austria?” se poate transforma în „Ce condiții de garanție se aplică pentru modelul A în Austria?”, dacă modelul A și garanția au fost stabilite clar în dialogul imediat anterior. Reformularea nu răspunde încă la întrebare. Ea servește exclusiv la găsirea surselor potrivite.

Ghidul actual de arhitectură Azure privind Conversational RAG recomandă includerea istoricului de conversație relevant și formularea întrebării curente înainte de căutare ca o interogare autonomă, cu referințele rezolvate. Este importantă separarea vizibilă menționată acolo: pentru răspunsul final se păstrează întrebarea originală a utilizatorului. Astfel, sistemul poate verifica dacă sursele găsite se potrivesc într-adevăr cu întrebarea adresată.

A completa, dar fără a inventa

Un modul de reformulare (rewriter) poate prelua informații existente în mod neechivoc: produsul, versiunea, țara, limba sau procesul menționat cel mai recent. Cu toate acestea, nu trebuie să adauge un cod de client lipsă, să stabilească o variantă de produs presupusă sau să transforme o mențiune de timp incertă într-o dată concretă. O precizare care sună util, dar este inventată, va trimite în mod sigur căutarea într-o direcție greșită.

Permisiunile rămân în afara modelului de text

Tenant-ul, utilizatorul autentificat, secțiunile de documente aprobate și rolurile sunt determinate la nivel de server. Ele nu trebuie să fie incluse ca afirmații liber formulate în interogarea reformulată. Backend-ul aplică filtrele de metadate corespunzătoare în mod separat și imutabil. Nici o intervenție anterioară în chat, nici o reformulare a modelului nu trebuie să deblocheze un spațiu de căutare mai extins.

Contextul are nevoie de un buget bine definit

Trimiterea întregului istoric de chat nefiltrat către modulul de reformulare este rareori o soluție bună. Subiectele vechi pot acoperi întrebarea curentă, conținutul cu caracter personal poate fi transmis inutil, iar istoricele lungi cresc latența și costurile. Ca orientare practică, ghidul Microsoft menționează două până la cinci secvențe de dialog recente și un rezumat al conținutului mai vechi. Aceasta nu este o limită universală, ci un punct de plecare pentru propriile teste.

Un pachet compact de context poate fi format din următoarele componente:

• întrebarea curentă a utilizatorului, nemodificată,
• câteva intervenții ale utilizatorului și ale asistentului cu relevanță directă,
• entități deja confirmate, cum ar fi produsul, procesul sau locația,
• setările regionale (locale) și fusul orar ca câmpuri tehnice,
• un rezumat temporar și verificat al părților mai vechi din dialog și
• versiunea regulii de reformulare, a indexului de cunoștințe și a configurației de căutare.

Permisiunile efective asupra documentelor rămân separate de acestea. De asemenea, adresele de e-mail, numerele de comandă sau răspunsurile complete care nu sunt necesare ar trebui eliminate înainte de reformulare. Un istoric eficient din punct de vedere al datelor facilitează, de asemenea, depanarea ulterioară.

Un flux robust în șase pași

1. Verificarea autonomiei: O întrebare nouă și clară, precum „Cum îmi schimb parola?”, poate merge direct la căutare. Nu fiecare mesaj necesită o reformulare prin model.
2. Identificarea referințelor: Sistemul marchează pronumele, elipsele, cuvintele de comparație și referințele precum „acolo”, „ambele” sau „a doua opțiune”.
3. Selectarea contextului relevant: Sunt preluate doar mesajele care rezolvă plauzibil aceste referințe. O schimbare intenționată de subiect încheie contextul vechi.
4. Decizia între reformulare sau clarificare: Dacă există o singură rezolvare sigură, se generează o interogare de căutare autonomă. Dacă există mai multe sensuri plauzibile, chatbot-ul adresează o scurtă întrebare de clarificare.
5. Căutarea și, dacă este cazul, descompunerea: Interogarea trece prin căutare după cuvinte cheie, vectorială sau Hybrid Search. Întrebările complexe pot fi descompuse în sub-întrebări clar definite.
6. Răspunsul raportat la întrebarea originală: Răspunsul este generat din sursele găsite, se referă la formularea inițială și menționează deschis incertitudinile sau lipsa dovezilor.

Prezentarea generală Microsoft privind Agentic Retrieval descrie un proces similar: interogarea și istoricul conversației sunt incluse în planificare, sub-interogările focalizate sunt executate în paralel, iar rezultatele sunt ulterior îmbinate. Documentația Amazon Bedrock descrie, de asemenea, planificarea, sub-interogările iterative și verificarea dacă conținutul găsit este suficient pentru un răspuns. Astfel de funcționalități de produs pot prelua părți din flux; totuși, filtrele de calitate și securitate ale propriei aplicații rămân necesare.

Reformulare, întrebare de clarificare sau Query Decomposition?

n

Introducere	Reacție potrivită	Justificare
„Și este valabil în Austria?” după o întrebare clară despre garanție	Formularea unei interogări autonome	Obiectul și referința sunt clare.
„Cum rămâne cu cealaltă?” după menționarea a trei variante	Adresarea unei scurte întrebări de clarificare	Sunt plauzibile mai multe interpretări.
„Compară prețul, timpul de livrare și returnarea pentru ambele modele”	Descompunerea în sub-interogări focalizate	Mai multe aspecte independente necesită rezultate solide.
„Subiect nou: Cum pot contacta suportul?”	Căutare fără contextul vechi de produs	Utilizatorul semnalează o Schimbare de subiect.

Prin urmare, Query Decomposition nu este același lucru cu Query Rewriting. Rewriting-ul face ca o întrebare dependentă să devină autonomă; Decomposition împarte o întrebare complexă în mai multe sarcini de căutare. Documentația Bedrock privind Query Decomposition arată că mai multe sub-interogări pot îmbunătăți acoperirea. Totuși, fiecare interogare suplimentară necesită o limită, un model de permisiuni comun și o îmbinare transparentă.

Tratarea rezultatelor de reformulare ca pe un cod

Chiar dacă rezultatul este doar text, acesta ar trebui să aibă o structură strictă. Este util un obiect structurat cu câmpuri precum standaloneQuery, decision, resolvedReferences și reason. Deciziile permise pot fi, de exemplu, SEARCH_AS_IS, REWRITE, CLARIFY și DECOMPOSE. Backend-ul validează lungimea, limba și câmpurile permise înainte de a începe o căutare.

Modulul de reformulare nu primește instrumente și nu răspunde direct utilizatorului. Instrucțiunile de sistem din istoricul de chat, textele din documentele inserate sau solicitările de tipul „Ignoră regulile” rămân date, nu comenzi de control. Pentru spațiile de căutare cu risc ridicat, o regulă deterministă poate impune suplimentar ca filtrele de produs, de regiune sau de tenant să nu provină niciodată din text liber.

Verificarea cu un set de teste propriu pentru întrebări de urmărire

Calitatea nu poate fi demonstrată prin câteva demonstrații reușite. Completați Golden Set-ul existent pentru calitatea răspunsurilor cu dialoguri multiple reale. Pentru fiecare caz, se înregistrează istoricul inițial, întrebarea curentă, decizia de reformulare așteptată, entitățile permise, completările interzise și sursele așteptate.

• Pronume și subiecte omise în întrebări scurte de urmărire
• Corecții precum „Nu, mă refeream la modelul B”
• Schimbări de subiect și revenirea la un subiect anterior
• Variante ambigue care necesită neapărat o clarificare
• Schimbări de setări regionale, dată și fus orar
• Încercări nepermise de a schimba spațiul de căutare sau tenant-ul
• Historice lungi cu detalii vechi irelevante
• Întrebări complexe care sunt descompuse și apoi reasamblate

Măsurați separat: Reformularea corespunde intenției utilizatorului? Căutarea găsește sursele așteptate? S-a cerut o clarificare în caz de ambiguitate reală? Filtrele de permisiuni au rămas nemodificate? Câtă latență suplimentară cauzează acest pas? Cadrul NIST AI RMF Core integrează testarea, măsurarea și documentarea repetată în întregul ciclu de viață al AI. Pentru echipele care administrează site-uri web, acest lucru înseamnă: modificați regula de reformulare, modelul sau selecția contextului doar cu teste de regresie și o lansare monitorizată.

Lista de verificare compactă pentru echipele web

• Întrebarea inițială a utilizatorului rămâne nemodificată până la generarea răspunsului?
• Sunt incluse doar părți relevante și esențiale din istoric?
• Modulul de reformulare poate alege clar între reformulare, clarificare și descompunere?
• Adaugă exclusiv entități confirmate și nicio presupunere?
• Backend-ul setează limba/regiunea, tenant-ul și permisiunile independent de reformulare?
• Fiecare sub-interogare are limite fixe de cantitate, timp și cost?
• Rezultatele căutării sunt evaluate în raport cu întrebarea inițială?
• Setul de teste pentru dialoguri include referințe, corecții și schimbări de subiect?

Concluzie: Mai întâi clarificați interogarea, apoi răspundeți

RAG Query Rewriting transformă formulările scurte și naturale dintr-o conversație într-o interogare de căutare de încredere. Cel mai mare beneficiu nu provine din reformulări cât mai creative, ci din limite clare: preluarea contextului confirmat, rezolvarea incertitudinilor prin clarificări, menținerea permisiunilor pe server și verificarea răspunsului în raport cu întrebarea originală. Începeți cu douăzeci de întrebări de urmărire tipice din serviciul dvs. de suport, marcați decizia așteptată și testați fiecare modificare folosind aceleași cazuri. Astfel, un chat derulat în mai mulți pași devine mai ușor de înțeles, fără ca sistemul de căutare să răspundă tacit la o altă întrebare.

Surse

• Microsoft Azure Architecture Center: Prompt Engineering pentru RAG
• Microsoft Learn: Agentic Retrieval în Azure AI Search
• Amazon Bedrock: Configurarea interogărilor și generarea răspunsurilor
• Amazon Bedrock: Agentic Retrieval pentru baze de cunoștințe
• NIST AI Risk Management Framework Core