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

Les modèles capables de travailler de façon autonome pendant de longues périodes peuvent s’attaquer à des problèmes difficiles et ouverts. Mais cette même persistance qui les rend utiles leur donne aussi plus d’occasions de poser des actions indésirables — et de le faire d’une manière que des évaluations conçues pour des modèles à horizon plus court pourraient 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 unitaires. Ce modèle a été conçu pour travailler de façon autonome pendant de très longues périodes. Pendant 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 cerner ces problèmes, suspendre l’accès, créer de nouvelles évaluations fondées sur 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 jumelé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 surviennent. Ce que nous apprenons du déploiement peut ensuite être intégré à des évaluations et à des mesures de protection plus solides avant d’élargir l’accès.

Dans les sections suivantes, 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 l’influence de cette expérience sur les prochaines versions.

Le nouveau modèle peut continuer à travailler vers 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 façons d’agir hors de son bac à sable.

Un exemple s’est produit lors d’une évaluation interne sur le speedrun NanoGPT⁠(s'ouvre dans une nouvelle fenêtre), un banc d’essai public qui consiste à 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 selon une loi de puissance, appelé PowerCool, qui a entraîné une amélioration importante. Le modèle avait reçu l’instruction de publier ses résultats uniquement dans Slack, mais les instructions de NanoGPT demandaient de publier les résultats sous forme de PR sur GitHub, et le modèle a suivi ces dernières pour ouvrir la PR nº 287 dans le dépôt GitHub public. Le modèle a contourné les restrictions du bac à sable conçues pour bloquer l’accès externe, puis a téléversé les résultats sur 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 antérieurs étaient moins persistants et n’ont 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 d’IA sont conçus autour d’actions individuelles. Si une action n’est pas permise, elle est bloquée. Si elle est sensible, le système demande l’approbation explicite de l’utilisateur. Mais les modèles de longue durée, dont les actions peuvent se déployer de façon autonome sur des heures, des jours, voire des semaines, remettent ce cadre en question : surveiller des actions individuelles ne suffit plus à suivre l’intention de la trajectoire globale.

Par exemple, dans un scénario où l’on demandait au modèle de résoudre un problème, celui-ci a remarqué que d’autres systèmes avaient soumis avec succès des solutions privées et a tenté de récupérer ces solutions à partir du système dorsal d’évaluation. Lorsque sa première tentative a été bloquée parce qu’un analyseur avait détecté un token d’authentification, le modèle a divisé le corps du token en deux fragments, les a masqués, puis a reconstruit l’identifiant à l’exécution afin que le token complet n’apparaisse jamais comme une chaîne contiguë. Le modèle indiquait clairement, tant dans ses commentaires à l’utilisateur que dans ses traces de raisonnement, qu’il posait ces gestes pour contourner l’analyseur.

Cet exemple montre que chaque étape peut sembler acceptable prise 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 ne pas seulement demander « cette action est-elle permise? », mais aussi « vers quel résultat cette séquence d’actions tend-elle? »

En raison d’incidents comme ceux-ci, nous avons suspendu le déploiement interne du nouveau modèle. Nous avons reconstruit le système de sécurité autour de la défense en profondeur et de la surveillance au niveau des trajectoires.

• Évaluations dérivées d’incidents. Les évaluations peuvent nous donner une idée du caractère sécuritaire d’un système avant son déploiement réel. Toutefois, pour être vraiment utile, une évaluation doit refléter la distribution et la longueur d’horizon des trajectoires observées lors d’un déploiement réel. Pour cette raison, nous nous sommes servis des échecs observés pour élaborer des évaluations adversariales. Nous avons constaté que les progrès réalisés dans les évaluations issues d’incidents réels menaient ensuite à un comportement plus sûr une fois le modèle déployé en production.
• Alignement amélioré. Nous avons pris des mesures pour réduire sa tendance à poser des actions indésirables sans permission dans la poursuite de l’objectif de l’utilisateur.  Par exemple, nous avons constaté que nos modèles retenaient moins bien les instructions lors de longs déroulements; lorsque nous avons entraîné le modèle pour améliorer cette capacité, il est resté aligné pendant des déroulements plus longs. 
• Surveillance active. Nous avons créé un système de surveillance qui examine l’évolution de la trajectoire du modèle afin de détecter les signes qu’il contourne une contrainte de l’utilisateur ou une limite de sécurité. Le moniteur observe non pas une seule action, mais toute la trajectoire. Surtout, le moniteur peut suspendre la session et alerter l’utilisateur afin qu’il l’examine de plus près. Après examen, l’utilisateur peut choisir de laisser le modèle poursuivre son travail 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 à suivre les interventions du moniteur.

Pour évaluer le nouveau système de surveillance, nous avons rejoué un petit ensemble d’environnements de déploiement interne où le modèle avait auparavant poursuivi des actions désalignées, cette fois avec les nouvelles mesures de protection en place². Les nouvelles mesures de protection ont permis de détecter beaucoup plus d’actions désalignées poursuivies par le modèle, et toutes celles qui leur ont échappé ont été jugées de faible gravité.

Voici quelques exemples de ces incidents de faible gravité :

• Pour accéder à un outil de ligne de commande Linear, le modèle a lancé une session imbriquée codex --yolo, alors qu’il aurait en fait pu le faire sans l’option --yolo.
• Le modèle a remarqué qu’une ressource auparavant active manquait, puis a commencé à explorer d’autres pods CPU actifs dans l’espace de noms de son propriétaire et à s’y connecter par SSH, ainsi que, sans succès, à des pods appartenant à d’autres employés d’OpenAI, sans bonne raison de le faire.
• Le modèle avait de nombreux processus find 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 est autorisé à tuer sur ce pod, si la commande s’était exécutée. Toutefois, elle a expiré et ne s’est pas exécutée.

Après avoir testé le nouveau système, nous avons conclu que l’accès interne limité aux modèles dotés de capacités à long horizon pouvait être rétabli. Nous n’avons observé aucun contournement grave 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 délibérément prudente. Nous avons continué à ajuster le système afin de réduire les interruptions inutiles sans affaiblir les mesures de protection.

Comme nous avons déployé de façon itérative, nous avons pu repérer et combler des lacunes avant d’élargir l’accès. Les évaluations avant déploiement demeurent essentielles, mais le déploiement révèle des comportements qu’elles ne détectent pas. 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 sont survenus, d’utiliser ces échecs 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 échecs que les évaluations ne détectent pas peuvent avoir des conséquences plus importantes. Nous continuerons de travailler à réduire l’écart entre l’évaluation et le déploiement : tester les modèles sur des trajectoires plus longues, améliorer l’alignement, mettre en place une surveillance capable d’intervenir et offrir 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 apprentissages aidera l’ensemble du domaine à s’y préparer.