Di Retrieval-Augmented Generation si parla ovunque, quasi sempre allo stesso modo: si prende un modello linguistico, gli si «collegano» i documenti aziendali, e da quel momento risponde citando le fonti. La realtà, come spesso accade, è più interessante della brochure.
Noi lo sappiamo perché una piattaforma RAG l'abbiamo costruita e messa in esercizio davvero — interamente on-premise, su hardware nel nostro perimetro, con modelli aperti. Oggi è la base di ACME ECMS IA & RAG Integration, e nella pagina dedicata trovi gli schemi dell'infrastruttura e una demo del suo funzionamento. Qui invece raccontiamo quello che gli schemi non dicono: le cinque lezioni che hanno cambiato il nostro modo di progettare questi sistemi.
1 · La qualità si decide nel retrieval, non nel modello
La tentazione di chi inizia è concentrarsi sul modello: quale LLM, quanti parametri, quale versione. È la parte sbagliata del problema. Se i passaggi che recuperano i documenti portano al modello il contenuto sbagliato, il modello più potente del mondo farà una cosa sola: riassumere bene la cosa sbagliata.
Il lavoro vero sta a monte: come si spezzano i documenti (il chunking), con quali rappresentazioni si indicizzano (gli embeddings), e soprattutto quanta struttura si dà alla base di conoscenza. Nella nostra piattaforma, accanto all'indice vettoriale vive un knowledge graph: entità e relazioni estratte dai documenti, che permettono di rispondere anche a domande che attraversano più documenti — dove la sola somiglianza semantica non basta.
2 · Recupero ibrido più re-ranking: due passaggi, non uno
Un solo passaggio di ricerca deve scegliere tra due obiettivi in conflitto: non perdere nulla di rilevante e non far passare rumore. La soluzione che ha funzionato per noi è separarli.
Il primo passaggio è largo e ibrido — vettori, parole chiave e grafo insieme — e ottimizzato per il richiamo: meglio un candidato in più che uno in meno. Il secondo passaggio è un re-ranker, un modello dedicato che riordina i candidati per pertinenza reale rispetto alla domanda, e taglia ciò che somiglia ma non risponde. È uno dei componenti che più ha alzato la qualità percepita delle risposte: le fonti citate smettono di essere «vicine al tema» e iniziano a essere quelle giuste.
3 · Non tutte le domande meritano il RAG
Un errore comune è trattare ogni richiesta allo stesso modo: qualunque cosa chieda l'utente, si lancia l'intera pipeline — ricerca, re-ranking, generazione con contesto. Il risultato sono risposte lente e costose anche quando non serviva nulla di tutto ciò.
Nella nostra architettura la prima decisione la prende un planner: un componente che classifica la richiesta e sceglie la strada. Un saluto o una domanda di cultura generale prendono la via diretta, senza toccare la base documentale; una domanda sui contratti, sulle procedure o sui progetti attiva la pipeline completa. Sembra un dettaglio: in esercizio è la differenza tra un sistema che «risponde quando può» e un servizio con latenze e consumi prevedibili.
4 · Senza metriche stai solo indovinando
Cambi il modello di embedding e le risposte «sembrano» migliori. Rivedi il chunking e «sembrano» peggiori. Sembrano a chi? Su quali domande? La sensazione di chi sviluppa non è una metrica, e su un sistema che risponde in linguaggio naturale l'occhio si abitua in fretta.
Per questo la piattaforma include una valutazione sistematica della qualità (usiamo il framework RAGAS, con un set di prova costruito in italiano sui nostri casi d'uso): a ogni modifica misuriamo quanto le risposte restano fedeli alle fonti, quanto sono pertinenti alla domanda e quanto è buono il contesto recuperato. È lo stesso principio del nostro metodo — misura, analizza, migliora, verifica — applicato all'IA: ogni intervento parte da un numero e torna a un numero.
La domanda giusta non è «l'IA risponde bene?», ma «rispetto a cosa, misurato come, e meglio o peggio di ieri?».
5 · On-premise è fattibile — e a volte è l'unica strada
La lezione forse più controintuitiva: per un RAG aziendale non serve un hyperscaler. Modelli aperti su GPU dimensionate al caso d'uso, dentro un'infrastruttura governata, coprono la stragrande maggioranza delle esigenze reali — e portano un vantaggio che nessuna API remota può offrire: i dati non escono mai dal perimetro.
Per interi settori questo non è un vezzo, è un requisito. In Sanità i dati relativi alla salute godono della protezione rafforzata dell'art. 9 del GDPR; nella Pubblica Amministrazione pesano sovranità del dato e indicazioni sul cloud. Un'architettura on-premise (o su private cloud in Italia) risolve il problema alla radice — e, con modelli aperti, elimina anche il vendor lock-in.
L'altra metà della lezione: un sistema del genere va gestito come un servizio, non come un esperimento. Monitoraggio dei componenti, backup della base di conoscenza, aggiornamenti controllati dei modelli: la parte «di esercizio» conta quanto quella di progettazione.
Da dove partire
Se dovessimo condensare le cinque lezioni in un consiglio solo: parti piccolo, ma parti misurando. Un caso d'uso concreto, un corpus documentale definito, metriche di qualità dal primo giorno — e un'architettura che non ti costringa a scegliere tra innovare e tenere i dati al loro posto.
Come è fatta la nostra piattaforma — schemi d'infrastruttura, flusso logico e una demo animata del ciclo di vita — è raccontato nella pagina IA, Agenti e RAG. Se invece vuoi capire cosa potrebbe fare sul tuo patrimonio documentale, parliamone.
