Per molte aziende, la promessa di insight basati sull’intelligenza artificiale si sta scontrando con un muro strutturale. Sebbene la Retrieval-Augmented Generation (RAG) sia diventata lo standard per connettere i Large Language Models (LLM) ai dati privati, si sta dimostrando sempre più inadeguata per le complesse questioni aziendali del mondo reale.
Una nuova ricerca di Databricks suggerisce che la limitazione non è l’intelligenza dei modelli stessi, ma piuttosto l’architettura utilizzata per interrogarli. Lo studio evidenzia un cambiamento fondamentale: il passaggio dal recupero a turno singolo verso flussi di lavoro agentici in più fasi.
Il problema dei “dati ibridi”.
La maggior parte della business intelligence richiede la connessione di due mondi diversi:
1. Dati strutturati: Numeri precisi, cifre di vendita e tabelle relazionali (SQL).
2. Dati non strutturati: recensioni dei clienti, documenti accademici e documenti di supporto.
Per quest’ultimo è previsto un sistema RAG standard. Eccelle nel trovare testo che “suona come” una query, ma fatica a eseguire filtri matematici precisi o unire dati in diversi formati.
“RAG funziona, ma non è scalabile”, afferma Michael Bendersky, direttore della ricerca presso Databricks. “Se vuoi capire perché le tue vendite sono in calo, devi aiutare l’agente a vedere le tabelle e osservare i dati di vendita. La tua pipeline RAG diventerà incompetente in questo compito.”
Architettura vs. Intelligenza: il divario del 21%.
Per dimostrare che il problema risiede nel modo in cui si accede ai dati piuttosto che in quanto intelligente sia il modello, Databricks ha condotto una serie di test utilizzando il benchmark STaRK (che copre prodotti Amazon, Microsoft Academic Graph e dati biomedici).
Hanno confrontato un sistema RAG a giro singolo all’avanguardia e ad alte prestazioni con un approccio ad agenti in più fasi. Anche quando si utilizza un modello di fondazione significativamente più forte, il sistema RAG a giro singolo perde di:
* 21% nel settore accademico.
* 38% nel settore biomedico.
Questo divario prestazionale dimostra che anche il modello più “intelligente” non può compensare un’architettura di recupero che non è fondamentalmente in grado di colmare il divario tra un foglio di calcolo e un documento di testo.
Come funziona l’”agente supervisore”.
La soluzione di Databricks, il Supervisor Agent, si allontana dall’idea di “recupero ibrido” (tentativo di unire incorporamenti e tabelle) e tratta invece il problema come orchestrazione di strumenti. L’agente funziona attraverso tre funzionalità principali:
- Scomposizione dello strumento parallelo: Invece di una ricerca massiva, l’agente attiva simultaneamente query SQL per numeri e ricerche vettoriali per testo. Quindi analizza i risultati combinati per formare una risposta coerente.
- Autocorrezione: se una ricerca iniziale non produce risultati, ad esempio la ricerca di un autore specifico con un conteggio preciso delle pubblicazioni, l’agente non si arrende. Riformula la query, esegue un SQL
JOINe verifica il risultato attraverso una seconda ricerca. - Configurazione dichiarativa: a differenza delle pipeline tradizionali che richiedono agli ingegneri di “appiattire” o normalizzare i dati in blocchi di testo, questo agente utilizza descrizioni in linguaggio semplice. Per aggiungere una nuova origine dati, un ingegnere descrive semplicemente quali sono i dati; l’agente impara come usarlo.
Il passaggio dall’ingegneria alla configurazione
Le implicazioni per l’ingegneria dei dati sono significative. In una configurazione RAG tradizionale, ogni nuova origine dati richiede un’enorme quantità di “raccolta dei dati”: conversione di JSON, normalizzazione delle tabelle e gestione degli incorporamenti. Ciò crea un collo di bottiglia che cresce man mano che l’impresa si espande.
L’approccio agentico capovolge questo modello: “Basta portare l’agente ai dati.”
Punti chiave per l’implementazione:
- Scalabilità: il modello ad agenti è più sostenibile per set di dati in crescita perché l’aggiunta di un’origine è un’attività di configurazione, non un’attività di codifica.
- Limiti di complessità: sebbene potente, l’approccio funziona meglio con da 5 a 10 origini dati. Collegare troppe fonti contraddittorie contemporaneamente può ridurre la velocità e l’affidabilità.
- Integrità dei dati: sebbene l’agente possa navigare in diversi formati, non può correggere “garbage in, garbage out”. Affinché l’agente sia efficace, i dati di origine devono essere fattivamente accurati.
Conclusione
La transizione da RAG ad agenti multi-step rappresenta un’evoluzione fondamentale nell’intelligenza artificiale aziendale: passare da sistemi che si limitano a trovare informazioni a sistemi che possono ragionare attraverso diversi ecosistemi di dati. Trattando le origini dati come strumenti anziché come semplici porzioni di testo, le aziende possono finalmente iniziare a rispondere alle complesse domande interfunzionali che guidano le decisioni aziendali.
