Résumé Technique : UNIQL

Énoncé du Problème

Les benchmarks actuels de text-to-SQL, tels que Spider et BIRD, sont principalement centrés sur le dialecte SQLite. Cette dépendance crée un fossé d'évaluation significatif : il reste incertain de savoir si les grands modèles de langage (LLM) peuvent généraliser leurs capacités à travers des dialectes SQL hétérogènes. Les systèmes de bases de données réels (par exemple, PostgreSQL, MySQL, Oracle, Hive) diffèrent substantiellement en termes de syntaxe, de fonctions intégrées, de systèmes de types et de sémantique d'exécution. Par conséquent, une même intention en langage naturel nécessite souvent des réalisations SQL spécifiques au dialecte. Les benchmarks existants se concentrent soit sur un seul dialecte, soit couvrent plusieurs systèmes sans aligner les mêmes intentions de langage naturel entre eux, ce qui rend impossible l'isolement de la variation de dialecte par rapport aux différences de schémas ou de tâches. Cette limitation conduit à une surestimation de la robustesse et de l'universalité des systèmes text-to-SQL actuels.

Méthodologie

Les auteurs introduisent UNIQL, un benchmark exécutable, vérifié par l'humain, conçu pour l'évaluation text-to-SQL cross-dialecte. La construction de UNIQL implique un pipeline hybride qui étend l'ensemble de développement de BIRD à 16 dialectes SQL.

Pipeline de Construction du Jeu de Données

1. Migration de Base de Données : Les bases de données originales de BIRD (basées sur SQLite) sont migrées vers 15 systèmes de bases de données cibles (incluant ClickHouse, Doris, Drill, Druid, DuckDB, Hive, MySQL, Oracle, PostgreSQL, Presto, Spark, StarRocks, Teradata, Trino et T-SQL). Ce processus implique l'adaptation du schéma, le mappage des types, la normalisation des identifiants et l'adaptation des espaces de noms afin de garantir l'exécutabilité tout en préservant la sémantique des données.
2. Traduction et Vérification Automatisées :
   • Traduction Basée sur des Règles : Un outil déterministe (SQLGlot) est utilisé pour générer les requêtes initiales pour les dialectes cibles.
   • Vérification Guidée par l'Exécution : Les requêtes traduites sont exécutées sur la base de données cible. Une requête n'est acceptée automatiquement que si elle s'exécute avec succès et produit des résultats strictement équivalents à la requête SQLite source. Le protocole préserve la sémantique de l'ordre et les multiplicités de doublons, évitant ainsi les faux positifs courants dans les comparaisons d'ensembles non ordonnés.
   • Traduction par LLM : Pour les requêtes échouant à la traduction par règles, un LLM (GPT-5-mini) génère des traductions conditionnées par le SQL source, le schéma cible et l'ensemble de règles actuel.
   • Auto-Réflexion : Si les traductions par LLM échouent à la vérification d'équivalence, le modèle entre dans une boucle d'auto-réflexion bornée (jusqu'à 3 tours) utilisant le feedback d'exécution (erreurs ou écarts de résultats) pour affiner la requête.
3. Évolution Itérative des Règles : Les échecs de traduction sont analysés pour abstraire les modèles d'erreurs récurrents en règles de transformation de dialecte réutilisables. Ces règles sont mises à jour de manière itérative (en utilisant Gemini-2.5-Pro) pour gérer les problèmes spécifiques aux dialectes de la "longue traîne", tels que la réécriture de fonctions, la conversion de types et le comportement d'agrégation.
4. Vérification Humaine : Les cas qui ne peuvent être résolus par la traduction automatisée, la réflexion ou l'affinement des règles sont transmis à des annotateurs humains. Deux annotateurs indépendants examinent l'exécutabilité et la cohérence sémantique, réécrivant les requêtes si nécessaire pour s'assurer qu'elles correspondent à l'intention originale du langage naturel.

Statistiques du Benchmark

• Source : 1 534 questions en langage naturel provenant du jeu de développement de BIRD.
• Couverture : 16 dialectes SQL (1 source + 15 cibles).
• Total des Annotations : 24 544 requêtes SQL exécutables et spécifiques au dialecte.
• Alignement : Tous les dialectes partagent des intentions de langage naturel, des schémas et des contenus de base de données identiques.

Protocole d'Évaluation

L'article évalue les modèles en utilisant l'Exactitude d'Exécution (EX). Contrairement aux benchmarks précédents qui convertissent les sorties en ensembles non ordonnés, le protocole de UNIQL préserve l'ordre lorsqu'il existe des clauses ORDER BY explicites et maintient les multiplicités de doublons pour les sorties non ordonnées. Les modèles sont évalués dans un cadre d'inférence uniquement, sans fine-tuning spécifique à la tâche, sans sélection de few-shot, ni adaptation spécifique au dialecte.

Résultats Clés

Les auteurs ont évalué un large éventail de LLM open-source (ex: Qwen3, Llama-3, DeepSeek) et closed-source (ex: GPT-5, Gemini, Claude).

1. Universalité de Dialecte Limitée : Même les modèles les plus puissants (ex: Claude-4.5-Sonnet) atteignent une exactitude d'exécution moyenne d'environ 54,63 %. Cela indique que la génération text-to-SQL cross-dialecte exécutable est loin d'être saturée.
2. Biais Centré sur SQLite : La performance sur SQLite ne prédit pas de manière fiable la performance sur d'autres dialectes. Par exemple, un modèle peut atteindre 59,84 % sur SQLite mais seulement 37,74 % sur Teradata. Les benchmarks à dialecte unique ne parviennent pas à capturer ces interactions significatives entre le modèle et le dialecte.
3. Effets d'Échelle : Les modèles plus larges au sein d'une même famille (ex: de Qwen3-1.7B à Qwen3-32B) montrent une performance améliorée, mais le passage à l'échelle booste principalement la capacité globale plutôt que d'éliminer les faiblesses spécifiques aux dialectes. Les dialectes difficiles comme Druid, Presto et Teradata restent problématiques même pour les modèles plus larges.
4. Familiarité du Dialecte : La performance est corrélée à la familiarité du modèle. Oracle, qui possède une documentation publique et une exposition à l'entraînement abondantes, génère une précision plus élevée que Teradata ou Druid, qui peuvent être sous-représentés dans les corpus de pré-entraînement et impliquent des fonctions spécifiques au système complexes.
5. Cohérence Cross-Dialecte : Une haute précision moyenne n'implique pas une correction universelle du dialecte. Pour le meilleur modèle, seulement environ 20 % des questions sont répondues correctement à travers les 16 dialectes. De plus, le succès sur la réalisation SQLite d'une intention ne garantit pas le succès sur les autres dialectes (par exemple, seulement ~33 % des questions correctes sur SQLite restent correctes sur tous les autres dialectes pour Claude-4.5-Sonnet).

Signification et Contributions

L'article présente trois contributions principales :

1. Benchmark UNIQL : L'introduction d'un benchmark exécutable, vérifié par l'humain, qui aligne les mêmes intentions de langage naturel avec des réalisations SQL à travers 16 dialectes, permettant une évaluation contrôlée de la généralisation des dialectes.
2. Framework de Construction : Un nouveau framework de traduction SQL intégrant la traduction par outil, la traduction par LLM, la vérification basée sur l'exécution, l'auto-réflexion, l'évolution itérative des règles et la validation humaine pour construire des jeux de données cross-dialecte de haute qualité.
3. Évaluation Diagnostique : Une évaluation complète montrant que les LLM actuels peinent avec la génération text-to-SQL universelle de dialecte. Les conclusions soulignent que l'interrogation robuste multi-systèmes nécessite une évaluation et une modélisation explicites de la robustesse cross-dialecte, plutôt que de se fier uniquement aux benchmarks centrés sur SQLite.

Les auteurs concluent que bien que les modèles actuels soient prometteurs, ils ne sont pas encore universels en matière de dialecte. La variation substantielle de performance entre les systèmes de bases de données souligne la nécessité de benchmarks cross-dialectes alignés et du développement de méthodes text-to-SQL plus conscientes des dialectes.