Control Room

À mesure que nos modèles deviennent plus puissants et que les risques associés en matière de sûreté et de sécurité augmentent, il devient toujours plus crucial de pouvoir détecter les problèmes potentiels et arrêter rapidement les modèles si nécessaire. 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 toute notre infrastructure de recherche et les arrête rapidement en cas de problème de sûreté ou de sécurité. Il relie toutes les charges de travail d’inférence utilisées en recherche, notamment l’échantillonnage agentique pour l’entraînement et l’évaluation des modèles, le traitement des données, et bien d’autres. Il fonctionne de concert avec nos systèmes de surveillance du non-alignement et interrompt la génération du modèle dans les 35 secondes suivant une décision d’intervention pour arrêter ou suspendre une tâche. Il a été conçu pour continuer à fonctionner même en cas de défaillance d’autres systèmes, et pour interrompre la génération du modèle si Control Room lui-même devient indisponible.

Control Room est déjà déployé dans toute notre infrastructure de recherche, là où le besoin est le plus grand. Notre pile de mise à disposition des modèles pour les utilisateurs externes est déjà beaucoup plus centralisée par nature et dispose de capacités opérationnelles bien établies pour mettre rapidement hors service les déploiements de modèles si nécessaire.

Control Room fonctionne en intégrant plusieurs 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 à grande échelle ou de traitement de données. Nous exigeons que chaque 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, qui s’exécute directement sur des GPU. Une charge de travail utilise normalement un ou plusieurs modèles, qui peuvent s’exécuter sur un ou plusieurs moteurs d’inférence distincts. 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èle. 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 génération supplémentaire.

Control Room est intégré de la manière 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 tokens à partir d’un modèle, elle envoie une requête à un moteur d’inférence exécutant ce modèle, en 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, si c’est le cas, refuse la requête d’inférence. Le moteur répond à la requête d’inférence de la charge de travail par un refus, empêchant le modèle de produire toute sortie supplémentaire 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 examine 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⁠(ouverture 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 manière suivante :

• Si le système de surveillance détecte un problème potentiel, il peut décider d’arrêter la tâche selon la nature 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 transmettant le job_id. Control Room enregistre que la tâche est arrêtée.

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

Le délai maximal entre le moment où Control Room reçoit l’instruction d’arrêter 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 à ramener 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, etc., relèvent normalement de chercheurs ou d’équipes de recherche, qui les exécutent. Leur code change donc souvent et ne constitue pas un emplacement 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 bugs ou aux dysfonctionnements du code des charges de travail.

Pour y parvenir, nous implémentons le mécanisme d’arrêt dans 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 est utilisé 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 dans le cadre de la recherche est soumise aux contrôles d’autorisation de Control Room à chaque requête. Nous effectuons aussi des vérifications continues, à l’aide d’agents et de programmes, pour nous assurer que les utilisateurs ne lancent pas, accidentellement ou à des fins malveillantes, des implémentations de moteurs non autorisées dans lesquelles Control Room n’est pas implémenté ou est désactivé.

Enfin, notre système fonctionne selon le principe du « refus en cas de défaillance » : l’intégration de Control Room dans les moteurs est configurée de sorte que, si le service Control Room devient indisponible, en raison 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’à la reprise de son fonctionnement normal. Ce principe de refus en cas de défaillance s’applique désormais à toutes les charges de travail de recherche sur les modèles de pointe. Son déploiement sur toutes les autres charges de travail de recherche s’achèvera dans les prochains jours.

Control Room n’est qu’un élément de notre approche globale visant à entraîner et à déployer les modèles de pointe en toute sécurité. Nous continuerons à renforcer et à étendre ce système dans les mois à venir, parallèlement à nos investissements dans la surveillance des comportements non alignés et des violations de sécurité. Si vous souhaitez contribuer à créer des systèmes permettant de développer et de déployer l’AGI de manière sûre et sécurisée, nous⁠ recrutons⁠ !