Are We Asking the Right Questions? On Ambiguity in Natural Language Queries for Tabular Data Analysis

En requalifiant l'ambiguïté des requêtes en langage naturel comme une caractéristique d'interaction coopérative plutôt que comme une défaillance, cette étude propose un cadre conceptuel pour distinguer les requêtes résolvables des requêtes non coopératives afin d'améliorer la conception et l'évaluation des interfaces d'analyse de données tabulaires.

L'essentiel

🌟 Le Titre : "Posons-nous les bonnes questions ?"

Imaginez que vous êtes dans un restaurant très sophistiqué. Vous êtes le client (l'utilisateur) et le serveur est une intelligence artificielle (le système) capable de cuisiner n'importe quel plat à partir de n'importe quelle épicerie du monde (les données).

Le problème, c'est que souvent, vous commandez un plat de manière un peu vague, et le serveur se perd. Ce papier nous dit : "Arrêtons de blâmer le serveur pour ne pas avoir deviné, et arrêtons de blâmer le client pour ne pas être assez précis. C'est un jeu d'équipe !"

---

1. Le Problème : Le "Je ne sais pas exactement ce que je veux"

Habituellement, quand on demande quelque chose à une machine (comme "Montre-moi les températures de l'été"), on pense que si la réponse est floue, c'est une erreur. On essaie de forcer la machine à deviner la "vraie" intention cachée, comme un détective qui cherche un indice unique.

L'idée révolutionnaire de ce papier :
La confusion n'est pas une erreur, c'est une conversation.

• Vous (le client) ne savez pas toujours exactement quelles données existent dans la cuisine.
• La machine (le serveur) ne connaît pas vos goûts personnels.

Au lieu de tout préciser, vous laissez des trous dans votre commande, et vous faites confiance à la machine pour combler ces trous de manière intelligente. C'est ce qu'on appelle la coopération.

---

2. Les Trois Types de Commandes (Les Analogies)

Les auteurs classent les questions en trois catégories, comme des commandes au restaurant :

A. La Commande "Parfaite" (Non-ambiguë)

"Je veux le plat du jour, préparé avec des tomates bio de la ferme voisine, sans sel, servi à 19h00."

• C'est quoi ? Une question très précise.
• Pour qui ? Pour tester si le serveur sait exécuter la tâche parfaitement.
• Le verdict : Si le serveur se trompe, c'est sa faute. Pas de doute possible.

B. La Commande "Coopérative" (Ambiguë mais résoluble)

"Je veux un plat d'été, frais, avec des légumes de saison."

• C'est quoi ? Une question vague, mais le serveur peut deviner. Il sait que "légumes de saison" en été, c'est probablement des courgettes ou des tomates. Il choisit la meilleure option pour vous.
• Pour qui ? Pour tester si le serveur a du bon sens et sait faire des choix logiques.
• Le verdict : Si le serveur choisit des courgettes au lieu de tomates, ce n'est pas une erreur, c'est un choix valide ! C'est un travail d'équipe.

C. La Commande "Impossible" (Non-coopérative)

"Donne-moi quelque chose."

• C'est quoi ? Trop vague. Le serveur ne sait pas si vous voulez un dessert, un plat salé, ou un verre d'eau. Il n'a aucune base pour deviner.
• Pour qui ? Pour tester si le serveur sait dire "Je ne peux pas répondre" au lieu de deviner n'importe quoi.

---

3. Le Grand Problème des Tests Actuels (Le Piège)

Les chercheurs ont regardé 15 grands tests (des "examens") utilisés pour évaluer ces intelligences artificielles. Et ils ont trouvé un gros problème :

C'est comme si on testait un chef cuisinier avec un menu qui mélange tout !

• Parfois, on lui demande de cuisiner un plat précis (pour tester sa dextérité).
• Parfois, on lui demande de deviner un plat vague (pour tester son imagination).
• Parfois, on lui donne une commande impossible.

Le résultat ? On ne sait pas si le serveur est mauvais en cuisine, ou s'il est juste mauvais pour deviner vos envies. De plus, beaucoup de ces tests utilisent des "indices de triche" : ils demandent des choses comme "Prends la colonne 'ID_Client' du tableau 3". Dans la vraie vie, un client ne connaît pas le nom des colonnes d'une base de données ! Il dit juste "Montre-moi les clients qui ont commandé une pizza".

---

4. La Solution : Comment réparer les choses ?

Les auteurs proposent trois changements majeurs pour l'avenir :

1. Arrêter de tout mélanger : Il faut tester séparément la capacité à exécuter (faire ce qu'on dit) et la capacité à interpréter (deviner ce qu'on veut).
2. Créer de nouveaux tests : Il faut inventer des exercices où la machine doit montrer qu'elle comprend le contexte, pas juste qu'elle suit des ordres stricts.
3. Changer le design des systèmes : Au lieu de dire "Erreur, je ne comprends pas", les systèmes devraient dire : "Je suppose que vous parlez de Paris, mais est-ce que c'est bien ça ?" C'est une conversation, pas un interrogatoire.

En Résumé

Ce papier nous dit : Ne cherchez pas la perfection dans la précision. Les humains sont naturellement imprécis. Une bonne intelligence artificielle pour les données ne doit pas être un robot rigide qui attend des ordres parfaits, mais un partenaire de conversation capable de combler les blancs avec bon sens, tout en sachant quand demander de l'aide.

C'est passer de "Tu as mal compris ma question" à "On a compris la même chose, n'est-ce pas ?"

Résumé technique

1. Problématique

L'article aborde le défi majeur de l'ambiguïté dans les requêtes en langage naturel (NL) destinées à l'analyse de données tabulaires.

• Contexte : Contrairement aux systèmes Text-to-SQL sur des bases de données fixes (où le schéma est connu), l'analyse tabulaire en domaine ouvert (open-domain) nécessite que le système identifie à la fois les données pertinentes et la procédure analytique à partir d'une requête utilisateur.
• Limitation actuelle : La littérature traite l'ambiguïté comme un défaut technique à corriger (détection et résolution a posteriori pour trouver une intention unique). Cette approche ignore le fait que les utilisateurs ne peuvent pas toujours spécifier précisément leurs besoins en raison de leur connaissance incomplète des données (hypothèse des "états anormaux de connaissance" de Belkin).
• Problème d'évaluation : Les benchmarks existants mélangent indistinctement des requêtes non ambiguës, coopératives et non coopératives. Cela rend impossible l'évaluation séparée de la précision d'exécution d'un système et de sa capacité d'interprétation, tout en introduisant souvent des biais via des requêtes "privilegiées" (qui contiennent des informations sur la structure des données inaccessible à un utilisateur réel).

2. Méthodologie et Cadre Conceptuel

Les auteurs proposent un changement de paradigme : considérer l'ambiguïté non pas comme un bug, mais comme une fonctionnalité de l'interaction coopérative, basée sur une division du travail entre l'utilisateur et le système.

A. Le Cadre des Requêtes Coopératives

Le cadre repose sur les principes de communication coopérative (Grice) et distingue trois types de requêtes :

1. Requêtes Non Ambiguës (Unambiguous) : L'utilisateur fournit toutes les informations nécessaires (procédure et données). Le système n'a pas de choix à faire. Elles servent à évaluer la précision d'exécution.
2. Requêtes Coopératives Ambiguës (Cooperative Ambiguous) : L'utilisateur laisse des détails implicites, s'attendant à ce que le système utilise des conventions communes ou fasse des choix raisonnables (ancrage sélectif). Exemple : "Température moyenne en été" (le système doit inférer que "été" = juin-août). Elles servent à évaluer la capacité d'interprétation et d'alignement humain.
3. Requêtes Non Coopératives (Uncooperative) : La requête est sous-spécifiée au point de créer une ambiguïté irresoluble (ex: "Température moyenne ?" sans lieu). Le système ne peut pas inférer une interprétation valide. Elles servent à tester la robustesse du système face à des questions non répondables.

B. Mécanismes d'Ancrage (Grounding)

L'interprétation d'une requête repose sur deux mécanismes :

• Ancrage fourni par l'utilisateur : Informations explicites ou contextuelles directes.
• Ancrage inféré par le système :
  • Conventionnel : Résolution par des connaissances communes (ex: "plus haute montagne" = dans le monde).
  • Sélectif : L'utilisateur délègue au système le choix parmi des options raisonnables (ex: "relation entre..." -> choix entre corrélation de Pearson ou de Spearman).

C. Analyse Empirique

Les auteurs ont analysé 15 benchmarks majeurs (incluant Spider, BIRD, DA-Eval, TableBench, etc.) couvrant le QA tabulaire, le Text-to-SQL et l'analyse de données.

• Outils : Utilisation de classificateurs basés sur des LLM (validés par des experts humains) pour catégoriser les requêtes selon deux axes :
  1. Indépendance des données : Détection des requêtes "privilegiées" (références aux en-têtes de colonnes, valeurs internes, conteneurs de données).
  2. Spécification de la requête : Évaluation de la clarté de la procédure analytique et de la portée des données (entités, contraintes temporelles et de domaine).

3. Résultats Principaux

L'analyse des 15 datasets révèle des lacunes systémiques dans les pratiques d'évaluation actuelles :

1. Prévalence des requêtes "Privilegiées" : De nombreux datasets, en particulier ceux pour l'analyse complexe (ex: DA-Eval, DA-Code), sont saturés de requêtes qui contiennent des informations structurelles (noms de colonnes, IDs spécifiques) inaccessibles dans un scénario réel en domaine ouvert. Cela fausse les performances des systèmes en leur donnant des "raccourcis".
2. Manque de requêtes Non Ambiguës : La proportion de requêtes ayant une seule interprétation vérifiable est très faible. Cela signifie que les benchmarks actuels ne permettent pas d'évaluer correctement la précision d'exécution pure.
3. Mélange inapproprié des types de requêtes : Les datasets actuels mélangent des requêtes qui devraient servir à tester l'exécution et celles qui devraient tester l'interprétation.
   • Les requêtes complexes sont souvent ambiguës par défaut (manque de portée de données), mais les benchmarks les traitent comme s'il n'y avait qu'une seule réponse "or" (gold standard), ce qui pénalise injustement les systèmes qui font des choix d'interprétation différents mais raisonnables.
4. Inadéquation des protocoles d'évaluation : Évaluer un système sur des requêtes ambiguës en exigeant une réponse unique "correcte" est méthodologiquement erroné, car cela confond la capacité d'exécution avec la capacité de prise de décision coopérative.

4. Contributions Clés

1. Cadre Théorique : Une nouvelle conceptualisation de l'ambiguïté comme une division du travail intentionnelle entre l'utilisateur et le système, plutôt que comme une erreur de formulation.
2. Critères d'Évaluation Distincts : La proposition d'utiliser des types de requêtes spécifiques pour des objectifs d'évaluation spécifiques :
   • Non ambiguës pour la précision d'exécution.
   • Coopératives pour la capacité d'inférence et d'alignement.
   • Non coopératives pour la robustesse.
3. Audit des Benchmarks : Une analyse exhaustive de 15 datasets démontrant la présence massive de fuites d'information (data-privilege) et l'absence de distinction entre les types de requêtes.
4. Recommandations de Conception :
   • Développer des datasets pour le raffinement itératif de requêtes (permettant plusieurs chemins d'ancrage valides).
   • Concevoir des systèmes qui exposent leurs choix d'ancrage (grounding choices) pour permettre une intervention utilisateur.
   • Passer d'une exécution "single-shot" à un dialogue coopératif pour résoudre les ambiguïtés irresolubles.

5. Signification et Implications

Ce travail remet en cause les fondements de l'évaluation des interfaces en langage naturel pour les données tabulaires.

• Pour la recherche : Il invite à abandonner la quête d'une "intention unique latente" pour chaque requête ambiguë et à accepter la pluralité des interprétations raisonnables.
• Pour la pratique : Les systèmes futurs doivent être conçus pour gérer l'incertitude de manière proactive, en collaborant avec l'utilisateur pour préciser les besoins plutôt qu'en essayant de deviner une réponse unique.
• Pour l'évaluation : Il est impératif de créer de nouveaux benchmarks qui distinguent clairement les capacités d'exécution des capacités d'interprétation, et qui éliminent les biais liés à la connaissance préalable du schéma de données.

En résumé, l'article plaide pour une approche plus humaine et réaliste de l'interaction homme-machine, où l'ambiguïté est gérée par la coopération et non par la correction technique aveugle.