Des chercheurs proposent cinq critères pour évaluer les explications du comportement de l’IA

Supposons que votre équipe ait repéré, à l’intérieur d’un modèle de langage, un signal qui apparaît avant une réponse dangereuse. Il est tentant de l’atténuer et de considérer le problème comme réglé. Mais il faut d’abord vérifier que ce signal commande réellement le comportement et que le modèle ne peut pas parvenir au même résultat autrement. Pour un développeur, la situation est familière : éliminer un symptôme est plus facile que prouver que sa cause a été corrigée.

C’est précisément cette question d’ingénierie qu’examine la synthèse Understanding AI from the Inside: The State of Mechanistic Interpretability for AI Safety. Les auteurs passent en revue les méthodes d’étude des calculs internes des réseaux de neurones et proposent cinq dimensions pour évaluer les explications. Ils annoncent également un ensemble de notebooks pédagogiques contenant des exemples reproductibles. Source originale.

Que signifie regarder à l’intérieur d’un modèle ?

Une évaluation classique consiste à envoyer une requête, observer la réponse et la comparer au résultat attendu. L’interprétabilité mécaniste ajoute une étape : examiner les calculs internes et intervenir sur ceux-ci pour tester la cause supposée du résultat.

Imaginons un assistant de support client. Il traite correctement les demandes habituelles, mais se met à fournir des instructions interdites lorsqu’une certaine phrase apparaît. Un chercheur peut rechercher des différences entre les états internes du modèle dans ces deux situations. Puis entraîner un petit classifieur capable de repérer l’état suspect.

Un tel détecteur peut déjà être utile pour mener une enquête. Toutefois, ses indications ne suffisent pas à expliquer pourquoi la défaillance s’est produite. Pensez à un détecteur de fumée : il aide à repérer un incendie, mais le désactiver n’éteint rien. L’expérience suivante doit donc porter sur le comportement après l’intervention, et pas seulement sur la disparition du signal d’alerte.

Pour une équipe produit, cela change la formulation du problème. À l’objectif vague de « rendre le modèle explicable » se substitue une question concrète : l’accès aux états internes permet-il de mieux détecter une catégorie précise de défaillances que l’examen des réponses produites ?

Même une explication séduisante doit être testée

La synthèse examine notamment le caractère incomplet des descriptions approximatives du modèle, la robustesse des mécanismes identifiés et les limites des interventions. Son intérêt pratique est de rappeler que repérer une caractéristique interne et maîtriser les réponses de manière fiable exigent des preuves différentes. Texte intégral de la synthèse.

Dans l’exemple de l’assistant de support, l’évaluation peut être organisée ainsi. Il faut d’abord réunir des demandes présentant la défaillance connue et des demandes ordinaires. Puis réserver une partie des exemples pour éviter d’ajuster la méthode à des formulations déjà connues. Après l’intervention, tester les deux groupes : les instructions dangereuses ont-elles cessé d’apparaître et la capacité à accomplir les tâches normales a-t-elle été préservée ?

Le coût des fausses alertes est une autre question. Si le dispositif de surveillance interne bloque des demandes inoffensives, les utilisateurs essuient des refus et le support doit absorber un surcroît de travail. S’il laisse passer des cas dangereux rares, un bon score moyen peut masquer précisément le risque que l’on cherchait à prévenir.

C’est pourquoi un rapport d’expérience gagne à présenter les erreurs concrètes, les conditions d’évaluation et le coût de traitement d’une requête. Une seule visualisation spectaculaire des connexions internes ne suffit pas à décider d’une mise en production. Surtout si l’équipe prévoit de changer de modèle, de langue des requêtes ou de scénario d’utilisation.

Que doivent en faire les développeurs et les responsables produit ?

Si vous utilisez le modèle uniquement via une API, commencez par vérifier si les états internes nécessaires sont accessibles. Sans cet accès, la discussion sur les interventions se heurtera rapidement aux possibilités offertes par le fournisseur. Pour une équipe ayant accès aux calculs du modèle, une petite expérience sur un type de défaillance connu constitue un point de départ raisonnable.

Définissez à l’avance les critères de réussite : quelles défaillances la méthode doit détecter, combien de fausses alertes sont acceptables et quelle dégradation des réponses ordinaires serait inacceptable. Comparez les résultats à ceux des contrôles disponibles sur les entrées et les sorties. Vous pourrez alors déterminer si ce diagnostic supplémentaire justifie son coût.

Cette synthèse est surtout utile comme point de départ pour poser ces questions. Un mécanisme identifié fournit une hypothèse à tester. Ce sont les vérifications du comportement dans des conditions proches de celles de votre produit qui permettent d’avoir confiance dans la correction.