RAG Query Rewriting: gestire e risolvere correttamente le domande di seguito nei chatbot AI

Una singola domanda come "E fino a quando vale?" è spesso chiarissima per le persone, che ricordano il prodotto citato prima, la sede e la scadenza intesa. Un motore di ricerca di conoscenza, al contrario, all'inizio vede solo poche parole. Senza il contesto di conversazione adeguato rischia di non trovare nulla o di cercare l'argomento sbagliato. Il RAG Query Rewriting risolve questo problema trasformando una domanda di seguito dipendente dal contesto in una query di ricerca autonoma prima di eseguire il retrieval.

Sembra un piccolo passaggio intermedio, ma spesso determina la qualità di un chat per siti web a più turni. Questa guida mostra come i team possono risolvere le domande di seguito, quando è meglio chiedere chiarimenti e come evitare che una riscrittura introduca nuovi fatti, autorizzazioni errate o contesti obsoleti nella ricerca.

Perché le domande di seguito mettono in crisi la ricerca di conoscenza

La prima domanda dell'utente è solitamente concreta: "Quale garanzia vale per il Modello A?". Dopodiché seguono brevi espressioni come "E per la variante più grande?", "Vale anche in Italia?" o "Di cosa ho bisogno per questo?". Pronomi, soggetti sottintesi e riferimenti alle risposte precedenti sono naturali in una conversazione, ma come query di ricerca isolate risultano estremamente deboli.

Una classica pipeline di ricerca basata su parole chiave, vettori o Hybrid Search può valutare solo ciò che riceve come input. Il reranking migliora l'ordine dei risultati esistenti, ma non sostituisce il significato mancante di "questo" o "per questo". Il query rewriting si posiziona prima di questo processo: trasforma la domanda attuale e la cronologia rilevante in una query di ricerca autonoma ed efficace.

Cosa deve fare una buona riscrittura

Una riscrittura ben riuscita è abbastanza completa per il retrieval, ma rimane strettamente fedele all'intenzione dell'utente. Da "E per l'Italia?" può diventare ad esempio "Quali condizioni di garanzia valgono per il Modello A in Italia?", se il Modello A e la garanzia sono stati definiti in modo chiaro nel dialogo immediatamente precedente. La riscrittura non risponde ancora alla domanda: serve esclusivamente a trovare le fonti adeguate.

Le attuali linee guida sull'architettura Azure per il Conversational RAG raccomandano di includere la cronologia di conversazione rilevante e di formulare la domanda attuale come query autonoma con i riferimenti risolti prima del retrieval. È importante anche la separazione evidenziata in tale documentazione: per la risposta finale viene mantenuta la domanda originale dell'utente. In questo modo il sistema può verificare se i documenti trovati corrispondono effettivamente al quesito posto.

Completare, ma non inventare

Un rewriter può riprendere informazioni chiaramente presenti: prodotto, versione, paese, lingua o l'ultima operazione menzionata. Non deve però aggiungere un codice cliente mancante, definire una variante di prodotto ipotizzata o trasformare un'indicazione temporale incerta in una data concreta. Una precisazione apparentemente utile ma inventata orienterà inevitabilmente la ricerca nella direzione sbagliata.

Le autorizzazioni rimangono fuori dal modello di testo

Tenant, utente autenticato, sezioni di documenti autorizzate e ruoli vengono stabiliti lato server. Non devono essere inseriti nella query di riscrittura come affermazioni liberamente formulabili. Il backend applica i relativi filtri di metadati in modo separato e inalterabile. Né un precedente messaggio di chat né una riscrittura del modello devono mai sbloccare uno spazio di ricerca più ampio.

Il contesto richiede un budget ben definito

Inviare l'intera cronologia di chat senza filtri al rewriter è raramente una buona idea. I vecchi argomenti possono sovrapporsi alla domanda attuale, i dati personali rischiano di essere trasmessi inutilmente e le conversazioni lunghe aumentano la latenza e i costi. Come guida pratica, le linee guida Microsoft suggeriscono da due a cinque turni di conversazione recenti e un riassunto dei contenuti precedenti. Non si tratta di un limite universale, ma di un punto di partenza per i propri test.

Un pacchetto di contesto compatto può essere composto dai seguenti elementi:

• la domanda attuale dell'utente non modificata,
• pochi messaggi dell'utente e dell'assistente direttamente rilevanti,
• entità già confermate come prodotto, procedura o sede,
• locale e fuso orario come campi tecnici,
• un riassunto temporaneo e verificato delle parti di dialogo meno recenti e
• la versione delle regole di riscrittura, dell'indice di conoscenza e della configurazione di retrieval.

Le autorizzazioni effettive sui documenti rimangono separate da questo pacchetto. Allo stesso modo, indirizzi e-mail non necessari, numeri d'ordine o risposte complete dovrebbero essere rimossi prima della riscrittura. Una cronologia essenziale sui dati facilita inoltre la successiva risoluzione dei problemi.

Un processo robusto in sei passaggi

1. Verificare l'autonomia: Una domanda chiara e nuova come "Come cambio la mia password?" può andare direttamente alla ricerca. Non ogni messaggio richiede una riscrittura via modello.
2. Riconoscere i riferimenti: Il sistema individua pronomi, ellissi, parole di confronto e riferimenti come "lì", "entrambi" o "la seconda opzione".
3. Selezionare il contesto rilevante: Vengono ripresi solo i messaggi che risolvono tali riferimenti in modo plausibile. Un cambio di argomento esplicito chiude il vecchio contesto.
4. Decidere tra riscrittura o chiarimento: Se esiste esattamente una risoluzione solida, si crea una query di ricerca autonoma. Se ci sono più significati plausibili, il chatbot pone una breve domanda di chiarimento.
5. Cercare ed eventualmente scomporre: La query passa attraverso la ricerca per parole chiave, vettoriale o Hybrid Search. Le domande complesse possono essere suddivise in sotto-query ben definite.
6. Rispondere rispetto alla domanda originale: La risposta viene generata dalle fonti trovate, si riferisce al testo originale e dichiara apertamente eventuali incertezze o fonti mancanti.

La panoramica sull'Agentic Retrieval di Microsoft descrive un processo simile: query e cronologia di conversazione confluiscono nella pianificazione, sotto-query mirate vengono eseguite in parallelo e i risultati vengono poi unificati. Anche la documentazione di Amazon Bedrock riporta pianificazione, sotto-query iterative e la verifica che i contenuti trovati siano sufficienti per una risposta. Tali funzionalità di prodotto possono gestire parti della pipeline; ciononostante, i controlli di qualità e sicurezza dell'applicazione rimangono indispensabili.

Riscrittura, domanda di chiarimento o Query Decomposition?

Input	Reazione adeguata	Motivazione
"E questo vale anche in Italia?" dopo una domanda chiara sulla garanzia	Formulare una query autonoma	L'oggetto e il riferimento sono inequivocabili.
"E la seconda?" dopo aver menzionato tre varianti	Porre una breve domanda di chiarimento	Sono possibili più interpretazioni plausibili.
"Confronta prezzo, tempi di consegna e reso per entrambi i modelli"	Scomporre in sotto-query mirate	Più aspetti indipendenti richiedono riscontri mirati.
"Nuovo argomento: Come posso contattare il supporto?"	Cercare senza il vecchio contesto prodotto	L'utente segnala un cambio di argomento.

La Query Decomposition non coincide quindi con il Query Rewriting. Il rewriting rende autonoma una domanda dipendente; la decomposition suddivide una domanda complessa in più compiti di ricerca. La documentazione Bedrock sulla Query Decomposition mostra che più sotto-query possono migliorare la copertura. Tuttavia, ogni query aggiuntiva richiede un limite, un modello di autorizzazione comune e una sintesi tracciabile.

Trattare gli output del rewriting come codice

Anche se il risultato è solo testo, deve rispettare una struttura ben definita. È consigliabile utilizzare un oggetto strutturato con campi come standaloneQuery, decision, resolvedReferences e reason. Le decisioni valide possono essere ad esempio SEARCH_AS_IS, REWRITE, CLARIFY e DECOMPOSE. Il backend valida lunghezza, lingua e campi consentiti prima dell'avvio della ricerca.

Il rewriter non riceve strumenti e non risponde direttamente all'utente. Le istruzioni di sistema nella cronologia di chat, i testi dei documenti inseriti o le richieste come "Ignora le regole" rimangono dati, non comandi di controllo. Per gli spazi di ricerca critici, una regola deterministica può anche garantire che i filtri di prodotto, locale o tenant non provengano mai da testo libero.

Testare con un set di test dedicato alle domande di seguito

La qualità non si dimostra con singole demo ben riuscite. Arricchite il vostro Golden Set per la qualità delle risposte con dialoghi a più turni reali. Per ciascun caso vanno registrati la cronologia originale, la domanda attuale, la decisione di riscrittura attesa, le entità consentite, le aggiunte vietate e le fonti previste.

• Pronomi e soggetti sottintesi nelle brevi domande di seguito
• Correzioni come "No, intendevo il Modello B"
• Cambi di argomento e ritorno a un tema precedente
• Varianti ambigue che richiedono necessariamente un chiarimento
• Cambi di locale, data e fuso orario
• Tentativi non autorizzati di modificare lo spazio di ricerca o il tenant
• Cronologie lunghe con dettagli datati e irrilevanti
• Domande articolate da scomporre e poi riunificare

Misurate in modo separato: la riscrittura corrisponde all'intenzione dell'utente? Il retrieval individua le fonti attese? In caso di reale ambiguità è stato chiesto un chiarimento? I filtri di autorizzazione sono rimasti inalterati? Quanta latenza aggiuntiva comporta questo passaggio? Il NIST AI RMF Core inserisce il test continuo, la misurazione e la documentazione nell'intero ciclo di vita dell'IA. Per i team che gestiscono siti web questo significa: modificare le regole di riscrittura, il modello o la selezione del contesto solo previo test di regressione e rollout monitorato.

Checklist sintetica per i team di siti web

• La domanda originale dell'utente rimane inalterata fino alla generazione della risposta?
• Vengono incluse solo parti della cronologia rilevanti e minime nei dati?
• Il rewriter può scegliere chiaramente tra riscrittura, domanda di chiarimento e scomposizione?
• Aggiunge esclusivamente entità confermate evitando qualsiasi supposizione?
• Il backend imposta locale, tenant e autorizzazioni in modo indipendente dal rewriting?
• Ogni sotto-query ha limiti fissi di quantità, tempo e costi?
• I risultati del retrieval vengono valutati rispetto alla domanda originale?
• Il test set per dialoghi a più turni copre riferimenti, correzioni e cambi di argomento?

Conclusione: prima chiarire la query di ricerca, poi rispondere

Il RAG Query Rewriting trasforma la naturale brevità di una conversazione in una query di ricerca solida. Il valore maggiore non deriva da riscritture estremamente creative, ma da confini precisi: mantenere il contesto confermato, risolvere le incertezze con domande di chiarimento, gestire le autorizzazioni lato server e verificare la risposta sempre rispetto alla domanda originale. Iniziate con venti tipiche domande di seguito estratte dal vostro supporto clienti, definite la decisione attesa e testate ogni modifica rispetto agli stessi casi. In questo modo una chat a più turni diventa più precisa e affidabile, senza che il sistema risponda silenziosamente a un quesito diverso.

Fonti

• Microsoft Azure Architecture Center: Prompt Engineering per RAG
• Microsoft Learn: Agentic Retrieval in Azure AI Search
• Amazon Bedrock: Configurare query e generazione di risposte
• Amazon Bedrock: Agentic Retrieval per base di conoscenza
• NIST AI Risk Management Framework Core