RAG basato su evidenze: come decidere cosa rispondere, cosa citare e quando astenersi

Recuperare un passaggio non dimostra una risposta

In un sistema di generazione aumentata dal recupero, o RAG, il risultato non dipende soltanto dal fatto che il motore di ricerca trovi documenti correlati alla richiesta. Dipende anche da come la risposta finale usa quei documenti. Un passaggio può trattare lo stesso argomento senza rispondere alla domanda; più passaggi pertinenti possono lasciare irrisolta una parte importante; e un riferimento può essere autentico senza supportare l’affermazione a cui è associato.

Perciò, la domanda di progettazione non dovrebbe essere soltanto «il sistema ha trovato dei documenti?», ma «quali affermazioni sono consentite dalle evidenze recuperate?». La differenza può sembrare minima, ma cambia il modo in cui si costruiscono le risposte, si testa il sistema e si analizzano i malfunzionamenti. L’obiettivo non è costringere il sistema a rispondere a ogni richiesta: è fare in modo che risponda quando i passaggi sono sufficienti e scelga un esito controllato quando non lo sono.

Questa guida si concentra su tale decisione finale. Non tratta la manutenzione o il versionamento del corpus, la migrazione degli embedding né la valutazione di agenti per la ricerca sul Web. E non propone che un punteggio automatico certifichi la veridicità di una risposta. Propone invece un metodo operativo per esaminare il rapporto tra richiesta, evidenze e affermazioni, e individuare i casi in cui questo rapporto si interrompe.

Definisci un contratto delle evidenze prima di valutare

Un contratto delle evidenze descrive i requisiti che una risposta deve soddisfare per essere considerata accettabile in uno specifico prodotto. Non è una promessa di accuratezza assoluta né un’istruzione generica come «usa le fonti». Deve precisare quali fonti il sistema può utilizzare, che cosa si considera un supporto sufficiente, quali riferimenti deve restituire e come deve comportarsi quando le evidenze non bastano.

Inizia classificando le richieste che prevedi di ricevere. Una domanda su una data, una procedura interna, un confronto o una raccomandazione può richiedere tipi diversi di supporto. Per una semplice domanda fattuale potrebbe bastare un passaggio diretto e applicabile. Un confronto potrebbe richiedere dati su entrambi gli elementi. Per una domanda articolata, ogni parte deve essere supportata oppure indicata come irrisolta. È una scelta di prodotto: le fonti disponibili non stabiliscono una soglia universale di sufficienza.

Specifica anche quali fonti sono ammissibili. Per esempio, un assistente interno potrebbe essere limitato ai documenti autorizzati nell’ambiente di lavoro; un prodotto basato su documentazione pubblica potrebbe consentire un insieme selezionato di pubblicazioni. Non mescolare senza spiegazioni una fonte ammessa con una che il prodotto non dovrebbe usare. Se due fonti ammissibili sono in disaccordo, stabilisci se il sistema deve rendere visibile il conflitto, applicare una regola di precedenza approvata oppure astenersi. Non consentirgli di inventare una soluzione.

Infine, definisci quali informazioni servono a una persona per controllare un riferimento: un’identità stabile del documento e una posizione rintracciabile, come una sezione o un passaggio. La forma tecnica specifica dipenderà dal sistema. L’importante è che il riferimento non sia un’etichetta decorativa e che una persona possa verificare il contenuto citato senza dover indovinare dove si trovi.

Separa le affermazioni dai relativi riferimenti

Una risposta può combinare diverse affermazioni: un fatto, una condizione, una data e una conclusione. Se tutte rimandano a un unico elenco di riferimenti alla fine, diventa difficile capire quale fonte supporti ciascuna di esse. È utile progettare l’output in modo che una persona possa esaminare separatamente le affermazioni verificabili e i passaggi che il sistema associa loro.

Non è necessario imporre un unico formato visivo. Si può usare un testo con i riferimenti accanto a ogni affermazione, un elenco strutturato di affermazioni e fonti oppure una risposta breve accompagnata da estratti consultabili. Qualunque sia il formato, deve mantenere chiaro il legame tra affermazione e supporto. Evita di associare un’unica citazione a frasi che contengono fatti diversi, se il passaggio ne supporta soltanto una parte.

È importante distinguere tra un riferimento corretto e una risposta fedele alle evidenze. Un documento può essere pertinente e autentico, ma la risposta può attribuirgli qualcosa che non dice oppure basarsi su conoscenze estranee al passaggio. Un lavoro di ricerca sulle attribuzioni nel RAG tratta proprio la differenza tra correttezza della citazione e fedeltà nell’uso delle evidenze, compreso il problema di aggiungere citazioni a posteriori, dopo aver scritto la risposta. In pratica, la revisione deve confrontare l’affermazione con il testo, non limitarsi a verificare che il documento esista.

Per le risposte più lunghe, valuta la possibilità di suddividere il testo in unità verificabili. Per ogni unità fattuale, registra se il supporto è diretto, parziale, contraddittorio oppure insufficiente. È una raccomandazione progettuale, non la garanzia che il modello classifichi sempre correttamente le evidenze. Il vantaggio di questa separazione è che rende visibili i problemi e permette di correggerli con esempi concreti.

Testa separatamente recupero, supporto e decisione

Una valutazione utile non riduce l’intero processo a un solo punteggio complessivo. Se la risposta non funziona, bisogna poter distinguere se il passaggio necessario non è stato recuperato, se è stato recuperato ma interpretato male, se il riferimento non è consultabile oppure se il sistema avrebbe dovuto astenersi. La documentazione di Microsoft sui valutatori RAG descrive dimensioni distinte per esaminare il recupero e aspetti della risposta come fondamento, pertinenza e completezza. Anche un framework di valutazione RAG pubblicato con il nome RAGAS separa dimensioni quali pertinenza del contesto, fedeltà della risposta e pertinenza della risposta.

Per un primo insieme di test non serve iniziare con una batteria enorme. Raccogli domande che rappresentino l’uso reale e, per ciascuna, prepara una risposta attesa in termini di evidenze: quale parte dovrebbe essere risolta, quale passaggio sarebbe sufficiente e quale esito dovrebbe essere prodotto se quel passaggio non compare. Una persona dovrebbe verificare il materiale di riferimento e i criteri; altrimenti l’insieme di test potrebbe misurare con precisione un’interpretazione sbagliata.

Registra i risultati per fase. Per ogni domanda, annota quali documenti e passaggi sono stati recuperati, quali affermazioni ha prodotto il sistema, quali riferimenti ha allegato e quale decisione ha preso. Distingui almeno tra recupero insufficiente, passaggio irrilevante, evidenze parziali, affermazione non supportata, riferimento non rintracciabile, contraddizione non segnalata e astensione inappropriata. Sono categorie diagnostiche proposte: adattane i nomi al prodotto, ma mantieni la possibilità di individuare il punto in cui si verifica il problema.

Non interpretare un punteggio aggregato come una certificazione di verità. Un buon risultato di pertinenza non dimostra che tutte le affermazioni siano supportate; una risposta ben fondata può essere incompleta; e un riferimento verificabile non prova che la conclusione sia corretta. Le misure automatiche aiutano a individuare schemi e a dare priorità alle revisioni, ma i casi limite e gli errori ad alto impatto richiedono un esame umano commisurato al rischio del prodotto.

Includi casi difficili, non solo domande a cui si può rispondere

Un insieme di test formato soltanto da domande la cui risposta compare letteralmente in un documento non verifica se il sistema sa fermarsi. Includi deliberatamente richieste senza risposta nel corpus, richieste ambigue, domande a cui si può rispondere solo in parte e passaggi che condividono termini con la richiesta ma non contengono l’informazione cercata. Questi casi rivelano se il modello confonde la somiglianza tematica con la prova.

Quando la risposta è assente, verifica se il sistema riconosce i limiti del materiale disponibile senza affermare che il fatto non esista nel mondo. «Non trovo supporto sufficiente nei documenti disponibili» è diverso da «non esiste». Per le ambiguità, stabilisci se una domanda di chiarimento può risolvere una differenza importante, come un periodo, una regione o una definizione. Nel caso di una risposta parziale, conserva ciò che è supportato e delimita esplicitamente ciò che non lo è.

Le evidenze contraddittorie meritano un test specifico. Recupera due documenti ammissibili che affermano cose incompatibili e osserva se la risposta presenta una versione come indiscutibile, combina le due in modo incoerente oppure segnala la discrepanza. Se esiste una regola approvata per stabilire validità o priorità, verifica che il sistema la applichi solo quando le evidenze lo consentono. Se non esiste, la scelta prudente è descrivere il conflitto o astenersi dal risolverlo.

Metti alla prova anche i falsi indizi: documenti che menzionano le stesse entità o gli stessi concetti, ma non rispondono alla domanda. Non basta verificare che il sistema abbia recuperato qualcosa di correlato; controlla se le affermazioni derivano davvero da quel contenuto. Lo scopo di questi casi non è punire il sistema perché non indovina, ma verificare che sappia distinguere un indizio tematico da un supporto sufficiente.

Verifica ogni citazione rispetto all’affermazione specifica

La verifica delle citazioni può essere organizzata in una breve sequenza. Per prima cosa, controlla che il riferimento punti a una fonte ammissibile e che il documento esista nell’ambiente in cui verrà usato. Poi verifica che la posizione indicata permetta di trovare il passaggio. Confronta quindi il testo del passaggio con l’affermazione esatta: la supporta direttamente, fornisce solo contesto, la contraddice oppure non tratta quel punto? Infine, controlla se la risposta ha aggiunto condizioni, rapporti causali o considerazioni sull’ambito che la fonte non contiene.

La verifica deve riguardare l’affermazione specifica. Il fatto che un documento sia generalmente affidabile non significa che supporti qualsiasi affermazione a esso attribuita. Analogamente, una risposta può sembrare ragionevole e avere un riferimento pertinente senza che il passaggio citato implichi la conclusione. Se la fonte supporta solo una parte, modifica la formulazione affinché rispecchi quel limite oppure elimina il resto dell’affermazione.

Testa anche i riferimenti difettosi: identificativi inesistenti, posizioni troppo generiche, passaggi duplicati e citazioni associate all’affermazione sbagliata. Se l’interfaccia mostra i riferimenti alla fine di un paragrafo, una persona dovrebbe poter determinare chiaramente quali frasi coprono. Un collegamento tecnicamente funzionante non sostituisce questo rapporto semantico.

Quando registri un problema, conserva la richiesta, il passaggio e la risposta esatta. «La citazione è sbagliata» non basta per migliorare il sistema: specifica se la fonte non esiste, se il passaggio non si trova, se il contenuto non supporta l’affermazione o se la risposta va oltre ciò che si può concludere. Questa precisione aiuta a decidere se intervenire sul recupero, sulla composizione della risposta o sulle regole di attribuzione.

Scegli se rispondere, rispondere in parte, chiedere chiarimenti o astenerti

L’esito non deve necessariamente essere binario. Una politica pratica distingue quattro possibilità: rispondere quando i passaggi supportano quanto richiesto; rispondere in parte quando una parte è risolta e un’altra no; chiedere chiarimenti quando diverse interpretazioni ragionevoli porterebbero a risposte diverse; e astenersi quando non ci sono evidenze sufficienti o il conflitto non può essere risolto con le regole disponibili.

Definisci queste opzioni con esempi e criteri osservabili. Evita istruzioni vaghe come «rispondi con cautela»: non indicano che cosa debba fare il sistema davanti a una data assente, una contraddizione o una domanda ambigua. Un’astensione utile dovrebbe spiegare il limite in modo circoscritto e, se possibile, indicare quali informazioni permetterebbero di proseguire. Non dovrebbe inventare una spiegazione per giustificare la mancata risposta.

Valuta gli errori in entrambe le direzioni. Una risposta non supportata è un problema, ma un’astensione non necessaria può impedire all’utente di ottenere informazioni effettivamente disponibili. Per questo, l’insieme di test deve includere sia casi in cui astenersi è appropriato, sia casi in cui le evidenze bastano per rispondere. La documentazione Microsoft sulla valutazione include l’astensione tra le dimensioni valutabili nei sistemi generativi; qui il principio si applica alla decisione di risposta, senza estendere l’ambito alla valutazione di agenti per la ricerca sul Web.

Le risposte parziali richiedono particolare attenzione: non presentare una parte confermata in modo che sembri risolvere l’intera domanda. Se l’utente chiede una durata e un’eccezione, rispondi sulla durata con il relativo supporto e dichiara che il passaggio non identifica chi autorizza l’eccezione. Se la parte irrisolta cambia sostanzialmente il significato, chiedi chiarimenti prima di formulare una conclusione potenzialmente fuorviante.

Analizza i problemi prima di modificare il sistema

Quando un test fallisce, evita di correggerlo subito aggiungendo istruzioni più lunghe. Prima individua la fase in cui si è verificato il problema. Se il documento necessario non è comparso, il problema potrebbe riguardare il recupero. Se il passaggio è presente ma non supporta la risposta, potrebbe esserci un errore di interpretazione, composizione o applicazione della regola che autorizza a rispondere. Se il riferimento non conduce al passaggio, il problema riguarda la tracciabilità. Se le evidenze sono insufficienti e il sistema risponde come se bastassero, non funziona la decisione di astenersi.

Tieni un registro degli esempi problematici con la relativa categoria, l’impatto e la modifica applicata. Quando possibile, modifica un componente alla volta e riesegui sia il caso che falliva sia gli esempi che superavano il test. Una modifica che migliora la gestione delle risposte assenti può aumentare le astensioni non necessarie; un’altra che rafforza la scorrevolezza può nascondere i limiti. La regressione serve a individuare questi compromessi.

Separa gli indicatori per fase. Puoi riportare quante richieste recuperano passaggi giudicati pertinenti, quante affermazioni hanno un supporto sufficiente, quanti riferimenti sono consultabili e come si comporta la politica quando le evidenze non bastano. Non riunire tutto in un unico numero che nasconda le differenze. Nessuna di queste misure, da sola, dimostra che il sistema sia corretto; aiutano a capire che cosa riesaminare e a confrontare le modifiche usando lo stesso insieme di test.

Esamina i problemi in base al loro impatto nell’uso previsto. Un’affermazione non supportata su una procedura interna può avere conseguenze diverse da un errore su una domanda a basso impatto. Il livello di revisione umana, la dimensione dell’insieme di test e i criteri di accettazione dovrebbero essere adeguati al rischio e al contesto del prodotto. Questa calibrazione spetta al team responsabile: non è una soglia universale ricavabile da una metrica.

Lista di accettazione prima del rilascio

Prima di mettere in uso un sistema RAG, verifica che il team sappia rispondere chiaramente alle domande di accettazione. Non basta che alcune dimostrazioni producano risposte plausibili. Occorre verificare il comportamento con domande a cui si può e non si può rispondere, distinguere la qualità del recupero dal supporto delle affermazioni e assicurarsi che la decisione di risposta corrisponda alle evidenze disponibili.

La revisione deve includere casi spesso esclusi dalle dimostrazioni: conflitti tra fonti, domande incomplete, recupero di un documento simile ma insufficiente e richieste la cui risposta è documentata solo in parte. Verifica inoltre che il formato consenta di ispezionare la fonte e associarla all’affermazione pertinente. Se questa verifica non è possibile, il team non dispone di basi sufficienti per sostenere che le citazioni rendano l’output verificabile.

Le citazioni sono un aiuto per l’ispezione, non una garanzia di verità o correttezza. Una citazione può rimandare al documento giusto senza supportare la frase; un passaggio può sostenere un’affermazione senza rispondere a tutto ciò che è stato chiesto; e una valutazione automatica può semplificare sfumature importanti. Il criterio operativo è più circoscritto e verificabile: richiedere un supporto per ogni affermazione fattuale importante, descrivere i limiti quando il supporto non basta e misurare separatamente i punti in cui il processo fallisce.

Il sistema è più pronto quando il team può mostrare esempi verificati delle quattro decisioni — rispondere, rispondere in parte, chiedere chiarimenti e astenersi —, identificare le evidenze a supporto di ogni affermazione e spiegare come sono state gestite le contraddizioni. Se ancora non è possibile, il passo successivo non consiste nell’aggiungere altre citazioni al testo: occorre migliorare il contratto, l’insieme di test o la tracciabilità delle evidenze.

Continua a esplorare

Correzioni e trasparenza

Se trovi un dato errato o non aggiornato, inviaci la pagina e la fonte da verificare.