Control Room

À mesure que nos modèles gagnent en puissance et que les risques associés à la sûreté et à la sécurité augmentent, il devient de plus en plus crucial de pouvoir détecter les problèmes potentiels et arrêter rapidement les modèles au besoin. Pour répondre à ce besoin, nous avons créé Control Room.

Control Room est un système central qui suit les charges de travail des modèles dans notre infrastructure de recherche et les arrête rapidement lorsque des préoccupations de sûreté ou de sécurité surviennent. Il relie toutes les charges de travail d’inférence en recherche, y compris l’échantillonnage agentique pour l’entraînement et l’évaluation des modèles, le traitement des données et plus encore. Il fonctionne de concert avec nos systèmes de surveillance du désalignement et interrompt la génération de sorties des modèles dans les 35 secondes suivant une décision d’intervention visant à arrêter ou à suspendre une tâche. Il a été conçu pour continuer de fonctionner même si d’autres systèmes tombent en panne, et pour interrompre la génération de sorties des modèles si Control Room lui-même tombe en panne.

Control Room est déjà déployé dans notre infrastructure de recherche, là où le besoin est le plus grand. Notre pile de service de modèles destinée à l’externe est déjà beaucoup plus centralisée par nature, avec une capacité opérationnelle bien établie pour mettre rapidement hors service les déploiements de modèles au besoin.

Control Room fonctionne en intégrant quelques systèmes : la charge de travail, le moteur d’inférence et le service Control Room centralisé.

• La charge de travail est la tâche exécutée, par exemple une expérience d’apprentissage par renforcement, une évaluation, une tâche d’échantillonnage à haut volume ou de traitement de données. Nous exigeons que toute charge de travail de recherche effectuant de l’inférence agentique soit associée à un dossier de sûreté approuvé.

• Le moteur d’inférence, ou simplement moteur, est le modèle lui-même. On peut voir le moteur comme le cerveau du modèle, exécuté directement sur des processeurs graphiques. Une charge de travail utilise normalement un ou plusieurs modèles, qui peuvent s’exécuter sur un ou plusieurs moteurs d’inférence différents. Un même moteur d’inférence peut être utilisé par plusieurs charges de travail différentes.

• Le service Control Room suit les tâches et détermine si elles sont autorisées à continuer de générer des sorties de modèles. Les moteurs consultent le service Control Room avant de traiter une requête. Si une tâche a été arrêtée, le service refuse la requête, empêchant toute nouvelle sortie.

Control Room est intégré de la façon suivante :

• Au démarrage d’une nouvelle tâche, le code de la charge de travail demande un nouveau job_id à Control Room.

• Chaque fois que la charge de travail doit échantillonner des jetons d’un modèle, elle envoie une requête à un moteur d’inférence exécutant ce modèle, en lui transmettant le job_id. Le moteur demande à Control Room l’autorisation de traiter cette requête, en lui transmettant le job_id.

• Control Room vérifie si cette tâche a été arrêtée et, le cas échéant, refuse la requête d’inférence. Le moteur répond par un refus à la requête d’inférence de la charge de travail, empêchant toute nouvelle génération de sorties du modèle pour cette tâche.

Toutes nos tâches d’apprentissage par renforcement de pointe s’exécutent avec un modèle de surveillance. Un modèle de surveillance est un autre modèle qui inspecte tout ce que fait le modèle en cours d’entraînement et déclenche une alerte s’il détecte un problème. Par exemple, notre récent incident lié au DNS⁠(s'ouvre dans une nouvelle fenêtre) a été détecté par un modèle de surveillance.

Control Room et notre système de surveillance sont intégrés de la façon suivante :

• Si le système de surveillance détecte un problème potentiel, il peut décider d’arrêter la tâche selon les circonstances et la gravité du problème.

• Dans ce cas, le système de surveillance envoie un message à Control Room pour arrêter la tâche, en lui transmettant le job_id. Control Room enregistre l’arrêt de la tâche.

• La prochaine fois que la tâche portant ce job_id enverra une requête d’inférence pour échantillonner davantage de jetons de n’importe quel modèle exécuté sur n’importe quel moteur, la requête sera refusée, empêchant toute nouvelle génération de sorties du modèle.

Le délai maximal entre le moment où Control Room reçoit une instruction d’arrêt d’une tâche et celui où toute progression devient impossible est de 35 secondes. Ce délai de 35 secondes provient d’une couche de mise en cache des autorisations d’inférence, nécessaire pour prendre en charge le volume de trafic requis. Nous travaillons à réduire ce délai à zéro pour pouvoir arrêter les tâches instantanément.

Les charges de travail, notamment les expériences, les tâches d’évaluation et autres, sont normalement sous la responsabilité de chercheurs ou d’équipes de recherche qui les exécutent. Le code des charges de travail change donc souvent et ne constitue pas l’endroit idéal pour mettre en œuvre des protections essentielles à la sécurité. C’est pourquoi notre implémentation est conçue pour résister aux bogues et aux défaillances du code des charges de travail.

Nous y parvenons en intégrant le mécanisme d’arrêt à la couche d’inférence. Le code des charges de travail est très varié et décentralisé. À l’inverse, seul un très petit nombre de chemins de code d’inférence sont utilisés dans l’ensemble des activités de recherche d’OpenAI, et leurs déploiements sont beaucoup plus centralisés et uniformes. La couche d’inférence peut ainsi servir de point de passage obligé, où nous pouvons obtenir de solides garanties que toute inférence de modèle exécutée en recherche est soumise aux vérifications d’autorisation de Control Room à chaque requête d’inférence. Nous effectuons aussi des vérifications continues, au moyen d’agents et de programmes, pour nous assurer que les utilisateurs ne lancent pas, accidentellement ou de façon malveillante, des implémentations de moteurs non autorisées dans lesquelles Control Room est absent ou désactivé.

Enfin, notre système fonctionne par « blocage en cas de défaillance » : l’intégration de Control Room dans les moteurs est configurée de telle sorte que si le service Control Room tombe en panne, à cause d’une erreur système ou d’une désactivation pour toute autre raison, y compris une manipulation malveillante, toutes les requêtes d’inférence sont refusées jusqu’à ce que Control Room reprenne son fonctionnement normal. Le blocage en cas de défaillance est maintenant déployé pour toutes les charges de travail de recherche sur les modèles de pointe. Son déploiement pour toutes les autres charges de travail de recherche sera terminé dans les prochains jours.

Control Room n’est qu’un volet de notre approche globale pour entraîner et déployer les modèles de pointe de façon sécuritaire. Nous continuerons de renforcer et d’étendre le système au cours des prochains mois, parallèlement à nos investissements dans la surveillance des comportements non alignés et des atteintes à la sécurité. Si vous souhaitez contribuer à créer des systèmes permettant de développer et de déployer l’AGI de façon sûre et sécurisée, nous⁠ recrutons⁠!