Dal Designer al browser: un vero chatbot text-to-SQL

Lo Schema Designer, il Configuratore Semantico, la finestra "Genera prompt AI" con la sua esecuzione di verifica e la sua autocorrezione. Il passo successivo renderlo disponibile a tutti sul web.

La risposta è un web server scritto in C++Builder (WebBroker su Indy) che espone lo stesso motore — prompt semantico, esecuzione, sicurezza, autocorrezione — come una manciata di endpoint HTTP, più un client Vue che li consuma. Non è stata una riscrittura da zero: è stato il momento in cui tutto il lavoro fatto sul lato "server" del Configuratore Semantico (pensato fin dall'inizio per essere indipendente dall'interfaccia desktop) ha dimostrato di reggere davvero fuori da quel contesto.

Server C++Builder (service o stand-alone GUI Application)

Il cuore: stesso motore, architettura diversa

SDServerPromptBuilder — il componente che trasforma una domanda in un prompt strutturato per l'AI — non ha richiesto una sola riga di modifica per girare sul web server. Era già stato progettato per non dipendere da nulla di specifico del Designer: solo RTL, nessuna dipendenza da componenti visuali. La differenza vera è stata nel come orchestrarlo.

Nel Designer, tutto girava sull'interfaccia utente: bisognava restare asincroni per non bloccare la finestra mentre si aspettava una risposta AI. Su un web server, ogni richiesta HTTP ha già il proprio thread — bloccarlo per la durata di una chiamata è normale, atteso, persino più semplice da scrivere. Lo stesso ciclo (prompt → AI → controllo di sicurezza → esecuzione → eventuale correzione) è diventato un semplice ciclo sincrono, senza bisogno dell'architettura a callback che serviva sul desktop.

Nessuno sconto sulla sicurezza

Il guardrail costruito per il Designer — solo SELECT di sola lettura, niente scritture, niente statement multipli — è arrivato intatto sul server. Ha senso: se qualcosa deve essere rigoroso, è proprio il confine tra "un chatbot può proporre una query" e "un chatbot può eseguire qualcosa contro un database di produzione". Ogni query, prima di toccare il database, passa dallo stesso controllo testuale rigoroso — e se anche l'AI dovesse inventarsi qualcosa di strano, il controllo non fa eccezioni per nessuno.

Il ciclo di autocorrezione ha guadagnato per strada un affinamento non banale: se un errore di esecuzione si ripete identico dopo che l'AI ha già prodotto una query diversa, il sistema smette di insistere. È nato da un caso reale — un errore di configurazione del database (non della query) che veniva rimandato all'AI tre volte di fila, sprecando ogni tentativo su qualcosa che nessuna riscrittura del SQL avrebbe mai potuto risolvere. Ora quel pattern viene riconosciuto e segnalato subito come probabile problema di infrastruttura, non di query.

Vedere cosa sta succedendo, non solo aspettare

Qui è dove le cose si sono fatte interessanti. Le prime versioni rispondevano in un unico blocco: silenzio totale, poi tutto insieme. Con un modello locale (Ollama) che può metterci anche un minuto a rispondere, quel silenzio è indistinguibile da un sistema bloccato.

La soluzione è stata disaccoppiare l'avvio dall'attesa: il client avvia il lavoro (che gira su un thread in background), riceve subito un identificativo, e interroga a ripetizione lo stato — un pattern di polling piuttosto che una singola chiamata bloccante. Da lì è nato un ticker che scandisce i secondi in tempo reale, e poi qualcosa di più preciso: passando alla modalità streaming di Ollama, il primo pezzo di testo che arriva diventa il confine naturale tra "il modello si sta ancora caricando/elaborando" e "sta generando davvero" — una distinzione che con una singola risposta bloccante non era osservabile in nessun modo. Il risultato: tre fasi visibili in tempo reale nel client, ognuna basata su un segnale vero, mai un'etichetta inventata.

Una cache che impara da sola

Sul Designer, la cache si alimentava da un gesto esplicito dell'operatore: un bottone "Verifica e salva come esempio". Sul server quel passaggio manuale è sparito del tutto — ogni volta che una domanda va a buon fine, la coppia domanda/query viene registrata automaticamente, perché un successo sul server è già una verifica reale contro il database. Nessuno deve ricordarsi di salvare nulla.

Stesse due soglie di sicurezza già validate sul Designer: corrispondenza esatta prima, corrispondenza approssimata solo sopra una soglia molto alta, e — il dettaglio a cui teniamo di più — mai un match se i numeri nelle due domande non coincidono. "Fatture 2024" e "fatture 2023" restano sempre due domande diverse, per quanto si somiglino nel resto della frase. E prima di restituire una risposta dalla cache come definitiva, il sistema la riesegue comunque per conferma: se lo schema o i dati sono cambiati nel frattempo, se ne accorge da solo e chiede una risposta fresca invece di rischiare.

Un file per portarsi via il risultato

Client Vue.js con Vuelityx

La tabella mostrata in chat è volutamente un'anteprima limitata (configurabile, 10 righe di default) — serve a confermare che la query funzioni, non a sostituire un vero export. Per quello c'è un endpoint dedicato che riesegue la stessa query, già passata dal controllo di sicurezza, con un tetto molto più alto, e restituisce un CSV vero e proprio, scaricabile con un click. Un dettaglio che conta più di quanto sembri: punto e virgola come separatore, non virgola — perché Excel in locale italiano usa la virgola come separatore decimale, e con il separatore sbagliato il file si aprirebbe tutto incolonnato in un'unica cella.

Sapere cosa sta succedendo, in aggregato

Ogni domanda che arriva a un esito — riuscita, fallita, risolta dalla cache — viene registrata in modo silenzioso: quanti tentativi sono serviti, quanto ci ha messo, se è arrivata dalla cache o dall'AI. Un endpoint restituisce il quadro aggregato: percentuale di successo, tempo medio, gli errori più frequenti. È il dato che dice dove guardare quando qualcosa non va, invece di doverlo dedurre osservando il client in tempo reale — è così, tra l'altro, che abbiamo diagnosticato un problema di configurazione FireDAC che altrimenti sarebbe sembrato un errore casuale dell'AI.

Il client: niente di più di quanto serva

Dall'altra parte, un frontend Vue essenziale — bolle di conversazione, evidenziazione del testo generato, una tabella per i risultati, un link per il CSV completo. Niente framework pesanti, niente stato complesso: solo quello che serve per rendere leggibile ciò che il server produce, con un dettaglio di attenzione che vale la pena raccontare — durante lo sviluppo, un bug di reattività (Vue 3 non sempre traccia le mutazioni su un oggetto se non è stato reso "reattivo" fin dall'inizio) faceva sì che l'interfaccia restasse bloccata sui primi tre puntini per sempre, qualunque cosa succedesse davvero lato server. Un promemoria utile: anche l'interfaccia più semplice ha i suoi dettagli sottili, e vale la pena controllarli con la stessa cura riservata al motore che sta dietro.

#TextToSQL #AI #DatabaseLegacy #SQL #Firebird #CodeGeneration #SoftwareArchitecture #DataEngineering #LLM #PromptEngineering #DigitalTransformation #PubblicaAmministrazione #SoftwareDevelopment #TechInnovation #PlyxSQL

martedì 28 luglio 2026

Free PlyxSQL© SQL Beta - 1.0.0.85 - Text to SQL