UniQL: Towards Dialect-Universal Benchmarking for Text-to-SQL

## UniQL : pourquoi le text-to-SQL SQLite-centrique est une illusion de compétence

### 1. Ce qui existait avant

Les benchmarks dominants du text-to-SQL — Spider, BIRD, WikiSQL — reposent quasi-exclusivement sur SQLite. Cette convergence n'est pas anodine : SQLite est permissif syntaxiquement, sans serveur, facile à embarquer dans des pipelines d'évaluation. Résultat : depuis 2018, les classements de modèles text-to-SQL mesurent essentiellement la capacité à produire du SQLite valide sur des schémas académiques. Les scores ont grimpé (GPT-4 dépasse 85% sur Spider), créant l'impression que le problème est presque résolu.

UniQL casse cette illusion en posant une question simple : un modèle qui réussit sur SQLite peut-il produire du SQL correct pour MySQL, PostgreSQL, T-SQL, ou les 13 autres dialectes couverts ?

### 2. Ce que UniQL mesure concrètement

Le benchmark aligne **1 534 questions en langage naturel** avec des annotations SQL exécutables sur **16 dialectes**, produisant **24 544 requêtes dialect-spécifiques**. Tous les dialectes partagent les mêmes intentions, les mêmes schémas et le même contenu de base de données — ce qui permet une comparaison contrôlée, sans biais de difficulté sémantique.

La construction est hybride : migration de bases de données, traduction SQL automatique, vérification guidée par l'exécution, résumé itératif de règles, et validation humaine finale. Ce dernier point est critique : l'exécution d'une requête peut retourner les bons résultats pour de mauvaises raisons syntaxiques sur certains dialectes tolérants. La validation humaine filtre ces faux positifs.

Les dialectes couverts incluent des systèmes très différents dans leurs systèmes de types, leurs fonctions d'agrégation, leur gestion des dates, leur syntaxe de fenêtrage (window functions), et leurs comportements de cast implicite. T-SQL (SQL Server) diffère de PostgreSQL sur des points aussi basiques que la concaténation de chaînes (`+` vs `||`) ou la gestion des NULLs dans les agrégats.

### 3. Les résultats : l'échec de généralisation est massif

Les expériences sur modèles open-source et closed-source montrent une **variation substantielle des performances selon le dialecte**. Les auteurs ne publient pas encore de tableau complet dans l'abstract, mais le constat central est que le succès sur SQLite ne transfère pas aux autres dialectes — ce qui invalide directement les classements actuels comme proxy de compétence réelle.

Ce résultat est mécaniquement explicable : les corpus d'entraînement des LLM sur-représentent massivement SQLite (Stack Overflow, tutoriels, GitHub). Les dialectes enterprise comme T-SQL ou PL/pgSQL apparaissent moins fréquemment, et souvent dans des contextes où les requêtes complexes (CTEs récursives, fonctions analytiques spécifiques) sont rares. Le modèle apprend une grammaire SQLite avec des variations superficielles, pas une compréhension des sémantiques d'exécution dialecte-spécifiques.

### 4. Qui perd, qui gagne

**Perdants directs :** Les équipes qui ont optimisé leurs modèles text-to-SQL sur Spider/BIRD et communiquent des scores élevés comme preuve de production-readiness. UniQL expose que ces scores ne prédisent pas les performances sur PostgreSQL ou MySQL — les deux dialectes les plus déployés en production. Les fournisseurs de solutions NL-to-SQL (Text2SQL.ai, Defog, Vanna) dont les benchmarks marketing reposent sur SQLite sont directement challengés.

**Gagnants potentiels :** Les équipes qui construisent des pipelines dialect-aware — soit par fine-tuning dialecte-spécifique, soit par prompting avec injection de documentation dialecte, soit par post-processing de validation syntaxique. UniQL fournit enfin un signal d'évaluation propre pour ces approches.

**Impact sur les pratiques d'évaluation :** Pour tout déploiement text-to-SQL en production sur un SGBD non-SQLite, UniQL devient immédiatement le benchmark de référence pertinent. Utiliser Spider comme proxy pour PostgreSQL était déjà une approximation douteuse ; après UniQL, c'est indéfendable.

Le code et les données sont disponibles sur GitHub (JerryGao818/UniQL), ce qui permet une intégration immédiate dans les pipelines d'évaluation existants. La prochaine étape critique sera de voir si les modèles fine-tunés sur UniQL généralisent mieux, ou si la variation dialectale est suffisamment profonde pour nécessiter des modèles spécialisés par famille de dialectes.