Una procedura aziendale viene aggiornata, ma il chatbot continua a citare la versione precedente. Oppure una persona chiede quale clausola di un contratto preveda una penale e riceve una spiegazione plausibile, senza un riferimento alla pagina. Il testo è scorrevole. La risposta, però, non si può controllare.
È il genere di problema per cui ha senso valutare un sistema RAG. Un modello linguistico può scrivere molto bene, ma i documenti di un'organizzazione cambiano, contengono eccezioni e spesso sono accessibili soltanto ad alcune persone. Chiedere al modello di ricordarli tutti, per sempre, è una cattiva scelta progettuale.
Che cos'è un sistema RAG
RAG significa Retrieval-Augmented Generation, cioè generazione aumentata tramite recupero delle informazioni. Prima di formulare una risposta, il sistema cerca materiale pertinente in una raccolta di documenti. Poi passa al modello linguistico alcuni estratti selezionati, affinché risponda a partire da quelle evidenze.
La distinzione è importante: il modello non deve avere imparato il contenuto durante l'addestramento. Può consultare un manuale inserito ieri, una scheda prodotto aggiornata stamattina o un regolamento interno revisionato da poco.
Il metodo è stato formalizzato in un lavoro di ricerca del 2020 di Patrick Lewis e altri autori. Da allora il termine RAG è diventato un'etichetta piuttosto larga. Si usa per sistemi molto diversi, da una ricerca documentale con risposta automatica fino ad architetture che uniscono più motori di recupero, controlli di autorizzazione e verifiche delle fonti.
Il vantaggio non sta soltanto nell'avere risposte più pertinenti. Sta soprattutto nella possibilità di risalire al documento da cui è stata tratta un'affermazione. Naturalmente una citazione non garantisce che l'interpretazione sia corretta. Offre, però, un punto di partenza verificabile.
Dalla domanda alla risposta: cosa succede davvero
Prendiamo una domanda ipotetica: «Il contratto di assistenza prevede interventi durante il fine settimana?». I passaggi avvengono in due momenti distinti.
Prima della domanda, il sistema acquisisce i documenti, ne estrae il testo e lo organizza in porzioni gestibili, spesso chiamate chunk. Registra l'origine di ogni porzione e, quando previsto, genera rappresentazioni numeriche del suo significato, gli embedding. Questi dati vengono indicizzati per consentire ricerche rapide.
Quando arriva la domanda, il motore cerca i passaggi pertinenti e costruisce un contesto limitato. Il modello riceve la domanda insieme a quel contesto e produce una risposta. Un sistema progettato con attenzione controlla anche che le citazioni indicate corrispondano a fonti effettivamente recuperate.
Immagina che il contratto distingua tra «assistenza ordinaria» e «reperibilità straordinaria». Cercare soltanto la parola fine settimana potrebbe non bastare. Un buon recupero deve trovare anche le clausole che parlano di sabato, festivi, turni e reperibilità, senza confonderle con quelle di un contratto appartenente a un altro cliente.
Questa è la parte difficile di un RAG: individuare il materiale giusto, nel perimetro giusto, prima ancora che il modello cominci a scrivere.
Come si sviluppa un RAG, dalla prima prova alla produzione
Una demo si realizza rapidamente. Un sistema che lavora su documenti reali richiede decisioni meno appariscenti.
Si definiscono le domande a cui deve rispondere
«Interrogare tutti i documenti aziendali» è un requisito troppo generico. Meglio partire da un insieme di domande frequenti e annotare, per ciascuna, quale documento dovrebbe contenere la risposta. Nel caso di un servizio di assistenza: copertura oraria, esclusioni, tempi contrattuali, differenze tra piani.
Vanno preparati anche casi in cui il sistema non dovrebbe rispondere, perché la fonte manca, è superata oppure l'utente non è autorizzato a leggerla. Sono test indispensabili, non eccezioni da gestire a fine progetto.
Si prepara l'acquisizione delle fonti
PDF, pagine web, file di testo e database hanno strutture differenti. Un PDF può contenere tabelle mal estratte; una pagina HTML può includere menu, cookie banner e testo duplicato. Prima dell'indicizzazione occorrono connettori che acquisiscano solo le fonti autorizzate, estraggano il contenuto utile e conservino metadati come titolo, origine, data e permessi.
Un crawler non è automaticamente parte del motore RAG. Spesso è meglio mantenerlo separato: il modulo di acquisizione conosce il formato della fonte, mentre il motore di ricerca conosce documenti già normalizzati.
Si dividono i documenti senza distruggerne il contesto
La dimensione dei chunk influisce sul risultato. Tagliare una clausola a metà può separare un obbligo dalle sue eccezioni; inserire un intero manuale in un unico blocco rende difficile trovare il paragrafo rilevante.
La suddivisione dovrebbe rispettare, quando possibile, titoli, sezioni, paragrafi e tabelle. A ogni estratto conviene associare la posizione nel documento originale. Per un contratto, un numero di pagina o una sezione precisa valgono più di una citazione generica al nome del file.
Si sceglie come cercare
Ci sono due famiglie di ricerca utili. La ricerca lessicale individua parole e formule presenti nel testo: funziona bene con codici, sigle, nomi di prodotti e riferimenti normativi. La ricerca vettoriale confronta gli embedding e può recuperare passaggi semanticamente vicini anche quando usano parole differenti.
Usarle insieme è spesso una scelta sensata. Una richiesta che contiene il codice esatto di un componente non dovrebbe perdere il risultato migliore soltanto perché un altro paragrafo assomiglia di più alla domanda sul piano semantico.
La scelta del modello per gli embedding, della lingua e della strategia di classificazione va verificata con esempi del dominio. Il database vettoriale, da solo, non risolve il problema della pertinenza.
Si costruiscono risposta, citazioni e possibilità di rifiuto
I passaggi recuperati vengono ordinati e ridotti a una quantità di testo compatibile con il modello scelto. Serve una regola esplicita per i casi senza prove sufficienti. In quei casi è preferibile una risposta che dichiari il limite delle fonti a una spiegazione inventata.
Le istruzioni date al modello devono distinguere la richiesta dell'utente dal contenuto dei documenti. Un testo indicizzato può contenere istruzioni malevole o fuorvianti: non dovrebbe diventare un comando soltanto perché è stato recuperato.
Si isolano i dati e si gestiscono gli aggiornamenti
Un sistema multiutente deve verificare i permessi prima di selezionare i risultati. Cercare dappertutto e cancellare in seguito i documenti non autorizzati è una scelta pericolosa: la separazione deve agire già nel recupero e, dove possibile, anche nel database.
C'è poi la questione delle versioni. Se una procedura cambia, bisogna sapere quale testo è attualmente valido ed evitare che la ricerca mescoli revisioni diverse. Conservare lo storico può essere utile per audit e confronti, purché non venga scambiato per la documentazione corrente.
Si misura il comportamento su domande reali
Per valutare un RAG, la fluidità della risposta conta meno della qualità del materiale recuperato. Bisogna misurare quante volte il passaggio corretto compare tra i risultati, se la prima fonte è pertinente, se compaiono documenti di altri utenti e se il sistema sa fermarsi quando manca un'evidenza.
Lavoriamo quindi con un set di domande e risposte attese, includendo documenti simili, versioni precedenti e quesiti senza soluzione. Dopo ogni modifica a chunking, embedding o ranking, il confronto si ripete. È qui che un prototipo diventa un prodotto affidabile.
Un RAG serve a tutte le aziende?
No. Se le informazioni sono poche, stabili e già organizzate in un database strutturato, può bastare una ricerca tradizionale o una normale interfaccia applicativa. Un RAG aggiunge costi operativi: acquisizione, indicizzazione, interrogazioni, modello linguistico, osservabilità e manutenzione.
Diventa interessante quando una parte rilevante della conoscenza è distribuita in documenti lunghi o soggetti a frequenti revisioni. Pensa a un ufficio tecnico che consulta manuali, a una società che gestisce procedure interne, a un catalogo con migliaia di schede oppure a un archivio storico con materiali consultabili secondo diritti differenti.
Per un sito istituzionale, ad esempio, si può progettare un assistente che cerchi tra regolamenti, pubblicazioni e pagine ufficiali. Non dovrebbe inventare orari, modalità di accesso o interpretazioni normative: se il documento non contiene la risposta, deve dirlo.
Un RAG non equivale neppure all'addestramento di un nuovo modello. Il fine-tuning modifica il comportamento del modello attraverso un processo di training; il RAG mantiene le conoscenze nei sistemi documentali e le recupera al momento della domanda. Le due tecniche possono coesistere, ma servono a problemi diversi.
Perché abbiamo sviluppato PerseoRAG
Quando si realizza un assistente per documenti, molte componenti tornano identiche da progetto a progetto: suddivisione, versionamento, ricerca, gestione dei permessi, citazioni. Riscriverle ogni volta aumenta il rischio di errori e rende più difficile capire dove una risposta abbia perso il contatto con le fonti.
Da qui nasce PerseoRAG, il nucleo RAG open source di PerSeoDesign. La versione 1.1.0 è una libreria Python riutilizzabile, con orchestrazione FastAPI, persistenza PostgreSQL e supporto pgvector. Il progetto è pubblicato con licenza Apache 2.0.
La prima scelta architetturale è tenerlo indipendente dalle applicazioni che lo utilizzano. PerseoRAG non è un chatbot già pronto e non include un crawler universale, un modello linguistico imposto o il sistema di autenticazione di un prodotto specifico. Questi elementi sono collegati dall'applicazione che integra la libreria.
Questo confine ha conseguenze pratiche. Si può cambiare fornitore di embedding o generazione senza riscrivere il formato delle evidenze; si può costruire una nuova interfaccia senza duplicare le regole di recupero; si possono mantenere le autorizzazioni nel servizio che conosce gli utenti.
Dentro PerseoRAG: le scelte che contano
Documenti versionati e ricerche sulla revisione corrente
Ogni documento appartiene a uno scope, cioè un perimetro di accesso, e a una raccolta. Il contenuto viene normalizzato e identificato attraverso un'impronta. Se si importa due volte la stessa versione, il sistema evita di duplicarla; quando il contenuto cambia, registra una nuova versione immutabile e aggiorna il riferimento alla versione corrente.
Questo evita che una procedura vecchia concorra normalmente con quella aggiornata. Lo storico rimane disponibile per le esigenze di verifica, ma il recupero ordinario considera la revisione attiva.
Ricerca ibrida in PostgreSQL
PerseoRAG combina la ricerca full-text di PostgreSQL con quella vettoriale di pgvector. I due elenchi di risultati vengono fusi attraverso Reciprocal Rank Fusion, una tecnica che combina le posizioni dei documenti senza pretendere che i punteggi dei due motori siano direttamente confrontabili.
Per la versione 1.1 la ricerca vettoriale è esatta. La scelta di eventuali indici approssimati viene lasciata al contesto di distribuzione, dove si conoscono dimensioni delle raccolte, modelli e vincoli prestazionali. È una decisione meno spettacolare di una promessa di velocità universale, ma più facile da verificare.
Sicurezza prima della classifica
Lo scope viene risolto dall'applicazione autenticata, non scelto liberamente dal testo della richiesta. Il recupero cerca già dentro quel perimetro, con una seconda barriera basata su Row-Level Security di PostgreSQL.
In altre parole, i risultati di un cliente non vengono recuperati globalmente e poi eliminati da una lista visibile. Devono rimanere separati durante la selezione stessa. Per progetti che trattano documenti riservati, è un requisito progettuale, non una funzione accessoria.
Risposte basate su evidenze controllabili
Prima di chiamare il modello, PerseoRAG costruisce un contesto di dimensioni limitate, conserva gli identificativi delle fonti e applica una politica che può scegliere di non generare alcuna risposta in assenza di materiale sufficiente.
Dopo la generazione controlla che le citazioni appartengano davvero al contesto recuperato. Una citazione inesistente o una risposta priva dei riferimenti richiesti viene rifiutata. Resta necessaria la verifica del significato, soprattutto su materie legali, mediche o contrattuali: nessun controllo automatico delle citazioni rende infallibile un modello.
La libreria comprende inoltre test di recupero e isolamento, con metriche come Recall@K, Mean Reciprocal Rank e perdita di isolamento fra scope. Questi test servono a trovare regressioni; non costituiscono una promessa di accuratezza uguale per ogni archivio.
PerseoRAG, Gnosis e Sherlock: dove finiscono i confini
È utile distinguere il motore RAG dal prodotto che il cliente usa. Gnosis e Sherlock non sono moduli interni di PerseoRAG. Un'applicazione può integrare il motore come dipendenza e aggiungere una propria interfaccia, il proprio sistema di permessi e le proprie funzioni. PerseoRAG si occupa del recupero e della preparazione delle evidenze, entro i contratti definiti dall'integrazione.
La separazione permette anche di mantenere un progetto con modelli locali o con servizi esterni, ma il livello effettivo di riservatezza dipende dall'infrastruttura e dai provider scelti. Usare PerseoRAG, di per sé, non significa che tutti i dati restino automaticamente sul server del cliente.
Quanto costa realizzare un RAG e da dove iniziare
Non esiste un costo sensato da indicare prima di aver visto i documenti. Cambia molto tra un archivio pubblico di poche centinaia di pagine e migliaia di file riservati, con permessi individuali, scansioni difficili da leggere e aggiornamenti continui.
In un progetto concreto partirei da un campione rappresentativo: fonti, domande, risposte attese e utenti con autorizzazioni differenti. Solo dopo deciderei il modello, l'hardware e il modo in cui il servizio viene esposto sul sito. La qualità dell'estrazione e dei controlli di accesso condiziona il risultato più della scelta del chatbot più famoso.
PerSeoDesign lavora proprio su questo confine tra applicazioni web, dati e ricerca documentale. Se stai valutando un assistente per il tuo sito o per la documentazione interna, la prima domanda utile da portarci non è «quale IA usiamo?», ma «quali documenti devono poter essere consultati, da chi, e con quale grado di affidabilità?».
Per approfondire la parte tecnica puoi consultare il codice e la documentazione pubblica di PerseoRAG. Per discutere di una possibile integrazione, trovi i riferimenti nella pagina contatti.