RAG e knowledge base: ancorare un LLM ai tuoi documenti

Come funziona il RAG: recuperare, arricchire, rispondere

Il RAG opera in due fasi. Nella fase di indicizzazione si prepara la knowledge base: i documenti vengono suddivisi in passaggi (chunk), ogni chunk è convertito in un vettore numerico (embedding) che ne cattura il significato e i vettori sono archiviati in un database vettoriale. In fase di interrogazione la domanda dell'utente viene trasformata nello stesso modo in un vettore, il sistema recupera i chunk semanticamente più simili e li inserisce nel prompt come contesto. L'LLM genera quindi una risposta ancorata al testo recuperato anziché alla memoria di addestramento.

• Chunking: suddividere i documenti in passaggi coerenti affinché il recupero restituisca frammenti mirati e citabili.
• Embedding: convertire testo e domande in vettori affinché a guidare il recupero sia la somiglianza semantica, non le sole parole chiave.
• Database vettoriale e recupero: trovare i passaggi più pertinenti, spesso combinati con la ricerca per parole chiave (ricerca ibrida).
• Arricchimento e generazione: passare all'LLM i passaggi recuperati e la domanda; il modello risponde e può citare le fonti.

Perché l'ancoraggio riduce le allucinazioni

Un LLM isolato risponde a partire dagli schemi appresi durante l'addestramento. Quando gli manca un fatto, può comunque produrre una risposta fluente ma errata: un'allucinazione. Il RAG trasforma il compito da 'ricordare' a 'leggere e riassumere': al modello viene fornito il testo di origine pertinente e gli si chiede di rispondere basandosi su quello. Questo riduce lo spazio per inventare, mantiene aggiornate le risposte quando i documenti cambiano e, soprattutto, permette al sistema di mostrare da quale passaggio proviene una risposta, così le persone possono verificarla. L'ancoraggio non elimina del tutto gli errori: se il recupero restituisce il passaggio sbagliato o il prompt non istruisce il modello a restare nel contesto fornito, gli errori possono ancora verificarsi.

Costruire una knowledge base che funziona davvero

La qualità di un sistema RAG dipende meno dal modello e più dalla knowledge base che lo alimenta. Documenti puliti, ben strutturati e aggiornati battono un modello più grande che gira su dati disordinati.

• Selezionare le fonti: manuali, policy, FAQ, contratti, pagine wiki — solo contenuti affidabili e mantenibili.
• Suddividere con criterio: i passaggi troppo grandi diluiscono la pertinenza, quelli troppo piccoli perdono il contesto. Rispettare la struttura naturale (titoli, sezioni).
• Mantenerla aggiornata: reindicizzare quando i documenti cambiano; i chunk obsoleti sono una causa frequente di risposte errate.
• Aggiungere metadati: lingua, reparto, data di validità, livello di accesso — così il recupero può filtrare (es. solo attuali, solo DE).
• Gestire i permessi: un assistente RAG deve rispettare chi può vedere quale documento.

RAG, fine-tuning o finestra di contesto più ampia?

Questi approcci risolvono problemi diversi e spesso si combinano. Esempi illustrativi per una PMI svizzera: un assistente interno che risponde alle domande del personale attingendo al manuale HR e cita la clausola; un bot di supporto ancorato alla documentazione di prodotto attuale in tedesco e francese; un assistente vendite che recupera il listino prezzi più recente invece di tirare a indovinare.

• Il RAG aggiunge conoscenza: ideale quando i fatti cambiano spesso, devono essere citabili o sono troppi per un prompt. Si aggiorna modificando i documenti, non riaddestrando.
• Il fine-tuning plasma comportamento e stile: insegna formato, tono o una competenza specifica — non è un modo affidabile per memorizzare molti fatti.
• Le finestre di contesto ampie permettono di incollare i documenti direttamente: semplice con pochi file, ma costoso e più lento su larga scala — e devi comunque scegliere cosa includere, che è esattamente ciò che fa il recupero.

Errori comuni e come evitarli

• Trattare il RAG come plug-and-play: la qualità del recupero va testata e regolata (chunking, ricerca ibrida, re-ranking).
• Nessuna citazione delle fonti: senza mostrare i passaggi, gli utenti non possono verificare e la fiducia si erode.
• Ignorare la valutazione: misurare se le risposte sono ancorate al testo recuperato, non solo se suonano fluenti.
• Lasciare che il modello risponda oltre il contesto: istruirlo a dire 'non trovato nelle fonti' invece di indovinare.
• Dimenticare la data governance: i documenti sensibili nell'indice necessitano comunque di controllo degli accessi e di una base giuridica.

Prospettiva svizzera e DACH: protezione dei dati fin dalla progettazione

Per le organizzazioni svizzere, una knowledge base RAG contiene spesso dati personali o riservati, quindi la protezione dei dati è parte della progettazione, non un ripensamento. Ai sensi della legge federale riveduta sulla protezione dei dati (revDSG/nFADP), vigilata dall'EDÖB, servono una base giuridica, trasparenza e una sicurezza adeguata per i dati personali che indicizzi ed elabori. Se servi utenti dell'UE o vi implementi sistemi di IA, l'EU AI Act può applicarsi in via extraterritoriale.

• Residenza dei dati e scelta del fornitore: sapere dove avvengono indicizzazione, embedding e generazione; per i dati sensibili può essere necessario l'hosting in Svizzera o nell'UE.
• Controllo degli accessi: il recupero deve rispettare i permessi dei documenti affinché l'assistente non mostri mai dati che un utente non può vedere.
• Trasparenza e supervisione umana: informare gli utenti che interagiscono con la KI, mostrare le fonti e mantenere una persona nel processo per le risposte rilevanti.
• Minimizzazione dei dati: indicizzare solo ciò che serve al caso d'uso; non inserire nella knowledge base dati particolarmente degni di protezione senza giustificazione.