RAG tradizionale: il modello Naive

Il Naive RAG, o RAG standard, si basa su una pipeline rigida a tre fasi: Retrieve → Read → Generate. L'utente invia una domanda, il sistema la converte in un embedding vettoriale, esegue una ricerca di similarità su un database di vettori e recupera i top‑k frammenti più pertinenti. Questi frammenti vengono poi inseriti nella finestra di contesto del Large Language Model (LLM), che genera la risposta.

Immaginate uno studente che, per preparare un esame, inserisce una singola parola chiave nel catalogo della biblioteca, prende i primi tre libri che trova e scrive un saggio basandosi solo su quel materiale, senza verificare se le fonti rispondono davvero alla domanda. Questo è il funzionamento interno del Naive RAG.

Durante l’ingestione, i documenti vengono suddivisi in chunk, trasformati in vettori densi mediante un modello di embedding e memorizzati in un database ottimizzato per la ricerca approssimata dei più vicini (approximate nearest‑neighbor). Al momento dell’inferenza, la query dell'utente è embeddata con lo stesso modello; il database restituisce i chunk più vicini nello spazio ad alta dimensione e questi vengono passati al LLM.

Il risultato è stato rivoluzionario: è stato possibile costruire assistenti di knowledge base aziendali, sistemi di Q&A e sintetizzatori di documenti che rimangono ancorati a fonti verificate. Per molte applicazioni, il Naive RAG rimane una soluzione efficace e a basso costo.

Limiti della linearità

Il punto debole principale è la linearità. Il recupero avviene una sola volta; se la query è mal formulata, se l'informazione rilevante è sparsa su più documenti, o se la risposta richiede più passaggi di ragionamento, il pipeline non può recuperare.

Quando il recupero fallisce, il modello deve generare comunque una risposta basandosi su un contesto incompleto o irrilevante. Non può riconoscere l'insuccesso né provare un approccio alternativo.

Esempio pratico: “Quali politiche regolamentari segue l'azienda che ha acquisito WhatsApp nell’Unione Europea?”. La risposta richiede due step: identificare l’acquirente (Meta) e poi ricercare le politiche UE di Meta. Una singola ricerca vettoriale per “WhatsApp EU regulatory policies” difficilmente restituisce entrambi i pezzi di informazione. Il Naive RAG non può scomporre la domanda in sotto‑query, né utilizzare il risultato intermedio per una ricerca successiva.

Se i risultati top‑k sono irrilevanti, il LLM può:

    • generare una risposta non ancorata alle fonti (aumento delle hallucination);
    • restituire un “non ho abbastanza informazioni” poco utile in contesti aziendali critici.

Agentic RAG: il retrieval come agente autonomo

L’Agentic RAG ridefinisce completamente il problema del recupero. L’LLM non è più un semplice consumatore di contesto, ma un “motore di ragionamento” che orchestra l’intero processo di retrieval.

La struttura diventa un ciclo: Plan → Execute → Evaluate → Repeat. Il modello decide cosa cercare, dove cercare, valuta i risultati e, se necessario, itera finché non ritiene di avere abbastanza informazioni per generare una risposta affidabile.

Meccanismi chiave dell’Agentic RAG

Quattro meccanismi distinti risolvono i fallimenti del Naive RAG:

    • Routing della query: il modello analizza la domanda e sceglie la fonte più adatta (database vettoriale, database SQL strutturato, ricerca web in tempo reale, ecc.). Questo evita di forzare ogni query in un unico meccanismo di ricerca.
    • Decomposizione delle domande: le query complesse vengono spezzate in sotto‑domande indipendenti. Nell’esempio di WhatsApp, il sistema prima chiede “Chi ha acquisito WhatsApp?” e, una volta ottenuta la risposta (Meta), formula una seconda domanda su “Quali sono le politiche UE di Meta?”.
    • Valutazione iterativa del contesto: dopo ogni recupero, il modello verifica se i chunk restituiti rispondono alla sotto‑domanda. Se i risultati sono insufficienti o contraddittori, il ciclo ricomincia con una nuova formulazione della query o con una fonte diversa.
    • Orchestrazione dinamica: l’LLM può combinare più fonti in una singola risposta, integrando dati strutturati, informazioni aggiornate da web e documenti interni, mantenendo la coerenza logica.

Questo approccio trasforma il retrieval da un pre‑processing statico a un processo auto‑correttivo e adattivo.

Esempio di flusso Agentic RAG

1. Input: “Quali politiche regolamentari segue l'azienda che ha acquisito WhatsApp nell'UE?”

2. Routing: il modello riconosce che la prima parte richiede un dato strutturato (acquirente) e la seconda una ricerca normativa.

3. Decomposizione: genera le sotto‑query “Chi ha acquisito WhatsApp?” e “Quali sono le politiche UE di Meta?”.

4. Esecuzione 1: interroga un database di fatti aziendali, ottiene “Meta”.

5. Valutazione 1: conferma che la risposta è corretta e la usa per costruire la seconda query.

6. Esecuzione 2: esegue una ricerca semantica su documenti normativi di Meta.

7. Valutazione 2: controlla la pertinenza dei risultati; se necessario, effettua un nuovo ciclo.

8. Generazione: una volta raccolte le informazioni sufficienti, il modello genera una risposta completa e citata.

Quando scegliere l’uno o l’altro

Naive RAG è consigliato quando:

    • Le query sono semplici e ben definite.
    • Le informazioni risiedono in un unico repository strutturato.
    • Il budget computazionale è limitato e la latenza deve rimanere minima.

Agentic RAG è preferibile quando:

    • Le domande richiedono ragionamento multi‑step o decomposizione.
    • Le fonti sono eterogenee (documenti, tabelle, web).
    • È necessario garantire alta affidabilità e ridurre al minimo le hallucination.
    • Il contesto aziendale è dinamico e richiede aggiornamenti in tempo reale.

In pratica, molte organizzazioni iniziano con un Naive RAG per i casi d'uso più comuni e, una volta identificati i limiti, introducono componenti agentic per le richieste più complesse.

Implementazione pratica

Per passare da Naive a Agentic RAG occorre:

    • Integrare un layer di orchestrazione (ad es. LangChain, LlamaIndex) che consenta al LLM di invocare tool differenti.
    • Definire un registro di fonti con metadati (tipo, endpoint, costi).
    • Costruire prompt di pianificazione che guidino la decomposizione della query.
    • Implementare meccanismi di feedback (valutazione della rilevanza, rilevamento di conflitti) e loop di retry.

Queste componenti aggiuntive aumentano la complessità del sistema, ma forniscono un guadagno significativo in termini di precisione e robustezza.

Conclusioni

L’evoluzione dal Naive RAG all’Agentic RAG rappresenta un passo verso sistemi di intelligenza artificiale più autonomi e consapevoli delle proprie limitazioni. Mentre il primo offre velocità e semplicità per compiti lineari, il secondo introduce una capacità di ragionamento iterativo, routing intelligente e valutazione continua, indispensabili per applicazioni aziendali critiche e query complesse.

La scelta dipende dal bilancio tra complessità architetturale, costi computazionali e requisiti di accuratezza. Con una chiara comprensione dei punti di forza e di debolezza di ciascuna architettura, le organizzazioni possono progettare soluzioni RAG su misura, garantendo risposte affidabili e riducendo drasticamente le hallucination dei modelli di linguaggio.