🤖 AI

SIRIUS-SQL: Anchoring Multi-Candidate Text-to-SQL in Execution Feedback

SIRIUS-SQL est un nouveau cadre de Text-to-SQL qui améliore la précision sur les schémas complexes en abordant les limites des systèmes multi-candidats existants grâce à une stratégie d'entraînement par apprentissage par renforcement à lissage de difficulté pour une génération diversifiée, un cycle de vie ancré dans l'exécution pour une réparation d'erreurs ciblée, et un sélecteur hybride à porte de confiance, atteignant des performances de pointe sur les benchmarks BIRD et SPIDER.

Auteurs originaux : Leo Luo, Haining Xie, Siqi Shen, Zhipeng Ma, Rui Ling, Hang Xu, Hefeng Jiang, Dingwei Chen, Yang Li, Peng Chen, Jie Jiang

Publié 2026-06-02

📖 5 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Leo Luo, Haining Xie, Siqi Shen, Zhipeng Ma, Rui Ling, Hang Xu, Hefeng Jiang, Dingwei Chen, Yang Li, Peng Chen, Jie Jiang

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous essayez de donner une instruction très spécifique et complexe à un robot chef (l'IA) pour cuisiner un repas (écrire une requête SQL) en se basant sur un livre de recettes massif et désordonné (la base de données).

Si vous demandez au robot de cuisiner le plat une seule fois, il fait souvent des erreurs parce que le livre de recettes est déroutant, les ingrédients sont nommés bizarrement ou les instructions sont vagues.

L'ancienne méthode : Le problème du « vote de la foule »
Récemment, d'autres systèmes ont tenté de corriger cela en demandant au robot de cuisiner le repas 16 fois au lieu d'une seule. Ensuite, ils regardaient les 16 plats et choisissaient celui sur lequel la majorité s'accordait (vote majoritaire).

Les auteurs de ce document, SIRIUS-SQL, affirment que cette approche de « vote de la foule » présente trois problèmes majeurs :

La chambre d'écho : Si vous demandez au même robot de cuisiner 16 fois, il va faire les mêmes 16 erreurs. C'est comme demander à une seule personne de deviner un mot de passe 16 fois ; elle donnera probablement la même mauvaise réponse encore et encore.
Le correctif « taille unique » : Lorsqu'un plat sort mal, les anciens systèmes disent simplement : « Oh, c'est cassé, réessaie », sans regarder comment cela s'est cassé. Est-ce que la casserole a brûlé ? Ont-ils oublié le sel ? Ont-ils utilisé la mauvaise poêle ? Tous ces cas nécessitent des corrections différentes, mais l'ancien système les traite tous de la même manière.
Le mauvais vainqueur : Parfois, le plat correct est bien présent sur la table parmi les 16, mais la foule vote pour le mauvais car elle regarde les mauvaises choses (comme le goût plutôt que la liste des ingrédients).

La solution SIRIUS-SQL : Un Maître Chef et un Généraliste
SIRIUS-SQL corrige ces problèmes avec une stratégie en trois parties :

1. Le « Spécialiste » et le « Généraliste » (Corriger la chambre d'écho)

Au lieu de demander à un seul robot de cuisiner 16 fois, ils utilisent deux chefs différents :

Le Spécialiste (SIRIUS-32B) : C'est un robot formé spécifiquement pour la cuisine (SQL). Il a été enseigné grâce à un système de « récompense » spécial (Apprentissage par Renforcement) où il ne reçoit une friandise que si le plat est réussi. Il apprend à créer de nombreuses versions différentes du plat correct, et non pas seulement la même erreur.
Le Généraliste : C'est un robot super intelligent et polyvalent (comme un modèle d'IA célèbre) qui est doué pour comprendre les langages complexes et les instructions étranges.
Le Résultat : En combinant la connaissance approfondie du Spécialiste avec la compréhension large du Généraliste, ils obtiennent une bien plus grande variété de tentatives. C'est comme avoir un maître chef sushi et un chef français créatif travaillant ensemble ; on a plus de chances que l'un d'eux réussisse la recette.

2. Le système de la « Infirmière de Triage » (Corriger le « taille unique »)

Quand un plat sort mal, SIRIUS-SQL ne se contente pas de dire « réessaie ». Il agit comme une infirmière de triage dans un hôpital, diagnostiquant précisément ce qui a mal tourné :

Erreur d'exécution (La casserole a brûlé) : Le robot a essayé d'utiliser un outil qui n'existe pas. Le système corrige la syntaxe immédiatement.
Délai d'attente dépassé / Timeout (La cuisinière est trop lente) : La recette est trop compliquée et prend trop de temps. Le système réécrit la recette pour la rendre plus efficace sans changer le goût.
Résultat vide (La poêle est vide) : Le robot a suivi la recette parfaitement, mais le résultat est vide parce qu'il a cherché le mauvais ingrédient. Le système tente des corrections « structurelles » spécifiques pour trouver le bon ingrédient.

Ce n'est qu'après que le robot a tenté ces corrections spécifiques qu'il est autorisé à réessayer. Cela permet de gagner du temps et d'éviter que le système ne gaspille des efforts sur des corrections impossibles.

3. Le « Juge Intelligent » (Corriger le mauvais vainqueur)

Enfin, lorsqu'il est temps de choisir le meilleur plat parmi la pile, le système utilise un processus de vote en deux étapes :

Étape 1 : Le test de goût : Il examine les résultats réels. Si 10 plats ont le même goût, ils reçoivent un score élevé.
Étape 2 : Le départage : Si deux groupes de plats ont le même score de goût, le système ne se contente pas de deviner. Il examine le plan (la structure) des recettes. Il demande : « Plusieurs chefs différents (le Spécialiste et le Généraliste) sont-ils arrivés indépendamment au même plan ? » Si oui, ce plan est probablement le vrai vainqueur.

Les Résultats
En utilisant cette équipe « Spécialiste + Généraliste », le système de réparation « Infirmière de Triage » et le « Juge Intelligent », SIRIUS-SQL est devenu le meilleur système dans son domaine.

Sur le test BIRD (un test difficile avec des données réelles désordonnées), il a obtenu 75,88 % de précision, battant le système précédent.
Sur le test SPIDER (un test standard), il a atteint 91,20 % de précision.

En résumé, SIRIUS-SQL arrête de compter sur un seul robot qui devine 16 fois. Au lieu de cela, il utilise une équipe d'experts différents, diagnostique les erreurs spécifiques pour les réparer correctement, et utilise un système de vote intelligent à plusieurs étapes pour trouver la seule et vraie réponse.

Résumé Technique : SIRIUS-SQL

Énoncé du Problème

Les systèmes Text-to-SQL peinent face aux schémas complexes des bases de données réelles, où la génération en un seul passage échoue souvent en raison de l'hétérogénéité des schémas, des contraintes implicites et des références de valeurs ambiguës. Bien que les approches récentes atténuent ce problème en générant plusieurs candidats SQL et en utilisant le vote pour filtrer les erreurs, l'article identifie trois faiblesses structurelles couplées dans les pipelines multi-candidats existants :

Échantillonnage à Rendements Décroissants (L1) : L'échantillonnage de plus de candidats à partir d'un seul générateur produit des sorties de plus en plus redondantes car la distribution du générateur est fixée par son entraînement. Simplement augmenter le budget d'échantillonnage ( $k$ ) ne permet pas de faire émerger de nouvelles hypothèses correctes en dehors de la région préférée du générateur.
Signal d'Exécution Gaspillé (L2) : Les pipelines existants appliquent une stratégie de correction unique et générique à tous les résultats d'exécution non propres. Cependant, différents modes de défaillance — erreurs d'exécution (erreurs de syntaxe/types), dépassements de délai (plans inefficaces) et résultats vides (dérive sémantique) — indiquent des distances différentes par rapport à la correction et nécessitent des stratégies de réparation distinctes.
Écart Vote-Oracle (L3) : Même lorsque le SQL correct existe dans le pool de candidats, le vote majoritaire échoue souvent à le sélectionner. Cela se produit car la sélection nécessite un jugement conjoint dans deux espaces : l'espace des résultats (où différents SQL peuvent produire des sorties identiques) et l'espace de la logique (où la même intention admet de nombreuses formes de surface). Les sélecteurs existants opèrent généralement dans un seul de ces espaces.

Méthodologie : SIRIUS-SQL

SIRIUS-SQL répond à ces limitations en ancrant chaque étape du pipeline dans le retour d'exécution. Le système se compose de trois composants clés :

1. Construction de Candidats Complémentaires à la Source

Pour surmonter les rendements décroissants (L1), le système construit un pool de candidats initial à partir de deux sources complémentaires :

Spécialiste ( $G_{sp}$ ) : Un modèle spécialisé pour la tâche (SIRIUS-32B) entraîné avec un Apprentissage par Renforcement à partir de Récompenses d'Exécution Vérifiables (RLVR). L'entraînement utilise une stratégie de synthèse de données lissée par la difficulté pour se concentrer sur les instances où la politique peut s'améliorer, et un programme DAPO à deux étapes avec régularisation d'entropie par seuil pour éviter l'effondrement de l'entropie tout en maintenant des candidats diversifiés et exécutables.
Généraliste ( $G_{ge}$ ) : Un LLM puissant prêt à l'emploi (ex. Qwen3-235B, Gemini-3.1) utilisé avec des démonstrations few-shot pour couvrir les formulations de longue traîne et les contraintes implicites que le spécialiste pourrait manquer.
L'union de ces sources garantit que les candidats exposent différents modes de défaillance, réduisant ainsi la corrélation des erreurs.

2. Cycle de Vie des Candidats Ancré sur l'Exécution

Au lieu de traiter l'exécution comme une simple vérification binaire finale, le système utilise les résultats d'exécution pour piloter une boucle de réparation dynamique (L2) :

Filtrage Pré-exécution : Des filtres déterministes basés sur des règles éliminent le SQL malformé (ex. erreurs de syntaxe, discordances de schéma) avant l'exécution pour économiser le budget de réparation.
Diagnostic et Typage : Les candidats survivants sont exécutés et classés en quatre catégories : propre, erreur d'exécution, dépassement de délai (timeout), et résultat vide.
Réparation Spécifique au Type :
- Erreurs d'Exécution : Le texte de l'exception du moteur est transmis tel quel à un correcteur.
- Dépassements de Délai : La réécriture préserve l'intention mais restructure les ordres de jointure ou les formes de sous-requêtes pour améliorer l'efficacité.
- Résultats Vides : Une approche en deux étapes est utilisée : d'abord, des opérateurs structurels de haute précision (ex. ré-liaison de littéraux, ajustement de prédicats) tentent une récupération locale ; si cela échoue, un repli (fallback) de l'LLM conditionné par le diagnostic est déclenché.
Consolidation du Pool : Les candidats réparés sont ré-exécutés et ré-admis dans le pool. Si le pool s'effondre, un générateur de récupération utilise un feedback négatif condensé pour régénérer les candidats.

3. Sélection Hybride à Seuil de Confiance

Pour combler l'écart vote-oracle (L3), le système emploie un sélecteur à deux étapes qui combine des signaux de niveau résultat et de niveau logique :

Étape 1 (Score de Niveau Résultat) : Calcule un score grossier ( $S_{coarse}$ $S_{co a r se}$ ) en sommant :
- Consensus au Niveau des Tuples ( $S_{maj}$ ) : Fréquence des triplets de cellules à travers l'ensemble des candidats.
- Préférence Par Paire Débiaisée par la Position ( $S_{rm}$ ) : Un juge LLM compare les représentants des classes d'équivalence de signature de résultat pour classer la qualité logique.
Étape 2 (Reranker de Support Structurel) : Un mécanisme de seuil de confiance. Si les meilleurs candidats sont à égalité sur tous les signaux (marge faible), un reranker déterministe sans LLM intervient. Il analyse la signature structurelle au niveau de l'AST (tables, projections, agrégations) et sélectionne le candidat soutenu par le plus grand nombre de groupes de provenance distincts (accord entre les générateurs). Cela agit comme un arbitre sans coût supplémentaire.

Contributions Clés

Recette de RL Lissée par la Difficulté : Une méthodologie d'entraînement pour SIRIUS-32B qui produit une distribution de candidats large mais validée par récompense, atténuant efficacement les rendements décroissants dans l'échantillonnage.
Cycle de Vie Ancré sur l'Exécution : Un cadre de réparation qui classifie les résultats d'exécution et applique des réparations ciblées et spécifiques au type (exécution, timeout, vide) avant de ré-admettre les candidats, maximisant l'utilité des signaux d'exécution.
Sélecteur Hybride à Seuil de Confiance : Un mécanisme de sélection qui fusionne le consensus de niveau tuple avec la préférence de SQL par paire, n'escaladant les cas ambigus vers un contrôle structurel déterministe que si nécessaire, résolvant ainsi l'écart vote-oracle sans coût de calcul excessif.

Résultats

SIRIUS-SQL atteint des performances de pointe sur les benchmarks standards :

BIRD Dev : 75,88 % de précision d'exécution (utilisant SIRIUS-32B + Gemini-3.1 Pro), surpassant le système multi-candidat publié le plus fort, Agentar-Scale-SQL (74,90 %), de 0,98 point de pourcentage. Il montre également des gains significatifs par rapport aux lignes de base en un seul passage (ex. +11,54 % par rapport à Qwen3-Coder).
SPIDER Test : 91,20 % de précision d'exécution, démontrant une forte généralisation sans ré-ajustement spécifique à la tâche.
Études d'Ablation :
- La synthèse de données lissée par la difficulté a amélioré les récompenses de validation de 1,8 pp sur BIRD et de 0,5 pp sur SPIDER pendant l'entraînement.
- La construction de candidats complémentaires (Spécialiste + Généraliste) a surpassé le passage à l'échelle à source unique, prounant que des modes de défaillance diversifiés sont plus précieux qu'un simple nombre élevé d'échantillons.
- Le cycle de vie spécifique aux types a surpassé les stratégies de correction unifiées de 0,13 à 0,71 pp.
- Le sélecteur hybride (fusion + seuil) a apporté un gain de 0,20 pp par rapport aux sélecteurs à signal unique, principalement en résolvant les égalités à faible marge.

Signification

L'article soutient que le principal goulot d'étranglement du multi-candidat Text-to-SQL n'est pas la génération de plus de candidats, mais la sous-utilisation systématique des signaux d'exécution lors de l'entraînement, de la réparation et de la sélection. En ancrant l'ensemble du pipeline dans le feedback d'exécution — en entraînant un spécialiste pour produire des candidats exécutables diversifiés, en réparant les échecs selon les types d'erreurs spécifiques, et en sélectionnant sur la base d'une fusion du consensus de résultat et de la logique structurelle — SIRIUS-SQL démontre que le raffinement ancré sur l'exécution est un levier critique pour améliorer la fiabilité sur des schémas complexes. La capacité du système à surpasser des lignes de base robustes avec deux de ses trois associations de généralistes suggère une architecture robuste et agnostique vis-à-vis du partenaire pour les applications Text-to-SQL à enjeux élevés.