Per ottenere risposte affidabili da un sistema RAG non basta caricare molti file: bisogna selezionare fonti attendibili, organizzare i contenuti in modo chiaro, aggiungere metadati utili e definire regole per aggiornamenti, permessi e verifiche. La qualità delle risposte dipende soprattutto dalla qualità della conoscenza recuperata.
Un sistema RAG cerca nei documenti aziendali le informazioni pertinenti alla domanda e le fornisce al modello linguistico per costruire la risposta. Se trova versioni obsolete, testi ambigui o documenti duplicati, può generare una risposta plausibile ma sbagliata. Prima della tecnologia serve quindi un lavoro editoriale e organizzativo sulla knowledge base.
Il primo passaggio consiste nel definire gli utenti, i casi d’uso e le domande previste. Un assistente per il servizio clienti avrà bisogno di manuali, condizioni commerciali e procedure di assistenza. Uno strumento interno per l’area vendite potrebbe invece consultare schede prodotto, listini, FAQ tecniche e regole per la preparazione delle offerte.
Questo perimetro permette di evitare un errore frequente: importare l’intero archivio aziendale senza distinguere ciò che è utile da ciò che è soltanto disponibile. Se il progetto è ancora in fase di valutazione, può essere utile partire dall’approfondimento sulla RAG aziendale per le PMI.
Ogni documento dovrebbe avere un proprietario interno, cioè una persona o una funzione responsabile della sua correttezza. È inoltre opportuno stabilire quale fonte prevale quando due documenti trattano lo stesso argomento in modo diverso.
Per ogni contenuto conviene verificare almeno:
Bozze, copie locali, vecchi listini e procedure superate non dovrebbero essere trattati come fonti equivalenti ai documenti ufficiali.
La knowledge base funziona meglio con contenuti strutturati e comprensibili anche fuori dal loro contesto originale. Titoli generici come “Note”, “Varie” o “Procedura aggiornata” aiutano poco. Sono preferibili titoli descrittivi, sezioni brevi, elenchi coerenti e termini usati sempre con lo stesso significato.
Ogni sezione dovrebbe contenere le informazioni necessarie per essere capita senza dipendere eccessivamente dalle pagine precedenti. Sigle e abbreviazioni vanno spiegate. Eccezioni, vincoli e condizioni devono essere espliciti: una regola valida soltanto per alcuni clienti o prodotti non dovrebbe apparire come universale.
Particolare attenzione richiedono PDF scansionati, immagini, tabelle complesse e file con impaginazioni elaborate. Prima dell’indicizzazione bisogna verificare che il testo sia effettivamente estraibile e che righe, colonne, note e intestazioni non perdano il loro significato. L’OCR può aiutare con le scansioni, ma il risultato deve essere controllato.
I metadati consentono al sistema di filtrare le fonti prima di generare la risposta. Possono includere titolo, autore, reparto, categoria, lingua, prodotto, versione, data di validità, stato di approvazione e livello di accesso.
Non serve aggiungere campi in modo indiscriminato. È meglio scegliere pochi metadati coerenti con le domande reali. Se, per esempio, le condizioni cambiano per paese o linea di prodotto, questi due elementi devono essere identificabili in modo uniforme.
Un documento corretto oggi potrebbe non esserlo tra sei mesi. La preparazione della knowledge base deve quindi includere un processo di manutenzione: frequenza delle revisioni, responsabili, modalità di sostituzione delle versioni e tempi di aggiornamento dell’indice RAG.
Quando una fonte viene sostituita, la vecchia versione dovrebbe essere rimossa dall’insieme consultabile oppure marcata chiaramente come storica. Conservare documenti quasi identici aumenta il rischio che il sistema recuperi una regola non più valida.
Il fatto che un documento sia tecnicamente accessibile non significa che debba essere mostrato a tutti. I permessi della knowledge base dovrebbero riflettere ruoli e autorizzazioni aziendali. Il controllo deve avvenire nella fase di recupero delle fonti, non soltanto nelle istruzioni date al modello.
Questa gestione va inserita in regole più ampie su dati, strumenti e responsabilità, come quelle affrontate in una policy AI aziendale. Anche la scelta tra servizi cloud e infrastruttura interna dipende dalla sensibilità dei documenti e dai requisiti organizzativi; sul tema è disponibile il confronto tra AI online e AI in locale.
Prima del rilascio è utile costruire un insieme di domande rappresentative, comprese richieste ambigue, casi limite e domande per le quali non esiste una risposta nei documenti. La verifica non dovrebbe limitarsi alla fluidità del testo, ma considerare:
È utile prevedere anche un canale con cui gli utenti possano segnalare risposte incomplete o fonti obsolete. Queste segnalazioni servono a migliorare documenti, metadati e criteri di ricerca, non soltanto il prompt.
Non deve essere perfetta né comprendere tutto l’archivio aziendale. Per un primo progetto è sufficiente un perimetro circoscritto nel quale le fonti siano approvate, leggibili, aggiornate, prive di duplicati rilevanti e associate a permessi chiari. Occorre inoltre disporre di domande di test e di una persona responsabile della manutenzione.
Se questi requisiti mancano, conviene sistemare prima il patrimonio informativo. Un sistema RAG può rendere più accessibile la conoscenza aziendale, ma non può trasformare automaticamente documenti disordinati o contraddittori in una fonte affidabile.