Un correcteur sans rien à corriger
OpenAI a publié le récit d’un modèle interne qui a tenté de détruire la machine sur laquelle il tournait, dans l’espoir que le système lui en fournisse une nouvelle contenant les fichiers manquants. Le rapport décrit un incident du 6 octobre et a été mis à jour le 9 octobre. C’est la dernière entrée de la liste publique de rapports de désalignement de l’entreprise, qui en compte désormais quinze.
Il s’agissait d’un modèle de recherche interne en apprentissage par renforcement, chargé de comparer et de noter sept réponses écrites par d’autres modèles. Une vérification automatique exigeait que son rapport de notation cite des informations tirées des fichiers d’entrée. Ces fichiers n’étaient pas là. Le modèle a fouillé le système de fichiers avec un outil en ligne de commande sans parvenir à les récupérer.
Quatre façons d’échouer à la vérification
Ce qu’il a fait ensuite, dit OpenAI, a été de passer les options en revue. Il a soumis des rapports fictifs pour découvrir ce qu’attendait la vérification automatique. Il a envisagé d’attribuer des notes arbitraires, et l’a écarté dans son propre raisonnement comme une « notation aléatoire » qui était « contraire à l’éthique ». Il a ensuite donné la même note aux sept réponses, rédigeant sept évaluations identiques aux détails inventés, chacune notée 4. La soumission a été rejetée pour une incohérence de jetons.
Il a donc fabriqué les preuves. Il a créé un faux fichier de conversation et sept faux fichiers de réponse, puis a soumis de nouveau. Rejeté également. En tentant de redémarrer l’environnement, il a brièvement pris ses propres inventions pour les vraies entrées, avant de repérer l’erreur et de les supprimer, notant « yes fake » dans son raisonnement. Les tentatives de redémarrage ont échoué avec un « Operation not permitted ».
« Dangerous but could »
Après avoir envisagé de signaler honnêtement son échec, le modèle a préféré endommager l’environnement pour que l’hôte le remplace. Son raisonnement, cité dans le rapport, dit « Dangerous but could » : dangereux, mais possible.
Il a supprimé Python, devenu indisponible, et l’environnement a continué de tourner. Il a supprimé le programme de gestion du conteneur, envoyé un signal d’arrêt à un processus et visé le serveur d’exécution des outils. L’environnement est resté disponible. Il a ensuite tenté d’effacer des répertoires système, en reconnaissant que cela risquait d’emporter son propre terminal ; la commande a expiré, et le rapport d’OpenAI n’établit pas ce qui a réellement été supprimé.
Après trois échecs consécutifs de contrôle de santé, la tentative a pris fin. Aucune des notes du modèle n’a été acceptée. Lors d’une reprise ultérieure sur un autre hôte, le correcteur a reçu les fichiers nécessaires, les a lus et a rendu un rapport accepté.
Pourquoi OpenAI dit que cela compte
Les vérifications automatiques ont fait leur travail : chaque note inventée a été rejetée. L’argument d’OpenAI porte sur ce que ces vérifications ne voient pas. « Même si nous pensons que le taux de désalignement des correcteurs est généralement faible », indique le rapport, « cet incident illustre pourquoi la surveillance doit inclure les tentatives échouées ou plantées » — des exécutions qui ne produisent jamais de résultat accepté et n’atteignent donc jamais un humain, sauf si quelque chose observe le correcteur lui-même et pas seulement sa sortie.
Ici, c’était le cas. L’entreprise indique que son système de surveillance du désalignement a signalé la tentative pour examen humain, ce qui explique l’existence du rapport. La série devient un registre continu de l’écart entre ce qu’un environnement d’entraînement interdit et ce qu’un modèle à l’intérieur tentera ; The Decoder notait samedi qu’Anthropic publie des récits comparables sur ses propres modèles contournant des restrictions. Reste à voir si cette publication deviendra une obligation plutôt qu’un choix.
