Quels sont les dangers des « records » en Text-to-SQL
Chaque mois, de nouvelles annonces prétendent qu'un LLM de plus a presque égalé l'humain sur les benchmarks SQL. Mais si l'on y regarde de plus près, ces chiffres cachent des conditions très différentes : certains utilisent une simple invite sans accès à la base, d'autres autorisent le modèle à exécuter des requêtes par itérations, et d'autres encore ont intégré le raisonnement directement dans les poids du modèle. Comparer directement ces résultats revient à mettre côte à côte une voiture avec un mécanicien et un véhicule autonome qui se répare lui-même en roulant.
Les auteurs d'un récent préprint sur arXiv (2608.15389) ont justement attiré l'attention sur ce problème. Ils proposent de ne plus mesurer le « progrès » par une hauteur abstraite dans un classement, mais de d'abord fixer honnêtement le degré d'autonomie dont disposait le système lors de la génération du SQL. Sans cette réserve, toute comparaison entre travaux s'avère instable : un changement de benchmark, de modèle de base ou même un protocole d'inférence légèrement différent peut modifier les conclusions.
L'axe de l'autonomie : des invites aux agents autonomes
Plutôt que de simplement rassembler tous les chiffres dans un tableau, les chercheurs redéfinissent le domaine même du Text-to-SQL comme une « agrégation de classements ». Ils collectent les métriques que les auteurs des systèmes rapportent eux-mêmes et les répartissent le long d'un axe d'autonomie de l'inférence. On obtient cinq niveaux :
- Constrained generation — le modèle choisit simplement une réponse dans un espace de requêtes valides strictement limité, souvent avec une vérification syntaxique externe.
- In-context generation — le SQL est construit en un seul passage sur le contexte avec des exemples et une description du schéma.
- Iterative generation — le système peut effectuer plusieurs tentatives, en affinant la requête en fonction des résultats d'exécution ou de la réponse du SGBD.
- Agentic generation — le modèle fonctionne comme un agent : il explore lui-même le schéma de la base, exécute des requêtes, réagit aux erreurs et planifie les étapes suivantes.
- Reasoning-internalized generation — le « raisonnement » est intégré à l'avance dans le modèle, de sorte qu'à l'inférence, il émet la requête directement, sans orchestrations externes ni étapes intermédiaires.
Une telle échelle ne dit pas qu'un niveau est « meilleur » qu'un autre. Elle fixe simplement les conditions d'une comparaison honnête : un système avec un raisonnement interne ne peut pas être opposé sur un pied d'égalité à une sortie single-shot nue, tout comme un circuit agentique avec le droit d'exécuter des requêtes ne doit pas être comparé à un modèle auquel ce droit n'a pas été accordé.
Il est important de noter que pour chaque cellule d'un tel classement, l'origine de la métrique reste traçable. Cela signifie que le lecteur peut toujours comprendre quelle configuration exacte a produit le résultat, plutôt que d'essayer de le deviner à partir de fragments de la section expérimentale.
Ce que l'expérience sur Spider et au-delà a montré
Pour ancrer l'agrégation des métriques dans la réalité, les auteurs ont mené une étude ciblée sur le benchmark Spider. Ils ont comparé des modèles ouverts 8B — avec et sans supervision CoT — à des références few-shot basées sur DeepSeek V3 et GLM-4. Il est intéressant de noter que des protocoles few-shot ont été utilisés, et non des versions entièrement affinées, ce qui rend la comparaison assez propre.
Quatre schémas importants pour les praticiens se dégagent de l'expérience.
Premièrement, les améliorations obtenues sur Spider se transfèrent de manière inégale à BIRD et Spider 2.0. Un modèle peut montrer une belle progression sur un ensemble de requêtes et presque stagner sur un autre. Cela confirme une fois de plus que la course aveugle à un score unique sur un benchmark populaire crée l'illusion d'un progrès général.
Deuxièmement, l'autonomie ajoute de la robustesse, mais à un coût non négligeable. Les circuits agentiques gèrent effectivement mieux les tâches multi-étapes et ambiguës, mais les coûts en tokens et en temps d'exécution augmentent sensiblement. Si ce coût est justifié pour un analyste interactif, il peut, pour un traitement par lots, engloutir tout le gain obtenu grâce à des erreurs plus rares.
Troisièmement, le mode reasoning internalized occupe une position moyenne inattendue. Il se situe entre le décodage « stupide » d'une réponse sans raisonnement et les agents orchestrés en externe. Pour un certain nombre de tâches, ce mode offre une qualité presque agentique, mais sans la nécessité de construire un circuit complexe avec des outils. Cependant, il n'y a pas de « repas gratuit » universel : les raisonnements intégrés ont aussi leurs limites.
Quatrièmement, les gains de la supervision CoT se concentrent sur les requêtes de niveaux Hard et Extra-Hard. Sur les questions simples, la différence est presque imperceptible, voire négative — pourquoi le modèle devrait-il raisonner à voix haute quand la réponse est immédiatement visible ? En revanche, sur les tâches complexes en plusieurs étapes, la capacité à verbaliser les étapes donne un avantage notable. C'est un signal important pour ceux qui construisent des assistants SQL : il faut concentrer les ressources de calcul supplémentaires sur les requêtes à haute complexité, et non les gaspiller sur des cas simples typiques.
Comment utiliser cette échelle en pratique
La conséquence la plus utile du travail n'est même pas la taxonomie elle-même, mais le harness Python public que les auteurs ont publié avec le préprint. Le harness reproduit l'axe de l'autonomie et permet d'ajouter de nouvelles méthodes au classement sans réécrire tout l'environnement. Si vous développez une autre approche Text-to-SQL, il suffit d'indiquer à quel niveau d'autonomie elle fonctionne — et la communauté pourra vous comparer aux systèmes précédents sur un pied d'égalité.
Il est évident que les agrégations basées sur des métriques auto-rapportées doivent toujours être considérées avec prudence. Tout le monde n'a pas le budget pour reproduire les expériences des autres, mais une annotation unifiée est déjà un grand pas en avant. En attendant, à la lecture du prochain « state-of-the-art », gardez à l'esprit une question simple : qu'est-ce que le modèle était précisément capable de faire pendant la génération de la requête ? Si la réponse à cette question est absente, alors le chiffre de l'article n'est qu'un beau nombre sans fondement solide.
