Free PlyxSQL© Beta - 1.0.0.81 - Text to SQL
POSTED , 23 LUG 2026
Free DOWNLOAD Clicca qui Info https://pgsoft.it/plyxhtml
1. Few-shot examples: mostrare invece di spiegare
Per ogni tabella si può ora configurare un piccolo set di coppie domanda → SQL già validate da un operatore umano. Non sono documentazione: finiscono letteralmente nel prompt come esempi di riferimento.
È il tipo di intervento che nella letteratura sul text-to-SQL ha il rapporto costo/beneficio più alto: una descrizione testuale di un JOIN complesso o di una CASE particolare lascia sempre margine di interpretazione, un esempio concreto no. E quando la domanda dell'utente somiglia a un esempio già validato, il modello smette di "indovinare" lo stile giusto e inizia a copiarlo.
2. Filtri incondizionati: la differenza tra "se serve" e "sempre"
Il configuratore aveva già i Keyword Filter: un filtro WHERE che scatta se una parola specifica compare nella domanda. Utile, ma con un buco di sicurezza evidente — se l'operatore non usa la parola giusta, il filtro semplicemente non scatta. Un record cancellato può finire in una query senza che nessuno l'abbia chiesto.
Gli always_filters risolvono esattamente questo: espressioni WHERE che vengono applicate sempre quando la tabella è coinvolta, indipendentemente da cosa scrive l'utente. Non sono un'opzione tra le tante nel prompt — arrivano accompagnate da un'istruzione esplicita che dice al modello: questo non è negoziabile, non è un'ipotesi, va sempre in AND. Soft delete, isolamento multi-tenant, esclusione di record di sistema: tutto ciò che deve valere a prescindere ora ha un posto dove stare.
3. Il formato che invecchia bene
Ogni volta che un formato di scambio dati vive abbastanza a lungo, arriva il giorno in cui cambia. Il pacchetto semantico esportato per il componente server ora porta un format_version come primo campo. Non è burocrazia: è la differenza tra un server che sa di dover ignorare educatamente un campo che non conosce ancora, e un server che lo interpreta male senza accorgersene. Non abbiamo aggiunto un blocco rigido — solo un avviso, mai un errore: forward-compatibility onesta, non difensiva all'eccesso.
4. Quando la domanda nomina due cose, non una
Questo è il bug più subdolo che abbiamo trovato. Il sistema aveva un meccanismo per mappare, ad esempio, il nome di un comune al suo codice interno — ma restituiva sempre un valore, quello di default. Se la domanda dell'utente diceva "confronta le occupazioni suolo tra Riccione e Gatteo", il sistema silenziosamente ignorava Gatteo e rispondeva solo per Riccione. Nessun errore, nessun avviso — solo una risposta a metà, spacciata per completa.
Ora ogni valore configurato porta un flag matched calcolato contro il testo reale della domanda, e quando più varianti dello stesso parametro risultano nominate esplicitamente, il prompt le espone tutte insieme in una sezione dedicata — con un'istruzione che vieta esplicitamente al modello di sceglierne una sola. Da lì il modello costruisce un IN (...) o l'unione che serve. La differenza tra "sembra funzionare" e "funziona davvero" spesso sta proprio in questo genere di casi limite.
5. Cosa succede quando lo schema ha 300 tabelle
Un prompt che include "tutte le tabelle perché non abbiamo capito quale serve" è già una toppa accettabile su uno schema piccolo. Su uno schema con centinaia di tabelle configurate diventa un problema serio: costo in token, e soprattutto rumore che confonde il modello più di quanto lo aiuti.
Abbiamo introdotto una soglia oltre la quale il sistema non include più tutto, ma ordina le tabelle candidate per un punteggio di pertinenza (il nome tabella nella domanda pesa più di una singola keyword) e tiene solo le migliori. Sempre con un avviso esplicito su quante e perché sono state escluse — mai un troncamento silenzioso che l'utente scopre solo quando manca qualcosa.
6. Quando "occupazione" nella configurazione non trova "occupazioni" nella domanda
L'ultimo pezzo è forse quello con il ritorno più immediato sulla qualità percepita. Il motore di riconoscimento delle tabelle cercava corrispondenze esatte, parola per parola. Se una keyword era configurata al singolare e l'utente scriveva al plurale, semplicemente non scattava — e il sistema, non trovando nulla, finiva dritto nel fallback "includi tutto".
Ora, solo dopo che il match esatto ha fallito, entra in gioco un secondo tentativo più permissivo: confronto per distanza di edit tra le parole, capace di riconoscere plurali, generi, piccoli refusi. Non è magia — non copre sinonimi concettualmente diversi, quello richiederebbe tutt'altro tipo di motore — ma chiude una fetta enorme dei "non ho capito la domanda" più frustranti, quelli dove la domanda era in realtà perfettamente chiara a un essere umano.
Un dettaglio non banale: questo fallback approssimato vale solo per decidere quali tabelle mostrare come contesto. Non tocca mai i filtri o i valori che finiscono letteralmente nel SQL generato — lì un match "quasi giusto" cambierebbe il risultato della query, non solo il contesto, ed è un rischio che semplicemente non vale il beneficio.
Il filo conduttore
Se c'è una lezione in tutto questo, è che un sistema text-to-SQL affidabile non nasce da un prompt più lungo o da un modello più potente. Nasce da mille piccoli casi limite trattati uno per uno, ciascuno con la stessa domanda di fondo: cosa succede davvero quando l'utente scrive qualcosa che non avevo previsto? A volte la risposta è "fallisci in modo rumoroso, con un avviso chiaro". Altre volte è "prova un secondo approccio, più permissivo, ma dillo". Non è mai "fai finta che vada tutto bene".
È un lavoro meno appariscente di un nuovo modello o di un prompt più elaborato. Ma è quello che, alla fine, decide se un utente si fida del sistema oppure smette di usarlo dopo la prima risposta sbagliata.
#TextToSQL #AI #DatabaseLegacy #SQL #Firebird #CodeGeneration #SoftwareArchitecture #DataEngineering #LLM #PromptEngineering #DigitalTransformation #PubblicaAmministrazione #SoftwareDevelopment #TechInnovation #PlyxSQL
Nessun commento:
Posta un commento