Benchmarker la génération de code SQL par les LLM

Dans l’engouement autour de la génération de code par les LLM pour Python, JavaScript et d’autres langages généralistes, le SQL peut sembler oublié.

Pourtant, on peut dire que le SQL fait tourner l’économie mondiale. La question mérite donc d’être posée : les LLM sont-ils bons pour écrire du SQL ?

Nous ne sommes pas les premiers à nous poser la question. Chercheurs comme éditeurs ont déjà publié des benchmarks mesurant les performances des LLM en génération de SQL.

Dans cet article, on passe en revue certains de ces benchmarks, on regarde ce qu’ils révèlent et on se demande ce qui fait un benchmark de génération de code SQL vraiment pertinent.

Qu’est-ce qu’un bon benchmark de génération de code SQL par les LLM ?

On a presque tous ressenti ce mélange de surprise — et peut-être un peu d’admiration — quand un LLM produit un bloc de code fonctionnel du premier coup. Mais tout aussi souvent, il trébuche : il appelle une bibliothèque qui n’existe pas, oublie une variable ou rate un cas limite pourtant détaillé dans le prompt.

Avec le SQL, le développement par itérations rapides rend la tâche encore plus difficile pour les LLM. En général, tu écris une requête, tu l’exécutes, tu inspectes le résultat, puis tu l’affines en fonction de ce que tu vois. Et c’est parce que les données elles-mêmes font autant partie du processus que le SQL.

Cela impose des exigences précises à tout benchmark qui veut juger la capacité d’un LLM à générer du SQL. Selon nous, un bon benchmark SQL doit :

• Couvrir plusieurs bases de données : Postgres, MySQL, SQL Server, ClickHouse et les autres ont tous leurs particularités, donc un benchmark équitable doit couvrir plus d’un moteur.
• Inclure des tâches variées : les requêtes vont de simples clauses SELECT … WHERE à des jointures complexes, des fonctions de fenêtrage et des défis qui exigent de connaître le schéma. Un benchmark doit refléter tout ce spectre.
• Vérifier les résultats, pas seulement la syntaxe : la vraie question n’est pas de savoir si le SQL s’exécute, mais s’il renvoie les bonnes données.
• Tenir compte de l’itération : un benchmark utile doit capturer les allers-retours d’affinage des requêtes, pas seulement la première tentative.
• Être transparent : sans schémas, jeux de données et code d’évaluation ouverts, les résultats sont moins fiables.

Alors, existe-t-il des benchmarks de génération de code SQL par l’IA à la hauteur de ces critères ?

Benchmarks SQL

Bien sûr, les benchmarks SQL sont antérieurs aux LLM. Le plus connu est sans doute Spider, publié en 2018 comme jeu de données pour la communauté de recherche text-to-SQL. Bien qu’il ait été conçu pour l’analyse sémantique plutôt que pour les LLM, il est depuis devenu une sorte de référence dans l’évaluation des LLM. Cela dit, chercheurs et éditeurs ont depuis proposé d’autres benchmarks.

Spider

De quoi s’agit-il : publié en 2018, Spider est un jeu de données à grande échelle de plus de 200 bases de données et de milliers de tâches de conversion du langage naturel en SQL, conçu à l’origine pour la communauté de recherche text-to-SQL.

Points forts : large couverture de schémas ; requêtes assez complexes et multi-domaines ; référence de longue date pour les évaluations académiques et de LLM (dont Codex, GPT-3.5, GPT-4).

Limites : repose sur des schémas SQLite propres, très éloignés des bases de production désordonnées ; se concentre sur une évaluation en une seule tentative ; ne reflète pas l’affinage itératif des requêtes.

Verdict : une référence utile et toujours le benchmark le plus cité, mais peut-être trop académique pour refléter les workflows SQL réels.

BIRD-SQL

De quoi s’agit-il : lancé en 2023 comme successeur de Spider, BIRD-SQL a été conçu spécifiquement pour mettre les grands modèles à l’épreuve avec des charges de travail de type BI plus réalistes.

Points forts : schémas plus grands et plus désordonnés ; requêtes qui exigent de raisonner sur le schéma et, dans certains cas, des connaissances externes ; plus exigeant que Spider.

Limites : conception toujours académique ; se concentre sur une évaluation en un seul tour ; moins accessible aux praticiens hors du monde de la recherche.

Verdict : un pas de plus vers les défis des données réelles, mais toujours ni itératif ni multi-moteurs.

Benchmark SQL de Tinybird

De quoi s’agit-il : un benchmark mené par l’industrie, signé Tinybird, qui évalue 19 LLM sur des tâches SQL analytiques avec leur propre plateforme (basée sur ClickHouse), en les comparant à des références humaines.

Points forts : présentation claire ; gros jeu de données (des centaines de millions de lignes) ; résultats comparés côte à côte sur plusieurs modèles.

Limites : lié à l’infrastructure de Tinybird ; limité à la génération de requêtes en une seule tentative ; les résultats ne se généralisent pas forcément au-delà de leur environnement.

Verdict : soigné et pratique, mais au périmètre étroit et peu représentatif des performances des LLM sur différentes bases de données ou dans des workflows itératifs.

SQL-EVAL

De quoi s’agit-il : SQL-EVAL est un framework d’évaluation open source qui mesure l’exactitude du SQL généré par les LLM. Chaque tâche est accompagnée d’une requête SQL de référence vérifiée par des humains. SQL-Eval exécute la requête du modèle et la requête de référence, puis compare les résultats.

Points forts : entièrement open source et reproductible ; gère la complexité du SQL (requêtes imbriquées, jointures multiples), la variété sémantique et les cas où plusieurs requêtes correctes existent.

Limites : vérifie seulement si la requête renvoie les mêmes résultats que la référence, sans juger sa qualité ni son efficacité ; ne gère que la génération en une seule tentative et ne simule pas l’affinage itératif.

Verdict : une ressource précieuse pour juger si les modèles renvoient les bons résultats, et excellente en matière de transparence, mais elle ne reflète toujours pas les workflows itératifs de l’usage réel du SQL.

D’autres benchmarks à découvrir

Des projets plus récents cherchent à combler certaines lacunes laissées par Spider et BIRD-SQL.

• BIRD-CRITIC : un benchmark plus récent construit sur BIRD-SQL. Au lieu de simplement demander au modèle d’écrire une requête une fois, il vérifie si le modèle sait corriger ses propres erreurs. Par exemple : si la première tentative renvoie une erreur ou un mauvais résultat, le benchmark demande au modèle de corriger et de réessayer. Il le fait aussi sur différents systèmes de bases de données (Postgres, MySQL, SQL Server, Oracle).
• BEAVER : un benchmark construit à partir de vraies requêtes issues d’entrepôts de données d’entreprise, et non de jeux de données académiques conçus sur mesure. Il inclut les gros schémas désordonnés qu’on trouve dans la finance, le commerce ou les opérations.

Pour résumer

Chaque benchmark met en lumière une facette différente du défi SQL. Spider et BIRD-SQL ont standardisé l’évaluation text-to-SQL à grande échelle, mais sur des jeux de données bien plus propres que les vrais systèmes de production. Tinybird montre une autre approche qui peut rendre les benchmarks plus accessibles et comparatifs, tandis que SQL-Eval apporte la dimension importante de la couverture multi-moteurs.

Ensemble, ils dessinent la prochaine étape : des benchmarks qui dépassent les requêtes statiques en une seule tentative pour capturer les allers-retours désordonnés du développement SQL.

Requêtes SQL avec l’IA dans Beekeeper Studio

Les benchmarks sont utiles pour comparer des modèles dans des conditions contrôlées, mais le vrai test, c’est la façon dont l’IA s’intègre à ton workflow au quotidien.

C’est là qu’intervient Beekeeper Studio : c’est l’interface SQL qui se connecte à ton LLM préféré pour t’aider à explorer et interroger tes données via une interface conversationnelle et des requêtes SQL manuelles. Elle est rapide, open source et multiplateforme, avec la prise en charge de Postgres, MySQL, SQLite, MongoDB et bien d’autres.

Essaie par toi-même.

Télécharger Beekeeper Studio

---