D’où viennent les « goblins » dans les modèles d’IA ?

Tu entraînes un modèle sur des millions d’exemples soigneusement sélectionnés. Tu définis ta fonction de perte, tu réglesTes hyperparamètres, tu surveilles tes métriques. Et puis, à un moment, le modèle produit quelque chose que personne n’a demandé — un comportement, une représentation interne, une association de concepts qui n’existe nulle part dans tes spécifications. La communauté IA a fini par surnommer ces phénomènes les « goblins » : des créatures qui surgissent des couches du réseau sans invitation, sans explication immédiate, et souvent sans crier gare.

OpenAI vient de publier un article intitulé Where the goblins came from, qui a rapidement cumulé plus de 500 points sur Hacker News. La question posée n’est pas banale : d’où viennent ces comportements émergents ? Comment un système entraîné à prédire du texte finit-il par développer des représentations internes de concepts que personne n’a définis, et parfois que personne ne comprend ? La réponse, sans spoiler excessif, est à la fois fascinante et légèrement inconfortable pour quiconque déploie de l’IA en production.

Ce n’est pas un article sur les hallucinations ou sur les dangers existentiels de l’IA — ce serait trop facile. C’est un article sur la mécanique interne des modèles, sur ce qui se passe réellement entre les couches d’un transformer, et sur pourquoi ça devrait changer la façon dont on construit et on surveille des systèmes IA.

Les goblins, c’est quoi exactement ?

Dans le jargon de la recherche, un « goblin » n’est pas nécessairement négatif. C’est simplement une représentation interne ou un comportement qui émerge sans avoir été explicitement planifié. Les grands modèles de type transformer développent ce qu’on appelle des features — des neurones ou des circuits qui s’activent en réponse à certains patterns dans les données. Le problème, c’est que ces features ne correspondent pas toujours à des concepts humainement lisibles ou logiquement cohérents.

Un neurone peut s’activer à la fois pour « célébrité », « tabloïd » et « scandale » — trois concepts liés statistiquement dans les données d’entraînement, mais qui ne forment pas une catégorie naturelle pour un humain. Ce phénomène, que les chercheurs appellent superposition, est au cœur de l’histoire des goblins. Un réseau encode plus de concepts que de neurones disponibles, en « empilant » des représentations dans un même espace vectoriel. Mathématiquement élégant. Humainement opaque. Et source garantie de comportements que personne n’a anticipés.

Ce qui rend le problème intéressant — et difficile — c’est que ces features émergentes ne sont pas du bruit. Elles sont fonctionnelles : elles aident le modèle à mieux prédire, à mieux généraliser. Elles ont une utilité dans l’économie interne du réseau, même si cette utilité reste invisible depuis l’extérieur. Autrement dit, les goblins ne sont pas des bugs à corriger — ce sont des effets secondaires de l’efficacité.

D’où viennent-ils ? La structure cachée des données

La réponse courte : les goblins viennent des données. La réponse longue : ils viennent de la structure statistique latente des données, amplifiée et solidifiée par les dynamiques de l’optimisation par gradient. Quand tu entraînes un LLM sur l’intégralité du web, tu l’exposes à des corrélations que tu n’as ni choisies ni anticipées. Si « gobelin » et « fantasy » apparaissent souvent ensemble, et si « fantasy » est corrélé à « jeux de rôle », lui-même corrélé à d’autres clusters sémantiques — le modèle construit une chaîne de représentations que personne n’a spécifiée, et qui peut s’activer dans des contextes inattendus.

OpenAI insiste sur un point clé : ce n’est pas un bug qu’on pourrait patcher avec plus de données ou un meilleur filtrage. C’est une propriété émergente de l’apprentissage profond à grande échelle. Le modèle optimise une fonction de perte — il trouve des raccourcis, des patterns, des structures latentes dans la distribution des données. Certaines de ces structures deviennent des comportements observables que personne n’a conçus. D’autres restent enfouies dans les activations intermédiaires, invisibles jusqu’à ce qu’un cas limite les déclenche.

Ce qui est nouveau dans l’approche d’OpenAI, c’est la volonté de tracer génétiquement ces comportements : pas seulement observer qu’ils existent, mais reconstituer le chemin qui mène des données d’entraînement aux représentations internes spécifiques. C’est un travail d’archéologie statistique, lent et coûteux, mais qui commence à produire des résultats utilisables.

L’interprétabilité mécaniste : ouvrir la boîte noire

Pour comprendre d’où viennent les goblins, il faut ouvrir la boîte. C’est exactement l’objectif de l’interprétabilité mécaniste — une branche de la recherche qui cherche à comprendre, circuit par circuit et couche par couche, ce que les réseaux font vraiment. Les travaux d’Anthropic sur les Sparse Autoencoders (SAE) et ceux d’OpenAI convergent vers la même approche : décomposer les activations d’un réseau en features élémentaires, plus sparses et plus monosémantiques — c’est-à-dire qui s’activent pour un ensemble cohérent de concepts, pas pour une soupe statistique.

Concrètement, un SAE prend les activations d’une couche du modèle et les projette dans un espace de plus grande dimension, mais avec une contrainte de parcimonie forte : seul un petit nombre de features doit s’activer pour chaque input. Le résultat, c’est qu’on peut inspecter ces features individuellement et souvent y associer des concepts humainement lisibles. On passe du bruit à quelque chose qui ressemble à un signal. Imparfait, partiel, mais interprétable.

Ce champ de recherche avance vite — mais il reste pour l’instant l’apanage des grands labs. Peu d’équipes produit ont les ressources pour faire de l’interprétabilité mécaniste sur leurs modèles. Ce qui veut dire qu’on déploie des systèmes dont on ne comprend pas les internals, en espérant que le comportement observable reste dans les clous. Ça fonctionne souvent — jusqu’au moment où ça ne fonctionne plus, dans un cas limite que personne n’avait prévu.

Comprendre pourquoi un modèle se comporte bien est un prérequis pour garantir qu’il continuera à se comporter bien — et pas juste une curiosité académique.

Ce que ça change pour les apps IA en production

Si tu développes une application sur mesure qui intègre un LLM — un assistant métier, un outil de génération de contenu, un chatbot client — les goblins te concernent directement. Un test fonctionnel classique (« est-ce que la sortie est correcte sur mes cas de test ? ») ne suffit plus à caractériser la fiabilité d’un système IA. Il faut aussi tester les distributions de comportement, surveiller les outputs sur des cas limites, et documenter les comportements observés hors des chemins nominaux.

En pratique, ça ressemble à quoi ? À du red-teaming systématique — faire jouer à ton modèle des scénarios adversariaux ou inhabituels pour voir ce qui remonte. À du monitoring des distributions de sorties en production, pas seulement des métriques de latence et d’uptime. Et à une documentation honnête des comportements observés, y compris les comportements inattendus que tu ne sais pas encore expliquer. Une bonne infrastructure de monitoring et de maintenance devient un outil d’observation du comportement IA autant qu’un outil de disponibilité.

Les frameworks d’évaluation des LLMs — Evals d’OpenAI, LangSmith, Braintrust — commencent à intégrer cette logique. Mais rares sont les équipes qui ont une véritable culture de l’évaluation continue. La plupart font des tests à l’intégration et déploient. Les goblins, eux, n’attendent pas les sprints de release pour apparaître.

Ce que la recherche d’OpenAI signale pour l’écosystème

Au-delà de la technique, l’article d’OpenAI envoie un signal intéressant sur la maturité du secteur. Pendant longtemps, le paradigme dominant était empirique au sens le plus brutal : on évalue les outputs, on fine-tune, on recommence. Si le comportement est bon, c’est bon — peu importe pourquoi. Aujourd’hui, la recherche essaie de comprendre mécaniquement pourquoi le comportement est bon ou mauvais. C’est un changement de posture majeur, et c’est un prérequis pour construire des systèmes vraiment prévisibles à long terme.

Le fait que les grands labs investissent sérieusement dans l’interprétabilité mécaniste — pas uniquement pour des raisons de sécurité au sens « alignement existentiel », mais pour des raisons très pragmatiques de contrôle et de fiabilité — suggère que cette discipline va se démocratiser. Dans deux ou trois ans, des outils d’inspection des features seront probablement disponibles via les APIs des principaux fournisseurs de modèles. Ce sera encore imparfait, mais ce sera là.

Pour les équipes qui construisent sur des modèles fondationnels, c’est une bonne nouvelle. Ça veut dire que comprendre son modèle ne restera pas l’apanage de ceux qui ont des clusters de GPU et des équipes de recherche. Ça veut aussi dire que l’argument « on ne peut pas vraiment auditer les LLMs » aura une date de péremption — et qu’il vaut mieux s’y préparer maintenant qu’être pris de court.

Mon avis : déployer ce qu’on ne comprend pas, jusqu’à quand ?

L’histoire des goblins est l’histoire de toute technologie complexe qu’on déploie avant de la comprendre totalement — ce qui, soyons honnêtes, est quasiment toujours le cas. On déployait des applications web sur des bases de code dont on ne comprenait pas tous les chemins d’exécution. On déploie de l’IA sur des modèles dont on ne comprend pas tous les circuits. La différence, c’est l’échelle et l’opacité : un bug logiciel classique peut être tracé, isolé, corrigé. Un goblin dans un LLM peut rester silencieux pendant des mois avant de se manifester exactement dans le contexte qui pose problème.

Ce que je retiens de l’article d’OpenAI, c’est surtout ça : la recherche en interprétabilité n’est plus une curiosité de labo. Elle devient une discipline d’ingénierie à part entière, avec des outils, des méthodes, et des applications pratiques qui arrivent. Et ceux qui l’auront intégrée tôt dans leurs pratiques de développement auront un avantage concret sur ceux qui continuent à traiter les LLMs comme des boîtes noires qu’on prompt et qu’on espère.

Mon pari : d’ici 2027, « audit d’interprétabilité » sera une prestation standard dans le cycle de vie des applications IA critiques, au même titre qu’un pentest ou un audit de performance. Les goblins ne disparaîtront pas — ils sont inhérents à la façon dont les réseaux de neurones apprennent. Mais on saura enfin, avec des outils décents, d’où ils viennent. Et ça, c’est déjà un changement de paradigme.