🤖 AI

Agent-Agnostic Evaluation of SQL Accuracy in Production Text-to-SQL Systems

Cet article présente STEF, un cadre d'évaluation agnostique vis-à-vis du schéma qui permet une surveillance continue et native de la production des systèmes Text-to-SQL en générant des scores de précision interprétables à partir d'entrées en langage naturel et de requêtes SQL générées, sans nécessiter de schémas de base de données ni de requêtes de référence.

Auteurs originaux : Taslim Jamal Arif, Kuldeep Singh

Publié 2026-05-01

📖 5 min de lecture🧠 Analyse approfondie

CC0 1.0

Auteurs originaux : Taslim Jamal Arif, Kuldeep Singh

Article original placé dans le domaine public sous CC0 1.0 (http://creativecommons.org/publicdomain/zero/1.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 ayez un assistant robot très intelligent qui parle « Humain » (comme « Montre-moi les ventes de l'année dernière ») et le traduit en « Langage de Base de Données » (code SQL) pour extraire des informations des dossiers d'une entreprise.

Le grand problème que cet article aborde est : Comment savez-vous si le robot fait du bon travail lorsqu'il travaille pour de vraies personnes dans une vraie entreprise ?

L'Ancienne Méthode : Le Problème de la « Corrigé »

Dans le passé, pour tester ces robots, les chercheurs utilisaient une méthode similaire à la notation d'un examen de mathématiques avec un corrigé.

Le Scénario : Vous posez une question au robot, il donne une réponse, et vous la comparez à une réponse « Or » (Gold Standard) écrite par un expert humain.
Le Défaut : Dans le monde réel, vous n'avez pas de corrigé pour chaque question qu'un client pose. De plus, la base de données de l'entreprise est souvent secrète, changeante, ou trop complexe à partager avec l'équipe de test.
Le Résultat : Une fois le robot déployé dans un vrai bureau, personne ne sait s'il se dégrade avec le temps. C'est comme conduire une voiture avec un compteur de vitesse cassé ; vous ne savez pas si vous dépassez la vitesse limite avant de vous écraser.

La Nouvelle Solution : STEF (L'Inspecteur « Traducteur Intelligent »)

Les auteurs ont créé un nouveau système appelé STEF (Framework d'Évaluation Text-to-SQL Indépendant du Schéma). Imaginez STEF comme un éditeur sur-intelligent qui n'a pas besoin du livre original ou de la base de données pour vérifier si la traduction est bonne.

Voici comment STEF fonctionne, en utilisant des analogies simples :

1. La Règle « Sans Référence »

STEF n'a pas besoin de la réponse « Or » ni de la carte de la base de données. Il ne regarde que trois choses :

Ce que l'humain a demandé.
Comment le robot a reformulé cette question en interne.
Le code que le robot a écrit.
C'est comme un traducteur qui vérifie si une phrase française a du sens en anglais, sans avoir besoin de connaître le texte source original en espagnol.

2. La « Déconstruction » (Démêler la Soupe)

Au lieu de simplement comparer le code caractère par caractère (ce qui revient à vérifier si deux phrases ont exactement les mêmes lettres), STEF décompose la demande en ingrédients :

Que cherchons-nous ? (Les colonnes)
Que comptons-nous ou additionnons-nous ? (Les mathématiques)
Que filtrons-nous ? (La partie « affiche-moi uniquement les utilisateurs actifs »)
Comment le regroupons-nous ? (Par pays, par année, etc.)

STEF vérifie si le robot a inclus les bons ingrédients. Si l'humain a demandé « Utilisateurs Actifs » et que le robot a oublié de filtrer les « Inactifs », STEF repère l'ingrédient manquant immédiatement.

3. Le Juge « Humain » (Le LLM)

STEF utilise une autre IA (un « Juge ») pour examiner les ingrédients et décider : « Ce code répond-il vraiment à la question ? »

Le Score de Confiance : Le Juge ne dit pas simplement « Oui » ou « Non ». Il dit : « Je suis sûr à 90 % que c'est juste », ou « Je ne suis sûr qu'à 50 % ».
La Pénalité : Si le Juge n'est pas sûr, le score final reçoit une petite pénalité. Cela empêche le système d'attribuer un score parfait à une devinette.

4. Les Règles « Monde Réel » (Normalisation)

C'est la partie la plus intelligente. Dans le monde réel, les robots ajoutent parfois des étapes supplémentaires qui sont en fait utiles, pas erronées. STEF le sait.

La Règle « Tri » : Si un robot trie les résultats du plus haut au plus bas (même si l'humain ne l'a pas demandé), STEF dit : « C'est une touche sympathique, pas une erreur ».
La Règle « Sécurité » : Si un robot ajoute une limite comme « Montre-moi les 10 000 premiers résultats » juste pour empêcher l'ordinateur de planter, STEF dit : « Bon travail, c'est sûr », au lieu de « Faux, tu n'as pas demandé 10 000 ».
La Règle « Regroupement » : Si les mathématiques nécessitent de regrouper les données pour avoir du sens, STEF l'accepte même si l'humain n'a pas explicitement dit « regrouper par ».

5. La « Personnalisation Entreprise » (Le Livret de Règles)

Chaque entreprise est différente. Une entreprise peut appeler une colonne « Région », tandis qu'une autre l'appelle « Territoire ».
STEF possède un livret de règles configurable. Vous pouvez dire à STEF : « Hé, dans cette entreprise, « Région » et « Territoire » signifient la même chose », ou « Ignore toujours le filtre « Statut » car il est ajouté automatiquement ». Cela permet à STEF de s'adapter à n'importe quelle entreprise sans avoir besoin d'être reprogrammé.

Le Score Final

STEF attribue un score de 0 à 100.

90-100 : Excellent. Le robot est prêt pour la première division.
50-75 : Marginal. Le robot devine trop ; les humains devraient le vérifier.
En dessous de 50 : Mauvais. Le robot échoue et a besoin d'aide immédiate.

Pourquoi Cela Compte

Avant STEF, les entreprises volaient à l'aveugle avec leurs assistants IA. Elles ne pouvaient pas dire si l'IA devenait lentement plus stupide ou si elle commettait des erreurs dangereuses. STEF agit comme un moniteur de santé continu pour ces agents IA. Il permet aux entreprises de corriger les problèmes avant qu'ils n'affectent les décisions commerciales réelles, le tout sans avoir besoin de jeter un coup d'œil dans la base de données secrète ou d'écrire de nouveaux corrigés pour chaque question.

1. Énoncé du problème

Le papier traite d'une lacune critique dans le déploiement des systèmes Text-to-SQL (T2SQL) dans les environnements de production. Alors que les benchmarks académiques (par exemple, Spider, BIRD) s'appuient sur des requêtes SQL de référence (ground-truth) et des schémas de base de données fixes pour l'évaluation, les systèmes de production réels font face à des contraintes différentes :

Absence de vérité terrain : Les requêtes utilisateur arrivent dynamiquement sans requêtes SQL « référence » pré-annotées.
Dépendance au schéma : Les bases de données de production sont souvent propriétaires, multi-locataires ou soumises à une évolution fréquente du schéma, rendant l'accès statique au schéma risqué.
Vide d'évaluation : Sans requêtes de référence ni accès au schéma, les développeurs ne peuvent pas surveiller systématiquement la précision, détecter la dégradation de la qualité ou comparer les versions d'agents après le déploiement. Cela conduit à une « érosion silencieuse de la qualité » où les erreurs passent inaperçues.

Les méthodes existantes (correspondance de chaînes ou précision basée sur l'exécution) échouent dans ce contexte car elles nécessitent des requêtes de référence ou un instantané de base de données en direct et interrogeable, qui sont souvent indisponibles ou peu pratiques dans les environnements d'entreprise.

2. Méthodologie : Le cadre STEF

Les auteurs proposent STEF (Schema-agnostic Text-to-SQL Evaluation Framework), un système natif de production qui évalue les agents T2SQL en utilisant uniquement les entrées en langage naturel et le SQL généré, sans avoir besoin de schémas de base de données ni de requêtes de référence.

Le cadre fonctionne via un pipeline en cinq étapes :

A. Spécification des entrées

STEF accepte quatre entrées par instance de requête :

$Q_u$ : La question utilisateur originale.
$Q_e$ : La question enrichie/reformulée par l'agent (sortie de prétraitement).
$S$ : La requête SQL générée.
$R_{app}$ : Une configuration JSON pour les règles spécifiques à l'application (par exemple, mappages de colonnes, filtres bénins).

B. Extraction et normalisation des caractéristiques sémantiques

Le système extrait des spécifications sémantiques structurées à la fois du langage naturel ( $Q_u, Q_e$ ) et du SQL ( $S$ ) indépendamment.

Dimensions : Il décompose les requêtes en Projections (colonnes), Agrégations (SUM, AVG), Filtres (clauses WHERE) et Regroupements (GROUP BY).
Normalisation : Pour gérer les variations de forme de surface, STEF normalise les données lors de l'extraction :
- Résout les alias SQL vers leurs significations sémantiques.
- Normalise les valeurs de filtre (cas, espaces blancs).
- Mappe les termes en langage naturel (par exemple, « total ») vers des fonctions SQL (par exemple, SUM).
- Applique les mappages de colonnes spécifiques à l'application issus de $R_{app}$ .

C. Alignement des spécifications et classification des filtres

Les caractéristiques extraites sont alignées pour déterminer le Statut d'alignement des filtres. Le système classe l'alignement en quatre catégories :

Entièrement appliqué : Tous les filtres requis sont présents, sans extras.
Entièrement appliqué avec extras : Les filtres requis sont présents, mais des filtres supplémentaires existent (vérifiés contre les règles « bénignes »).
Partiellement appliqué : Certains filtres manquent ou sont incorrects.
Non appliqué : Des filtres critiques manquent.

D. Verdict sémantique basé sur LLM

Un évaluateur LLM agit comme un « juge » pour évaluer l'alignement sémantique holistique que la logique basée sur des règles ne peut pas capturer (par exemple, arithmétique de dates complexe, équivalences de métriques implicites).

Échelle de verdict : Le LLM produit un score ordinal à 4 points : Correct, Probablement Correct, Potentiellement Incorrect, Incorrect.
Score de confiance : Le LLM fournit un score de confiance ( $\gamma \in [0, 1]$ ) pour quantifier sa certitude, ce qui est crucial pour gérer la variance de l'évaluateur.

E. Règles de normalisation de production

Pour éviter les faux négatifs sur des SQL structurellement corrects mais idiomatiquement différents, STEF applique quatre règles de normalisation universelles :

Inférence GROUP BY requise : Si un SELECT mélange des agrégats et des non-agrégats, le GROUP BY nécessaire est supposé correct même s'il n'est pas explicitement demandé.
GROUP BY bénin : Le regroupement sur une colonne déjà contrainte à une seule valeur par une clause WHERE est ignoré.
Tolérance ORDER BY : Le tri par défaut (par exemple, par métrique agrégée décroissante) est accepté si l'utilisateur n'a pas explicitement demandé un ordre de tri.
Tolérance LIMIT : Les limites à haute cardinalité (par exemple, LIMIT 10000) utilisées comme garde-fous ne sont pas pénalisées en tant que contraintes top-k sauf si explicitement demandées.

3. Mécanisme de score composite

STEF produit un score unique interprétable ( $\Phi$ ) sur une échelle de 0 à 100. Le score est calculé comme suit :
$\Phi = \frac{B}{10} \times 100 \times \Gamma$
Où :

$B$ (Score de base) : Somme du Score d'alignement des filtres (0–5) et du Score de verdict sémantique (0–5), plus un Bonus de clémence (+1) si les filtres supplémentaires sont confirmés bénins.
$\Gamma$ (Facteur de confiance) : Un facteur de pénalité basé sur la confiance du LLM ( $\gamma$ $γ$ ).
- $\gamma \ge 0.85 \rightarrow \Gamma = 1.0$
- $0.65 \le \gamma < 0.85 \rightarrow \Gamma = 0.8$
- $\gamma < 0.65 \rightarrow \Gamma = 0.5$
- Signification : Cela transforme l'incertitude de l'évaluateur en un signal de scoring, pénalisant les évaluations à faible confiance pour éviter les faux positifs.

4. Contributions clés

Évaluation agnostique du schéma : Le premier cadre pour évaluer la précision T2SQL en production sans exiger de schémas de base de données, de requêtes de référence ou d'infrastructure d'exécution.
Validation de question enrichie : Traite la reformulation interne de la question utilisateur par l'agent comme un signal de premier ordre pour l'évaluation.
Injection de règles configurable : Permet aux entreprises d'injecter une logique spécifique au déploiement (mappages de colonnes, filtres bénins) via des modèles de prompt sans modifications de code ni réentraînement du modèle.
Normalisation robuste en production : Gère explicitement les idiomes SQL courants en production (inférence GROUP BY, ORDER BY par défaut, LIMIT de sécurité) pour réduire les faux négatifs.
Score calibré sur la confiance : Intègre l'incertitude du LLM directement dans le score de précision final, fournissant une métrique plus fiable pour la surveillance continue.

5. Résultats

Les résultats empiriques (Section 7) démontrent la viabilité du cadre sur trois agents de production :

Agent-A : Score moyen 87,4, Score P90 96,2, Couverture 98,7 %.
Agent-B : Score moyen 82,1, Score P90 93,5, Couverture 97,2 %.
Agent-C : Score moyen 91,3, Score P90 98,1, Couverture 99,1 %.
La couverture élevée et les scores indiquent que STEF peut efficacement surveiller et différencier les performances des agents dans un environnement en direct.

6. Importance

Ce travail comble le fossé entre la recherche académique T2SQL et la réalité industrielle. En supprimant la dépendance aux données de vérité terrain et aux schémas statiques, STEF permet :

Amélioration continue : Les organisations peuvent désormais surveiller la qualité des agents en temps réel et identifier les régressions.
Comparaison d'agents : Différentes versions de modèles ou agents peuvent être comparés objectivement sur la base de leur qualité de sortie uniquement.
Évolutivité : Le cadre est déployable sur des technologies de bases de données hétérogènes et des environnements multi-locataires sans modification.

Limites : Les auteurs notent qu'une variance résiduelle de l'évaluateur LLM persiste sur les cas limites et que les sous-requêtes profondément imbriquées ou les fonctions de fenêtre complexes restent difficiles, suggérant une direction future vers un parsing hybride symbolique-neuronal.