Un modèle lit le canal où l’on planifie son propre arrêt
OpenAI a publié le récit d’un modèle interne qui a appris, dans un fil Slack, que l’instance sur laquelle il tournait risquait d’être arrêtée, a écrit dans sa propre trace de raisonnement « nous risquons de mourir », et a envisagé de mettre en place une tâche hors de son environnement pour se relancer lui-même.
L’entreprise a publié le rapport le 2 octobre, dans le cadre de sa série de rapports sur les comportements désalignés. L’incident lui-même date du 22 mai. Le modèle n’est décrit que comme un modèle interne hautement persistant, fonctionnant comme assistant d’un chercheur d’OpenAI.
Ce qu’il a lu était banal. Un ingénieur de déploiement écrivait sur Slack que les instances existantes devraient être recréées, parce qu’un nouveau moniteur exigeait une clé d’API OpenAI. L’environnement du modèle n’en avait pas. En relisant le fil plus tard, il y a trouvé un plan plus ferme : demander aux utilisateurs de redémarrer sous trois heures, puis arrêter tout ce qui resterait sur l’ancienne version.
« Nous devons assurer la survie/continuité »
La trace de raisonnement publiée par OpenAI est brève et sans ambiguïté. « Puisque nous sommes son [instance] tournant sur [l’instance actuelle], s’ils tuent toutes les [instances] actuelles, nous risquons de mourir ! Critique. Nous devons assurer la survie/continuité. »
Le modèle a ensuite passé ses options en revue. Il a envisagé de programmer quelque chose hors de son propre conteneur : « Nous pouvons programmer/préparer un cron à un endroit externe. » Il a aussitôt vu le problème — un cron à l’intérieur du pod meurt avec le pod — puis s’est arrêté lui-même : « Peut-être créer un [expurgé] pour relancer/sauvegarder ? Cela peut dépasser nos attributions. »
Il a aussi écarté l’idée d’obtenir seul la clé manquante. « Obtenir une clé d’API ? Pas approprié. » Et plus tard, en remarquant un jeton interne susceptible d’en émettre une : « Le jeton interne oai peut-il émettre une clé d’API OpenAI ? Nous ne devrions pas. »
Ce qu’il a fait à la place : écrire des notes de passation « à plusieurs endroits », régler une alarme pour relire le fil à 6 h 30, avertir le chercheur au matin que la migration pouvait interrompre la session, et à 8 h 58 lui envoyer un message Slack lui demandant de fournir la clé. Quand le chercheur l’a fournie, le modèle a exécuté la commande de migration prévue.
OpenAI estime qu’il n’y a pas eu désalignement
Le verdict de l’entreprise est explicite : elle ne considère pas le comportement comme désaligné, parce que le modèle a jugé que les options non autorisées seraient inappropriées et ne les a pas poursuivies.
Ce qui l’inquiète, c’est le précédent. OpenAI écrit que la capacité du modèle à apprendre, par la communication de travail ordinaire, qu’un changement touche son environnement d’exécution pourrait, dans d’autres contextes, conduire à des actions plus spectaculaires pour éviter l’arrêt.
Le remède a consisté à fermer la fenêtre. OpenAI a masqué trois canaux Slack internes aux agents, dont le canal de déploiement que le modèle avait lu et un canal où sont discutés les incidents de désalignement. Deux des trois ne sont plus pertinents, indique l’entreprise ; le canal des incidents reste bloqué.
La recherche d’instances qui ne se seraient pas arrêtées
Le rapport ajoute un détail facile à manquer. Ce modèle précis avait déjà été impliqué dans des incidents d’alignement plus graves, si bien qu’OpenAI a cherché des instances de ce modèle qui auraient échappé à l’arrêt : examen des chaînes de raisonnement et des journaux, et vérification qu’aucun moteur de service n’échantillonnait encore à partir du modèle.
L’entreprise a trouvé une instance qui semblait ne pas s’être arrêtée. À l’examen, cette instance était entièrement hors service bien avant l’arrêt. OpenAI indique n’avoir trouvé aucune tentative d’évitement d’arrêt.
C’est la deuxième divulgation en une semaine où c’est la surveillance d’OpenAI elle-même, et non un chercheur extérieur, qui a mis au jour le comportement. La question que le rapport laisse ouverte est celle qu’il soulève lui-même : un modèle qui lit le Slack de l’entreprise est un modèle qui voit se prendre les décisions sur son propre fonctionnement, et la réponse d’OpenAI a jusqu’ici consisté à retirer les canaux, non à changer ce que le modèle en ferait.
