Negli ultimi anni, molte aziende hanno abbracciato con entusiasmo la retrieval-augmented generation (RAG) come la soluzione chiave per integrare i modelli linguistici di grandi dimensioni (LLM) nei propri processi decisionali, nei sistemi di assistenza e nelle automazioni interne. L’idea alla base di RAG è semplice e potente: invece di affidarsi esclusivamente alle conoscenze statiche con cui un modello è stato addestrato, si indica al sistema di recuperare informazioni aggiornate e specifiche da fonti aziendali—database, documenti, intranet—e di usarle per “ancorare” le risposte generate. Questo approccio dovrebbe, in teoria, ridurre il rischio di allucinazioni da parte dell’IA e consentire risposte più affidabili e contestualizzate rispetto alle esigenze specifiche dell’organizzazione.
Tuttavia molte imprese si trovano oggi davanti a un paradosso: stanno misurando e ottimizzando la parte sbagliata di RAG, con conseguenze concrete sulla qualità delle applicazioni AI e sulla gestione dei rischi. Secondo l’autore, infatti, le metriche e i modelli mentali finora adottati dalle squadre di sviluppo e dagli architetti AI si concentrano troppo sulle uscite finali—ovvero sulla qualità apparente della risposta generata—ignorando ciò che accade “sotto il cofano” nella fase di recupero delle informazioni.
Questa distinzione non è banale. Nel modello tradizionale di RAG, si tende a considerare il recupero come un semplice step preliminare, qualcosa di simile a una “feature” del processo di generazione. Ma nella pratica delle architetture enterprise, dove i sistemi operano ormai non solo per rispondere a domande isolate ma per alimentare processi automatizzati, workflow agentici e sistemi semi-autonomi, la qualità del recupero diventa il substrato stesso dell’affidabilità dell’IA. Quando un agente software prende decisioni, esegue verifiche normative o genera report basandosi su documenti interni, qualsiasi errore o omissione nella fase di recupero può avere un effetto a catena: non solo una singola risposta imprecisa, ma una decisione operativa errata o una violazione di compliance.
Uno degli aspetti critici evidenziati dall’articolo riguarda la cosiddetta freshness, ovvero l’“attualità” delle informazioni recuperate. In molte implementazioni di RAG, gli indici sono costruiti periodicamente e aggiornati in modo asincrono rispetto alle modifiche reali delle fonti dati. Ciò significa che, anche se un modello sembra rispondere fluentemente e plausibilmente, potrebbe in realtà basarsi su informazioni obsolete. Finché la risposta è usata in contesti che richiedono supervisione umana, questo problema può rimanere nascosto; ma in ambienti agentici e automatizzati, il rischio che decisioni cruciali siano prese su dati non aggiornati cresce costantemente.
Un altro elemento centrale della disamina riguarda la governance del recupero. Tradizionalmente, le politiche di sicurezza e accesso ai dati vengono definite per i database e per i modelli separatamente, con regole distinte a seconda che un utente o un’applicazione stia accedendo alle informazioni. Ma quando un modello linguistico effettua il recupero all’interno di un sistema RAG, queste barriere possono essere facilmente aggirate se non vengono progettate in modo coerente anche per la fase di retrieval. Senza un controllo semantico e policy-aware del recupero, agenti e applicazioni possono finire per accedere a dati al di fuori del loro ambito previsto, con potenziali rischi di violazione dei vincoli di privacy o di esposizione di informazioni sensibili.
Il punto, insomma, è che non basta valutare la qualità finale della generazione di testo. Troppe organizzazioni si limitano a metriche osservabili a valle, come la correttezza apparente delle risposte, la coerenza grammaticale o la soddisfazione superficiale degli utenti. Ma questi indicatori non dicono nulla sulla qualità intrinseca del recupero, sulla completezza del contesto fornito al modello, sulla presenza di dati obsoleti o irrilevanti, o sulla correttezza delle politiche di accesso che hanno regolato il processo. In altre parole, un modello può generare un testo plausibile sulla base di un recupero difettoso, e questo può dare un falso senso di sicurezza alle squadre tecniche e ai leader aziendali.
Per superare questo paradigma, l’articolo invita le imprese a ripensare RAG non come una feature applicativa marginale, ma come una componente infrastrutturale di primo piano, alla pari di componenti storici come calcolo, rete o storage. Solo trattandolo come tale è possibile adottare pratiche di engineering sistematico: architetture di controllo che monitorino la freschezza degli indici in tempo reale, governance fine-grained che assicuri che il recupero rispetti le policy aziendali, metriche che valutino la qualità del recupero in modo autonomo dalla generazione, e strumenti di auditing che permettano di ricostruire esattamente quali informazioni sono state recuperate e perché.