È in questo contesto che si inserisce la Retrieval-Augmented Generation (RAG), un approccio architetturale che combina modelli generativi e sistemi di recupero delle informazioni, permettendo di costruire soluzioni di AI più affidabili, aggiornabili e osservabili.
Perché il recupero delle informazioni è fondamentale
I sistemi di Information Retrieval (IR) esistono da decenni: motori di ricerca, database indicizzati, sistemi documentali. La loro forza è sempre stata la stessa, ovvero recuperare informazioni pertinenti a partire da una query, in modo deterministico e tracciabile.
Gli LLM, invece, non "recuperano" informazioni: le ricostruiscono statisticamente a partire dal loro addestramento. Questo è potente, ma problematico quando:
le informazioni devono essere aggiornate;
i dati sono specifici dell’azienda;
sono richieste affidabilità, spiegabilità e/o conformità normativa.
RAG nasce proprio per unire il meglio di questi due mondi: usare il recupero delle informazioni per fornire contesto rilevante e verificabile, e la generazione per trasformare quel contesto in risposte utili e naturali.
Cos’è la Retrieval-Augmented Generation
In un sistema RAG il modello generativo non risponde "a memoria". Prima di generare una risposta, infatti, viene usata una query dell’utente per recuperare documenti o dati rilevanti da una knowledge base. Questi contenuti vengono forniti al modello come contesto, permettendo al modello di generare una risposta basata sia sulla query che sulle informazioni recuperate.
Il risultato è un sistema che:
riduce drasticamente le allucinazioni;
può lavorare su dati proprietari;
è aggiornabile senza riaddestrare il modello;
permette di tracciare le fonti delle risposte.
Facciamo un esempio
Consideriamo uno scenario ipotetico in cui uno sviluppatore Moku interroga il proprio LLM di fiducia con la seguente domanda: “Puoi spiegarmi quali sono le linee guida aziendali presso Moku, per quanto riguarda l’uso di Git?”
Nel caso in cui tale LLM non sia agganciato in alcun modo alla knowledge base di Moku, ecco che potrebbe rispondere in uno dei due seguenti modi:
“Non sono a conoscenza delle best-practice Git adottate in Moku” – nel caso migliore, in cui l’LLM è addestrato per riconoscere situazioni di incertezza e rispondere in maniera adeguata.
“Certo! Presso Moku…” – nel caso peggiore, in cui genera una risposta verosimile ma senza fondamenta, una cosiddetta “allucinazione”.
Viceversa, nel caso in cui l’LLM sia parte di un sistema RAG che ha accesso alla knowledge base di Moku, ecco che la risposta sarà realisticamente basata su documentazione concreta relativa all’utilizzo aziendale di Git, riducendo al minimo la possibilita’ che l’LLM produca informazioni verosimili ma errate.
Un esempio di risposta, in questo caso, potrebbe essere “Secondo il documento ‘Git - Linee guida e best-practice’, sono definiti diversi punti e casistiche cardine per un utilizzo ideale di Git: ...”
Costruire un sistema RAG
Costruire un sistema RAG efficace non è solo una questione di tecnologia, ci sono due aspetti sono particolarmente critici.
Qualità dei dati
Un principio vale sempre: garbage in, garbage out. Se buttiamo dentro spazzatura, abbiamo in cambio spazzatura.
La qualità delle risposte dipende direttamente dalla qualità della knowledge base :
dati obsoleti o contraddittori generano risposte incoerenti;
documenti troppo lunghi o mal strutturati peggiorano il retrieval;
mancanza di metadati riduce il controllo sul contesto.
Investire tempo nella governance del dato è spesso più importante che cambiare modello.
Osservabilità e monitoraggio
Un sistema RAG deve essere osservabile:
quali documenti vengono recuperati?
con quale confidenza?
quanto spesso il modello ignora il contesto?
dove fallisce il retrieval ?
Log, metriche e tracing permettono di:
migliorare iterativamente il sistema;
individuare colli di bottiglia;
costruire fiducia interna ed esterna.
Senza osservabilità, l’AI rimane una "scatola nera".
In Moku, abbiamo affrontato due casi studio che ci hanno permesso di esplorare meglio questo argomento e testarne le potenzialità.
Nel primo caso studio, l’implementazione di un assistente RAG è stata pensata come parte integrante di un’app mobile di supporto alla gravidanza e alla prima infanzia.
In questo contesto, l’accuratezza dei contenuti generati è stata un requisito imprescindibile: le risposte dell’assistente si basano infatti su informazioni spesso di natura sanitaria, validate da professionisti, e devono quindi riflettere fedelmente la knowledge base senza introdurre ambiguità o semplificazioni improprie.
Un ulteriore requisito dell’assistente era quello di poter guidare l’utente verso sezioni, contenuti e funzionalità rilevanti, trasformando il RAG in uno strumento di navigazione assistita.
Per questi motivi, è stato centrale il lavoro sulla qualità dei dati e sulla loro strutturazione, con una rappresentazione dell’app studiata appositamente per il retrieval. Parallelamente, l’integrazione con l’esperienza utente dell’app ha richiesto particolare attenzione: il chatbot non è un elemento isolato, ma un touchpoint che deve inserirsi in modo naturale e coerente nel percorso dell’utente, mantenendo continuità tra ricerca, risposta e fruizione dei contenuti.
Nel secondo caso studio, l’assistente RAG è stato progettato per supportare professionisti sanitari nell’accesso a una base di conoscenza proprietaria ad alta specializzazione, con la possibilità di interrogare anche documentazione clinica specifica del cliente finale.
Qui l’accuratezza non è solo una buona pratica, ma un vincolo tecnico e normativo: le risposte devono essere precise, verificabili e allineate a standard medici elevati, pena la perdita di fiducia da parte di un’utenza esperta.
Per questo motivo, l’osservabilità del sistema ha avuto un ruolo centrale, permettendo di monitorare quali fonti vengono recuperate, come vengono utilizzate dal modello e dove il retrieval può fallire.
Un ulteriore elemento di complessità è stato l’integrazione con altri servizi esistenti che gestiscono dati sensibili, come referti e informazioni cliniche.
La progettazione del sistema RAG ha quindi dovuto includere meccanismi rigorosi di isolamento del contesto, controllo degli accessi e protezione della privacy, dimostrando come, in scenari ad alta criticità, un’architettura RAG efficace sia tanto una questione di ingegneria del dato e sicurezza quanto di modelli linguistici.
La Retrieval-Augmented Generation rappresenta oggi uno degli approcci più maturi e pragmatici per portare l’AI generativa in produzione. Non è una scorciatoia, né una soluzione magica, ma un pattern architetturale che consente di costruire sistemi utili, affidabili e integrabili nei processi aziendali.
In definitiva, il valore non sta solo nel modello, ma nell’ecosistema che lo circonda: dati, pipeline, retrieval, agenti e osservabilità. È lì che l’AI smette di essere una demo e diventa un vero strumento di lavoro.
