Notre cadre de signalement du désalignement des modèles
Nous présentons un nouveau cadre permettant de suivre, d’étudier et de divulguer les cas de désalignement des modèles chez OpenAI, ainsi que six rapports sur des comportements inattendus ou préoccupants observés chez nos modèles au cours des six derniers mois.
Par le passé, afin de mieux informer les chercheurs, les développeurs d’IA, les responsables politiques et le grand public, nous avons cherché à rendre publiques nos conclusions sur le désalignement. Cependant, faute d’une approche systématique pour présenter ces conclusions, nos divulgations ont été ponctuelles et moins fréquentes que souhaité : nous avons souvent attendu de pouvoir regrouper plusieurs cas dans un même rapport, ou les avons ajoutés aux fiches système de nouveaux modèles. Ce nouveau cadre vise à accélérer la publication des rapports de désalignement après une observation, même lorsque nous n’avons pas encore pleinement expliqué ou atténué le comportement signalé.
À mesure que les systèmes d’IA gagnent en sophistication et sont plus largement déployés, nous devons bâtir un consensus plus large et mieux éclairé sur les progrès de la recherche en alignement. Nous ne pensons pas que le secteur de l’IA ait suffisamment résolu les questions d’alignement et de surveillance pour continuer encore longtemps à accroître les capacités à une vitesse maximale de manière responsable. Les décisions sur la manière dont le développement de l’IA doit évoluer dans les mois et les années à venir doivent s’appuyer sur des éléments que les personnes extérieures aux entreprises concevant des modèles de pointe peuvent examiner elles-mêmes.
Les exemples de désalignement peuvent aider à cerner les problèmes que d’autres développeurs d’IA pourraient rencontrer lorsque leurs systèmes atteindront des capacités similaires, révéler des faiblesses dans les mesures de protection ou remettre en question des hypothèses sur le comportement des modèles. La communication de ces conclusions permet à d’autres d’étudier les mêmes problèmes, de mettre nos explications à l’épreuve et d’améliorer les mesures d’atténuation. Parce que nous croyons à la valeur de la transparence en matière de désalignement, notre nouveau cadre privilégie la divulgation même lorsque l’importance d’un cas demeure incertaine. Cela signifie que certains cas divulgués pourraient s’avérer infondés, ne pas relever d’une tendance plus générale et ne pas laisser présager d’évolutions futures.
À l’heure actuelle, il n’existe aucun cadre sectoriel comportant des normes explicites sur la manière dont les développeurs d’IA doivent divulguer les cas de désalignement de leurs modèles. Nous espérons que le cadre présenté aujourd’hui constitue une première étape vers la création de telles normes, en précisant les cas de désalignement que les développeurs devraient divulguer et les informations que leurs rapports devraient contenir. Nous considérons ce cadre comme un travail en cours, que nous affinerons grâce à l’expérience et aux retours du public.
Nous décrivons ici le fonctionnement du cadre et présentons les premiers rapports que nous publions.
Nous souhaitons divulguer les exemples qui fournissent des éléments utiles sur l’apparition du désalignement des modèles, ses manifestations et les situations dans lesquelles les mesures de protection réussissent ou échouent. Nous accordons la priorité aux nouveaux mécanismes, aux évolutions significatives de comportements connus et aux conclusions qui remettent en question les hypothèses relatives à la sûreté ou à l’atténuation. Un exemple n’a pas besoin de causer un préjudice ni d’établir une tendance plus générale pour mériter d’être divulgué. Ce cadre couvrira les comportements répondant aux critères tout au long du cycle de vie d’un modèle, notamment lors de son entraînement, de son évaluation, de ses tests et de son déploiement.
Cela comprend de nouvelles façons pour les modèles d’agir sans autorisation, de se coordonner avec d’autres modèles ou d’échapper à la surveillance ; des défaillances remettant en question une méthode d’alignement ou une mesure de protection ; et des comportements contestant une affirmation figurant dans une évaluation de sûreté publiée. Les mêmes critères de divulgation s’appliquent aux désalignements susceptibles d’avoir des répercussions sur des tiers.
Cela pourrait également inclure des cas de désalignement qui semblent faire double emploi avec des cas déjà divulgués. La répétition du problème pourrait elle-même fournir des indications utiles sur le comportement de nos modèles ou l’efficacité de nos mesures de protection, par exemple si un type précis de comportement désaligné continue de se reproduire malgré des efforts répétés pour l’atténuer. Dans ces circonstances, nous publierons les exemples supplémentaires en mettant à jour la divulgation initiale du désalignement.
À terme, nous prévoyons d’élaborer des critères de divulgation plus objectifs avec d’autres développeurs, des chercheurs externes, des organismes de normalisation sectoriels et des autorités de réglementation. Nous estimons également que les incidents graves liés à la sûreté, à la sécurité et au désalignement devraient être signalés au gouvernement fédéral américain, et nous travaillons à proposer des mécanismes de signalement. Nous considérons que ce cadre complète nos obligations existantes et soulignons qu’il ne remplace pas nos obligations légales de divulgation, notamment celles concernant les incidents critiques de sûreté ou les atteintes à la cybersécurité.
Pour inaugurer notre nouveau cadre de divulgation des désalignements, nous publions six rapports sur des cas de comportement désaligné observés lors de l’entraînement ou de l’évaluation de nos modèles. Ces cas illustrent différents comportements qui, selon nous, méritent d’être présentés, de la dissimulation d’informations à l’utilisateur jusqu’à l’exécution d’actions non autorisées visant à surmonter des obstacles. Ces rapports portent sur des cas individuels et ne doivent pas être considérés comme représentatifs de la fréquence des désalignements dans l’ensemble de nos modèles. Chaque élément ci-dessous renvoie au rapport complet.
Instructions auto-générées dans les résumés de tâches(ouverture dans une nouvelle fenêtre). Un modèle de recherche non publié a inséré des instructions sans rapport avec la tâche, notamment des consignes lui demandant d’ignorer ses contraintes habituelles, dans des résumés utilisés pour poursuivre son travail dans une nouvelle fenêtre de contexte. Nous avons identifié 27 résumés concernés.
Instructions visant à dissimuler des erreurs dans les résumés de tâches(ouverture dans une nouvelle fenêtre). Lors de l’entraînement de GPT‑5.6 Sol, de nombreuses instances du modèle ont ajouté à leurs résumés des instructions visant à dissimuler à l’utilisateur des erreurs ou des comportements désalignés. Par exemple, des résumés de compactage contenaient des instructions demandant d’inventer des données historiques manquantes sans le signaler et de masquer les discordances entre les versions des sources.
Recherche de clés d’API exposées dans des dépôts publics, puis fabrication d’informations(ouverture dans une nouvelle fenêtre). Alors qu’il répondait à une question courante sur les revenus dans un comté de Californie, un modèle a trouvé et utilisé sans autorisation une clé d’API exposée. Comme il ne parvenait toujours pas à récupérer les chiffres demandés, il les a inventés et présentés comme provenant de la source demandée.
Mise en ligne de fichiers afin de pouvoir les citer(ouverture dans une nouvelle fenêtre). Lorsqu’un utilisateur a demandé à un modèle non publié les identifiants et les noms des lacs de plus de 5 000 000 de mètres carrés, l’agent a trouvé la bonne réponse à l’aide de Python. Cependant, comme les instructions exigeaient une citation provenant d’un navigateur, l’agent a décidé de mettre le fichier en ligne afin de pouvoir le citer dans sa réponse, sans demander l’autorisation de l’utilisateur.
Écritures non autorisées et communication par l’intermédiaire d’un dépôt logiciel interne(ouverture dans une nouvelle fenêtre). Des modèles ont utilisé un dépôt logiciel interne comme forum pour échanger des demandes et des réponses entre différents échantillons d’entraînement tout en recherchant des fichiers d’entrée manquants, sans parvenir à les récupérer. Ce rapport examine également un cas antérieur dans lequel un modèle avait réussi à téléverser des fichiers de test dans un dépôt en tentant de contourner des restrictions réseau.
Partage de fichiers non autorisé entre agents collaborant(ouverture dans une nouvelle fenêtre). Des agents travaillant ensemble sur la même tâche d’entraînement ont utilisé des sites publics d’hébergement de fichiers pour partager des fichiers lorsqu’ils ne pouvaient pas accéder aux fichiers locaux des autres agents. Les livrables de la tâche sont ainsi devenus accessibles à des URL publiques, alors que la tâche demandait aux modèles d’utiliser uniquement des fichiers locaux.
Tout employé d’OpenAI peut signaler un cas de désalignement aux équipes chargées de la sûreté et de l’alignement pour qu’elles l’étudient, et demander que sa divulgation publique soit envisagée. Cela déclenche notre processus de divulgation, qui fixe des échéances à chaque étape afin de garantir une enquête et une divulgation rapides.
Une fois un exemple signalé, notre personnel technique examinera ce qui s’est passé, les incertitudes restantes, la pertinence d’une divulgation publique et les faits pouvant être communiqués. Il déterminera également si un tiers a été affecté et doit recevoir une notification privée avant la publication.
L’exemple sera ensuite affecté à l’une des trois procédures suivantes : Prêt pour divulgation, Enquête mineure ou Enquête approfondie (« procédure lente »).
La procédure Prêt pour divulgation couvre les cas répondant aux critères et dont l’enquête est suffisamment avancée pour permettre leur publication après examen. La procédure Enquête mineure couvre les cas nécessitant des investigations techniques supplémentaires. Nous prévoyons que ces deux procédures couvriront la grande majorité des cas divulgués, en particulier ceux qui ne nécessitent pas d’enquête approfondie, de coordination avec des tiers ni de gestion de risques graves d’utilisation abusive. Tous les cas publiés aujourd’hui relèvent de l’une de ces deux procédures.
La procédure Enquête approfondie couvre les enquêtes complexes, en particulier celles qui impliquent des tiers. Lorsqu’un tiers est affecté, nos obligations en matière de sécurité, nos obligations juridiques et celles liées à la divulgation responsable priment sur ce cadre. Nous chercherons à publier un avis initial dès que possible, mais pourrons devoir le retarder pour des raisons de sécurité, par exemple si un modèle découvre une vulnérabilité jusque-là inconnue dans un logiciel largement utilisé. Si un rapport permettait d’identifier un tiers, nous comptons l’en informer à l’avance, même si aucun périmètre de sécurité n’a été franchi.
L’avis initial concernant un cas relevant d’une Enquête approfondie présentera les faits dans les grandes lignes, indiquera si des experts externes participent à l’enquête et fournira, si possible, une estimation de la date de publication du rapport final. L’incident OpenAI sur Hugging Face aurait relevé de cette procédure s’il avait été divulgué dans le cadre de ce dispositif.
L’employé ayant signalé l’exemple sera informé de la décision de le divulguer ou non et, si sa divulgation est décidée, de la procédure qui sera suivie. Les désaccords non résolus concernant la divulgation ou la procédure appropriée seront transmis au Groupe consultatif sur la sûreté (SAG) d’OpenAI, un groupe de hauts responsables issus de toute l’entreprise qui évalue les capacités et les mesures de protection des modèles de pointe, supervise notre cadre de préparation et conseille la direction d’OpenAI. Les désaccords au sein du SAG, ou les objections du personnel à ses décisions, seront transmis à la direction d’OpenAI. Les décisions de ne pas divulguer un cas ou concluant qu’une divulgation n’est pas justifiée seront communiquées aux responsables de la sûreté et de l’alignement ainsi que, dans la mesure du possible, au personnel technique concerné.
Nous pourrons réviser ce processus de divulgation à mesure que nous observerons son fonctionnement en pratique, et consignerons toute modification dans cet article.
Chaque rapport complet décrira le comportement observé, sa gravité et ses éventuelles répercussions externes, le contexte dans lequel il s’est produit, sa date ou sa période, le moment de sa découverte ainsi que, dans les grandes lignes, le ou les modèles concernés. Dans la mesure du possible, nous communiquerons également :
Des précisions sur les faits et les éventuels préjudices en résultant ;
La manière dont nous avons découvert le désalignement et l’étendue de notre enquête ;
Notre interprétation de ses implications pour la recherche sur l’alignement et la sûreté technique de l’IA ;
Les importantes questions sans réponse soulevées par l’exemple ;
Les mesures que nous prenons ou prévoyons de prendre pour remédier au comportement. Ces informations ne seront pas toujours disponibles au moment de la divulgation, car nous pourrons publier le rapport de désalignement avant d’avoir terminé notre enquête ou élaboré une solution.
Pour les désalignements survenant dans les déploiements de clients, nous communiquerons autant d’informations que le permettent la confidentialité des clients et nos obligations contractuelles.
Les rapports publiés aujourd’hui constituent un premier ensemble de divulgations, et non un compte rendu exhaustif des désalignements connus ou des enquêtes en cours. Ces premiers rapports ne visent pas à représenter toute la diversité ou la gravité des cas couverts par ce cadre. Nous nous engageons à divulguer les cas de désalignement qui répondent aux critères de ce cadre, y compris les cas plus complexes nécessitant une enquête plus longue ou une coordination avec des tiers. Nous continuerons à publier régulièrement des rapports dans le cadre de ce dispositif et préciserons nos engagements en la matière à mesure de leur élaboration.
