Résumé Technique : GLARE – Une interface en langage naturel pour l'interrogation d'explications globales

1. Énoncé du problème

Les modèles de vision profonds, bien que performants dans des domaines à enjeux élevés, restent opaques. Si l'IA explicable (XAI) offre des explications locales (par exemple, des cartes de saillance pour des instances uniques) et des explications globales (par exemple, des règles agrégées ou des prototypes résumant le comportement du modèle sur un ensemble de données), un fossé critique d'utilisabilité subsiste. Les explications globales actuelles sont souvent des artefacts monolithiques et statiques contenant des milliers de règles logiques ou de prototypes. Présenter ce « déversement d'explications » aux utilisateurs induit une surcharge cognitive, occultant les informations plutôt que de les révéler.

Les utilisateurs n'ont généralement pas besoin d'un résumé statique ; ils s'engagent dans un processus itératif et piloté par des requêtes pour tester des hypothèses spécifiques (par exemple, « Le modèle s'appuie-t-il sur la neige en arrière-plan pour classer les loups ? »). Les outils existants forcent les utilisateurs à filtrer et agréger manuellement les explications locales pour répondre à de telles questions, créant une friction qui limite l'utilité pratique des informations globales. Il existe un besoin pour une interface permettant d'interroger les explications globales en langage naturel sans exposer les utilisateurs à des représentations de bas niveau ou sans exiger d'expertise en programmation.

2. Méthodologie

Les auteurs proposent GLARE (Global Language-based Analysis and Retrieval of Explanations), un système interactif qui traite les explications globales non pas comme des documents statiques, mais comme une base de données interrogeable.

Architecture du système

Le système suit un pipeline analyse-validation-exécution :

1. Entrée : Les utilisateurs posent des questions en langage naturel concernant le comportement agrégé du modèle (par exemple, « Quel pourcentage d'images de chambres contient à la fois un lit et un mur ? »).
2. Analyse sémantique (LLM) : Un Grand Modèle de Langage (LLM) affiné agit comme un analyseur sémantique. Il traduit la requête en langage naturel de l'utilisateur en une requête SQL structurée.
   • Le LLM choisit parmi une taxonomie prédéfinie de 24 modèles de requêtes couvrant des tâches telles que les comptages de fréquence, les combinaisons booléennes, la cooccurrence et l'analyse contrefactuelle.
   • Il extrait les paramètres (noms de classes, noms d'objets, seuils) pour instancier le modèle.
3. Exécution : La requête SQL générée est validée pour sa sécurité et sa correction, puis exécutée contre une base de données relationnelle contenant les données d'explication globale.
   • La base de données est construite en agrégeant des Explications Minimales Suffisantes (MSX) locales en une structure de Forme Normale Disjonctive (DNF) globale.
   • Bien que les expériences utilisent des explications générées par une méthode spécifique (Vasu et al. [20]), l'interface est conçue pour fonctionner avec n'importe quelle méthode d'explication locale basée sur des concepts produisant des formes symboliques.
4. Sortie : Le système renvoie :
   • Un résumé en langage naturel augmenté de statistiques pertinentes.
   • Des explications locales de soutien (images de preuve).
   • Des visualisations alignées avec l'intention de la requête (par exemple, des cartes de segmentation mettant en évidence les objets pertinents).

Stratégie d'entraînement

Pour garantir que le LLM apprenne la structure de l'interrogation d'explications plutôt que de mémoriser des entités de jeux de données spécifiques, les auteurs emploient une approche d'apprentissage par transfert spécialisée :

• Données synthétiques : 50 000 paires d'entraînement sont générées en échantillonnant des combinaisons aléatoires d'objets et de classes de scènes du vocabulaire ADE20K et en appliquant des variations de langage naturel (synonymes, modèles de formulation).
• Masquage de perte SQL-Fence : Lors de l'apprentissage (utilisant LoRA sur les modèles Gemma 2 et Qwen 2.5), la perte d'entraînement est masquée pour se concentrer exclusivement sur les jetons situés entre les marqueurs SQL_START et SQL_END. Cela force le modèle à apprendre l'algèbre relationnelle du langage de requête, permettant un transfert zero-shot vers de nouveaux jeux de données avec des vocabulaires différents.

3. Contributions clés

Le document expose trois contributions principales :

1. Interface en langage naturel pour les explications globales : L'introduction de GLARE, qui transforme les explications globales en bases de données interrogeables, permettant d'interroger le comportement du modèle via le langage naturel.
2. Représentation intermédiaire basée sur SQL : La définition d'un schéma SQL structuré pour agréger, filtrer et contraster les explications locales, comblant le fossé entre l'intention en langage naturel et l'agrégation logique formelle.
3. Interprétation robuste des requêtes via l'apprentissage synthétique : La démonstration que l'apprentissage par transfert sur données synthétiques avec masquage de perte SQL-fence permet une interprétation robuste des requêtes. Cette approche permet un transfert zero-shot entre jeux de données (par exemple, de ADE20K à Pascal VOC) sans réentraînement, car le modèle apprend des schémas de raisonnement généralisés plutôt que des correspondances d'entités spécifiques au jeu de données.

4. Résultats expérimentaux

Le système a été évalué sur des explications globales dérivées du jeu de données de segmentation de scène ADE20K, avec une évaluation croisée sur Pascal VOC.

Précision en distribution (In-Distribution)

• Performance : Les modèles affinés (spécifiquement Gemma 2 9B et 27B) ont atteint une précision de correspondance de résultat >95 % sur les requêtes testées sur le jeu de données d'entraînement.
• Intégrité structurelle : Ces modèles ont obtenu des scores quasi parfaits sur la détection de clôture (fence detection), l'analyse syntaxique SQL et les taux d'exécution (100 % dans de nombreux cas).
• Comparaison avec les bases de référence : Les modèles de base (non entraînés) ont obtenu une précision proche de zéro, confirmant que la performance est le produit du pipeline d'apprentissage spécifique plutôt que d'une connaissance préexistante du SQL. Une base de référence Regex non apprenante a atteint 74,4 % de précision, ce qui est nettement inférieur aux modèles affinés.

Robustesse aux perturbations

Le système a démontré une forte résilience au bruit linguistique :

• Erreurs d'orthographe : Le modèle affiné a maintenu un taux de correspondance de 79,6 % contre 48,7 % pour la base de référence Regex, montant un avantage de 31 points de pourcentage.
• Substitution par synonymes : Le modèle a affiché une robustesse de 100 % face aux synonymes, surpassant la base de référence Regex de 17 points de pourcentage.
• Cohérence : Les paraphrases sémantiquement équivalentes ont produit des résultats SQL identiques 94,1 % du temps.
• Validité : Toutes les sorties respectaient les contraintes du domaine (par exemple, aucun compte négatif ou pourcentage hors de l'intervalle [0, 100]).

Généralisation et transfert

• Formulations hors distribution (OOD) : Le modèle a bien géré les nouvelles formulations de modèles entraînés (45,1 % de correspondance exacte), bien qu'il ait éprouvé des difficultés avec les doubles négations complexes ou les requêtes très informelles.
• Nouveaux construits SQL : Le modèle a montré une généralisation compositionnelle, assemblant des fragments SQL familiers en de nouvelles structures (par exemple, chained_filter avec 100 % de correspondance), mais a échoué sur des syntaxes entièrement inédites (par exemple, window_function avec 0 % de correspondance).
• Transfert entre jeux de données : Un modèle entraîné exclusivement sur les métadonnées d'ADE20K a atteint environ 90 % de précision lors d'un test sur une base de données Pascal VOC possédant un vocabulaire d'objets totalement disjoint. Cela confirme que le modèle a appris la structure relationnelle du schéma plutôt que les noms d'entités spécifiques.

Analyse de l'échelle des modèles

• Seuil de capacité : Une capacité minimale de modèle est requise. Qwen 2.5 0.5B n'a pas réussi à apprendre la tâche même après l'apprentissage, tandis que les modèles de 7B+ ont performé de manière robuste.
• Saturation : Au sein de la famille Gemma 2, la performance a saturé entre les modèles de 2B, 9B et 27B paramètres pour les tâches en distribution, suggérant que le pipeline synthétique est efficace même pour des modèles plus petits, mais suffisamment larges.

5. Signification et affirmations

L'article affirme que GLARE offre une voie pratique et fiable vers une XAI centrée sur l'humain. En passant d'une inspection passive d'artefacts statiques à un dialogue actif piloté par des requêtes, le système rend les explications globales accessibles aux non-experts.

Les auteurs soulignent que leur approche :

• Ancre la flexibilité dans la correction formelle : En utilisant les LLM comme des analyseurs contraints par la logique qui cartographient des modèles SQL vérifiables, le système évite les hallucinations courantes dans la génération directe d'explications par LLM.
• Permet un transfert zero-shot : La stratégie d'entraînement « SQL-fence » permet au système de se généraliser à de nouveaux domaines et vocabulaires sans réentraînement, à condition qu'une nouvelle liste d'entités soit disponible.
• Réduit la charge cognitive : Il permet aux utilisateurs de poser des questions ciblées sans avoir besoin de comprendre la complexité sous-jacente de milliers de règles logiques.

L'article conclut que, bien que la taxonomie actuelle des modèles soit extensible mais non exhaustive, la capacité démontrée à transférer entre les jeux de données et à gérer les variations linguistiques suggère que l'interrogation médiée par les LLM est une solution viable pour passer à l'échelle de l'analyse des explications globales.