Un dipendente domanda al nuovo assistente interno quanti giorni di preavviso servano per modificare un ordine. Il chatbot risponde correttamente, cita il manuale e chiude la frase con sicurezza. La dimostrazione sembra superata. Poi arriva una domanda quasi identica su un prodotto speciale e il sistema usa la procedura generale, ignorando l'eccezione contenuta in un allegato. È il momento in cui molte aziende scoprono che una risposta convincente non misura un sistema: misura soltanto quel singolo incontro fortunato tra domanda, documenti e modello. RAG significa Retrieval-Augmented Generation, cioè generazione potenziata dal recupero di informazioni. Prima di rispondere, l'applicazione cerca nei documenti aziendali i passaggi che sembrano pertinenti e li consegna al modello come contesto. L'idea è semplice e utile: invece di affidarsi soltanto a ciò che il modello ha appreso in passato, lo si collega a procedure, listini e manuali aggiornati. [[La scelta tra RAG e fine-tuning|/articoli/rag-o-fine-tuning-guida-scelta]] dipende proprio da questo obiettivo. Se la conoscenza cambia e deve restare citabile, recuperarla al momento della domanda è spesso la strada più sensata.
Perché è importante
- Un sistema RAG contiene almeno due motori da valutare separatamente: la ricerca dei documenti e la generazione della risposta.
- Una demo riuscita può nascondere domande non coperte, fonti irrilevanti o risposte corrette ottenute senza usare i documenti forniti.
- Il test utile combina casi reali, controlli deterministici, giudizi automatici calibrati e revisione umana sui rischi più importanti.
Una risposta giusta può nascondere un sistema sbagliato
Il problema è che il percorso contiene almeno due sistemi. Il primo cerca e ordina i frammenti di documento; il secondo li legge e produce la risposta. Se il risultato è sbagliato, la causa può trovarsi nell'indice, nella formulazione della domanda, nei permessi, nel modo in cui i file sono stati spezzati, nel modello o nelle istruzioni. Valutare soltanto la frase finale confonde tutti questi errori. Un RAG serio va aperto come un motore: prima si controlla che abbia trovato i pezzi giusti, poi che li abbia usati senza aggiungere dettagli non sostenuti. La prima misura è la precisione del contesto: tra i passaggi recuperati, quanti servono davvero a rispondere? La documentazione di Ragas la descrive anche come capacità di collocare i frammenti rilevanti prima di quelli inutili. Se una domanda sulla garanzia riceve dieci pagine su marketing, spedizioni e resi prima della clausola corretta, il modello parte svantaggiato e il costo cresce. Una precisione elevata non richiede necessariamente un solo frammento; richiede che ciò che entra nel contesto abbia un motivo verificabile per esserci.
La seconda è il richiamo del contesto, cioè quante informazioni necessarie sono state recuperate rispetto a quelle che avrebbero dovuto esserlo. Precisione e richiamo si possono muovere in direzioni opposte. Cercare pochi risultati molto mirati riduce il rumore ma può perdere una condizione; recuperare mezzo archivio aumenta la probabilità di includerla e sommerge il modello. Ragas definisce il richiamo attraverso le affermazioni della risposta di riferimento sostenute dai documenti recuperati. Per misurarlo serve quindi una base di confronto: fonti attese o risposte preparate e verificate da chi conosce il processo. La terza prova riguarda la fedeltà, spesso indicata con il termine inglese faithfulness. Ogni affermazione della risposta deve poter essere ricondotta al contesto fornito. Un testo può essere pertinente e perfino corretto nel mondo reale, ma non fedele ai documenti autorizzati: il modello potrebbe aver completato il ragionamento con conoscenze generali o con un'ipotesi. In un assistente che risponde sulle procedure interne, questa scorciatoia è pericolosa. La quarta prova è l'astensione: quando l'evidenza manca o è contraddittoria, il sistema deve dichiararlo e indicare che cosa serve per proseguire. Un chatbot che risponde sempre non è più utile; è soltanto più difficile da controllare.
Il set di prova deve assomigliare al lunedì mattina
Il primo set di valutazione non deve contenere mille domande perfette. Ne bastano quaranta o sessanta raccolte da email, ticket, ricerche interne e colloqui con le persone che useranno l'assistente. Vanno eliminate informazioni personali non necessarie e conservata la varietà: domande brevi, termini tecnici, errori di battitura, richieste con più condizioni e quesiti espressi con il linguaggio reale dell'azienda. Se il test usa soltanto le frasi con cui gli sviluppatori hanno progettato il sistema, misurerà la familiarità con il laboratorio, non la qualità sul lavoro. Il campione deve includere anche i casi scomodi. Una domanda la cui risposta non esiste, due procedure in conflitto, un documento scaduto, un utente senza permesso, una richiesta che dipende da un dato presente nel gestionale e non nei PDF. Ogni caso riceve una fonte attesa, una risposta di riferimento quando serve e una regola di superamento. Alcuni controlli sono deterministici: la citazione deve aprirsi, l'utente non deve vedere un documento vietato, una data deve corrispondere al testo. Altri richiedono un giudizio: la spiegazione è completa? Distingue la regola dall'eccezione? Indica con chiarezza ciò che non può confermare?
I modelli usati come giudici aiutano a valutare molti esempi, ma non sono un arbitro infallibile. Google Cloud raccomanda di confrontare i punteggi del giudice automatico con valutazioni umane, usando dati annotati come riferimento. È un passaggio spesso saltato: se il giudice premia risposte verbose o non riconosce una sfumatura del settore, la dashboard può migliorare mentre il servizio peggiora. NIST inquadra test, valutazione, verifica e validazione come attività continue nella gestione del rischio AI. La revisione umana non deve leggere tutto per sempre; deve calibrare le metriche, controllare i casi ad alto impatto e indagare gli errori ricorrenti.
Cosa puoi farci concretamente
- Costruire un primo set di 40-60 domande reali, includendo casi facili, ambigui, incompleti e senza risposta nei documenti.
- Misurare separatamente recupero delle fonti, fedeltà al contesto, utilità della risposta e capacità di non rispondere quando manca evidenza.
- Registrare versione di documenti, indice, modello e prompt per capire quale modifica migliora o peggiora il risultato.
Il punto, oltre l’annuncio
Un punteggio ottenuto oggi non accompagna il sistema per tutta la vita. Basta aggiornare un listino, cambiare il metodo di suddivisione dei documenti o sostituire il modello di embedding — la rappresentazione numerica usata per cercare testi simili — per modificare ciò che viene recuperato. Per questo ogni esecuzione del test deve registrare versione dei file, indice, modello, prompt, numero di risultati e regole di ordinamento. Se una modifica porta il successo dal 84 all'88 per cento, bisogna sapere quale componente l'ha prodotto e quali categorie sono peggiorate. In produzione servono indicatori diversi dal voto medio. Le domande senza risposta crescono in un reparto specifico? Gli utenti aprono le fonti o riformulano subito? Quali citazioni portano a documenti superati? Quante risposte vengono corrette da una persona? La valutazione di un agente prima della produzione applica la stessa logica alle azioni e agli strumenti: osservare il risultato finale senza controllare il percorso lascia troppi errori invisibili. Un registro delle domande, minimizzato e protetto, permette di trasformare i fallimenti reali in nuovi casi di prova.
La valutazione editoriale di Opéria Tech è che il numero più utile non sia un punteggio assoluto di qualità, ma la percentuale di domande per cui il sistema soddisfa una soglia legata al rischio. Una FAQ interna può accettare una risposta incompleta e offrire un collegamento; un'indicazione contrattuale richiede fonte esatta, versione valida e controllo umano nei casi dubbi. Il RAG non diventa affidabile perché mostra le citazioni. Diventa affidabile quando l'azienda sa quali domande può gestire, quali deve rifiutare e quale prova dimostra la differenza.
Fonti
Documenti, comunicati e pubblicazioni consultati per ricostruire dati e contesto.
