MAC-SQL : Collaboration Multi-Agents pour le Text-to-SQL

MAC-SQL est apparu en décembre 2023 comme la réponse la plus explicitement centrée sur les agents au problème du text-to-SQL : au lieu d'un seul prompt générant une seule requête, trois agents spécialisés collaborent pour sélectionner un sous-schéma pertinent, décomposer la question et réparer le SQL après exécution. Je le lis parce que les deux articles précédents couvraient BIRD (le benchmark que MAC-SQL dominait lors de sa soumission) et DIN-SQL (la base de décomposition que MAC-SQL étend), et la question naturelle est de savoir si une enveloppe multi-agents apporte quelque chose de concret en plus de ces fondations.

L'article

"MAC-SQL: A Multi-Agent Collaborative Framework for Text-to-SQL" (Wang et al., COLING 2025) cible un mode d'échec que BIRD a mis en évidence dans les méthodes antérieures à prompt unique : les bases de données volumineuses avec des schémas bruyants et des questions complexes à plusieurs étapes submergent les modèles qui tentent de tout raisonner d'un seul coup.

L'architecture comporte trois agents. Un Selector réduit une base de données volumineuse à un sous-schéma pertinent en filtrant les tables et colonnes non pertinentes avant tout début de génération SQL. Un Decomposer est le moteur central — il décompose les questions complexes en langage naturel en sous-problèmes et génère le SQL de manière incrémentale avec un raisonnement par chaîne de pensée (few-shot chain-of-thought). Un Refiner exécute le SQL candidat sur la base de données réelle, lit les messages d'erreur textuellement et corrige itérativement la requête jusqu'à une limite maximale de tentatives. Les trois agents ne s'activent pas sur chaque requête ; les tâches plus simples ignorent le Selector ou le Refiner en fonction de signaux de complexité.

Les auteurs ont également affiné SQL-Llama (Code Llama 7B) sur les sorties produites par le framework, fournissant ainsi une variante open-source plus petite.

Idées clés

• Réduction de schéma avant la génération : Le Selector filtre la base de données vers un sous-schéma pertinent avant que le Decomposer n'écrive le SQL. L'ablation confirme un gain de +2,11 points de pourcentage sur le dev BIRD — réel, mais modeste.
• Affinement guidé par l'exécution : Le Refiner lit les messages d'erreur réels de la base de données et corrige le SQL. C'est le contributeur le plus important dans l'étude d'ablation : sa suppression fait chuter la précision du dev BIRD de 4,63 points, plus que la suppression du Selector (−2,11) ou même du Decomposer (−3,85).
• Dispatching conditionnel des agents : Orienter les requêtes plus simples au-delà du Selector et du Refiner économise des jetons sans nuire à la précision sur les cas faciles.
• Écart de distillation open-source : SQL-Llama (7B) atteint 43,94 % sur le dev BIRD contre 46,35 % pour la référence GPT-4. L'écart n'est pas dramatique compte tenu de la différence du nombre de paramètres, mais le modèle 7B affiné reste à plus de 15 points derrière le score de test complet de 59,59 % de GPT-4+MAC-SQL.
• Résultat du test BIRD : 59,59 % de précision d'exécution, dominant le classement au moment de la soumission et surpassant DAIL-SQL+GPT-4 (57,41 %) de 2,18 points.

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

Le Refiner est la meilleure idée ici, et l'ablation le démontre. Un agent qui lit un message d'erreur réel d'une base de données et corrige son propre SQL fait quelque chose de véritablement plus rigoureux qu'un LLM essayant de se corriger seul dans le vide — c'est le principe de "critique interactive par outil" (CRITIC) appliqué directement et concrètement au retour d'exécution SQL.

La contribution du Selector est positive mais mince. Pour les bases de données contenant des centaines de tables, cela compte probablement davantage ; pour le schéma typique de BIRD, c'est marginal, et l'article ne précise pas à quelle fréquence le Selector se déclenche ni sa précision à conserver les colonnes pertinentes — c'est une boîte noire avec un seul chiffre global.

Le Decomposer est une évolution incrémentale de DIN-SQL. DIN-SQL décomposait déjà les requêtes en sous-problèmes avec auto-correction ; MAC-SQL remballe cela sous forme de conversation multi-agents. La division architecturale en trois agents nommés ressemble plus à un choix de conception logicielle qu'à un nouvel algorithme d'inférence. La question de savoir si la structure de prompt à trois agents surpasse un agent unique avec un prompt plus long, à nombre total de jetons égal, n'est jamais testée. Les limitations reconnues — des prompts "pas largement optimisés" et un affinement limité à 7B — sont réelles, mais l'omission la plus substantielle est l'absence totale d'ablation sur la longueur du prompt par rapport à l'architecture.

Le contexte temporel importe pour l'étalonnage. Les 59,59 % de MAC-SQL sur le test BIRD représentaient l'état de l'art en décembre 2023. À la mi-2025, le classement BIRD montre des systèmes dépassant les 81 %. Les idées spécifiques — filtrage de sous-schéma, décomposition de questions, tentatives d'exécution — ont été absorbées et étendues par des travaux ultérieurs utilisant l'entraînement axé sur le raisonnement, le RLVR et des CoT plus riches. MAC-SQL en tant qu'objet semble daté ; MAC-SQL en tant que modèle architectural reste d'actualité.

Pourquoi cela compte pour l'IA financière

Beancount utilise beanquery — un langage de requête proche du SQL — comme interface de programmation principale pour les données du grand livre. Un fichier beancount réel s'étalant sur plusieurs années possède un schéma qui inclut des dizaines de comptes organisés en hiérarchie, plusieurs devises, des balises de métadonnées et des colonnes de solde calculées. C'est précisément le problème de schéma large et bruyant que cible le Selector.

Le Decomposer s'applique directement aux types de requêtes que les utilisateurs posent réellement : « Quelles ont été mes dépenses totales de restauration en EUR au troisième trimestre 2024, hors transactions remboursées, ventilées par mois ? » est un problème de décomposition — filtrer par préfixe de compte, filtrer par plage de dates, exclure les transactions marquées, agréger par mois. Le Refiner se transpose naturellement aussi : avant de valider une écriture beancount générée, un agent pourrait la tester via le parseur beancount, recevoir des erreurs de syntaxe ou d'équilibre, et la réviser. La boucle de retour d'exécution démontrée par MAC-SQL est la même boucle dont a besoin une couche de sécurité pour l'écriture de données.

Le résultat de la distillation open-source est un avertissement : affiner un modèle 7B pour approximer un pipeline basé sur GPT-4 produit un modèle qui reste loin derrière. Si Bean Labs construit un modèle local pour la génération de requêtes sur le grand livre, l'écart de MAC-SQL suggère que les petits modèles ont besoin de données d'entraînement spécifiques au domaine bien au-delà de ce qu'offre un affinement à usage général.

À lire ensuite

• DAIL-SQL (Gao et al., 2023, arXiv:2308.15363) — l'évaluation de référence systématique de l'ingénierie de prompts que MAC-SQL améliore directement sur BIRD, à lire pour l'ablation contrôlée de la représentation du schéma et de la sélection d'exemples few-shot.
• SQLFixAgent (arXiv:2406.13408) — étend la correction SQL guidée par l'exécution en un système multi-agents avec vérification de cohérence, un descendant direct de l'idée du Refiner de MAC-SQL.
• BIRD-Critic / SWE-SQL (2025) — la nouvelle piste de raisonnement BIRD exigeant la compréhension des erreurs d'exécution, l'évolution naturelle de ce que faisait le Refiner dans MAC-SQL.