Conversational Database Management
Interroga i tuoi dati in linguaggio naturale e ottieni risposte in minuti, non in giorni.
Il problema in breve
In molte aziende, ogni volta che serve una risposta dai dati, quante vendite questo mese, quale prodotto sta calando, dove si concentrano i ritardi, bisogna chiedere a qualcuno che sappia scrivere query tecniche. Quel qualcuno è spesso una sola persona, o un team piccolo, già impegnato su altro. Il risultato è una coda: le domande si accumulano, le risposte arrivano in ritardo e le decisioni vengono prese a intuito invece che sui dati. Il conversational database management elimina questa coda, permettendo a chiunque in azienda di fare domande ai propri database come se parlasse con un collega.
La sfida
La promessa di interrogare un database in linguaggio naturale si scontra con una realtà tecnica complessa. I modelli di linguaggio generativi raggiungono accuratezze superiori al 90% su benchmark accademici standardizzati come Spider, ma scendono al 65-75% su benchmark più realistici come BIRD. Quando vengono applicati a schemi enterprise reali, con abbreviazioni non intuitive, logiche di join implicite, metriche di business codificate in viste complesse, l’accuratezza può scendere a valori a singola cifra, rendendo il text-to-SQL naive inutilizzabile in produzione.
Il problema non è il modello di linguaggio in sé, ma l’assenza di contesto. Uno schema con tabelle denominate ord_hdr, cust_mstr, inv_dtl non contiene informazione semantica sufficiente perché un LLM generi query corrette. Senza una mappa esplicita tra il linguaggio del business (“fatturato mensile per cliente”) e la struttura fisica del database (quali tabelle, quali join, quali filtri, quale aggregazione), il modello allucina tabelle inesistenti, inventa metriche e omette filtri critici.
A questo si aggiunge il problema della fiducia. Un decision maker che riceve una risposta da un sistema conversazionale deve poter verificare la correttezza della query sottostante. Se il sistema è una scatola nera che restituisce numeri senza spiegazione, l’adozione crolla: nessun responsabile baserà decisioni strategiche su dati di cui non può validare l’origine. Servono meccanismi di explainability, validazione automatica e audit trail delle query generate.
La soluzione
Analisi del Contesto
Soluzioni generiche di text-to-SQL integrate in piattaforme cloud offrono un punto di partenza, ma la loro accuratezza degrada rapidamente su schemi non standardizzati e metriche di business specifiche. Per ottenere risultati affidabili in contesti reali, serve un approccio diverso: partire dall’analisi del contesto dati del cliente, quali sono le domande ricorrenti, come è strutturato lo schema, dove risiedono le metriche di business, chi sono gli utenti e quale livello di accuratezza è accettabile per ciascun caso d’uso.
Semantic Layer
L’approccio che adottiamo si articola in tre componenti, la cui configurazione dipende dall’analisi dello schema e delle esigenze specifiche. Il primo elemento è un semantic layer, uno strato intermedio che traduce la struttura fisica del database in un modello concettuale comprensibile dal LLM. Il semantic layer definisce metriche (es. “fatturato = SUM(order_total) WHERE status = 'completed'”), relazioni tra entità, regole di aggregazione e filtri di sicurezza basati sul ruolo dell’utente. Il LLM non genera SQL contro le tabelle raw: interroga il modello semantico, che a sua volta produce query corrette per costruzione. Su schemi non preparati, l’accuratezza può restare inferiore al 10%. Con un semantic layer ben progettato e calibrato sul dominio, si raggiungono accuratezze superiori al 90%.
Retrieval-Augmented Schema Understanding
Il secondo elemento è il retrieval-augmented schema understanding: embedding vettoriali di metadati, descrizioni di colonne, glossari di business e query storiche vengono indicizzati e recuperati contestualmente ad ogni domanda dell’utente. Questo fornisce al modello il contesto necessario per disambiguare termini ambigui, selezionare le tabelle corrette e applicare la logica di business appropriata. L’approccio è estendibile a schemi federati su più sorgenti dati (ERP, CRM, piattaforma e-commerce, fogli di calcolo), unificati sotto un unico modello semantico.
Pattern Agentico Multi-Step
Il terzo elemento è un pattern agentico multi-step: l’agente non genera una singola query, ma esplora lo schema, formula la query, la valida contro vincoli noti, la esegue, verifica la plausibilità dei risultati e presenta la risposta con la query SQL sottostante visibile e spiegata. Query ricorrenti vengono riconosciute e riutilizzate tramite pattern caching, riducendo latenza e costi computazionali. Questo ciclo di generazione-validazione-spiegazione è ciò che rende la soluzione utilizzabile in contesti decisionali reali.
Tecnologie chiave
Text-to-SQL / NL2SQL
Traduzione di domande in linguaggio naturale in query SQL corrette tramite modelli di linguaggio specializzati.
ApprofondisciSemantic Layer
Modellazione delle metriche di business e delle relazioni tra entità come strato intermedio tra utente e database.
ApprofondisciRetrieval-Augmented Generation (RAG)
Recupero contestuale di metadati, glossari e query storiche per ancorare le risposte del modello a dati reali e verificabili.
ApprofondisciLLM Orchestration & Agents
Pattern agentico multi-step per generazione, validazione e spiegazione delle query.
ApprofondisciVector Databases
Indicizzazione e ricerca semantica su embedding di schema, metadati e domande storiche.
ApprofondisciRisultati e benefici
Riduzione del 70-80% delle richieste ad-hoc ricorrenti al team dati, per le tipologie di domanda coperte dal semantic layer, liberando capacità per analisi a maggior valore aggiunto
Tempo medio da domanda a risposta ridotto da ore/giorni a secondi
Accuratezza delle query superiore al 90% su domini coperti dal semantic layer
Accessibilità ai dati estesa a profili non tecnici (vendite, operazioni, management) senza formazione SQL
Controllo degli accessi ereditato dal database sorgente: ogni utente vede solo i dati autorizzati dal proprio ruolo, con row-level security applicata a livello di semantic layer
Audit trail completo di ogni query generata, con SQL visibile e spiegazione in linguaggio naturale
Use case
Analytics conversazionale per un e-commerce in crescita
Un e-commerce con 20-50 milioni di fatturato e un catalogo di migliaia di SKU genera quotidianamente domande operative: quali prodotti stanno rendendo sotto le aspettative, dove si concentrano i resi, come variano i margini per categoria. Il team dati, composto da due persone, non riesce a soddisfare le richieste di marketing, acquisti e operations simultaneamente. La progettazione di una soluzione conversazionale con semantic layer costruito sulle metriche e-commerce (GMV, conversion rate, average order value, return rate) consente ai team di business di ottenere risposte autonomamente. Risultato atteso: riduzione del 75% delle richieste ricorrenti al team dati e decisioni su pricing e assortimento prese in ore invece che in settimane.
Rilevamento anomalie in tempo reale per una fintech
Una fintech in fase di scaling gestisce volumi crescenti di transazioni e deve monitorare KPI operativi (volume transato, tasso di frode, tempi di settlement, chargeback rate) con frequenza giornaliera. I report tradizionali sono statici e arrivano con 24-48 ore di ritardo, un ritardo che trasforma un’anomalia gestibile in un problema conclamato. Lo sviluppo di un layer conversazionale integrato con il data warehouse e dotato di audit trail permette al CFO e al team compliance di accedere ai dati necessari per le proprie valutazioni in tempo reale: “Qual è il tasso di chargeback di questa settimana rispetto alla media mobile a 30 giorni?”. Ogni risposta include la query SQL sottostante per verifica. Risultato atteso: anomalie identificate in minuti invece che nel report del giorno successivo, con riduzione stimata del 30% dei tempi di identificazione e prima risposta a eventi critici.
Decisioni operative in tempo reale per una PMI manifatturiera
In una PMI manifatturiera con 30-40 milioni di fatturato, la differenza tra identificare un problema di produzione oggi e scoprirlo nel report settimanale può valere decine di migliaia di euro in scarti e fermi macchina evitabili. L’azienda raccoglie dati di produzione (tempi ciclo, scarti, consumi energetici, fermi macchina) in un database relazionale, ma solo il responsabile IT sa estrarre i dati. La progettazione di una soluzione conversazionale con semantic model mappato sulle metriche di produzione (OEE, tasso di scarto, MTBF, consumo per unità) permette al direttore di produzione di interrogare direttamente: “Qual è l’OEE del turno notturno di questa settimana?”, “Quali macchine hanno avuto più fermi non pianificati nel mese?”. Risultato atteso: ciclo decisionale sulla produzione ridotto da settimanale a giornaliero, con potenziale di miglioramento dell’OEE grazie alla tempestività degli interventi correttivi.
Vuoi rendere i tuoi dati accessibili a tutta l'azienda?
Richiedi un assessment sul tuo schema dati: analizzeremo la struttura dei tuoi database, le domande ricorrenti del tuo team e progetteremo un'architettura conversazionale calibrata sul tuo contesto.