La svolta silenziosa: da «chiedere al modello» a «orchestrare agenti sul dato»
Nel corso del 2024 e per buona parte del 2025, la conversazione sui modelli linguistici applicati all’analisi dei dati ruotava attorno alla chat: incollare un CSV, chiedere un grafico, ottenere una tabella. Quel modello si sta esaurendo. Ciò che domina le novità recenti è altro: modelli che non rispondono con testo, ma che eseguono codice, interrogano cataloghi, validano ipotesi e restituiscono risultati verificabili.
La differenza pratica è enorme. Una chat che «interpreta» un CSV allucina righe e medie con una facilità preoccupante. Un agente che esegue SQL o Python contro un archivio reale non può inventarsi una cifra senza che il motore di database protesti. Questo è l’asse del cambiamento: il modello smette di essere l’analista e diventa il pianificatore che scrive query e verifica i risultati.
Text-to-SQL maturo: dove funziona e dove continua a rompersi
La generazione di query SQL a partire dal linguaggio naturale è l’applicazione più diffusa, e anche la più sopravvalutata nelle demo. Secondo la documentazione ufficiale dei principali fornitori di database analitici, i benchmark pubblici di text-to-SQL sono migliorati in modo costante, ma quei numeri si ottengono su schemi puliti, con nomi di colonne autoesplicativi e senza ambiguità semantica.
In un archivio reale, la cosa cambia. Un caso che si ripete: la tabella si chiama fact_ventas_v3, esiste una fact_ventas_v2 che non viene più aggiornata ma è ancora viva, e c’è una colonna importe che in realtà è in centesimi nelle righe precedenti a una specifica migrazione. Nessun modello lo indovina. Lo risolve un catalogo dati con descrizioni, lineage e regole di business documentate.
Cosa sta effettivamente funzionando
- Query esplorative su un dominio circoscritto (un reparto, un insieme chiuso di tabelle).
- Traduzione di domande frequenti in query parametrizzate precedentemente riviste da un umano.
- Generazione di bozze di SQL che un analista corregge in pochi secondi invece di scriverle da zero.
Cosa non funziona (e conviene ammetterlo)
- Domande che richiedono di conoscere definizioni di business non scritte («clienti attivi» può significare cinque cose diverse).
- Schemi con centinaia di tabelle senza descrizioni: il tasso di errore schizza alle stelle.
- Calcoli in cui un JOIN scelto male duplica le righe e nessuno se ne accorge finché il report non arriva alla direzione.
Agenti con esecuzione di codice: il pattern che si impone
L’approccio che è cresciuto di più consiste nel dare al modello un interprete di codice isolato. Il modello scrive pandas, DuckDB o R, lo esegue, legge l’output e, se c’è un errore, itera. Questo ha un vantaggio decisivo per l’analisi: il risultato è riproducibile. Puoi salvare lo script, versionarlo e rieseguirlo il mese successivo.
Qui c’è un dettaglio che si impara solo usando questi strumenti quotidianamente: la maggior parte dei fallimenti non deriva dal ragionamento statistico, ma dalla gestione dei tipi e dei valori nulli. Date in formati misti, categorie con spazi finali, importi con virgola decimale ereditati da un’esportazione vecchia. Un modello potente scrive un groupby impeccabile e poi raggruppa male perché «Madrid» e «Madrid » sono due valori distinti. La soluzione non è un modello migliore: è uno strato di pulizia preliminare e validazioni esplicite.
Integrazione con lo stack: MCP e cataloghi semantici
La novità architetturale più rilevante degli ultimi mesi è la standardizzazione dei connettori. Il protocollo aperto promosso per collegare assistenti a fonti di dati (noto come MCP) sta permettendo che uno stesso modello interroghi un archivio, un CRM e un foglio di calcolo senza che ogni integrazione sia uno sviluppo su misura.
Questo ha una conseguenza che le organizzazioni stanno iniziando ad assumersi: il valore non è più nel modello, è nello strato semantico. Definire le metriche una sola volta (ricavi netti, churn, margine) ed esporle come strumenti che il modello può invocare è ciò che separa un pilota appariscente da un sistema che sopravvive al terzo mese.
Un pattern che emerge nei team che hanno già superato la fase di test: meno prompt lunghi, più funzioni registrate con nome e descrizione precisa. Il modello sceglie tra dieci strumenti ben documentati invece di improvvisare SQL su cinquanta tabelle.
Valutazione: il problema che quasi nessuno risolve bene
Misurare se un LLM analizza bene è più difficile che farlo funzionare. I benchmark pubblici non riflettono i tuoi dati. La pratica che si sta consolidando tra i team maturi è costruire un insieme di domande con risposta verificata manualmente sul proprio archivio, ed eseguirlo a ogni cambio di modello o di prompt.
Senza quell’insieme di valutazione, qualsiasi migrazione a un modello nuovo è una scommessa al buio. E qui c’è una sfumatura che conviene tenere presente: migliorare su un benchmark generico non garantisce di migliorare nel tuo dominio. Abbiamo visto modelli che peggiorano le prestazioni in attività di aggregazione con gerarchie di date perché cambiano lo stile di ragionamento, non perché siano peggiori.
Costo e latenza: il fattore che decide l’architettura
Un’analisi interattiva tollera due secondi di attesa; un report programmato che viene eseguito su migliaia di righe ogni notte non tollera il costo di un modello grande per ogni query. Da qui la tendenza ad architetture ibride:
- Modelli piccoli o regole deterministiche per le domande frequenti e ben tipizzate.
- Modelli grandi solo per l’esplorazione aperta e il debug degli errori.
- Cache dei risultati per le query ripetute, che in pratica sono la maggioranza.
La spesa in token diventa una voce di costo operativo reale quando il sistema viene usato da venti persone ogni giorno. Progettare senza tenerne conto è la via rapida alla cancellazione del progetto.
Governance e privacy: la conversazione che arriva tardi ma arriva
Inviare dati dei clienti a un fornitore esterno richiede di rivedere contratti, conservazione e residenza del dato. Le opzioni di deployment privato e i modelli eseguiti su infrastruttura propria sono maturati abbastanza da essere praticabili in settori regolamentati, anche se con un costo di manutenzione che molte aziende sottovalutano.
Un errore abituale: presumere che «il fornitore non si addestra con i miei dati» risolva il problema. Non lo risolve se il dato esce dal tuo perimetro. La decisione reale è architetturale, non contrattuale.
Cosa monitorare nei prossimi mesi
- Verifica dei risultati: meccanismi che confrontano l’output del modello con una fonte di verità prima di mostrarlo.
- Lineage automatico: sapere da quale tabella e da quale trasformazione proviene ogni cifra che il sistema presenta.
- Interfacce ibride: la chat non scompare, ma convive con dashboard in cui l’LLM redige solo la spiegazione del grafico.
- Valutazione continua: suite proprie che vengono eseguite a ogni aggiornamento del modello.
La conclusione onesta è che gli LLM apportano già un valore chiaro nell’esplorazione, nella documentazione dei dati e nella generazione assistita di query, e restano fragili in qualsiasi attività in cui una cifra sbagliata abbia conseguenze. Progettare con questa asimmetria in mente, mettendo il dato e la validazione al centro e il modello alla periferia, è oggi la differenza tra un esperimento e un sistema in produzione.