💬 NLP

Test-Time Verification for Text-to-SQL via Outcome Reward Models

Cet article présente GradeSQL, un cadre qui exploite les modèles de récompense par résultat (ORM) en tant que scoreurs sémantiques appris pour améliorer la fiabilité du Text-to-SQL, démontrant qu'une vérification basée sur l'ORM surpasse significativement les méthodes heuristiques traditionnelles telles que le Best-of-N basé sur l'exécution et le vote majoritaire sur les benchmarks BIRD et Spider.

Auteurs originaux : Mattia Tritto, Giuseppe Farano, Dario Di Palma, Gaetano Rossiello, Fedelucio Narducci, Dharmashankar Subramanian, Tommaso Di Noia

Publié 2026-07-01

📖 5 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Mattia Tritto, Giuseppe Farano, Dario Di Palma, Gaetano Rossiello, Fedelucio Narducci, Dharmashankar Subramanian, Tommaso Di Noia

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 demandiez à un chef très intelligent, mais parfois un peu trop sûr de lui (l'IA), de cuisiner un plat spécifique en se basant sur une recette que vous décrivez en langage courant. Le chef sait cuisiner, mais il arrive parfois qu'il se trompe d'ingrédients ou qu'il mélange les étapes.

Dans le monde de l'informatique, cela s'appelle le Text-to-SQL : traduire une question humaine en une requête SQL (un ensemble d'instructions pour une base de données informatique). Le problème est que si le chef commet ne serait-ce qu'une infime erreur, l'ordinateur pourrait vous donner la mauvaise réponse, ou rien du tout.

L'ancienne méthode : « Deviner et vérifier »

Habituellement, quand le chef n'est pas sûr, le système lui demande de cuisiner le plat 32 fois (générer 32 requêtes SQL différentes). Il doit ensuite choisir la meilleure.

Les anciennes méthodes pour choisir le vainqueur sont les suivantes :

Le vote majoritaire : « Qui a cuisiné le plat le plus souvent ? » Si 20 chefs disent « ajoute du sel » et 12 disent « ajoute du sucre », le système suppose que le « sel » est la bonne réponse. Mais que se passe-t-il si la recette nécessitait réellement du sucre et que la majorité a simplement fait la même erreur ?
Le succès de l'exécution : « Qui a réussi à faire fonctionner la poêle ? » Si une requête s'exécute sans planter, le système la choisit. Mais une requête peut s'exécuter parfaitement et pourtant vous donner les mauvaises données (comme servir un gâteau alors que vous avez demandé une soupe).

Ces méthodes reposent sur des indices simples et superficiels (heuristiques) plutôt que de comprendre réellement si le plat est correct.

La nouvelle méthode : Le critique culinaire « GradeSQL »

Ce document présente un nouveau système appelé GradeSQL. Au lieu de simplement compter les voix ou de vérifier si la poêle fonctionne, ils entraînent un Critique spécialisé (appelé un Modèle de Récompense par Résultat ou ORM).

Voici comment fonctionne le système GradeSQL, étape par étape :

1. Le cours de cuisine (Entraînement)
D'abord, le système doit apprendre au Critique ce qu'est un « bon » et un « mauvais » résultat.

Il prend une question et demande au chef principal (l'IA) de cuisiner 32 versions différentes du plat.
Il exécute ensuite les 32 plats par rapport au « Standard d'Or » (la réponse correcte).
Si un plat a exactement le même goût que le Standard d'Or, le Critique lui donne une Note Élevée. S'il a un goût différent, il reçoit une Note Basse.
Le Critique apprend de ces exemples pour reconnaître la saveur d'une requête correcte, et non pas seulement si elle a planté.

2. La séance de dégustation (Inférence)
Maintenant, lorsqu'un véritable utilisateur pose une question :

Le chef cuisine 32 nouvelles versions.
Au lieu de simplement vérifier si elles fonctionnent, le Critique goûte chacune d'entre elles.
Le Critique donne à chaque plat une note basée sur la manière dont il correspond à l'intention de la question.
Le système choisit le plat ayant obtenu la note la plus élevée.

Pourquoi est-ce meilleur ?

Le papier a testé ce système sur deux énormes bases de données de questions (appelées BIRD et Spider). Ils ont constaté que le Critique était bien meilleur pour repérer la bonne réponse que les anciennes méthodes de « comptage de votes » ou de « vérification de plantage ».

L'analogie : Imaginez un QCM (questionnaire à choix multiples). L'ancienne méthode choisit la réponse qui apparaît le plus souvent ou qui ne contient pas de faute de frappe. La nouvelle méthode (GradeSQL) lit réellement la question et la réponse pour voir si elles font sens ensemble.
Les résultats : Sur les questions difficiles, le Critique a aidé le système à obtenir la bonne réponse environ 4 % de plus souvent sur le jeu de données BIRD et 2 % de plus souvent sur le jeu de données Spider. Bien que 2 à 4 % puisse paraître faible, dans le monde de l'IA, c'est une amélioration énorme, surtout pour les questions les plus complexes où les anciennes méthodes abandonnent généralement.

Points clés à retenir

C'est un juge « appris » : Le Critique ne suit pas seulement des règles ; il a appris ce qu'est une requête SQL correcte en s'entraînant sur des milliers d'exemples.
Pas besoin d'humain : Le système s'est auto-enseigné comment être un critique en vérifiant automatiquement quelles réponses fonctionnaient, de sorte qu'aucun humain n'a eu à corriger manuellement les devoirs.
C'est évolutif : Plus il y a d'options (candidats) que le chef génère, meilleur est le travail du Critique. Les anciennes méthodes stagnent et cessent de progresser, mais le Critique devient de plus en plus intelligent à mesure qu'il a plus de choix à sélectionner.

En résumé, GradeSQL est comme l'embauche d'un critique gastronomique professionnel pour choisir le meilleur plat parmi un lot de 32, plutôt que de simplement demander l'avis de la foule ou de vérifier si la cuisinière est allumée. Cela rend l'IA plus fiable lorsque les questions deviennent complexes.

Résumé Technique : Vérification au Moment de l'Inférence pour le Text-to-SQL via des Modèles de Récompense de Résultat (Outcome Reward Models)

Énoncé du Problème

La fiabilité des Grands Modèles de Langage (LLM) dans les tâches de raisonnement structuré, spécifiquement le Text-to-SQL, demeure un défi critique. Bien que les LLM aient progressé de manière significative, ils éprouvent souvent des difficultés avec les requêtes complexes impliquant des jointures multi-tables, des sous-requêtes imbriquées et des contraintes subtiles. Les stratégies d'inférence actuelles au moment de l'exécution, telles que l'échantillonnage Best-of-N (BoN) et le Vote Majoritaire, tentent d'atténuer cela en générant plusieurs requêtes SQL candidates et en sélectionnant la meilleure. Cependant, ces méthodes reposent sur des signaux heuristiques — principalement le succès d'exécution (la requête s'exécute-t-elle sans erreur ?) ou la fréquence de sortie (plusieurs requêtes renvoient-elles le même résultat ?).

Les auteurs soutiennent que ces heuristiques ne sont que des approximations grossières de la correction sémantique. À mesure que les ensembles de candidats augmentent, ces signaux saturent et échouent à discriminer entre les requêtes sémantiquement valides et invalides, particulièrement lorsque plusieurs requêtes incorrectes s'exécutent avec succès mais renvoient des résultats erronés, ou lorsque des requêtes sémantiquement équivalentes possèdent des structures syntaxiques différentes. Il existe un besoin pour un mécanisme de vérification appris capable de noter les candidats sur la base d'un alignement sémantique spécifique à la tâche plutôt que sur des métriques d'exécution de surface.

Méthodologie : Le Cadre GradeSQL

Pour répondre à la rareté des données étiquetées nécessaires à l'entraînement de vérificateurs pour les tâches structurées, les auteurs introduisent GradeSQL, un cadre évolutif pour l'entraînement de Modèles de Récompense de Résultat (ORM). Contrairement aux Modèles de Récompense de Processus (PRM) qui évaluent les étapes intermédiaires, les ORM attribuent des scores scalaires aux sorties finales. Le cadre fonctionne en trois étapes :

Génération de Candidats : Étant donné une question en langage naturel et un schéma de base de données, un LLM générateur produit un ensemble diversifié de $N$ requêtes SQL candidates en utilisant des stratégies de décodage stochastiques. Cette diversité est cruciale pour exposer le vérificateur à une large gamme de formulations correctes et d'erreurs de type "presque correct".
Étiquetage Automatisé des Données : Au lieu d'une annotation manuelle, le cadre étiquette les candidats via l'équivalence d'exécution. Chaque candidat est exécuté contre la base de données. Si l'ensemble de résultats correspond à celui de la requête de référence (gold-standard) ( $R(c_j) = R(y_{gold})$ ), le candidat est étiqueté "Correct" ; sinon, il est étiqueté "Incorrect". Les requêtes provoquant des erreurs d'exécution sont écartées. Cela crée un ensemble de données à grande échelle, automatiquement étiqueté, pour l'entraînement du vérificateur.
Fine-Tuning Supervisé (SFT) : Un LLM vérificateur est affiné (en utilisant LoRA) en tant que classificateur autorégressif binaire. L'entrée consiste en le schéma, la question et une requête candidate, et le modèle est entraîné à prédire la probabilité du jeton "Oui" (indiquant la correction).

Pipeline d'Inférence : Au moment de l'inférence, le générateur produit $N$ candidats. L'ORM entraîné note chaque candidat sur la base de la probabilité du jeton "Oui". Le candidat ayant le score le plus élevé est sélectionné, remplaçant la sélection heuristique par une notation sémantique apprise.

Contributions Clés

Le papier présente trois contributions principales :

Vérification basée sur l'ORM pour le Text-to-SQL : L'étude adapte les Modèles de Récompense de Résultat comme des scoreurs sémantiques appris pour la sélection de candidats au moment de l'inférence dans la génération de requêtes structurées, démontrant leur applicabilité au-delà de leur usage traditionnel dans l'alignement et le raisonnement.
Pipeline de Curage de Données Évolutif : Les auteurs proposent GradeSQL, un cadre automatisé qui génère et étiquette des requêtes SQL candidates via l'équivalence d'exécution. Cela permet l'entraînement d'ORM spécifiques à la tâche sans nécessiter d'annotation manuelle coûteuse.
Analyse Empirique de la Vérification au Moment de l'Inférence : Une évaluation systématique sur plusieurs familles de LLM open-source (incluant Qwen, Granite, Llama et OmniSQL) et des benchmarks (BIRD et Spider) montre que la sélection basée sur l'ORM surpasse systématiquement les bases heuristiques.

Résultats Expérimentaux

L'approche a été évaluée sur les benchmarks BIRD et Spider en utilisant plusieurs modèles générateurs. Les conclusions clés incluent :

Gains de Performance : La sélection basée sur l'ORM a systématiquement obtenu une précision d'exécution (EX) plus élevée que le Vote Majoritaire et le Best-of-N basé sur l'exécution.
- Sur BIRD dev, l'ORM a atteint 68,90 %, soit un gain de +5,01 % par rapport à la ligne de base ( $N=1$ ) et surpasse le Vote Majoritaire (+3,06 %) et le BoN basé sur l'exécution (+2,15 %).
- Sur Spider test, l'ORM a atteint 87,47 %, surpassant le Vote Majoritaire (85,47 %) et le BoN basé sur l'exécution (85,14 %).
Évolutivité avec les Ensembles de Candidats : Contrairement aux méthodes heuristiques qui saturent rapidement, la performance de l'ORM a continué de s'améliorer à mesure que la taille du pool de candidats ( $N$ ) augmentait, approchant la limite supérieure oracle définie par le Pass@N. Cela indique que les ORM exploitent efficacement l'augmentation du calcul au moment de l'inférence.
Robustesse : La méthode a montré des améliorations constantes à travers différentes familles de générateurs et échelles de modèles. Les bénéfices de la sélection par l'ORM ont persisté même en utilisant des générateurs plus larges (jusqu'à 32 milliards de paramètres).
Dynamique d'Entraînement :
- Déséquilibre des Données : Bien que les jeux de données générés soient déséquilibrés (ex: ~69 % de corrects dans Spider), l'entraînement sur des sous-ensembles équilibrés (50/50) n'a pas dégradé la performance et, dans certains cas, l'a améliorée tout en réduissant les coûts d'entraînement.
- Taille du Modèle : Augmenter la taille de l'ORM au-delà de 7 milliards de paramètres n'a apporté que des améliorations marginales et inconsistantes, suggérant que les ORM légers offrent un équilibre performance-efficacité favorable.
- Conception de Prompt : Les prompts exposant directement la structure SQL ("SQL-Only") ont donné les meilleurs résultats par rapport aux prompts de type instruction ou de type données uniquement.

Signification et Revendications

Le papier affirme qu'une vérification apprise offre une alternative simple, efficace et évolutive aux stratégies de sélection heuristiques au moment de l'inférence pour le Text-to-SQL. La signification de ce travail réside dans la démonstration que :

L'étiquetage basé sur l'exécution est suffisant pour entraîner des vérificateurs efficaces pour les tâches structurées, supprimant la barrière de l'annotation manuelle.
La discrimination sémantique est possible au moment de l'inférence sans modifier le générateur et sans nécessiter d'interaction supplémentaire avec l'environnement au-delà de la génération initiale des candidats.
Les ORM sont particulièrement efficaces pour les requêtes complexes où les signaux heuristiques échouent, offrant une manière principled de gérer l'ambiguïté et la complexité structurelle inhérentes au Text-to-SQL.

Les auteurs maintiennent un ton modeste, reconnaissant que les gains absolus sont modérés (2–5 %) et que l'approche repose sur l'équivalence d'exécution comme proxy de la correction sémantique, ce qui peut ne pas distinguer les requêtes sémantiquement équivalentes mais syntaxiquement différentes ou récompenser des correspondances fallacieuses. Le travail se concentre sur l'amélioration de la sélection des candidats plutôt que sur la capacité de génération elle-même.