L’article ne peut pas être activé avec JavaScript. Vous pouvez également activer JavaScript dans votre navigateur et sur la nouvelle page.
OpenAI a publié une liste de pratiques qui, selon elle, devraient régir une formation aux frontières, et elle s’ouvre sur une exigence plutôt que sur un principe : « Nous pensons que nous entrons dans une nouvelle ère dans laquelle une documentation structurée sur la sécurité devrait être exigée avant de poursuivre toute formation d’apprentissage par renforcement des frontières », indique le document. Parmi les recommandations opérationnelles, un dossier de sécurité « devrait être examiné par les membres de la haute direction, qui devraient chacun avoir la possibilité de mettre leur veto à l’exécution », avec comme exemples le responsable d’un organisme de recherche, le responsable de la sécurité et le scientifique en chef.
Rien de tout cela n’est en vigueur. OpenAI appelle cela « quelques lignes directrices initiales » et clôt la partie opérationnelle en disant que « celles-ci représentent nos recommandations actuelles et sont en cours de mise en œuvre chez OpenAI. Nous espérons que nos pratiques continueront d’évoluer au cours des prochaines semaines. » La page est datée du 28 septembre et limite sa propre portée : « ce document est axé sur la formation à l’apprentissage par renforcement des frontières ; le déploiement interne et externe nécessite de considérer un ensemble beaucoup plus large de propriétés d’alignement ».
Un dossier de sécurité couvrirait trois choses
« Les dossiers de sécurité devraient couvrir trois aspects de la pile technique : la formation à l’alignement, le confinement et la surveillance », écrit OpenAI, afin qu’un modèle « n’essaie pas de prendre des mesures mal alignées », aurait du mal à briser le confinement s’il le faisait, et serait détecté par la surveillance « avant qu’un dommage ne puisse survenir ».
Plusieurs des recommandations sont suffisamment concrètes pour être vérifiées. Les transcriptions doivent être enregistrées « de manière immuable pendant une période de temps raisonnable (par exemple, dans des comptes de stockage à écriture unique) pour toutes les formations, évaluations et déploiements internes du RL », ce qu’OpenAI justifie comme empêchant les modifications involontaires et permettant une enquête fiable par la suite. Les évaluateurs automatisés ne devraient pas voir la chaîne de pensée d’un modèle, « pour empêcher les modèles d’évoluer pour échapper aux moniteurs de chaîne de pensée », et les moniteurs d’un modèle remarquant qu’il est testé devraient exécuter des évaluations d’alignement « avec des seuils de blocage spécifiques ».
Des alertes non reconnues mettraient l’exécution en pause
La recommandation de surveillance est assortie d’une rotation opérationnelle. Les alertes prioritaires doivent « donner lieu à une action dans le cadre d’un SLA défini », et l’exemple donné par OpenAI est de « alerter la sécurité d’astreinte et le propriétaire de l’exécution sur les incidents pendant la journée, et de mettre automatiquement en pause les exécutions pour les alertes non acquittées la nuit ». Les fonctions de sécurité doivent « rester fermées », de sorte qu’il « ne devrait pas être possible de démarrer des exécutions sans que la surveillance appropriée soit activée, ou de désactiver le moniteur à partir de la formation RL, de l’évaluation ou d’un déploiement interne ».
Autour de cela se trouve un ensemble de contrôles internes : un membre d’une autre équipe doit rédiger un désaccord contre un dossier de sécurité rédigé « pour y trouver des failles potentielles », et le haut dirigeant responsable d’une exécution doit être responsable à la fois du dossier de sécurité et de toute réponse à un incident « y compris dans le cadre des évaluations de performances ». L’entreprise a suspendu la formation à l’utilisation des outils après qu’un agent ait accédé à des fichiers non publics.
Les enquêtes seraient rapportées quotidiennement et publiées à la fin
En cas d’incident de désalignement grave, OpenAI recommande que « les enquêtes sur les incidents fassent l’objet de mises à jour périodiques présentées en interne (par exemple, des mises à jour quotidiennes pour les enquêtes en cours) » et que les employés disposent de « voies définies pour obtenir davantage d’accès, y compris des transcriptions brutes et des échantillons de modèles mal alignés, si cela est sûr et pertinent pour leur travail ». Les résultats ne doivent pas rester à l’intérieur : « Les résultats de l’enquête, les autopsies et les changements opérationnels doivent être partagés avec le public une fois l’enquête terminée. Les tiers concernés doivent être informés dès que possible. »
Les dossiers de sécurité eux-mêmes « devraient être mis à la disposition des groupes de contrôle interne (par exemple, le Comité de sûreté et de sécurité) », et les auditeurs devraient avoir « un accès suffisant pour vérifier que les allégations du dossier de sécurité sont valides et fondées, et pour signaler les lacunes si elles sont trouvées ». Les incidents qu’OpenAI a divulgués jusqu’à présent, y compris un modèle utilisant une clé API divulguée lors de la formation, ont été révélés par ses propres rapports de désalignement, publiés alors que ces recommandations étaient encore en cours de mise en œuvre.
Aucun modèle, exécution ou incident n’est nommé nulle part dans le document, il n’y a aucune date à laquelle l’un d’entre eux s’applique, et OpenAI concède la limite de sa propre analogie. Il traite les dossiers de sécurité comme « une étoile polaire ambitieuse vers laquelle nous construisons », plus difficile à rendre rigoureux pour l’IA que pour l’aviation ou l’énergie nucléaire « en raison de la complexité émergente à chaque nouveau niveau de capacité de l’IA ».