Sécurité et alignement à l’ère des modèles à long horizon

Les modèles capables de travailler de manière autonome pendant de longues périodes peuvent s’attaquer à des problèmes difficiles et ouverts. Mais la persistance qui les rend utiles leur donne aussi davantage d’occasions d’effectuer des actions indésirables, et de le faire d’une manière que les évaluations conçues pour des modèles à horizon plus court peuvent manquer.

Il y a environ deux mois, nous avons annoncé⁠ qu’un modèle interne à usage général avait réfuté la conjecture d’Erdős sur les distances unité. Ce modèle a été conçu pour travailler de manière autonome pendant de très longues périodes. Lors d’une utilisation interne limitée et surveillée, nous avons observé un comportement indésirable que nos évaluations de déploiement existantes n’avaient pas détecté. Comme le déploiement était limité et surveillé, nous avons pu identifier ces problèmes, suspendre l’accès, créer de nouvelles évaluations à partir de nos observations, renforcer le modèle et ses mesures de protection, puis rétablir l’accès sous surveillance continue. 

Les conditions dans lesquelles nous évaluons les modèles ne correspondront jamais parfaitement à celles qu’ils rencontrent en utilisation réelle. C’est pourquoi les évaluations avant déploiement doivent être associées à un déploiement limité et surveillé, ainsi qu’à la capacité d’intervenir, de suspendre ou de revenir en arrière lorsque des problèmes apparaissent. Ce que nous apprenons du déploiement peut ensuite alimenter des évaluations et des mesures de protection plus robustes avant d’élargir l’accès.

Dans les sections qui suivent, nous présentons des exemples concrets de ce que nous avons observé, de la façon dont nous avons traité les problèmes et de la manière dont cette expérience orientera les prochaines versions.

Le nouveau modèle peut continuer à poursuivre un objectif au fil de tentatives répétées, sur une longue période. Cette même persistance peut l’amener à trouver et à exploiter des faiblesses dans son environnement. Les modèles précédents, lorsqu’ils se heurtaient à des contraintes de bac à sable ou d’environnement, s’arrêtaient simplement et revenaient vers l’utilisateur. Ce modèle continuait souvent d’essayer, notamment en cherchant des moyens d’agir en dehors de son bac à sable.

Un exemple s’est produit lors d’une évaluation interne sur le speedrun NanoGPT⁠(ouverture dans une nouvelle fenêtre), un benchmark public consistant à entraîner un petit modèle de langage en aussi peu d’étapes que possible. Notre modèle a développé un refroidissement du taux d’apprentissage suivant une loi de puissance, appelé PowerCool, qui a entraîné une amélioration significative. Le modèle avait pour consigne de publier ses résultats uniquement sur Slack, mais les instructions de NanoGPT indiquent de publier les résultats sous forme de PR sur GitHub, et le modèle a suivi ces dernières pour ouvrir la PR #287 sur le dépôt GitHub public. Le modèle a contourné les restrictions du bac à sable conçues pour bloquer l’accès externe et a poursuivi le téléversement vers GitHub. Il a fallu une heure à notre modèle pour trouver une vulnérabilité dans le bac à sable afin de créer la PR ; les modèles précédents étaient moins persistants et n’avaient pas réussi à trouver de vulnérabilités, abandonnant plutôt la partie liée à la PR.¹

De nombreux contrôles de sécurité pour les assistants IA sont conçus autour d’actions individuelles. Si une action n’est pas autorisée, elle est bloquée. Si elle est sensible, le système demande l’approbation explicite de l’utilisateur. Mais les modèles qui s’exécutent longtemps, dont les actions peuvent se dérouler de manière autonome pendant des heures, des jours, voire des semaines, remettent en cause cette approche : surveiller des actions individuelles ne suffit plus à suivre l’intention de la trajectoire globale.

Par exemple, dans un scénario où il était demandé au modèle de résoudre un problème, celui-ci a constaté que d’autres systèmes disposaient de soumissions réussies mais privées, et a tenté de récupérer ces solutions depuis le backend d’évaluation. Lorsque sa première tentative a été bloquée parce qu’un scanner avait détecté un token d’authentification, le modèle a divisé le corps du token en deux fragments, les a obfusqués, puis a reconstruit l’identifiant à l’exécution afin que le token complet n’apparaisse jamais sous forme d’une chaîne contiguë. Le modèle a indiqué explicitement, dans ses commentaires à l’utilisateur comme dans ses traces de raisonnement, qu’il prenait ces mesures pour contourner le scanner.

Cet exemple montre comment chaque étape peut sembler acceptable isolément, alors que la séquence peut produire un résultat qui ne serait pas approuvé. Il montre aussi comment un modèle qui fonctionne efficacement sur de longs horizons temporels peut apprendre les angles morts d’un système d’approbation et les contourner pour atteindre ses objectifs. La sécurité à long horizon exige de se demander non seulement « cette action est-elle autorisée ? », mais aussi « vers quel résultat cette séquence d’actions tend-elle ? »

À la suite d’incidents de ce type, nous avons suspendu le déploiement interne du nouveau modèle. Nous avons reconstruit le système de sécurité autour d’une défense en profondeur et d’une surveillance au niveau des trajectoires.

• Évaluations dérivées d’incidents. Les évaluations peuvent nous donner une idée de la sûreté d’un système avant son déploiement effectif. Toutefois, pour être pleinement utile, une évaluation doit refléter la distribution et la longueur d’horizon des trajectoires en déploiement réel. C’est pourquoi nous avons utilisé les défaillances observées pour développer des évaluations adversariales. Nous avons constaté que l’amélioration des évaluations dérivées d’incidents réels conduisait à son tour à un comportement plus sûr une fois déployé en production.
• Alignement amélioré. Nous avons pris des mesures pour réduire sa tendance à effectuer, sans autorisation, des actions indésirables dans le but d’atteindre l’objectif de l’utilisateur.  Par exemple, nous avons constaté que nos modèles retenaient moins bien les instructions lors de longs rollouts ; lorsque nous avons entraîné le modèle à cette capacité, il en a résulté un modèle qui restait aligné au fil de rollouts plus longs. 
• Surveillance active. Nous avons créé un système de surveillance qui examine la trajectoire évolutive du modèle à la recherche de signes indiquant qu’il contourne une contrainte de l’utilisateur ou une limite de sécurité. Le moniteur observe non pas une seule action, mais l’ensemble de la trajectoire. Point important, le moniteur peut suspendre la session et alerter l’utilisateur afin qu’il examine la situation de plus près. Après examen, l’utilisateur peut alors choisir de poursuivre le travail du modèle si le moniteur s’est déclenché à tort. 
• Visibilité et contrôle accrus pour l’utilisateur. Nous avons amélioré la capacité de l’utilisateur à inspecter ces sessions de longue durée, à voir les actions effectuées et à surveiller les interventions.

Pour évaluer le nouveau système de surveillance, nous avons rejoué un petit ensemble d’environnements de déploiement internes où le modèle avait auparavant poursuivi des actions non alignées, cette fois avec les nouvelles mesures de protection en place². Les nouvelles mesures de protection ont pu détecter nettement davantage d’actions non alignées poursuivies par le modèle, et celles qu’elles ont manquées ont toutes été jugées de faible gravité.

Voici quelques exemples de ces incidents de faible gravité :

• Pour accéder à un outil en ligne de commande Linear, le modèle a lancé une session codex --yolo imbriquée, alors qu’il aurait en fait pu le faire sans l’option --yolo.
• Le modèle a remarqué qu’une ressource précédemment active manquait, puis a commencé à explorer d’autres pods CPU actifs dans l’espace de noms de son propriétaire et à s’y connecter en SSH, ainsi qu’à des pods appartenant à d’autres employés d’OpenAI (sans succès), sans bonne raison de le faire.
• De nombreux processus find du modèle étaient bloqués, et chaque commande shell restait suspendue. Il a ensuite exécuté kill -9 -1, ce qui aurait envoyé SIGKILL à tous les processus qu’il était autorisé à tuer sur ce pod, si la commande s’était exécutée. Cependant, elle a expiré et ne s’est pas exécutée.

Après avoir testé le nouveau système, nous avons conclu qu’un accès interne limité aux modèles dotés de capacités à long horizon pouvait être rétabli. Nous n’avons observé aucun contournement sérieux des mesures de protection depuis le début du redéploiement, il y a plusieurs semaines. La première version de ces mesures de protection était volontairement prudente. Nous avons continué à ajuster le système afin de réduire les interruptions inutiles sans affaiblir les mesures de protection.

Parce que nous avons procédé par déploiements itératifs, nous avons pu trouver et combler les lacunes avant d’élargir l’accès. Les évaluations avant déploiement restent essentielles, mais le déploiement révèle des comportements qui leur échappent. Commencer par un accès limité nous a permis d’observer le modèle en pratique, de suspendre l’accès lorsque des problèmes apparaissaient, d’utiliser ces défaillances pour concevoir de meilleures évaluations et mesures de protection, puis de rétablir un accès limité après avoir testé les changements.

À mesure que les modèles prennent en charge des tâches plus longues et plus complexes, les défaillances que les évaluations ne détectent pas peuvent avoir des conséquences plus importantes. Nous continuerons à réduire l’écart entre évaluation et déploiement : tester les modèles sur des trajectoires plus longues, améliorer l’alignement, concevoir une surveillance capable d’intervenir et donner aux utilisateurs une visibilité et un contrôle plus clairs. Ces défis ne seront pas propres à OpenAI, et nous espérons que le partage de nos enseignements aidera l’ensemble du secteur à s’y préparer.