L’industria dell’intelligenza artificiale ha una memoria selettiva, quasi opportunistica; dimentica velocemente le promesse non mantenute e amplifica ogni miglioramento incrementale come se fosse una rivoluzione epistemologica. Alla fine del 2023, quando il paradigma del Retrieval-Augmented Generation veniva presentato come la strada maestra per rendere gli LLM affidabili, aggiornabili e tracciabili, sembrava che finalmente si fosse trovato un compromesso ingegneristico tra probabilità e verità. Una sorta di tregua tra statistica e conoscenza. Oggi, a distanza di pochi cicli di hype, la domanda non è più se il RAG funzioni, ma se stiamo davvero costruendo sistemi affidabili oppure semplicemente architetture più complesse che mascherano gli stessi limiti fondamentali.
Il punto di partenza è noto e, per certi versi, imbarazzante nella sua semplicità. I modelli linguistici non “sanno”, predicono. Non possiedono conoscenza nel senso classico, ma distribuzioni probabilistiche su sequenze di token. Questa distinzione, che nei paper accademici viene trattata con elegante distacco, nella realtà operativa diventa una frattura strutturale. Le allucinazioni non sono bug, sono feature emergenti di un sistema progettato per completare, non per verificare. In questo contesto, il RAG è stato presentato come una protesi cognitiva: aggiungere memoria esterna per compensare l’assenza di grounding.
La narrativa era convincente. Collegare il modello a basi di conoscenza aggiornate, recuperare documenti rilevanti, inserirli nel contesto e generare risposte più accurate. Un’idea quasi ovvia, che ricorda le prime architetture client-server degli anni Novanta, quando si scoprì che centralizzare i dati migliorava coerenza e controllo. Tuttavia, come spesso accade nella tecnologia, l’ovvio è facile da descrivere e difficile da implementare su scala.
Nel passaggio da naive RAG ad advanced RAG, fino alla visione di modular RAG, si è consumata una trasformazione silenziosa ma significativa. Il focus si è spostato dal modello alla pipeline, dall’algoritmo all’orchestrazione. Non è un dettaglio tecnico, è un cambio di paradigma industriale. Le aziende non stanno più “usando modelli”, stanno costruendo sistemi distribuiti in cui il modello è solo uno dei componenti, spesso nemmeno il più critico.
E qui emerge la prima contraddizione. Se il valore si sposta verso il sistema, allora l’ossessione per i benchmark dei modelli diventa quasi irrilevante. Una verità scomoda per un ecosistema che continua a misurare il progresso con leaderboard accademiche. La realtà operativa racconta altro. Un sistema RAG mediocre con retrieval ben progettato può outperformare un modello di frontiera mal orchestrato. Non è elegante da dire, ma è ciò che succede nei deployment reali.
Il problema, tuttavia, è che il retrieval non è una panacea. La qualità del recupero è il vero collo di bottiglia, e qui l’industria mostra tutte le sue fragilità. I vector database sono diventati il nuovo oggetto di culto, come lo erano i data lake un decennio fa. Promettono semantica, similarità, intelligenza latente. In pratica, spesso restituiscono risultati rumorosi, ridondanti o, peggio, plausibili ma irrilevanti. La differenza tra rilevanza semantica e utilità contestuale è sottile e raramente gestita con rigore.
Il contesto, poi, è diventato una risorsa scarsa, nonostante l’espansione delle finestre di token. Più documenti vengono recuperati, maggiore è il rischio di saturare il modello con informazioni contraddittorie o marginali. Il paradosso è evidente. Aggiungere conoscenza può peggiorare la qualità della risposta. Una lezione che l’ingegneria del software conosce da decenni: più input non significa automaticamente migliore output.
Nel frattempo, si moltiplicano i layer. Retrieval, re-ranking, chunking, embedding, tool use, agent orchestration. Ogni componente introduce complessità, latenza e nuovi punti di fallimento. La pipeline diventa fragile, difficile da debuggare, quasi opaca. In molti casi, si ha l’impressione di osservare sistemi che funzionano “per caso”, sostenuti da euristiche più che da principi solidi. Una situazione che ricorda le prime architetture di microservizi mal progettate, dove la modularità promessa si traduceva in caos distribuito.
La promessa del modular RAG, quella di sistemi ben orchestrati, composabili e robusti, è ancora lontana. Non per mancanza di strumenti, ma per assenza di standard. Ogni azienda costruisce la propria versione, spesso reinventando componenti già esistenti. L’ecosistema è frammentato, competitivo, e sorprendentemente poco interoperabile. Un’ironia sottile, considerando che il RAG nasce proprio come risposta alla frammentazione della conoscenza.
La questione della “vera reasoning” aggiunge un ulteriore livello di complessità. Integrare dati esterni migliora l’accuratezza fattuale, ma non risolve il problema del ragionamento. I modelli continuano a simulare inferenze senza una comprensione strutturata. Il risultato è una forma sofisticata di imitazione, non di cognizione. Inserire documenti nel contesto non trasforma un sistema probabilistico in un sistema logico. È un miglioramento incrementale, non una trasformazione ontologica.
Il mercato, tuttavia, sembra poco interessato a queste distinzioni filosofiche. La pressione competitiva spinge verso soluzioni rapide, deployabili, vendibili. Il RAG diventa quindi un layer commerciale, un’etichetta da inserire nelle slide. “AI powered by RAG” suona rassicurante, quasi scientifico. Ma spesso nasconde implementazioni superficiali, dove il retrieval è poco più di una ricerca keyword-based mascherata da semantica.
Un osservatore cinico potrebbe sostenere che stiamo vivendo una nuova fase di “complexity theater”. Più componenti, più acronimi, più architetture. Ma non necessariamente più affidabilità. La storia dell’informatica è piena di questi cicli. Dalla programmazione orientata agli oggetti ai microservizi, ogni paradigma promette ordine e produce, almeno inizialmente, una nuova forma di disordine.
Detto questo, sarebbe intellettualmente disonesto negare i progressi. I sistemi odierni sono indubbiamente più robusti rispetto a un anno fa. La capacità di integrare fonti esterne, di aggiornare le informazioni, di tracciare parzialmente le risposte rappresenta un passo avanti concreto. In alcuni domini, come il customer support o la documentazione tecnica, il RAG ha già dimostrato valore tangibile. Non è una rivoluzione, ma è un miglioramento significativo.
Il vero cambiamento, però, è meno visibile e più strutturale. Si sta formando una nuova disciplina, a metà tra ingegneria del software e information retrieval. Un territorio ibrido, dove competenze tradizionali vengono rimescolate con nuove esigenze. Ottimizzare un sistema RAG richiede conoscenze di embedding, ranking, distribuzione dei dati, UX conversazionale e persino psicologia cognitiva. Non è più un problema di machine learning in senso stretto, ma di architettura dei sistemi complessi.
Questa transizione da modelli a sistemi a infrastrutture è forse il segnale più importante. Il valore si sposta verso chi riesce a orchestrare, non solo a addestrare. Le grandi piattaforme lo hanno capito da tempo. Offrono non solo modelli, ma interi stack: vector storage, tool integration, agent frameworks. L’obiettivo è chiaro. Rendere il RAG una commodity infrastrutturale, come il cloud computing.
In questo scenario, la domanda iniziale assume una sfumatura diversa. Non si tratta più di capire se stiamo seguendo la roadmap, ma se la roadmap stessa era sufficientemente ambiziosa. Il RAG risolve alcuni problemi, ma non affronta il nodo centrale: la natura probabilistica degli LLM. Finché i modelli continueranno a generare senza verificare, ogni sistema costruito sopra di essi erediterà una quota di incertezza.
Una frase che circola sempre più spesso nei corridoi delle aziende tecnologiche sintetizza bene la situazione. “We are not eliminating hallucinations, we are managing them.” Non è un fallimento, è un cambio di aspettativa. L’affidabilità diventa una questione di probabilità, non di certezza. Un concetto familiare nel mondo finanziario, meno in quello informatico.
La sensazione, osservando l’evoluzione attuale, è che ci troviamo in una fase intermedia. Abbiamo superato l’entusiasmo ingenuo per i modelli puri, ma non abbiamo ancora raggiunto la maturità dei sistemi realmente affidabili. Il RAG è un ponte, non una destinazione. Un’architettura di transizione che ci avvicina a sistemi più robusti, ma che porta con sé nuove complessità e nuovi rischi.
In ultima analisi, la risposta alla domanda iniziale è inevitabilmente ambivalente. Sì, stiamo facendo progressi verso sistemi più affidabili. No, non stiamo ancora costruendo qualcosa che possa essere definito veramente robusto in senso ingegneristico. La differenza tra i due stati è sottile, ma cruciale. È la differenza tra un sistema che funziona nella maggior parte dei casi e uno che può essere considerato affidabile per definizione.
Il mercato, come sempre, deciderà quale livello di affidabilità è sufficiente. Nel frattempo, l’industria continuerà a costruire, iterare, complicare. Perché, in fondo, aggiungere layer è più facile che risolvere problemi fondamentali. E perché, come insegna la storia della tecnologia, la complessità è spesso il prezzo che paghiamo per evitare di affrontare le verità più scomode.
Risorse: https://www.researchgate.net/figure/Technology-tree-of-RAG-research-10_fig2_394104475