Quasi tutte le aziende con cui parliamo hanno la stessa idea: mettere un assistente sopra i propri documenti, così le persone smettono di cercare e iniziano a chiedere. Contratti, manuali di prodotto, policy interne, ticket di assistenza, dieci anni di Confluence. La demo si fa in un pomeriggio. La versione di cui le persone si fidano richiede qualche settimana di lavoro accurato, e la differenza tra le due è l’argomento di questo articolo.
La retrieval-augmented generation (RAG) è semplice da descrivere. Quando qualcuno fa una domanda, il sistema trova i passaggi che con più probabilità contengono la risposta e li passa a un modello linguistico insieme alla domanda. Il modello scrive una risposta basata su quei passaggi e indica le fonti. Non serve che sia stato addestrato sui tuoi dati, e i tuoi dati non escono dal tuo controllo più di quanto tu consenta.
Ecco a cosa facciamo attenzione quando un sistema RAG deve funzionare il lunedì mattina, non solo in riunione.
Partire dalle domande, non dai documenti
L’errore più comune è cominciare indicizzando tutto. Un primo passo migliore è raccogliere da cinquanta a cento domande reali dalle persone che useranno l’assistente, insieme alla risposta che darebbe un esperto e ai documenti da cui proviene.
Quell’elenco fa tre cose insieme:
- indica quali fonti contano davvero, di solito una frazione di quelle esistenti;
- rivela la forma delle domande (ricerca di un dato, confronti, «qual è la nostra regola se…», calcoli), che determina l’architettura;
- diventa il set di test con cui verificherai ogni modifica successiva.
Se nessuno sa scrivere com’è fatta una buona risposta, nessuna ingegneria ne produrrà una. È la settimana più economica del progetto e quella che fa risparmiare di più.
La preparazione dei documenti è la maggior parte del lavoro
I modelli linguistici leggono bene. Non leggono bene un PDF scansionato di traverso, una tabella schiacciata in una sola riga o un’intestazione che si ripete in ogni frammento. La qualità della ricerca si decide molto prima che il modello veda qualcosa.
Conservare la struttura, non solo il testo
Titoli, elenchi, tabelle e numeri di sezione hanno un significato. Una clausola che dice «fatto salvo il punto 4.2» è inutile se il punto 4.2 è finito in un altro frammento senza etichetta. Convertiamo prima i documenti in un formato intermedio strutturato, conserviamo per ogni passaggio il percorso dei titoli («Regolamento aziendale › Ferie › Congedo parentale») e trattiamo le tabelle come tabelle. Per i documenti scansionati significa OCR con riconoscimento del layout e, nei casi più difficili, un modello in grado di leggere le immagini che descrive a parole figure e diagrammi.
Dividere secondo il significato
Frammenti di lunghezza fissa di qualche centinaio di token sono un punto di partenza ragionevole e una soluzione finale debole. Dividere per sezioni, lasciare una piccola sovrapposizione e associare a ogni frammento il percorso della sezione e i metadati del documento fa una differenza misurabile. Lo stesso vale per aggiungere a ogni frammento un riassunto di una frase dell’intero documento: così un passaggio sul «preavviso» sa ancora a quale contratto appartiene.
Restare aggiornati
I documenti cambiano. Un sistema RAG ha bisogno di una pipeline di acquisizione che rilevi i file nuovi e modificati, rielabori solo ciò che è cambiato, rimuova ciò che è stato eliminato e registri da quale versione di un documento proviene una risposta. Senza questo, l’assistente diventa poco a poco sicuro di sé e superato, il che è peggio di non avere alcun assistente.
Ricerca: l’ibrido batte l’ingegnoso
La ricerca vettoriale trova passaggi dal significato simile alla domanda. È ottima con le parafrasi e debole con le cose esatte: codici prodotto, nomi, numeri di articolo, messaggi di errore. La ricerca per parole chiave (BM25) è l’opposto. In pratica la configurazione robusta le combina entrambe, seguite da un passaggio di re-ranking che esamina insieme la domanda e ogni passaggio candidato e li ordina in base a quanto rispondono bene.
Alcune tecniche ulteriori si guadagnano un posto nella maggior parte dei sistemi in produzione:
- Filtri sui metadati per ciò che l’utente sa già: paese, linea di prodotto, tipo di documento, intervallo di date. Costano meno e sono più affidabili che sperare che la somiglianza faccia da sé.
- Riscrittura delle query: il modello trasforma una domanda di follow-up («e per i collaboratori esterni?») in una query autonoma.
- Ricerca in più passaggi per domande che richiedono più fonti: l’assistente cerca, legge e cerca di nuovo. Qui un sistema RAG comincia ad assomigliare a un agente, e va usato con criterio, perché ogni passaggio aggiunge latenza e costo.
Per iniziare non serve un database vettoriale esotico. PostgreSQL con pgvector gestisce una quota molto ampia dei corpus reali, tiene i dati in un sistema che già gestisci e rende i filtri sui permessi una semplice questione di SQL. I motori dedicati hanno senso su scala maggiore o con esigenze di prestazioni particolari.
I permessi non sono facoltativi
Se una persona non può aprire un documento, l’assistente non deve citarglielo. Sembra ovvio, ed è il requisito che più spesso si scopre tardi.
Lo schema affidabile è portare i diritti di accesso nell’indice: ogni frammento sa quali gruppi o utenti possono vederne la fonte, la query di ricerca filtra in base all’identità di chi chiede e il modello non riceve mai un passaggio a cui l’utente non ha diritto. Filtrare dopo la generazione non basta, perché il modello ha già letto il testo. Per i sistemi collegati a SharePoint, Google Drive o a un sistema documentale, sincronizziamo i permessi insieme ai contenuti e trattiamo una modifica dei permessi come una modifica dei contenuti.
Risposte verificabili
La fiducia nasce dalla possibilità di verificare. Ogni risposta dovrebbe mostrare le fonti, idealmente con un link alla sezione esatta, e il modello dovrebbe dire «non lo trovo nei documenti» quando la ricerca non restituisce nulla di pertinente. Un assistente che declina con onestà è molto più utile di uno che improvvisa.
Progettiamo anche il formato della risposta in base al compito. Un operatore di assistenza vuole una risposta breve e i passi da seguire. Un legale vuole la clausola citata alla lettera. Un team commerciale vuole una tabella di confronto. Lo stesso livello di ricerca serve tutti e tre con istruzioni diverse.
La valutazione trasforma le opinioni in numeri
Senza valutazione ogni modifica è una questione di gusti. Con la valutazione puoi capire se una nuova strategia di suddivisione, un altro modello o un prompt diverso hanno migliorato o peggiorato i risultati.
Misuriamo due cose separatamente:
| Livello | Domanda | Come verifichiamo |
|---|---|---|
| Ricerca | I passaggi giusti sono arrivati al modello? | Quota delle fonti attese ritrovate sul set di test |
| Generazione | La risposta è corretta, completa e fedele alle fonti? | Revisione di esperti su un campione e controlli automatici rispetto a risposte di riferimento |
Eseguire questa suite a ogni modifica, come i test unitari, impedisce alla qualità di peggiorare lentamente. Una volta in produzione, le domande reali con pollice su o giù e una revisione periodica degli esperti aggiungono nuovi casi al set.
Costi, latenza e scelta del modello
La maggior parte del costo di un sistema RAG sta in due punti: i token inviati al modello (il contesto recuperato ne è la parte principale) e il tempo di ingegneria per mantenere la pipeline. Inviare meno passaggi, ma migliori, abbassa i costi e di solito migliora anche le risposte. Il prompt caching aiuta quando le stesse istruzioni o gli stessi documenti lunghi tornano spesso. Indirizzare le domande semplici a un modello più piccolo e veloce, riservando il più potente a quelle difficili, tiene sotto controllo sia la spesa sia i tempi di risposta.
Per questo tipo di lavoro usiamo spesso Claude di Anthropic, perché legge bene documenti lunghi e densi e segue con cura le istruzioni su citazioni e rifiuti. Lo combiniamo con altri fornitori o modelli aperti quando costi, latenza o residenza dei dati lo richiedono. Poter cambiare modello senza ricostruire il sistema è un obiettivo di progettazione in sé, perché la scelta migliore di quest’anno potrebbe non esserlo l’anno prossimo.
Protezione dei dati nell’UE
Le domande delle aziende europee sono prevedibili e hanno risposta: dove vengono trattati i dati, se vengono usati per l’addestramento, per quanto tempo si conservano richieste e risposte, chi può vedere i log. I principali fornitori di modelli offrono il trattamento dei dati nell’UE e l’impegno contrattuale a non addestrare sui dati aziendali. I dati personali presenti nei documenti sorgente vanno ridotti al minimo o mascherati dove non servono alla risposta. Una breve descrizione dei flussi di dati e della finalità del sistema facilita molto il confronto con il tuo DPO e qualsiasi valutazione ai sensi del GDPR o dell’AI Act europeo.
Una prima versione sensata
Un primo rilascio in produzione che mostreremmo con tranquillità a utenti reali di solito comprende:
- una o due fonti ben scelte, non l’intera intranet;
- acquisizione strutturata con aggiornamenti automatici;
- ricerca ibrida con re-ranking e filtri sui permessi;
- risposte con fonti e un onesto «non trovato»;
- un set di valutazione di domande reali, eseguito a ogni modifica;
- un pulsante di feedback e una dashboard di ciò che le persone chiedono.
Tutto il resto, come nuove fonti, agenti che eseguono azioni o l’integrazione con Slack, Teams o il tuo CRM, si costruisce su queste fondamenta. Se stai valutando un assistente sui tuoi documenti, il nostro team IA e LLM può partire da una breve fase di analisi e da un prototipo funzionante sui tuoi dati reali, mentre l’ingegneria dei dati si occupa delle pipeline sottostanti. Oppure raccontaci semplicemente cosa hai in mente.