Riepilogo Tecnico: UNIQL

Problematica

I benchmark attuali per il text-to-SQL, come Spider e BIRD, sono prevalentemente centrati sul dialetto SQLite. Questa dipendenza crea un significativo divario di valutazione: rimane poco chiaro se i grandi modelli linguistici (LLM) possano generalizzare le proprie capacità attraverso dialetti SQL eterogenei. I sistemi di database reali (ad esempio, PostgreSQL, MySQL, Oracle, Hive) differiscono sostanzialmente per sintassi, funzioni integrate, sistemi di tipi e semantica di esecuzione. Di conseguenza, la stessa intenzione in linguaggio naturale richiede spesso realizzazioni SQL specifiche per il dialetto. I benchmark esistenti si concentrano su un singolo dialetto o coprono più sistemi senza però allineare gli stessi intenti in linguaggio naturale tra di essi, rendendo impossibile isolare la variazione del dialetto dalle differenze negli schemi o nei compiti. Questa limitazione porta a una sovrastima della robustezza e dell'universalità degli attuali sistemi text-to-SQL.

Metodologia

Gli autori introducono UNIQL, un benchmark eseguibile e verificato da esseri umani, progettato per la valutazione cross-dialetto del text-to-SQL. La costruzione di UNIQL prevede una pipeline ibrida che estende il set di sviluppo di BIRD a 16 dialetti SQL.

Pipeline di Costruzione del Dataset

1. Migrazione dei Database: Gli originali database di BIRD (basati su SQLite) vengono migrati in 15 sistemi di database target (inclusi ClickHouse, Doris, Drill, Druid, DuckDB, Hive, MySQL, Oracle, PostgreSQL, Presto, Spark, StarRocks, Teradata, Trino e T-SQL). Questo processo prevede l'adattamento dello schema, la mappatura dei tipi, la normalizzazione degli identificatori e l'adattamento dei namespace per garantire l'eseguibilità preservando al contempo la semantica dei dati.
2. Traduzione e Verifica Automatizzata:
   • Traduzione Basata su Regole: Uno strumento deterministico (SQLGlot) viene utilizzato per generare le query iniziali per il dialetto target.
   • Verifica Guidata dall'Esecuzione: Le query tradotte vengono eseguite sul database target. Una query viene accettata automaticamente solo se viene eseguita con successo e produce risultati strettamente equivalenti alla query SQLite originale. Il protocollo preserva la semantica dell'ordinamento e le molteplicità dei duplicati, evitando i falsi positivi comuni nelle comparazioni di set non ordinati.
   • Traduzione Basata su LLM: Per le query che falliscono la traduzione basata su regole, un LLM (GPT-5-mini) genera le traduzioni condizionate sulla query SQL sorgente, sullo schema target e sull'attuale set di regole.
   • Auto-Riflessione: Se le traduzioni dell'LLM falliscono la verifica di equivalenza, il modello entra in un ciclo di auto-riflessione limitato (fino a 3 round) utilizzando il feedback di esecuzione (errori o discrepanze nei risultati) per perfezionare la query.
3. Evoluzione Iterativa delle Regole: Le traduzioni fallite vengono analizzate per astrarre pattern di errore ricorrenti in regole di trasformazione del dialetto riutilizzabili. Queste regole vengono aggiornate iterativamente (utilizzando Gemini-2.5-Pro) per gestire problemi specifici dei dialetti a "coda lunga", come la riscrittura delle funzioni, la conversione dei tipi e il comportamento delle aggregazioni.
4. Verifica Umana: I casi che non possono essere risolti tramite traduzione automatica, riflessione o raffinamento delle regole vengono indirizzati agli annotatori umani. Due annotatori indipendenti revisionano l'eseguibilità e la coerenza semantica, riscrivendo le query se necessario per garantire che corrispondano all'intento originale in linguaggio naturale.

Statistiche del Benchmark

• Sorgente: 1.534 domande in linguaggio naturale dal set di sviluppo di BIRD.
• Copertura: 16 dialetti SQL (1 sorgente + 15 target).
• Annotazioni Totali: 24.544 query SQL eseguibili e specifiche per dialetto.
• Allineamento: Tutti i dialetti condividono identici intenti in linguaggio naturale, schemi allineati e contenuti del database.

Protocollo di Valutazione

Il documento valuta i modelli utilizzando l'Accuratezza di Esecuzione (EX). A differenza dei benchmark precedenti che convertono gli output in set non ordinati, il protocollo di UNIQL preserva l'ordinamento quando esistono clausole ORDER BY esplicite e mantiene le molteplicità dei duplicati per gli output non ordinati. I modelli sono valutati in un setting di sola inferenza, senza fine-tuning specifico per il compito, selezione few-shot o adattamento specifico per il dialetto.

Risultati Chiave

Gli autori hanno valutato un ampio set di LLM open-source (ad esempio, Qwen3, Llama-3, DeepSeek) e closed-source (ad esempio, GPT-5, Gemini, Claude).

1. Limitata Universalità del Dialetto: Anche i modelli più forti (ad esempio, Claude-4.5-Sonnet) ottengono un'accuratezza di esecuzione media di soli ~54,63%. Ciò indica che la generazione text-to-SQL cross-dialetto eseguibile è tutt'altro che satura.
2. Bias Centrato su SQLite: Le prestazioni su SQLite non predicono in modo affidabile le prestazioni su altri dialetti. Ad esempio, un modello potrebbe ottenere il 59,84% su SQLite ma solo il 37,74% su Teradata. I benchmark a singolo dialetto non riescono a catturare queste significative interazioni modello-dialetto.
3. Effetti di Scaling: Modelli più grandi all'interno delle stesse famiglie (ad esempio, da Qwen3-1.7B a Qwen3-32B) mostrano prestazioni migliorate, ma lo scaling potenzia principalmente la capacità complessiva piuttosto che eliminare le debolezze specifiche del dialetto. Dialetti difficili come Druid, Presto e Teradata rimangono impegnativi anche per i modelli più grandi.
4. Familiarità del Dialetto: Le prestazioni correlano con la familiarità del modello. Oracle, che possiede un'abbondante documentazione pubblica e un'ampia esposizione nell'addestramento, produce un'accuratezza maggiore rispetto a Teradata o Druid, che potrebbero essere sottorappresentati nei corpora di pre-training e comportano funzioni specifiche del sistema più complesse.
5. Consistenza Cross-Dialetto: Un'alta accuratezza media non implica una correttezza universale del dialetto. Per il miglior modello, solo il ~20% delle domande è risposta correttamente in tutti i 16 dialetti. Inoltre, il successo nella realizzazione SQLite di un intento non garantisce il successo sugli altri dialetti (ad esempio, solo il ~33% delle domande corrette in SQLite rimangono corrette in tutti gli altri dialetti per Claude-4.5-Sonnet).

Significato e Contributi

Il documento apporta tre contributi primari:

1. Benchmark UNIQL: L'introduzione di un benchmark eseguibile e verificato da esseri umani che allinea gli stessi intenti in linguaggio naturale con le realizzazioni SQL attraverso 16 dialetti, consentendo una valutazione controllata della generalizzazione del dialetto.
2. Framework di Costruzione: Un nuovo framework di traduzione SQL che integra traduzione basata su strumenti, traduzione basata su LLM, verifica basata sull'esecuzione, auto-riflessione, evoluzione iterativa delle regole e validazione umana per costruire dataset cross-dialetto di alta qualità.
3. Valutazione Diagnostica: Una valutazione completa che mostra come gli attuali LLM fatichino con la generazione text-to-SQL cross-dialetto universale. I risultati evidenziano che l'interrogazione robusta tra sistemi richiede una valutazione esplicita e una modellazione della robustezza cross-dialetto, piuttosto che affidarsi esclusivamente ai benchmark centrati su SQLite.

Gli autori concludono che, sebbene i modelli attuali mostrino potenziale, non sono ancora dialetto-universali. La sostanziale variazione delle prestazioni tra i sistemi di database sottolinea la necessità di benchmark cross-dialetto allineati e dello sviluppo di metodi text-to-SQL più consapevoli dei dialetti.