DIN-SQL : Apprentissage en contexte décomposé pour le Text-to-SQL

La semaine dernière, j'ai abordé BIRD, le benchmark qui a révélé à quel point les LLM trébuchent lorsque le text-to-SQL passe de bases de données jouets à des schémas réels comportant des nommages désordonnés, des connaissances métier spécifiques et des contraintes d'efficacité. DIN-SQL est l'article que j'aurais dû lire en premier : il définit ce qu'un pipeline de prompts LLM soigneusement décomposé peut réellement accomplir sur Spider et BIRD, et il a été présenté à NeurIPS 2023 par Mohammadreza Pourreza et Davood Rafiei au moment même où GPT-4 devenait largement disponible. Le lire maintenant — après que BIRD a exposé les limites — permet de voir beaucoup plus clairement les forces et les faiblesses.

L'article

DIN-SQL (arXiv:2304.11015) s'attaque à un écart de performance flagrant. Début 2023, les meilleurs modèles fine-tunés — RESDSQL-3B+NatSQL — atteignaient 79,9 % d'exactitude d'exécution sur l'ensemble de test de Spider, tandis que GPT-4 avec un prompt few-shot naïf ne parvenait qu'à 67,4 % sur l'ensemble de développement. L'hypothèse de Pourreza et Rafiei est que cet écart est principalement un problème d'interface : les LLM sont suffisamment capables, mais générer du SQL en un seul passage leur demande de résoudre simultanément la liaison de schéma, la classification de la complexité et la synthèse de la requête. Décomposez ces éléments en sous-tâches séquentielles et transmettez chaque solution comme contexte, et l'histoire change.

Leur pipeline comporte quatre étapes : (1) un module de liaison de schéma (schema-linking) qui utilise le prompt par chaîne de pensée (chain-of-thought) pour faire correspondre la question en langage naturel à des colonnes et des valeurs spécifiques du schéma ; (2) un module de classification et de décomposition qui classe la requête en catégories facile (table unique, pas de jointures), complexe non imbriquée (jointures mais pas de sous-requêtes) ou complexe imbriquée (jointures, sous-requêtes, opérations d'ensemble) et, pour les requêtes imbriquées, décompose le problème en sous-requêtes ; (3) un module de génération SQL qui adapte la stratégie de prompt à la classe de complexité — few-shot simple pour le facile, représentation intermédiaire NatSQL pour le complexe non imbriqué, chaîne de pensée multi-étapes pour l'imbriqué ; et (4) un module d'auto-correction qui demande au modèle de réviser son propre résultat pour corriger des erreurs mineures comme un DISTINCT manquant ou un DESC mal placé.

Idées clés

• GPT-4 + DIN-SQL atteint 85,3 % d'exactitude d'exécution sur le jeu de test réservé de Spider, soit un bond de +5,4 points par rapport au SOTA fine-tuné de l'époque, RESDSQL-3B+NatSQL (79,9 %), sans aucune donnée d'entraînement spécifique à la tâche.
• Sur le dev set de Spider, le pipeline de décomposition fait passer GPT-4 de 67,4 % (ligne de base few-shot) à 74,2 % — un gain net de +6,8 points. CodeX Davinci passe de 61,5 % à 69,9 %.
• L'ablation confirme que chaque étape contribue : la suppression de la liaison de schéma seule fait chuter CodeX de 69,9 % à 65,9 % ; la suppression de la classification le fait descendre à 63,1 %.
• Les gains sont concentrés sur les requêtes faciles et moyennes. Sur les requêtes "extra difficiles", même le pipeline complet DIN-SQL + GPT-4 n'atteint que 43,4 % sur Spider dev — la décomposition ne résout pas la complexité, elle réduit simplement les erreurs évitables sur les requêtes traitables.
• L'auto-correction est sensible au modèle : GPT-4 répond à des prompts "doux" qui demandent des améliorations potentielles ; CodeX répond mieux à des prompts "génériques" qui supposent que le SQL est faux. Cela suggère que le module effectue un nettoyage stylistique plutôt qu'une réelle vérification sémantique.
• Sur BIRD dev, DIN-SQL + GPT-4 obtient 50,72 % contre 46,35 % pour GPT-4 seul — une amélioration de +4,4 points, nettement inférieure aux gains sur Spider, point sur lequel je reviendrai.

Ce qui tient la route — et ce qui ne tient pas

Le résultat principal est bien réel. Décomposer le text-to-SQL en sous-tâches explicites améliore les performances, et les études d'ablation sont suffisamment claires pour croire aux contributions de chaque module individuel. La liaison de schéma est ce qui importe le plus pour les requêtes difficiles, ce qui est logique : le modèle ne peut pas générer de jointures (JOIN) correctes s'il n'a pas d'abord identifié correctement les tables et colonnes auxquelles la question se réfère.

Cependant, plusieurs points me laissent perplexe. L'écart entre 74,2 % (dev) et 85,3 % (test) est suspect. Les ensembles de développement sont généralement aussi difficiles, voire plus, que les ensembles de test car les modèles sont implicitement ajustés par rapport à eux ; un bond de +11 points du dev au test est inhabituel. Les auteurs ne l'expliquent pas, ce qui me fait me demander si l'ensemble de test a une distribution de difficulté différente, ou s'il y a quelque chose dans l'évaluation du test réservé (via le serveur officiel du classement Spider) qui diffère de leur évaluation sur le dev set. Je ne citerais pas 85,3 % sans cette mise en garde.

L'écart sur BIRD (50,72 % dev) est notablement plus faible que les gains sur Spider. Les bases de données de BIRD ont des schémas réels désordonnés avec des noms de colonnes abrégés, une terminologie spécifique au domaine et des valeurs ambiguës. Le module de liaison de schéma de DIN-SQL a été conçu avec les schémas relativement propres de Spider en tête ; quand les schémas deviennent plus "sales", l'exactitude de la liaison chute et le reste du pipeline se dégrade avec elle. C'est exactement ce que l'article BIRD a mesuré, et DIN-SQL ne le résout pas.

Les chiffres de coût et de latence sont un problème pour tout système de production : environ 0,50 $ et 60 secondes par question avec GPT-4. C'est acceptable pour un analyste de données effectuant dix requêtes par jour, mais totalement inutilisable pour un usage interactif. L'article présente cela comme une limitation connue mais ne propose pas de voie pour la réduire. DAIL-SQL (arXiv:2308.15363), paru quelques mois plus tard, montrera qu'une meilleure sélection d'exemples plutôt qu'une décomposition explicite pourrait atteindre 86,6 % sur Spider — dépassant DIN-SQL pour un coût nettement inférieur.

Le module d'auto-correction est la partie la plus faible. Les auteurs reconnaissent qu'il ne capture que les erreurs "mineures". Ce qu'il ne peut pas faire, c'est détecter les erreurs sémantiques — les cas où le SQL généré est syntaxiquement valide et s'exécute même, mais répond à la mauvaise question. C'est le mode d'échec le plus difficile pour les utilisateurs réels.

Pourquoi cela est important pour l'IA financière

Beanquery (BQL) est un langage de requête de type SQL pour les données de grand livre Beancount. Il possède sa propre structure de tables — transactions, postings, balance, prices — avec des hiérarchies de comptes, des étiquettes (tags) et des champs de métadonnées qui ne ressemblent en rien à des schémas de bases de données génériques. Une interface en langage naturel pour BQL est une chose réelle et utile (il existe déjà un serveur expérimental beanquery-mcp implémentant précisément cela via MCP), et la stratégie de décomposition de DIN-SQL est le bon point de départ.

La liaison de schéma sur BQL est le problème analogue à la liaison de schéma sur des tables relationnelles, mais avec deux complexités supplémentaires : les noms de comptes sont des chemins hiérarchiques comme Assets:US:Checking:Bank, et le schéma pertinent dépend du type de requête posée par l'utilisateur (compte de résultat, bilan, flux de trésorerie). Le module de classification de DIN-SQL suggère une adaptation directe : classer d'abord l'intention de la requête (solde vs flux vs recherche de prix), puis l'orienter vers différents modèles de prompts.

Le constat du benchmark BIRD selon lequel le désordre du monde réel nuit au text-to-SQL par LLM est directement pertinent. Un grand livre Beancount est également "désordonné" — noms de comptes définis par l'utilisateur, symboles de commodités incohérents, clés de métadonnées personnalisées. L'amélioration de 4,4 points sur BIRD contre 6,8 points sur Spider me dit que le régime des schémas structurés et propres surestime l'aide qu'apportera la décomposition sur de réelles requêtes BQL. Attendez-vous à des gains plus modestes en pratique.

La contrainte de coût est réelle mais moins contraignante ici. Un utilisateur de finances personnelles effectuant 10 à 20 requêtes par jour peut tolérer 5 à 10 $ par jour en coûts d'API si l'interface est véritablement utile. La latence (60 secondes) est plus problématique pour un usage interactif ; le traitement par lots des requêtes analytiques pourrait permettre de contourner ce problème.

Que lire ensuite

• DAIL-SQL: Text-to-SQL Empowered by Large Language Models: A Benchmark Evaluation (arXiv:2308.15363) — étude systématique des stratégies d'ingénierie de prompts ; atteint 86,6 % sur Spider en se concentrant sur la sélection d'exemples plutôt que sur la décomposition architecturale, un contrepoint utile à DIN-SQL.
• RESDSQL: Decoupling Schema Linking and Skeleton Parsing for Text-to-SQL (arXiv:2302.05965, AAAI 2023) — la base de référence fine-tunée que DIN-SQL a battue ; comprendre ce que l'approche par fine-tuning réussit permet de clarifier les points où le prompting échoue encore.
• MAC-SQL: A Multi-Agent Collaborative Framework for Text-to-SQL (arXiv:2312.11242) — étend l'idée de décomposition multi-étapes en un pipeline multi-agents explicite avec un Sélecteur, un Décomposeur et un Raffineur ; atteint 59,59 % sur BIRD avec GPT-4 et constitue l'approche la plus centrée sur les agents dans ce domaine.