Le Oltre 20 Principali Architetture RAG Agentiche

Il panorama dell'intelligenza artificiale continua a evolversi rapidamente, e con esso emergono nuove architetture progettate per spingere i confini delle capacità dei modelli linguistici di grandi dimensioni (LLM). Tra queste, l'Agentic Retrieval-Augmented Generation (RAG) si sta affermando come una soluzione all'avanguardia che eleva il RAG tradizionale, potenziando le prestazioni degli LLM e abilitando una maggiore specializzazione. Questa tecnologia non si limita a recuperare informazioni, ma permette ai sistemi di intelligenza artificiale di ragionare, prendere decisioni e agire autonomamente.

Recentemente, è stato condotto un benchmark approfondito per valutare le prestazioni dell'Agentic RAG nella gestione di due compiti critici: l'instradamento intelligente tra più database e la generazione di query precise. Questo studio mira a illustrare come i framework e le librerie Agentic RAG si differenziano dal RAG standard, quali benefici offrono e quali sfide devono affrontare per sbloccare il loro pieno potenziale.

Come l'Agentic RAG migliora la gestione dei dati aziendali

Nelle aziende moderne, i dati sono spesso distribuiti su una moltitudine di database, ognuno contenente informazioni specializzate pertinenti a domini o compiti specifici. Ad esempio, un database potrebbe archiviare registri finanziari, mentre un altro gestisce dati sui clienti o dettagli di inventario. Un sistema Agentic RAG efficace deve essere in grado di instradare intelligentemente la query di un utente al database più rilevante per recuperare informazioni accurate. Questo processo implica l'analisi della query, la comprensione del contesto e la selezione della fonte di dati appropriata da un insieme di database disponibili.

Al centro di un sistema Agentic RAG risiede la capacità dell'LLM di ragionare e agire autonomamente per raggiungere un obiettivo. L'approccio basato sul function-calling, impiegato nel benchmark, consente ai modelli di dimostrare un vero comportamento agentico attraverso la selezione autodiretta del database e la raccolta iterativa di informazioni. Questo si manifesta attraverso diverse capacità chiave:

• Decisione autonoma: L'agente analizza la query utente in entrata e determina autonomamente quale funzione di database chiamare in base al contesto della query e alle descrizioni delle funzioni disponibili. Questo processo decisionale avviene senza regole di instradamento predeterminate, dimostrando capacità di ragionamento autentiche.
• Esecuzione multi-step: L'agente tipicamente esegue più chiamate di funzione in sequenza, prima per identificare e accedere al database rilevante, poi per raccogliere informazioni dettagliate sullo schema, e infine per affinare la sua comprensione prima di generare la query SQL. Questo processo iterativo rispecchia gli approcci umani di risoluzione dei problemi.
• Capacità di autocorrezione: Quando le chiamate di funzione iniziali non forniscono informazioni sufficienti, l'agente può decidere autonomamente di effettuare chiamate aggiuntive con parametri raffinati, dimostrando un comportamento adattivo che va oltre i semplici sistemi di recupero.
• Comportamento orientato all'obiettivo: Durante tutto il processo, l'agente mantiene la focalizzazione sulla generazione di una query SQL accurata, utilizzando il risultato di ogni chiamata di funzione per informare decisioni e azioni successive.

Questo modello di interazione autonomo e multi-turn differenzia fondamentalmente l'Agentic RAG dai sistemi RAG tradizionali che seguono percorsi predeterminati e meccanismi di recupero "single-shot".

La metodologia del benchmark

Questo benchmark valuta la capacità dei Large Language Models (LLM) di funzionare come agenti autonomi all'interno di una pipeline di Retrieval-Augmented Generation (RAG). Specificamente, misura due competenze fondamentali:

1. L'accuratezza dell'instradamento a più database.
2. La generazione di query SQL sematicamente accurate.

Dataset e selezione dei dati

Il benchmark utilizza il dataset BIRD-SQL¹, un benchmark accademico ampiamente adottato per compiti text-to-SQL. BIRD-SQL fornisce domande in linguaggio naturale abbinate a identificatori di database "ground truth" e query SQL "gold-standard", rendendolo ideale per valutare sia l'accuratezza dell'instradamento che la qualità della generazione delle query.

Dal dataset completo BIRD-SQL, è stato curato un sottoinsieme di 500 domande distribuite su cinque database distinti che coprono domini diversi:

• Database finanziario: contenente dati su prestiti, conti e transazioni finanziarie.
• Database di carte di debito: con informazioni su carte, clienti e pagamenti.
• Database di inventario: gestisce prodotti, magazzino e fornitori.
• Database clienti: dettagli sui profili dei clienti, acquisti e interazioni.
• Database di risorse umane: informazioni sui dipendenti, stipendi e dipartimenti.

Ogni domanda ha esattamente un database target corretto. La risposta a ogni domanda risiede in un solo database specifico, richiedendo all'agente di prendere una decisione di instradamento definitiva.

Il fattore di confondimento della similarità semantica

Per valutare le capacità di ragionamento dell'agente oltre la semplice corrispondenza di parole chiave a livello superficiale, è stata introdotta la similarità semantica cross-database come fattore di confondimento deliberato durante la selezione delle domande.

• Domanda A (DB finanziario): “Per il cliente il cui prestito è stato approvato per primo il 1993/7/5, qual è il tasso di aumento del suo saldo conto dal 1993/3/22 al 1998/12/27?”
• Domanda B (DB carta_di_debito): “Per il cliente che ha pagato 634.8 il 2012/8/25, qual è stato il tasso di diminuzione dei consumi dal 2012 al 2013?”

Entrambe le domande seguono schemi semantici quasi identici: identificano un cliente specifico attraverso un evento di transazione, quindi calcolano una variazione di tasso su un periodo di tempo. Eppure i database corretti differiscono completamente; uno richiede dati su prestiti e conti, mentre l'altro necessita di dati su transazioni e consumi. Questo costringe l'agente a eseguire un ragionamento contestuale più profondo sul dominio dei dati piuttosto che affidarsi a parole chiave finanziarie a livello superficiale che potrebbero corrispondere a entrambi i database.

Archiviazione dello schema e architettura agentica

Lo schema e una breve descrizione in linguaggio naturale di ciascun database sono stati archiviati in ChromaDB, un database vettoriale utilizzato per un recupero semantico efficiente. La collezione di ogni database contiene:

• Metadati dello schema: nomi delle tabelle, nomi delle colonne, tipi di dati.
• Descrizioni in linguaggio naturale: una breve spiegazione dello scopo di ciascuna tabella e delle relazioni tra le tabelle.

Questa configurazione consente all'agente di recuperare informazioni rilevanti sullo schema tramite ricerca semantica dopo aver selezionato un database target.

Un'architettura agentica basata su function-calling è stata impiegata su tutti i modelli per garantire un confronto equo e standardizzato. Ciascuno dei cinque database è stato rappresentato come una funzione richiamabile distinta (strumento) con parametri standardizzati. Questo design sfrutta le capacità native di function calling di ciascun modello, consentendo ai modelli di agire autonomamente:

• Selezionare la funzione (database) appropriata: In base all'intento della query.
• Estrarre gli argomenti della funzione: Ad esempio, nomi di tabelle o condizioni di filtro.
• Comprendere i risultati della funzione: Utilizzando le descrizioni dello schema recuperato per formulare query SQL accurate.

Questo approccio mantiene una metodologia di valutazione coerente tra diverse famiglie di modelli, inclusi i modelli tradizionali e quelli ottimizzati per il ragionamento.

Il loop agentico multi-turn

Il sistema implementa un vero e proprio loop agentico multi-turn anziché una pipeline fissa:

• Query Utente: L'utente invia una domanda in linguaggio naturale.
• Decisione di Instradamento: L'agente LLM utilizza la sua funzione di chiamata per selezionare il database più rilevante.
• Recupero dello Schema: L'agente richiama una funzione per recuperare lo schema dettagliato e le descrizioni dal database selezionato.
• Generazione SQL: Con lo schema come contesto, l'agente genera una query SQL sematicamente accurata per il database selezionato.
• Risposta: I risultati della query vengono recuperati ed elaborati, e l'agente fornisce la risposta all'utente.

Questo flusso conversazionale multi-turn differenzia il benchmark dagli approcci RAG "single-shot" tradizionali. L'agente mantiene il contesto completo attraverso i turni, può osservare i risultati delle sue azioni e può affinare iterativamente il suo approccio, tutte caratteristiche distintive di un vero comportamento agentico.

Metriche di valutazione

La valutazione delle prestazioni si è basata su due metriche principali:

• Accuratezza dell'instradamento al database

  La prima chiamata di funzione del database dell'agente viene registrata come sua decisione di instradamento. Questa viene confrontata con il database "ground truth" specificato nel dataset BIRD-SQL. Metrica: Accuratezza dell'instradamento al database (% selezioni corrette sul totale delle domande).

• Qualità della query SQL

  La query SQL generata dall'agente viene valutata utilizzando un approccio LLM-as-Judge. Un modello giudice separato (Claude 4 Sonnet) riceve sia la SQL generata dall'agente che la SQL "ground truth" di BIRD-SQL, e assegna un punteggio di similarità semantica su una scala da 0 a 5:
  • 5: Query identiche o funzionalmente equivalenti.
  • 4: Query quasi identiche, differenze minori senza impatto sul risultato.
  • 3: Query sematicamente simili, differenze sostanziali ma producono un output simile.
  • 2: Query con alcune somiglianze, ma con differenze significative che portano a output diversi.
  • 1: Query con somiglianze minime, output largamente diversi.
  • 0: Query completamente non correlate o errate.

  Importante decisione di progettazione: La qualità della SQL viene valutata solo quando l'agente seleziona il database corretto. Se l'agente ha instradato a un database sbagliato, riceve un punteggio automatico di 0, poiché una query SQL su uno schema sbagliato è intrinsecamente priva di significato. Questo assicura che la metrica della qualità SQL rifletta puramente la capacità di generazione delle query, non contaminata da errori di instradamento.

I principali framework e librerie Agentic RAG

I framework Agentic RAG consentono ai sistemi di intelligenza artificiale non solo di trovare informazioni ma anche di ragionare, prendere decisioni e agire. Ecco alcuni degli strumenti e delle librerie più importanti che alimentano l'Agentic RAG:

• LangChain Agents
• LlamaIndex Agents
• AutoGen
• CrewAI
• OpenAI Assistants API
• Marvin
• Superagent
• FastRAG
• MetaGPT
• BabyAGI
• GPT Engineer
• HuggingFace Agents
• Semantic Kernel
• Haystack
• Camel
• AgentVerse
• OpenDevin
• Dify
• Evals
• Mojo

Questo elenco include strumenti che soddisfano i seguenti criteri:

• Sono open source o hanno una versione gratuita che consente la personalizzazione.
• Forniscono funzionalità di agentic RAG out-of-the-box.
• Sono attivamente mantenuti e ricevono aggiornamenti frequenti.
• Hanno una comunità attiva di sviluppatori e utenti.
• Hanno una documentazione adeguata per gli sviluppatori.

Cos'è l'Agentic RAG?

L'Agentic Retrieval-Augmented Generation (RAG) è un framework di intelligenza artificiale che combina tecniche di recupero con modelli generativi per abilitare il processo decisionale dinamico e la sintesi della conoscenza. Questo approccio integra l'accuratezza del RAG tradizionale con le capacità generative dell'AI avanzata, mirando a migliorare l'efficienza e l'efficacia dei compiti basati sull'AI.

L'Agentic RAG mira a superare le limitazioni affrontate con il sistema RAG standard, come:

• Ragionamento limitato: Il RAG tradizionale spesso manca di capacità di ragionamento multi-step, affidandosi a corrispondenze dirette o a semplici classificazioni.
• Mancanza di esecuzione multi-step: Le pipeline RAG standard di solito sono single-shot, non riuscendo a gestire compiti che richiedono una sequenza di azioni o recuperi iterativi.
• Gestione degli errori insufficiente: Quando i recuperi iniziali non riescono o producono risultati irrilevanti, i sistemi RAG tradizionali hanno difficoltà ad adattarsi o a recuperare.
• Pipeline fisse: Molti sistemi RAG operano con flussi di lavoro predefiniti, limitando la loro flessibilità in scenari dinamici in cui i passaggi devono essere adattati al contesto.

Per flussi di lavoro complessi, gli agenti utilizzano cicli di ragionamento per eseguire ragionamenti iterativi e multi-step, mantenendo la memoria dei passaggi intermedi. Questi cicli comportano:

• Pianificazione: Suddividere compiti complessi in sotto-obiettivi gestibili.
• Monitoraggio: Valutare i risultati delle azioni e identificare le deviazioni.
• Riflessione: Analizzare i fallimenti e imparare dagli errori.
• Azione: Eseguire il compito attuale in base alla pianificazione e alla riflessione.

I framework spesso definiscono più agenti per gestire sotto-compiti specifici, garantendo un'esecuzione efficiente del processo complessivo.

Un approccio ibrido combina pipeline di recupero con strategie di esecuzione dinamiche:

• Componenti modulari: Utilizzo di diversi modelli e strumenti per compiti specifici.
• Orchestratori dinamici: Algoritmi che guidano il flusso di lavoro in base al contesto e agli obiettivi.
• Architettura del ciclo di feedback: Permette agli agenti di imparare e adattarsi nel tempo.

RAG vs. Agentic RAG: un confronto

Ecco i punti di forza e di debolezza di RAG vs. Agentic RAG basati su diversi aspetti:

• Ragionamento:
  • RAG: Ragionamento limitato (principalmente corrispondenza).
  • Agentic RAG: Ragionamento multi-step, cicli iterativi, consapevolezza contestuale.
• Processo decisionale:
  • RAG: Basato su regole fisse o classificazioni predefinite.
  • Agentic RAG: Autonomo, adattivo, basato sugli obiettivi, in tempo reale.
• Interazione con i dati:
  • RAG: Recupero "single-shot" da fonti predefinite.
  • Agentic RAG: Recupero multi-turn, instradamento dinamico, esplorazione interattiva dello schema.
• Gestione degli errori:
  • RAG: Gestione limitata degli errori, spesso si blocca o produce output irrilevanti.
  • Agentic RAG: Autocorrezione, riflessione, capacità di recupero dall'errore.
• Flessibilità:
  • RAG: Bassa flessibilità, pipeline fisse.
  • Agentic RAG: Alta flessibilità, flussi di lavoro dinamici, personalizzazione dell'agente.
• Complessità di implementazione:
  • RAG: Relativamente più semplice.
  • Agentic RAG: Più complessa a causa della necessità di gestione degli agenti, stati e cicli di ragionamento.
• Costo computazionale:
  • RAG: Generalmente inferiore per compiti semplici.
  • Agentic RAG: Generalmente superiore per compiti complessi a causa di molteplici interazioni con l'LLM.
• Performance per compiti semplici:
  • RAG: Buono per compiti di recupero e risposta diretti.
  • Agentic RAG: Overhead per compiti semplici, ma più robusto per compiti complessi.

Le sfide future: la rivoluzione della finestra di contesto

La rivoluzione della finestra di contesto del 2025-2026 sfida un'assunto fondamentale nell'architettura RAG. I modelli ora supportano da 1 a 2 milioni di token, sollevando una domanda fondamentale: quando l'elaborazione diretta del contesto supera gli agenti di recupero complessi? L'espansione drammatica delle finestre di contesto da 128k token nei primi LLM, porta a riflettere su come questo impatterà la necessità e il design delle architetture RAG agentiche in futuro, richiedendo un bilanciamento tra l'efficienza del recupero e la capacità di elaborazione diretta del contesto.