Explainability Assistant analyse 94 % des requêtes, surpassant les 76,8 % de TalkToModel

Les personnes qui exploitent des bâtiments ont rarement l'occasion de poser une question à leurs modèles de prévision. Elles reçoivent un tableau de bord : un graphique d'importance des variables, une rangée de commandes conçues pour quelqu'un qui sait déjà quel bouton tourner. Pour un responsable de site qui cherche à comprendre pourquoi la prévision de charge de mardi est ressortie élevée, ce graphique n'est pas une explication.

Un article soumis à arXiv le 10 septembre 2026 soutient que le problème vient de l'interface elle-même, et que la solution est arrivée d'un endroit inattendu. Explainability Assistant, que les auteurs présentent comme open source, permet aux opérateurs d'interroger un modèle de consommation d'énergie en langage ordinaire. Il affiche une précision d'analyse d'intention de 94 %, contre 76,8 % pour TalkToModel, un système d'IA explicable conversationnel antérieur contraint par des grammaires écrites à la main.

L'écart de dix-sept points n'est pas ce qu'il y a d'intéressant. Ce qui compte, c'est pourquoi il existe : TalkToModel reconnaissait un ensemble fixe de formulations, tandis qu'Explainability Assistant achemine les questions via les capacités d'appel de fonctions des grands modèles de langage modernes. Selon l'article, cela permet au système de prendre en charge un langage naturel souple et de s'adapter à différents types de problèmes de ML sans réglage fin spécifique à la tâche.

Les grammaires écrites à la main étaient le goulot d'étranglement

Une grammaire personnalisée est un pari : celui de pouvoir prévoir comment les gens formuleront une question. On écrit des motifs pour le mot « pourquoi », pour les questions hypothétiques, pour les demandes d'explication d'une prédiction donnée, puis un opérateur pose une question que les motifs n'avaient jamais anticipée. La grammaire échoue. L'opérateur reformule, légèrement différemment. L'interface semble cassée, même lorsque le modèle qui la sous-tend fonctionne correctement.

L'appel de fonctions contourne cet écueil en laissant le modèle décider à quel outil correspond une question, plutôt que de la faire correspondre à une liste. L'article traite ce point comme le choix architectural central, et l'écart de 76,8 % à 94 % est la preuve qui y est attachée. Ces dix-sept points séparent un système qui comprend la majeure partie de ce qu'on lui demande d'un système qui comprend presque tout.

Le résumé contient une seconde affirmation qui mérite d'être décomposée. Parce que l'interface n'est pas réglée finement pour une tâche spécifique, l'article indique qu'elle s'adapte à différents types de problèmes de ML. Une seule couche conversationnelle pourrait être placée devant un régresseur symbolique fondé sur la programmation génétique ou un autre modèle sans être reconstruite. L'évaluation porte sur le domaine de l'énergie, mais l'argument architectural n'en dépend pas.

Ce que le chiffre phare ne couvre pas

À la lecture de ce tableau, cela ressemble à une victoire nette, ce qui correspond à peu près à la façon dont le résumé le présente. La précision d'analyse d'intention mesure si le système a compris ce que voulait l'utilisateur. Elle ne dit rien de la justesse, de l'exhaustivité ou de l'utilité de l'explication qui a suivi pour la personne qui la lit.

L'article rapporte bien une évaluation comparative menée avec des spécialistes du domaine de l'énergie, opposant l'assistant à un tableau de bord XAI traditionnel. Les résultats sont décrits comme une meilleure utilisabilité et une exactitude constante dans les tâches, et tous les experts ont préféré l'interface conversationnelle pour un usage pratique.

Une préférence unanime est un signal réel, et sous-spécifié. Les éléments disponibles n'indiquent ni combien de spécialistes ont participé, ni combien de tâches chacun a réalisées, ni si l'exactitude des tâches a été notée selon une grille fixe. Dans les études sur les interfaces, la préférence tend à aller vers ce qui semble plus rapide et plus réactif, ce qui est généralement le cas d'un chatbot. Savoir si les opérateurs sont parvenus à de meilleures conclusions relève d'une autre mesure, que le résumé ne rapporte pas.

La dépendance dont l'article ne parle pas

Une couche d'explication bâtie sur l'appel de fonctions hérite des propriétés du modèle qui la sous-tend. Chaque question entraîne un coût par requête et une certaine latence, et celui qui héberge ce modèle peut le mettre à jour ou le retirer sans demander l'avis de personne. Les auteurs qualifient le système d'open source, mais les éléments fournis ne précisent pas quel modèle il appelle, ni si ce modèle tourne localement ou via une API hébergée. Pour une équipe de gestion des installations d'un campus ou un distributeur d'énergie qui décide s'il faut placer cela devant son personnel, ce détail décidera probablement du déploiement.

Où doit se porter la prochaine évaluation

La contribution ici est plus étroite qu'un chatbot qui explique une prévision, et plus utile qu'elle n'en a l'air. Une couche d'IA explicable conversationnelle peut désormais être assemblée sans analyseur syntaxique sur mesure, ce qui élimine l'un des principaux coûts d'ingénierie qui tenaient ces interfaces à l'écart des logiciels de gestion des installations. Ce coût consistait autrefois à recruter une équipe pour écrire et maintenir une grammaire. Il consiste désormais à connecter un modèle doté de l'appel de fonctions.

Ce qui n'est pas devenu plus facile, c'est l'étape qui suit l'analyse. Un opérateur qui demande pourquoi un modèle a prédit une consommation élevée veut une réponse lui permettant d'agir : décaler un programme ou vérifier un capteur. Reconnaître correctement la question est une condition préalable, pas un substitut. Savoir si l'explication qui suit change ce que l'opérateur fait ensuite est la question que cet article soulève et laisse ouverte.