🤖 machine learning

SQLConductor: Search-to-Policy Learning for Step-wise Text-to-SQL Orchestration

Le document présente SQLConductor, un cadre d'orchestration par étapes qui emploie l'apprentissage de la recherche vers la politique (Search-to-Policy Learning) pour entraîner un modèle de politique afin de sélectionner dynamiquement des sous-tâches SQL basées sur un retour d'information intermédiaire, atteignant ainsi une précision d'exécution et une généralisation supérieures sur les benchmarks complexes de Text-to-SQL par rapport aux pipelines fixes et à l'entraînement direct du backbone.

Auteurs originaux : Yizhang Zhu, Zhangyang Peng, Boyan Li, Yuyu Luo

Publié 2026-06-23

📖 5 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Yizhang Zhu, Zhangyang Peng, Boyan Li, Yuyu Luo

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 d'obtenir une réponse très spécifique à partir d'une immense et désordonnée bibliothèque d'informations (une base de données) en posant une question en langage naturel. C'est le problème du « Text-to-SQL » : transformer une question humaine en une commande informatique (SQL) que la bibliothèque peut comprendre.

Pendant longtemps, les ordinateurs ont tenté de résoudre cela en suivant une recette stricte et préétablie. Peu importe votre question, l'ordinateur devait suivre les mêmes étapes : Étape 1, Étape 2, Étape 3, Étape 4. Si vous posiez une question simple comme « Quelle est la capitale de la France ? », l'ordinateur devait quand même passer par ces quatre étapes, perdant ainsi du temps et se confondant parfois. Si vous posiez une question difficile et que l'ordinateur faisait une erreur à l'Étape 2, il continuait sa course en emportant cette erreur, menant à une mauvaise réponse.

SQLConductor est un nouveau système qui change la donne. Au lieu de suivre une recette rigide, il agit comme un chef de projet intelligent ou un chef d'orchestre qui décide de la prochaine étape en fonction de ce qui se passe en ce moment même.

Voici comment cela fonctionne, en utilisant des analogies simples :

1. La boîte à outils (L'espace d'action)

Imaginez que l'ordinateur possède une boîte à outils avec différents outils spécialisés :

Le Briseur : Décompose une question complexe en parties plus petites.
Le Chercheur : Cherche des chiffres ou des noms spécifiques dans la base de données.
Le Filtre : Élimine les informations non pertinentes.
L'Écrivain : Rédige la véritable commande informatique.
L'Éditeur : Corrige les erreurs dans la commande.
Le Finisseur : Dit : « Nous avons terminé, voici la réponse. »

Les anciens systèmes forçaient l'ordinateur à choisir les outils dans un ordre spécifique (par exemple, Briseur $\to$ Chercheur $\to$ Écrivain $\to$ Finisseur). SQLConductor permet au « Chef d'orchestre » de choisir l'outil dont il a besoin immédiatement. Si le Chercheur réalise qu'il a besoin de plus d'informations, le Chef d'orchestre peut appeler à nouveau le Briseur. Si l'Écrivain fait une erreur, le Chef d'orchestre peut appeler l'Éditeur immédiatement.

2. Le camp d'entraînement (Apprentissage Search-to-Policy)

Comment le Chef d'orchestre apprend-il à prendre ces décisions intelligentes ? Il ne se contente pas de lire un manuel ; il suit un camp d'entraînement rigoureux appelé Apprentissage Search-to-Policy.

La Simulation (MCTS) : Imaginez un joueur d'échecs s'entraînant contre un ordinateur. L'ordinateur essaie des milliers de chemins de jeu différents (flux de travail) pour voir lesquels gagnent. SQLConductor fait de même : il simule des millions de façons différentes de résoudre une question, en testant différentes combinaisons d'outils.
Le Test de Stabilité : Ce n'est pas parce qu'un chemin a fonctionné une fois que c'est une bonne stratégie ; cela pourrait être de la chance. Le système examine quels chemins fonctionnent de manière constante. C'est comme un entraîneur qui dirait : « Ne te contente pas de copier la fois où tu as gagné par chance ; copie la stratégie qui gagne 9 fois sur 10. »
Le « Curriculum » (Problèmes plus difficiles) : Une fois que le Chef d'orchestre devient doué pour les problèmes faciles, le camp d'entraînement lui lance des questions plus difficiles et plus complexes. Le système apprend spécifiquement comment gérer les cas difficiles où il échoue habituellement.

3. Le Résultat : Un travailleur flexible et efficace

Une fois entraîné, le SQLConductor est déployé pour résoudre de vraies questions.

Adaptabilité : Si vous posez une question simple, le Chef d'orchestre peut dire : « Je n'ai pas besoin de l'Éditeur ni du Briseur ; je vais juste utiliser l'Écrivain et le Finisseur. » Cela gagne du temps. Si vous posez une question complexe, il sait qu'il doit revenir en arrière, rassembler plus de preuves et affiner la réponse.
Efficacité : Parce qu'il n'utilise que les outils dont il a réellement besoin, il utilise moins de puissance de calcul et coûte moins cher que les systèmes qui forcent chaque question à travers un long pipeline fixe.
Précision : Lors de tests, ce système a obtenu la bonne réponse plus souvent que les méthodes précédentes, même lorsque les questions étaient très difficiles ou que les bases de données étaient désordonnées.

La vue d'ensemble

Considérez les anciens systèmes Text-to-SQL comme un tapis roulant dans une usine : chaque article passe par les mêmes machines, qu'il en ait besoin ou non. Si une pièce se casse sur le tapis, toute la ligne continue de tourner, produisant des produits défectueux.

SQLConductor est comme un artisan qualifié dans un atelier. Il regarde l'objet (la question), décide quels outils saisir, tente une étape, vérifie le résultat, puis décide de la suite. S'il fait une erreur, il la corrige immédiatement. Si le travail est simple, il le termine rapidement. Si c'est complexe, il prend le temps de bien faire les choses.

L'article affirme qu'en apprenant à un ordinateur à agir comme cet artisan qualifié — plutôt que comme une machine rigide — il peut résoudre des questions de base de données avec plus de précision, plus d'efficacité et une meilleure adaptabilité à différents types de problèmes.

Résumé Technique : SQLConductor

1. Énoncé du Problème

Le passage du texte au SQL (Text-to-SQL) en conditions réelles reste un défi en raison de la nécessité d'un raisonnement coordonné sur des environnements de bases de données complexes et hétérogènes. Les systèmes existants se répartissent généralement en deux catégories, qui présentent toutes deux des limites en termes d'adaptativité :

Pipelines Fixes : Ils reposent sur des ordres d'étapes prédéfinis et rigides (ex: liaison de schéma $\to$ extraction de valeurs $\to$ génération $\to$ révision). Bien que structurés, ils ne peuvent pas reconsidérer les décisions antérieures basées sur un retour intermédiaire ou des erreurs d'exécution, ce qui entraîne une propagation des erreurs.
Orchestration de type "Planification puis Exécution" (Plan-then-Execute) : Ces méthodes génèrent un plan de flux de travail complet avant l'exécution. Bien que plus flexibles que les pipelines fixes, elles s'engagent néanmoins dans une séquence statique une fois l'exécution commencée, empêant le système de s'adapter aux artefacts intermédiaires ou au feedback d'exécution pendant le processus de résolution.

Le défi central est d'apprendre une politique d'orchestration étape par étape capable de sélectionner dynamiquement l'action suivante en fonction du contexte de résolution actuel et des preuves intermédiaires, sans dépendre de données de flux de travail créées par l'humain ou sans encourir de coûts de recherche en ligne prohibitifs lors de l'inférence.

2. Méthodologie : SQLConductor

SQLConductor est un cadre d'apprentissage d'orchestration étape par étape qui sépare l'organisation du processus (orchestration) de l'exécution des sous-tâches (raisonnement). Il emploie un paradigme de Apprentissage par Recherche vers Politique (Search-to-Policy Learning), transformant une recherche large de flux de travail hors ligne en une politique déployable pour une inférence efficace.

2.1 Espace d'Actions

Le système définit un espace d'actions modulaire $\mathcal{A}$ comprenant sept modules spécialisés, invoqués par des Grands Modèles de Langage (LLM) gelés :

Décomposition de la Question ( $a_{dec}$ ) : Réécrit les questions complexes en exigences fines.
Extraction de Valeurs Pertinentes ( $a_{val}$ ) : Identifie les valeurs de condition pour les prédicats SQL.
Identification d'Opérations ( $a_{op}$ ) : Enregistre les opérations SQL requises (ex: agrégation, tri).
Élagage de Schéma ( $a_{sch}$ ) : Sélectionne les tables et colonnes pertinentes.
Génération de Requête SQL ( $a_{gen}$ ) : Synthétise un candidat SQL.
Raffinement de Requête SQL ( $a_{ref}$ ) : Corrige les erreurs de syntaxe ou d'exécution.
Terminaison et Sortie ( $a_{term}$ ) : Met fin au flux de travail et retourne le SQL final.

2.2 Apprentissage de la Recherche vers la Politique (Search-to-Policy Learning)

Le processus d'entraînement consiste en une phase hors ligne et une phase de déploiement en ligne.

Phase 1 : Entraînement Hors Ligne de la Recherche vers la Politique

Exploration de Flux de Travail par MCTS :
- Pour chaque instance d'entraînement, SQLConductor effectue une recherche arborescente de Monte Carlo (MCTS) sur l'espace d'actions.
- Les nœuds représentent les états d'orchestration ; les arêtes représentent les sélections d'actions.
- La recherche explore diverses compositions et profondeurs d'actions, guidée par des récompenses de cohérence d'exécution (mesurant si le SQL généré produit des résultats cohérents sur plusieurs échantillons).
- Cela génère un ensemble diversifié de trajectoires candidates $\mathcal{X}(q, D)$ .
Curation de la Supervision du Flux de Travail :
- Extraction de Squelette : Les trajectoires sont regroupées par leurs séquences d'actions (squelettes de flux de travail).
- Estimation de la Stabilité : Étant donné que l'espace de recherche est combinatoire et bruyant, SQLConductor estime la stabilité de chaque flux de travail en utilisant la règle de succession de Laplace : $\hat{p}_\tau = \frac{s_\tau + 1}{n_\tau + 2}$ , où $s_\tau$ est le nombre d'exécutions réussies et $n_\tau$ le nombre total.
- Sélection : Les top- $k$ flux de travail ayant les scores de stabilité les plus élevés sont sélectionnés. Une trajectoire réussie est échantillonnée de chaque groupe comme représentante.
- Augmentation du Raisonnement : Un LLM déployé génère un raisonnement au niveau de l'étape ( $e_t$ ) expliquant pourquoi une action spécifique a été choisie compte tenu du contexte actuel, créant ainsi une trajectoire augmentée $\bar{\xi}$ .
Fine-Tuning Supervisé (SFT) pondéré par la Stabilité :
- Le modèle de politique est entraîné sur les trajectoires augmentées curatées.
- Masquage : La fonction de perte masque les jetons <results> (sorties d'actions) pour empêcher la politique d'apprendre à prédire les sorties d'actions, se concentrant plutôt sur les décisions d'orchestration.
- Pondération : Les trajectoires sont pondérées par leurs scores de stabilité ( $\hat{p}_\tau$ ) pour prioriser les modèles d'orchestration robustes tout en préservant la diversité.
Apprentissage par Renforcement par Curriculum (RL) :
- Pour gérer les requêtes difficiles où les trajectoires réussies sont rares, le système construit un ensemble de curriculum d'instances difficiles (faible ratio de succès MCTS).
- En utilisant l'Optimisation de Politique Relative de Groupe (GRPO), la politique effectue des auto-simulations sur ces cas difficiles.
- Récompenses : La fonction de récompense combine l'Exécutabilité (SQL valide) et la Qualité du Résultat (score F1 d'exécution par rapport à la vérité terrain), encourageant la politique à apprendre des stratégies de récupération pour les cas complexes.

Phase 2 : Déploiement en Ligne

Le modèle de politique entraîné coordonne les modules d'action gelés étape par étape.
À chaque étape, la politique génère un raisonnement et sélectionne l'action suivante basée sur l'état actuel (preuves accumulées et feedback).
Le flux de travail est construit dynamiquement pendant l'exécution, s'adaptant aux demandes spécifiques de la requête.

3. Contributions Clés

Cadre d'Orchestration Étape par Étape : SQLConductor introduit un cadre qui découple l'organisation du processus de l'exécution des sous-tâches, permettant des flux de travail spécifiques à la requête avec des profondeurs et des compositions de modules adaptatives, contrairement aux pipelines fixes ou aux approches de planification-puis-exécution.
Apprentissage de la Recherche vers la Politique : Le papier propose un mécanisme pour entraîner une politique d'orchestration adaptative sans données de flux de travail créées par l'humain. Il utilise MCTS pour l'exploration, l'estimation de la stabilité pour la curation, et une combinaison de SFT pondéré par la stabilité et de RL par curriculum pour l'entraînement.
Performance Empirique et Généralisation :
- BIRD-Dev : SQLConductor atteint 73,2 % d'Exactitude d'Exécution (EX) sur le benchmark BIRD-Dev, surpassant les méthodes antérieures qui entraînent directement des modèles de base Text-to-SQL comparables ou plus grands.
- Efficacité des Paramètres : Il obtient ces résultats en entraînant uniquement une politique d'orchestration compacte (ex: 8B paramètres) pour coordonner des modèles d'action plus grands et gelés (ex: 32B), démontant une efficacité supérieure de l'exactitude par paramètre entraîné.
- Généralisation : Le modèle montre une forte généralisation sur des jeux de données hors distribution (OOD) (Spider-Test, KaggleDBQA, ScienceBenchmark) sans ré-entraînement spécifique au jeu de données.
- Efficacité : Il réduit considérablement l'utilisation de jetons lors de l'inférence et les coûts d'API (environ 8 fois moins cher que des bases comme CHESS) tout en maintenant une précision plus élevée.

4. Signification et Revendications

Le papier affirme qu'un apprentissage d'orchestration est plus efficace en termes de paramètres et plus performant qu'un entraînement supplémentaire d'un modèle monolithique de Text-to-SQL.

Adaptativité vs Force Brute : Les résultats démontrent que les gains de performance ne proviennent pas simplement de l'augmentation de la longueur du flux de travail ou de la taille du modèle, mais de la capacité de la politique à allouer l'effort d'orchestration de manière adaptative. La politique entraînée assigne plus d'étapes aux requêtes difficiles tout en gardant les requêtes simples efficaces.
Robustesse : La curation pondérée par la stabilité garantit que la politique apprend des modèles robustes plutôt que des succès accidentels, lui permettant de gérer efficacement des requêtes complexes, bruitées et spécialisées sur des domaines.
Scalabilité : En séparant la politique d'orchestration des modules d'action, le cadre permet l'intégration de modèles d'action plus grands ou spécialisés sans réentraîner l'ensemble du système, offrant une voie évolutive pour les tâches complexes de Text-to-SQL.

En résumé, SQLConductor remédie à la rigidité des systèmes Text-to-SQL existants en apprenant une politique d'orchestration par étapes dynamique qui s'adapte aux preuves intermédiaires, atteignant des performances de pointe avec des coûts de calcul nettement inférieurs.