💬 NLP

Disentangling Ambiguity from Instability in Large Language Models: A Clinical Text-to-SQL Case Study

Cet article introduit CLUES, un cadre qui démêle l'ambiguïté de l'entrée de l'instabilité du modèle dans le Text-to-SQL clinique en décomposant l'incertitude sémantique en scores distincts, permettant ainsi des interventions ciblées et un tri des erreurs plus efficace par rapport aux méthodes existantes.

Auteurs originaux : Angelo Ziletti, Leonardo D'Ambrosi

Publié 2026-07-09

📖 7 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Angelo Ziletti, Leonardo D'Ambrosi

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 soyez un détective tentant de résoudre un mystère à l'aide d'un assistant IA super intelligent. Vous posez une question sur une immense bibliothèque de dossiers médicaux, du type : « Combien de patients de plus de 18 ans souffrent de dermatite atopique ? » L'IA pourrait vous répondre par une requête SQL (un langage spécial pour interroger la base de données) et une réponse. Mais attention : parfois, l'IA se trompe, et parfois, elle se trompe pour deux raisons très différentes.

Le papier « Disentangling Ambiguity from Instability in Large Language Models » présente un nouvel outil de détective appelé CLUES. Sa mission principale est de comprendre pourquoi l'IA est confuse. Est-ce que la question elle-même est une énigme aux sens multiples (Ambiguïté) ? Ou est-ce que l'IA passe simplement une mauvaise journée et agit de manière agitée (Instabilité) ?

Les deux types de confusion

Considérez le cerveau de l'IA comme une cuisine.

1. Le problème de l'Ambiguïté (L'énigme)
Imaginez que vous demandiez au chef : « Préparez-moi un sandwich. »

Interprétation A : « Faites-moi un sandwich à la dinde sans mayonnaise. »
Interprétation B : « Faites-moi un sandwich au jambon avec du fromage supplémentaire. »
Si le chef prépare les deux et que vous recevez deux sandwichs différents, c'est de l'Ambiguïté. Le problème n'était pas les compétences culinaires du chef ; c'est votre commande qui était vague. Dans le monde médical, demander « Combien de patients de plus de 18 ans ? » est délicat. Est-ce que « plus de 18 ans » signifie leur âge actuel, ou leur âge lors de leur premier diagnostic ? Si l'IA devine le mauvais sens, elle donne la mauvaise réponse. Le papier suggère que lorsqu'un tel cas se produit, la solution consiste à demander à l'humain : « Hé, vouliez-vous dire l'âge actuel ou l'âge au moment du diagnostic ? »

2. Le problème de l'Instabilité (Le chef agité)
Maintenant, imaginez que vous donniez une commande parfaitement claire au chef : « Faites-moi un sandwich à la dinde sans mayonnaise. »

Tentative 1 : Un sandwich à la dinde parfait.
Tentative 2 : Un sandwich à la dinde brûlé.
Tentative 3 : Un sandwich à la dinde avec de la mayonnaise (oups !).
Ici, la commande était parfaite, mais le chef est instable. C'est l'Instabilité. L'IA est confuse par ses propres règles internes ou subit simplement un bug. Le papier suggère que lorsqu'il se produit, vous ne devriez pas demander de clarification à l'humain ; vous devriez plutôt signaler la réponse pour qu'un humain la vérifie ou corrige l'entraînement de l'IA.

L'ancienne méthode vs La méthode CLUES

Avant ce papier, les chercheurs utilisaient un score unique (appelé Entropie de Langage Kernel ou KLE) pour mesurer à quel point les réponses de l'IA étaient « brouillées ».

L'ancienne méthode : Si l'IA donnait cinq réponses différentes, le score augmentait. Mais l'ancien score ne pouvait pas dire pourquoi. Était-ce parce que la question était une énigme, ou parce que l'IA buggait ? C'était comme une alarme incendie qui hurle simplement « Feu ! » sans dire s'il s'agit d'un vrai feu ou juste de pain grillé.
L'argument du papier : Les auteurs soutiennent explicitement qu'il ne faut pas utiliser un seul score. Ils disent qu'il est impératif de séparer les deux types de confusion pour savoir quoi faire ensuite.

Comment fonctionne CLUES : Le graphe magique

Les auteurs ont construit un cadre appelé CLUES (Conditional Language Uncertainty via Entropy and Schur). Ils traitent le processus de pensée de l'IA comme un spectacle en deux étapes :

Étape 1 (L'interprétation) : L'IA devine ce que la question pourrait signifier. Elle écrit quelques versions différentes de la question.
Étape 2 (La réponse) : Pour chaque version de la question, l'IA essaie de répondre plusieurs fois.

Pour mesurer la confusion, ils dessinent une grande carte (un « graphe sémantique bipartite »).

Un côté de la carte contient les Questions (Interprétations).
L'autre côté contient les Réponses.
Ils les relient par des lignes. Si deux questions sont similaires, la ligne est épaisse. Si deux réponses sont similaires, la ligne est épaisse.

Ensuite, ils utilisent un tour mathématique sophistiqué, le complément de Schur (imaginez cela comme un filtre mathématique qui soustrait la « confusion de la question » de la « confusion totale »).

Le résultat : Ils obtiennent deux nombres distincts :
- $H_I$ (Score d'Ambiguïté) : À quel point les questions diffèrent les unes des autres.
- $H_{R|I}$ (Score d'Instabilité) : À quel point les réponses diffèrent même lorsque la question est fixée.

Ce que disent les chiffres

L'équipe a testé cela sur deux types de puzzles :

Culture générale : Ils ont utilisé 300 questions de AmbigQA et 300 de SituatedQA.
- Ils ont constaté que le nouveau Score d'Instabilité ( $H_{R|I}$ ) était bien meilleur pour prédire l'échec de l'IA que l'ancien score unique.
- Par exemple, sur le modèle KimiK2, l'ancien score prédisait l'échec avec une précision (AUROC) de 0,663, tandis que le nouveau score CLUES a bondi à 0,770.
- Ils ont également remarqué que s'ils essayaient simplement de soustraire les scores (une méthode « naïve »), cela échouait lamentablement, donnant des nombres négatifs 37 % à 60 % du temps. Cela prouve que leur calcul complexe est nécessaire.
Dossiers médicaux (Le cas réel) : Ils ont testé cela sur un ensemble de données cliniques de Text-to-SQL comprenant 2 180 questions.
- Ici, le nouveau score était encore meilleur. L'ancien score avait une précision de 0,600, tandis que CLUES atteignait 0,762.
- Ils ont découvert que le score d'« Instabilité » était particulièrement efficace pour repérer quand l'IA était simplement agitée.

La stratégie des « Régimes » : Trier le désordre

Le papier suggère de classer chaque question dans l'un des quatre « Régimes » basés sur les deux scores :

Régime I (Confiant) : Faible Ambiguïté, Faible Instabilité. -> Répondez automatiquement.
Régime II (Ambiguïté) : Haute Ambiguïté, Faible Instabilité. -> Demandez une clarification à l'humain.
Régime III (Instabilité) : Faible Ambiguïté, Haute Instabilité. -> Signalez pour révision humaine.
Régime IV (Composite) : Haute Ambiguïté, Haute Instabilité. -> Faites les deux !

Ce tri change la donne en termes d'efficacité. Dans leur test de déploiement, ils ont constaté que le Régime IV (la zone de désordre à haut risque) contenait 51 % de toutes les erreurs, même s'il ne détenait que 25 % du total des questions.

La leçon à retenir : Si vous n'envoyez que les 25 % de questions problématiques à un humain pour vérification, vous attrapez la moitié de toutes les erreurs ! C'est deux fois plus efficace que de vérifier des questions au hasard.

Quel est leur degré de certitude ?

Les auteurs sont assez confiants dans leurs résultats, mais ils veillent à ne pas surestimer la nature de leurs découvertes.

Ils ont démontré et validé l'efficacité du cadre par des preuves empiriques sur des ensembles de données spécifiques (AmbigQA, SituatedQA et leur référence clinique), plutôt que de fournir une preuve mathématique théorique des équations sous-jacentes.
Ils ont mesuré l'amélioration dans des contextes proches du monde réel, montissant que le nouveau score est systématiquement meilleur pour détecter les échecs.
Cependant, ils admettent que dans un déploiement réel où les erreurs sont rares (seulement environ 4,4 % des questions étaient erronées dans leur test), le système n'est pas encore parfait. C'est un excellent outil de « triage » (tri), mais il ne résout pas tout de manière automatique.
Ils notent également une limite : le système doit d'abord générer plusieurs interprétations, ce qui coûte plus de puissance de calcul. Si l'IA qui génère les interprétations est mauvaise, tout le système risque d'être confus.

L'essentiel à retenir

Le papier ne prétend pas avoir « résolu » l'incertitude de l'IA. Il suggère plutôt qu'en utilisant un processus en deux étapes et un filtre mathématique spécial (le complément de Schur), nous pouvons enfin distinguer une question déroutante d'un bug de l'IA. Cela nous permet de cesser de deviner et de prendre la bonne mesure : demander de l'aide quand la question est vague, ou vérifier le travail quand l'IA est instable. C'est un pas vers des IA médicales et de recherche plus sûres et plus fiables.

Résumé Technique : Désentrelacer l'Ambiguïté de l'Instabilité dans les Grands Modèles de Langage

Énoncé du Problème

Le déploiement de Grands Modèles de Langage (LLM) pour des applications cliniques de Text-to-SQL se heurte à une barrière critique : le risque de générer des requêtes syntaxiquement correctes mais sémantiquement erronées. Un défi majeur est l'ambiguïté latente, où les requêtes d'entrée contiennent des incertitudes implicites (par exemple, « patients de plus de 18 ans » faisant référence à l'âge au moment du diagnostic versus l'âge actuel) qui modifient considérablement les résultats mais ne sont pas évidentes pour l'utilisateur.

Les méthodes actuelles de quantification de l'incertitude, telles que l'Entropie de Langage par Noyau (KLE), fournissent un score unique pour mesurer la diversité de la sortie. Cependant, cette approche confond deux sources de diversité fondamentalement distinctes :

L'Ambiguïté d'Entrée (de type Aléatoire) : La diversité découlant de l'ambiguïté inhérente à la requête de l'utilisateur, qui produit légitimement plusieurs interprétations valides.
L'Instabilité du Modèle (de type Épistémique) : La diversité découlant de l'incohérence interne du modèle ou de son manque de connaissances lors du traitement d'une interprétation unique et claire.

Cette confusion entrave le déploiement efficace des systèmes. Une ambiguïté élevée devrait déclencher un dialogue de clarification avec l'utilisateur, tandis qu'une instabilité élevée devrait signaler la requête pour une révision humaine. Les méthodes existantes ne peuvent pas distinguer ces régimes, empêchant ainsi des interventions ciblées.

Méthodologie : Le Cadre CLUES

Les auteurs proposent CLUES (Conditional Language Uncertainty via Entropy and Schur), un cadre qui modélise le Text-to-SQL comme un processus génératif en deux étapes pour décomposer l'incertitude sémantique.

1. Processus Génératif en Deux Étapes

Le système est formalisé comme suit :

Étape d'Interprétation : Le système génère $N$ interprétations sémantiques distinctes ( $I = \{I_1, ..., I_N\}$ ) représentant des lectures plausibles de la requête originale.
Étape de Génération : Pour chaque interprétation $I_n$ , le système génère $M$ requêtes SQL candidates et les réponses correspondantes ( $R_n = \{R_{n,1}, ..., R_{n,M}\}$ ).
Cette structure crée une relation bipartite où la diversité entre les interprétations représente l'ambiguïté, et la diversité au sein d'une même interprétation représente l'instabilité.

2. Construction d'un Graphe Sémantique Bipartite

Une fonction de similitude $k(\cdot, \cdot)$ est utilisée pour construire une matrice d'adjacence pondérée $W$ , structurée comme un graphe bipartite :
$W = \begin{pmatrix} W_{II} & W_{IR} \\ W_{RI} & W_{RR} \end{pmatrix}$

$W_{II}$ : Encode la similitude sémantique entre les interprétations.
$W_{RR}$ : Encode la similitude sémantique entre toutes les réponses générées.
$W_{IR}/W_{RI}$ : Matrices d'assignation binaire reliant les réponses à leurs interprétations parentes.

Un noyau de diffusion thermique ( $K_\tau = e^{-\tau L}$ ) est appliqué pour lisser ces similitudes, où $\tau$ contrôle la granularité du partitionnement (clustering).

3. Décomposition via le Complément de Schur

L'innovation centrale est la décomposition de l'incertitude totale en un Score d'Ambiguïté ( $H_I$ ) et un Score d'Instabilité ( $H_{R|I}$ ).

Ambiguïté ( $H_I$ ) : Calculée comme l'entropie de la matrice d'interprétation $W_{II}$ en utilisant le cadre KLE.
Instabilité ( $H_{R|I}$ ) : Définie comme l'entropie conditionnelle des résultats étant donné les interprétations. Les auteurs rejettent l'approche de soustraction naïve ( $\tilde{H}_{R|I} = H_{R,I} - H_I$ ) car elle viole la règle de la chaîne pour l'entropie de von Neumann sur les matrices de densité de noyau thermique et produit fréquemment des valeurs négatives.
Solution par Complément de Schur : Au lieu de la soustraction, le cadre calcule directement la structure de similitude conditionnelle :
$S = W_{RR} - W_{RI}(W_{II} + \epsilon I)^{-1}W_{IR}$
La matrice $S$ représente la similitude résiduelle dans les réponses qui ne peut être expliquée par la structure d'interprétation. L'entropie de $S$ produit $H_{R|I}$ . Cette approche garantit des scores non négatifs et isole mathématiquement l'incohérence interne du système.

4. Régimes d'Incertitude

Le cadre définit quatre régimes opérationnels basés sur des seuils pour $H_I$ et $H_{R|I}$ :

Régime I (Confident) : Faible ambiguïté, faible instabilité $\rightarrow$ Réponse automatique.
Régille II (Ambiguïté) : Haute ambiguïté, faible instabilité $\rightarrow$ Déclencher un dialogue de clarification.
Régime III (Instabilité) : Faible ambiguïté, haute instabilité $\rightarrow$ Signaler pour révision humaine.
Régime IV (Composé) : Haute ambiguïté, haute instabilité $\rightarrow$ Clarification + Révision.

Contributions Clés

Cadre CLUES : Une méthode agnostique au modèle pour décomposer l'incertitude sémantique en ambiguïté et instabilité conditionnelle en utilisant le complément de Schur d'un graphe sémantique bipartite.
Jeu de Données Cliniques et Procédure : Une procédure d'interprétation-génération pour les questions épidémiologiques et un benchmark de Text-to-SQL clinique présentant de multiples interprétations valides pour des requêtes connues.
Validation Empirique : Preuve démontrant que $H_{R|I}$ améliore la prédiction des échecs par rapport à l'état de l'art KLE ( $H_R$ ) et permet un triage efficace des erreurs via un routage par régime.

Résultats Expérimentaux

QA en Domaine Ouvert (AmbigQA & SituatedQA)

En utilisant des interprétations de référence (gold-standard), CLUES a été évalué sur cinq LLM de pointe.

Prédiction de l'Échec : Le score d'instabilité $H_{R|I}$ a systématiquement surpassé la ligne de base $H_R$ pour prédire les échecs (améliorations de l'AUROC de +0,074 à +0,077 sur les données agrégées).
Discrimination de Régime : Parmi les requêtes présentant une grande diversité de sortie (haute $H_R$ ), celles ayant une faible instabilité ( $H_{R|I}$ ) présentaient une précision nettement supérieure à celles ayant une haute instabilité. Par exemple, dans SituatedQA, la précision est tombée de 46,8 % (Régime A) à 13,3 % (Régime B), une différence statistiquement significative (odds ratio ~5,7).
Échec de la Soustraction Naïve : L'approche de soustraction naïve ( $\tilde{H}_{R|I}$ ) a produit des valeurs négatives dans 37 à 60 % des cas et a performé proche du hasard, validant la nécessité du complément de Schur.

Text-to-SQL Clinique (Interprétations Connues)

Évalué sur un jeu de données dérivé d'EHRSQL et EpiAskKB comprenant 2 180 instances requête-modèle.

Performance : $H_{R|I}$ a atteint un AUROC agrégé de 0,762 contre 0,600 pour $H_R$ (p < $10^{-10}$ ).
Robustesse : Le score d'instabilité est resté stable à travers différents paramètres de noyau thermique ( $\tau \in [2, 20]$ ), alors que la ligne de base $H_R$ se dégradait considérablement à des $\tau$ élevés.
Sensibilité à la Température : Des températures d'échantillonnage modérées (T=1,0–1,5) ont produit les signaux d'instabilité les plus forts, suggérant qu'une diversité accrue expose l'instabilité latente du modèle.

Configuration de Déploiement (Interprétations Générées)

Dans un cadre de production où les interprétations sont générées à la volée (et non fournies comme étiquettes de référence) :

Précision : Les modèles ont atteint une précision élevée (84–100 %), résultant en des erreurs rares (taux d'erreur de 4,4 %).
Efficacité du Régime : Bien que l'AUROC à score unique ne soit pas significativement différent entre $H_R$ et $H_{R|I}$ dans ce régime de rareté, l'analyse de régime s'est avérée précieuse. Le Régime IV (Haute Ambiguïté + Haute Instabilité) contenait 51 % de toutes les erreurs tout en ne couvrant que 25 % des requêtes.
Routage : Une stratégie de routage du seul Régime IV vers la révision humaine permettrait de capturer la moitié de tous les échecs en révisant seulement un quart des requêtes, doublant ainsi l'efficacité par rapport à une sélection aléatoire.

Signification et Revendications

L'article affirme que CLUES fournit une décomposition diagnostique indisponible via les mesures à score unique. En distinguant l'ambiguïté d'entrée de l'instabilité du modèle, le cadre permet des interventions ciblées :

Clarification pour les requêtes à haute ambiguïté.
Révision Humaine pour les requêtes à haute instabilité.

Les auteurs soulignent que cette distinction est opérationnellement critique pour les domaines de sécurité critique comme l'accès aux dossiers médicaux électroniques (EHR), où les résultats « plausibles mais incorrects » posent des risques importants. Le cadre est conçu pour être agnostique au modèle, ne nécessitant que l'échantillonnage de sortie, et offre une approche mathématique rigoureuse de l'incertitude qui évite les pièges de la soustraction d'entropie naïve.

Les auteurs notent modestement des limites, notamment le coût computationnel des multiples appels de LLM par requête et la dépendance à la qualité des interprétations générées. Ils reconnaissent également que dans les contextes de déploiement à haute précision, le taux d'erreur faible limite le pouvoir discriminatoire des signaux d'incertitude fins, bien que le routage par régime offre toujours des gains d'efficacité par rapport à la sélection aléatoire.