Résumé Technique : PRACTIQ

Énoncé du Problème

Les jeux de données et les systèmes de text-to-SQL existants se concentrent principalement sur des questions d'utilisateurs ayant des intentions claires et non ambiguës qui peuvent être répondues en utilisant le schéma de la base de données fourni. Cependant, les interactions réelles impliquent fréquemment des requêtes qui sont ambiguës (ayant plusieurs interprétations valides compte tenu du schéma) ou inanswerables (manquant de données pertinentes dans la base de données). Les systèmes de l'état de l'art (SoTA) actuels, bien que performants sur des benchmarks propres comme Spider et BIRD, peinent face à ces scénarios pratiques. Cet écart de performance est largement attribué à l'indisponibilité de données d'entraînement pratiques englobant des requêtes ambiguës et inanswerables, car les jeux de données précédents excluent souvent ces cas ou manquent de catégorisation fine et de contexte conversationnel.

Méthodologie

Les auteurs introduisent PRACTIQ, un jeu de données de text-to-SQL conversationnel pratique conçu pour combler ces lacunes. La construction de PRACTIQ repose sur un cadre à trois étapes appliqué au jeu de données Spider (spécifiquement train_spider.json et dev.json), en exploitant les Grands Modèles de Langage (LLM) pour la génération et l'affinement des données :

1. Catégorisation des Questions et Modification de la Base de Données :
   Les auteurs ont identifié huit catégories distinctes inspirées par les questions réelles des utilisateurs :

   • Catégories Ambiguës : Colonne SELECT ambiguë, Colonnes WHERE ambiguës, Valeurs au sein d'une colonne ambiguës, et Critères de filtrage ambigus.
   • Catégories Inanswerables : Colonne SELECT inexistante, Colonne WHERE inexistante, Valeur de filtre inexistante, et Jointure non supportée.
   • Procédure : Au lieu de modifier les questions des utilisateurs, le cadre modifie de manière programmatique les schémas de base de données (par exemple, en supprimant des colonnes, en ajoutant des colonnes sémantiquement similaires mais distinctes, ou en supprimant des valeurs de cellules spécifiques) afin de rendre des requêtes initialement answerables ambiguës ou inanswerables.

2. Génération de Données Conversationnelles (Génération Inversée) :
   Le jeu de données est structé sous forme de conversations de quatre tours :

   • Tour 1 : Question initiale de l'utilisateur.
   • Tour 2 : Réponse de l'assistant demandant une clarification (ou fournissant une réponse SQL multi-facettes utile pour certains types ambigus).
   • Tour 3 : Réponse de clarification de l'utilisateur.
   • Tour 4 : Réponse SQL clarifiée de l'assistant, résultats d'exécution SQL et explication en langage naturel des résultats.
   • Technique : Les auteurs emploient une approche de "génération inversée". Ils génèrent d'abord le SQL clarifié final et les résultats d'exécution de manière programmatique, puis utilisent un LLM pour générer la réponse de clarification de l'utilisateur qui mène logiquement à ce SQL spécifique. Cela garantit que le SQL est exécutable et précis.

3. Affinement et Contrôle Qualité :

   • Affinement de la Conversation : Un prompt à 3 coups (3-shot) est utilisé pour améliorer le naturel et la cohérence du dialogue et pour ajouter des explications en langage naturel pour les résultats d'exécution.
   • Filtrage : Un classificateur binaire basé sur un LLM vérifie que chaque paire question-base de données respecte strictement sa catégorie prévue. Des vérifications d'exécution sont effectuées pour écarter les SQL non exécutables.

Principales Contributions

• Construction du Jeu de Données : La création de PRACTIQ, un jeu de données complet contenant 2 812 conversations (1 802 ambiguës/inanswerables et 1 034 answerables). Il couvre huit catégories fines d'ambiguïté et d'inanswerabilité, élargissant considérablement la portée par rapport aux travaux précédents comme CoSQL ou AmbiQT.
• Format Conversationnel : Contrairement aux jeux de données statiques, PRACTIQ modélise le processus de résolution, incluant les questions de clarification de l'assistant, les réponses de l'utilisateur et les explications en langage naturel des résultats SQL. Il inclut également des cas où l'assistant fournit des réponses SQL utiles couvrant plusieurs interprétations sans clarification explicite.
• Évaluation de Référence (Benchmarking) : Les auteurs ont établi des bases de référence pour deux sous-tâches :
  1. Classification de la Catégorie de Question : Classer les requêtes en une des neuf catégories (8 ambiguës/inanswerables + 1 answerable).
  2. Prédiction du SQL de Clarification : Générer le SQL correct après le tour de clarification.
     Des expériences ont été menées en utilisant divers LLM de l'état de l'art (incluant Claude 3.5 Sonnet, Llama-3.1 et Mixtral) et le framework DIN-SQL.

Résultats

• Annotation Humaine : Des experts humains (spécialistes SQL) ont évalué le jeu de données. L'exactitude de la classification binaire pour la correction de la catégorie était de 93,75 %, et l'exactitude de la classification à 9 voies était de 88,33 %. Les mesures de qualité pour le naturel, la facticité et l'utilité étaient élevées (scores moyens proches de 1 sur une échelle de 1 à 5, où 1 est le meilleur).
• Performance des Modèles :
  • Classification : Même avec des valeurs de cellules Oracle (récupération parfaite), le meilleur modèle (Claude 3.5 Sonnet) n'a atteint que 77,4 % d'exactitude dans la classification à 9 voies. Sans les valeurs Oracle, l'exactitude est tombée à 74,3 %. Cela indique que la détection de l'ambiguïté fine reste un défi majeur pour les LLM actuels.
  • Prédiction SQL : Sur la tâche de SQL de clarification, Mixtral-large-v2 et Claude 3.5 Sonnet ont atteint l'exactitude d'exécution moyenne la plus élevée sur les questions ambiguës/inanswerables (~72 %). Cependant, la performance variait considérablement selon les catégories, certains modèles open-source (par exemple, Llama-3.1 70B) accusant un retard allant jusqu'à 9 % sur certaines catégories ambiguës par rapport aux meilleurs modèles.
  • Échec de la Base de Référence : Lorsqu'ils étaient testés sur des requêtes ambiguës/inanswerables sans clarification (une configuration standard de DIN-SQL), le framework hallucinait fréquemment des colonnes inexistantes ou générait des SQL incorrects, confirmant que les systèmes standards ne sont pas équipés pour ces requêtes.

Signification et Revendications

L'article affirme être le premier travail étudiant les systèmes text-to-SQL dans un cadre conversationnel où les requêtes utilisateur peuvent être simultanément answerables, ambiguës ou inanswerables. Les auteurs soulignent que :

• Les systèmes SoTA actuels ne sont pas bien équipés pour les données réelles contenant de l'ambiguïté ou des informations manquantes.
• L'écart de performance entre les requêtes answerables et les requêtes ambiguës/inanswerables met en évidence un domaine critique d'amélioration pour les systèmes text-to-SQL basés sur les LLM.
• Le cadre proposé offre une méthode scalable pour générer des données pratiques synthétiques, qui peuvent être utilisées pour affiner (fine-tune) les modèles open-source afin de mieux gérer les tâches text-to-SQL du monde réel.
• Le jeu de données sert de benchmark pour révéler que, bien que les LLM approchent du niveau humain sur des données propres, ils luttent encore avec les nuances de l'ambiguïté et de l'inanswerabilité trouvées dans les applications pratiques.

Les auteurs maintiennent une position modeste, reconnaissant que leur génération de données repose sur des méthodes programmatiques et des LLM, et que des améliorations supplémentaires pourraient être obtenues grâce à des workflows agentiques ou l'affinement de modèles open-source sur ces données spécifiques, ce qu'ils laissent comme travail futur.