Un cliente scrive: “Mi avete detto che posso cancellare gratuitamente fino a 48 ore prima. Nella mia offerta c’è scritto altro.”
Il collaboratore apre la chat. La risposta dell’IA è precisa e sicura. Però il sistema non mostra quale documento è stato utilizzato, quale versione fosse attiva né quale paragrafo abbia sostenuto quella frase.
Non è per forza un problema di contenuti vecchi. Due documenti possono essere entrambi aggiornati ma destinati a clienti diversi.
Per questo un sistema RAG in produzione ha bisogno di provenance, cioè di una traccia che permetta di capire su quale evidenza si è basata la risposta.
Freschezza e provenienza risolvono due problemi diversi
La freschezza dice se una conoscenza è ancora valida. La provenance dice da dove arriva e perché è stata usata in quel caso.
Una policy aggiornata ieri può non valere per un contratto firmato l’anno scorso. Un documento più vecchio può invece essere ancora la fonte corretta per un determinato cliente.
W3C PROV descrive la provenance come informazione su entità, attività e persone coinvolte nella produzione di un dato. Una PMI non deve implementare l’intera ontologia per usare il principio.
In pratica, per una risposta importante conviene sapere: ID della fonte, versione, sezione utilizzata, ambito di applicazione, momento del retrieval e contesto di accesso.
Fatto confermato: la famiglia di standard W3C PROV è stata creata per rappresentare e scambiare informazioni sulla provenienza e derivazione dei dati.
Raccomandazione dell’autore: ogni risposta con un impatto concreto sul cliente dovrebbe conservare internamente almeno source ID, versione e passaggio rilevante, anche quando l’interfaccia mostra solo un riferimento breve.
Non trasformate il chatbot in una tesi universitaria
Se qualcuno chiede gli orari del sabato, non servono cinque note a piè di pagina. Nemmeno un “grazie” deve essere accompagnato da una fonte.
Il valore aumenta quando la risposta crea un impegno: prezzo, cancellazione, garanzia, disponibilità, rimborso, data di consegna, condizioni contrattuali o perimetro del servizio.
In questi casi il sistema può attivare una modalità di evidenza.
La risposta al cliente rimane naturale: “Secondo le condizioni di cancellazione, versione 12 agosto 2026…”. Un piccolo link può bastare. Il trace interno conserva di più: documento, sezione, timestamp, altri candidati recuperati e contesto dell’account.
Se la fonte è interna e l’utente non ha diritto di vederla, non va esposta. La provenance non sostituisce il permission-aware RAG.
Il caso più insidioso sono due fonti autorevoli che dicono cose diverse
Le aziende accumulano documenti.
Il sito pubblico dice 24 ore. Il PDF commerciale dice 48. Una vecchia FAQ aggiunge un’eccezione per gruppi. Nel CRM c’è una condizione speciale per quel cliente.
Un chatbot debole prende il chunk con similarity più alta e formula una risposta definitiva.
Un sistema migliore riconosce il conflitto. Quando la differenza può cambiare soldi o promesse al cliente, la regola dovrebbe essere: non mascherare l’incertezza con una frase fluida.
Il bot può rispondere: “Trovo due condizioni diverse che potrebbero applicarsi. Faccio verificare il caso al team.”
Questa è una buona esperienza, soprattutto se il passaggio a una persona include già le fonti.
Anche una singola fonte può essere problematica: testo ambiguo, tabella senza unità, memo mai approvato. La provenance rende il problema visibile, ma non rende automaticamente buona la documentazione.
Una struttura pratica per aggiungere provenance al RAG
Non serve partire cambiando database vettoriale. Serve prima disciplinare i documenti.
- Assegnare a ogni fonte importante un ID stabile, un owner e una versione/data di approvazione.
- Conservare queste informazioni quando il documento viene spezzato in chunk e indicizzato.
- Classificare le risposte: routine, promessa al cliente, informazione sensibile, conflitto.
- Mostrare la fonte dove è utile al cliente e mantenere un trace più ricco per il supporto.
- Impedire una risposta definitiva quando l’evidenza è debole, contraddittoria o fuori dai permessi.
- Testare sostituzione, archiviazione e cancellazione delle fonti.
La cancellazione è un test concreto: se un file scompare il mese prossimo, il transcript di oggi deve comunque spiegare quale fonte era stata usata, compatibilmente con la policy di retention e privacy.
Handover umano: passare anche il pacchetto di evidenza
Se l’operatore riceve soltanto “domanda sulla cancellazione”, deve ricominciare da zero.
Il passaggio dovrebbe contenere domanda, risposta provvisoria, fonti e versioni, eventuale conflitto e motivo dello stop.
Per esempio: “Listino pubblico v4 = X; contratto cliente = condizione speciale; nessun prezzo finale comunicato.” Ora la persona può davvero decidere.
La responsabilità non sparisce perché la fonte è ben tracciata. Un documento può essere sbagliato, non applicabile o incompleto. Provenance significa spiegabilità operativa, non garanzia assoluta di verità.
Pilot minimo e metriche
Scegliete una sola area dove le contestazioni esistono davvero: cancellazioni, garanzia, consegna, prezzi o copertura del servizio. Create 30–50 domande con fonti coerenti, fonti in conflitto, eccezioni cliente, documento mancante e accessi diversi.
Misurate risposte con source trace completo, risposte con impatto cliente basate sulla fonte corretta, conflitti rilevati, handover con evidenza sufficiente, affermazioni definitive senza supporto e il tempo necessario al collaboratore per verificare una risposta escalata.
La conclusione è concreta: il chatbot non deve soltanto generare una frase giusta. Quando la frase conta, l’azienda deve poter ricostruire perché il sistema l’ha prodotta. Senza questa traccia, anche un modello molto capace resta difficile da governare quando nasce una contestazione reale.
L'articolo sulla conoscenza aggiornata tratta la responsabilità. Il RAG con permessi evita che la citazione stessa riveli dati.
Fonti
Prima della realizzazione scegliete la tecnica necessaria. Il confronto RAG o fine-tuning distingue fatti mancanti, errori di ricerca e problemi di formato rendendo visibile la manutenzione.
FAQ
Ogni risposta deve mostrare una fonte?
No. Per le domande semplici mantenete l’esperienza leggera. Le affermazioni importanti dovrebbero però restare tracciabili internamente.
Basta salvare il titolo del documento?
Spesso no. Versione, sezione e timestamp aiutano quando una policy cambia o esistono più documenti simili.
Cosa fare con fonti in conflitto?
Non forzare una risposta definitiva se c’è un impatto sul cliente. Segnalare il conflitto e passare il caso a una persona.
Provenance e RAG sono la stessa cosa?
No. RAG recupera conoscenza. Provenance registra l’origine e il percorso che ha portato quella conoscenza nella risposta.
E se la fonte viene cancellata?
Conservare metadati sufficienti per capire il contesto storico, rispettando al tempo stesso retention e protezione dei dati.