Cos'è il text-to-SQL?

Il text-to-SQL è la tecnica che traduce una domanda in linguaggio naturale in una query SQL eseguibile sul database. Chiedi "quanto abbiamo venduto a marzo rispetto all'anno scorso?" e un LLM genera l'interrogazione, la esegue e ti restituisce la risposta. È la funzionalità che ogni dirigente chiede appena vede l'AI generativa: "voglio chattare con i miei dati", senza aspettare un report o imparare uno strumento di BI. Il modello riceve come contesto lo schema delle tabelle, le descrizioni delle colonne ed esempi di query corrette, e i sistemi più maturi vi aggiungono guardrail come l'accesso in sola lettura e i permessi ereditati dall'utente prima di eseguire qualunque interrogazione. La promessa è seducente perché elimina l'attesa di un report o l'apprendimento di uno strumento di business intelligence, ma la qualità della risposta dipende interamente da quanto è pulito e documentato lo schema sottostante: senza quella base, il modello genera SQL sintatticamente corretto ma semanticamente arbitrario.

Come funziona

Il modello riceve la domanda insieme al contesto sul database: lo schema delle tabelle, le descrizioni delle colonne, esempi di query corrette e, negli assetti più maturi, le definizioni di business delle metriche. Con quel contesto genera la query SQL, che viene eseguita sul warehouse o lakehouse; il risultato torna all'utente come tabella, grafico o frase. I sistemi seri aggiungono guardrail: accesso in sola lettura, permessi ereditati dall'utente, verifica delle query prima dell'esecuzione. Le piattaforme dati (BigQuery, Snowflake, Databricks, Microsoft Fabric) e gli strumenti di BI stanno integrando questa capacità nativamente, segno che la direzione è segnata.

Un esempio enterprise

QueryGPT di Uber, nato come progetto di hackathon a maggio 2023, è oggi in produzione su circa 1,2 milioni di query al mese e riduce il tempo medio per ottenere una query corretta da 10 a 3 minuti, con il 78% degli utenti attivi che dichiara un risparmio di tempo reale. La prima versione usava un RAG basilare: la domanda vettorizzata veniva confrontata via ricerca dei vicini più prossimi con un piccolo set fisso di tabelle ed esempi, e funzionava bene su scala ridotta ma perdeva accuratezza non appena il numero di tabelle cresceva, per la debolezza intrinseca della sola similarità vettoriale. La versione attuale restringe prima il perimetro per dominio di business (un LLM classifica l'intento), poi seleziona le tabelle candidate con conferma umana, poi elimina le colonne irrilevanti dagli schemi selezionati, e solo a quel punto assembla il prompt finale con schemi puliti, esempi e istruzioni di business. È la controprova pratica del punto sopra: il salto di qualità non è arrivato da un LLM più potente, ma dal restringere il problema prima di generare la query.

Perché fallisce senza fondamenta

Il problema non è generare SQL sintatticamente corretto: gli LLM lo fanno bene. Il problema è generare la query giusta. Se "fatturato" può voler dire tre cose diverse (con o senza IVA, con o senza note di credito), se le tabelle si chiamano TBL_ORD_03 e nessuno ha documentato le colonne, il modello tira a indovinare: e una risposta sbagliata detta con sicurezza è peggio di nessuna risposta, perché finisce in una decisione. Per questo il text-to-SQL funziona solo sopra un semantic layer che formalizza le metriche e uno schema pulito e documentato. La lettura pratica per la tua azienda: "chattare con i dati" non si compra come funzionalità, si costruisce come architettura. Il lavoro vero sta sotto l'interfaccia, ed è lo stesso che rende affidabile anche la BI tradizionale.