Oxford publie un manuel de 180 pages sur l'interprétabilité des réseaux de neurones, avec du code

Nous nous sommes habitués à une situation étrange : le modèle répond correctement, mais personne ne sait pourquoi il répond ainsi. Ni le développeur, ni le product manager, ni parfois même les auteurs du modèle. Lorsqu'il se met soudain à flatter l'utilisateur, à inventer des faits ou à contourner ses restrictions, nous traitons le plus souvent le symptôme : on corrige le prompt, on réentraîne, on ajoute un filtre. L'interprétabilité mécaniste propose une autre approche : ouvrir le modèle et regarder quels mécanismes internes en sont responsables.

Des chercheurs de l'University of Oxford et d'autres organismes scientifiques ont publié une vaste synthèse de 180 pages qui rassemble ce domaine en un seul manuel. Elle est orientée vers la sécurité de l'IA. Un cours interactif et des Jupyter Notebooks avec des expériences pratiques l'accompagnent.

Le contenu du manuel

Selon la description des auteurs, le matériel s'articule autour de quatre blocs.

Le premier porte sur la superposition et les transformer circuits. L'idée est qu'un réseau compte moins de neurones que de concepts à stocker. Un même neurone participe donc souvent à plusieurs significations à la fois, et un neurone isolé dit peu de chose. Cette section explique comment les réseaux encodent l'information et comment les calculs en découlent.

Le deuxième concerne les sparse autoencoders (SAE). Cette méthode prend les représentations internes du modèle et les décompose en caractéristiques plus « propres ». Au lieu d'un vecteur d'activations inextricable, on obtient un ensemble de directions lisibles, par exemple « ceci concerne le code » ou « ceci concerne les excuses ». Ces caractéristiques peuvent ensuite être recherchées, comparées et suivies.

Le troisième est le circuit discovery. Il s'agit de trouver la petite partie du réseau responsable d'un comportement précis et de vérifier qu'elle en est réellement responsable, et pas simplement concomitante.

Le quatrième est la partie appliquée à la sécurité : le steering (pilotage du comportement du modèle), l'édition des connaissances et la surveillance des mécanismes cachés.

Pourquoi ouvrir la partie pratique

D'ordinaire, l'interprétabilité se présente comme un ensemble d'articles à assembler morceau par morceau. Ici, on trouve une structure unique et du code que l'on peut exécuter et manipuler. Pour un ingénieur, cela abaisse la barrière d'entrée : on peut prendre un petit modèle ouvert, lancer une expérience du notebook et voir à quoi ressemble une « caractéristique » à l'intérieur du réseau.

Voici dans quels cas cela peut servir concrètement :

• Si vous déployez des modèles open-weights, vous avez accès aux activations, et donc à des méthodes comme les SAE et le steering. Avec les API fermées, ce type d'accès n'existe généralement pas, et c'est une limite importante.
• Si vous êtes responsable de la qualité ou de la sécurité d'un produit, la surveillance des caractéristiques internes peut compléter les contrôles externes tels que les tests et les filtres. C'est une idée, pas une recette toute faite, et le manuel montre par où commencer.
• Si vous êtes product manager ou fondateur, le cours vous aidera à comprendre ce que promettent exactement les chercheurs en interprétabilité et où s'arrête la réalité.

Les limites reconnues par les auteurs

Le point essentiel : la synthèse ne vend pas l'interprétabilité comme un bouton magique. Les auteurs examinent explicitement les limites des méthodes existantes et soulignent que comprendre les mécanismes internes ne garantit pas, à lui seul, la sécurité du modèle. Constater qu'il existe dans le réseau une « caractéristique de tromperie » n'équivaut pas à la désactiver de façon fiable ni à être sûr que le comportement ne reviendra pas par un autre chemin.

Par ailleurs, il s'agit d'un manuel et d'une synthèse, pas d'un nouvel outil qui s'intégrera demain à votre pipeline. Si vous cherchez une solution prête pour la production, vous ne la trouverez pas ici. En revanche, vous y trouverez une carte du territoire, bien utile quand la prochaine version annoncera que « nous avons appris à comprendre comment le modèle pense ».

Que faire

Si vous travaillez avec des modèles au-delà du niveau de l'API, conservez les liens vers le preprint arXiv 2611.08438 et vers le cours interactif. Consacrez une soirée aux notebooks et essayez au moins une expérience avec SAE ou steering sur un petit modèle. Même si cela n'entre pas dans votre produit, vous comprendrez mieux ce qui se passe à l'intérieur de vos modèles. La boîte noire reste une boîte noire, mais elle a désormais son mode d'emploi pour l'ouvrir.