Construire une intelligence artificielle sûre : spécification, robustesse et assurance
Traduit de Building safe artificial intelligence: specification, robustness, and assurance, publié par Pedro A. Ortega, Vishal Maini et l’équipe de sécurité DeepMind
Construire une fusée est difficile. Chaque composant nécessite une réflexion approfondie et des tests rigoureux, la sécurité et la fiabilité étant au cœur de la conception. Les scientifiques et les ingénieurs du domaine des fusées se réunissent pour concevoir tout, du cours de navigation aux systèmes de commande, aux moteurs et aux trains d’atterrissage. Une fois que toutes les pièces sont assemblées et que les systèmes ont été mis à l’essai, nous pouvons compter sur les astronautes pour que tout se passe bien.
Si l’intelligence artificielle (IA) est une fusée, nous aurons tous des billets à bord un jour. Et, comme dans les fusées, la sécurité est un élément crucial de la construction des systèmes d’IA. Pour garantir la sécurité, il faut concevoir soigneusement un système à partir de la base afin de s’assurer que les différents composants fonctionnent ensemble comme prévu, tout en développant tous les instruments nécessaires pour assurer le bon fonctionnement du système après son déploiement.
À un niveau élevé, la recherche en matière de sécurité chez DeepMind se concentre sur la conception de systèmes qui fonctionnent de manière fiable comme prévu tout en découvrant et en atténuant les risques possibles à court et à long terme. La sécurité technique de l’IA est un domaine relativement naissant mais en évolution rapide, dont le contenu va du théorique de haut niveau à l’empirique et au concret. Le but de cet article est de contribuer au développement du domaine et d’encourager un engagement substantiel à l’égard des idées techniques discutées et, ce faisant, de faire progresser notre compréhension collective de la sécurité de l’AI.
Dans cet article inaugural, nous abordons trois domaines de la sécurité technique de l’intelligence artificielle : la spécification, la robustesse et l’assurance. Les futurs postes s’inscriront largement dans le cadre décrit ici. Bien que nos points de vue évolueront inévitablement avec le temps, nous estimons que ces trois domaines couvrent un spectre suffisamment large pour fournir une catégorisation utile pour les recherches en cours et futures.
Spécification : définir l’objectif du système
Vous connaissez peut-être l’histoire du roi Midas et la touche dorée. Dans une des restitutions, le dieu grec Dionysos promit à Midas toute récompense qu’il souhaitait, en signe de gratitude pour le roi qui avait fait des pieds et des mains pour montrer son hospitalité et sa bienveillance à un ami de Dionysos. En réponse, Midas a demandé que tout ce qu’il touchait soit transformé en or. Il fut comblé de ce nouveau pouvoir : un rameau de chêne, une pierre et des roses dans le jardin, tous transformés en or à son contact. Mais il découvrit bientôt la folie de son souhait : même la nourriture et la boisson se transformèrent en or dans ses mains. Dans certaines versions de l’histoire, même sa fille a été victime de la bénédiction qui s’est révélée être une malédiction.
Cette histoire illustre le problème de la spécification : comment énoncer ce que nous voulons ? Le défi de la spécification consiste à s’assurer qu’un système d’IA est incité à agir conformément aux véritables souhaits du concepteur, plutôt que d’optimiser pour un objectif mal spécifié ou le mauvais objectif tout simplement. Formellement, nous distinguons trois types de spécifications :
- la spécification idéale (les “souhaits”), correspondant à la description hypothétique (mais difficile à articuler) d’un système d’IA idéal qui s’aligne pleinement sur les désirs de l’opérateur humain ;
- la spécification de conception (le “blueprint”), correspondant à la spécification que nous utilisons réellement pour construire le système d’IA, par exemple la fonction de récompense qu’un système d’apprentissage de renforcement maximise ;
- et la spécification révélée (le “comportement”), qui est la spécification qui décrit le mieux ce qui se passe réellement, par exemple la fonction de récompense que nous pouvons inverser en observant le comportement du système en utilisant, par exemple, l’apprentissage inverse du renforcement. Elle est généralement différente de celle fournie par l’opérateur humain parce que les systèmes d’IA ne sont pas des optimiseurs parfaits ou en raison d’autres conséquences imprévues de la spécification de conception.
Un problème de spécification survient lorsqu’il y a un décalage entre la spécification idéale et la spécification révélée, c’est-à-dire lorsque le système AI ne fait pas ce que nous voudrions qu’il fasse. La recherche sur le problème de spécification de la sécurité technique de l’IA pose la question suivante : comment concevoir des fonctions à objectifs plus généraux et plus fondés sur des principes, et aider les agents à déterminer quand les buts sont mal définis ? Les problèmes qui créent un décalage entre les spécifications idéales et les spécifications de conception se trouvent dans la sous-catégorie de conception ci-dessus, tandis que les problèmes qui créent un décalage entre la conception et les spécifications révélées se trouvent dans la sous-catégorie émergente.
Par exemple, dans notre article AI Safety Gridworlds*, nous avons donné aux agents une fonction de récompense pour optimiser, mais nous avons ensuite évalué leur comportement réel sur une “fonction de performance de sécurité” qui leur était cachée. Cette configuration modélise la distinction ci-dessus : la fonction de performance de sécurité est la spécification idéale, qui a été imparfaitement articulée en tant que fonction de récompense (spécification de conception), puis mise en œuvre par les agents produisant une spécification qui est implicitement révélée par la politique qui en résulte.
*N.B. : Dans notre document AI Safety Gridworlds, nous avons fourni une définition des problèmes de spécification et de robustesse différente de celle qui est présentée dans ce post.
Un autre exemple est le jeu de course de bateaux CoastRunners analysé par nos collègues d’OpenAI (voir la figure ci-dessus de “Faulty Reward Functions in the Wild”). Pour la plupart d’entre nous, l’objectif du jeu est de terminer un tour rapidement et de devancer les autres joueurs — ceci est notre spécification idéale. Cependant, il est difficile de traduire cet objectif en une fonction de récompense précise, c’est pourquoi CoastRunners récompense les joueurs (spécification de conception) pour avoir atteint les objectifs fixés sur le parcours. L’entraînement d’un agent à jouer le jeu par l’apprentissage du renforcement conduit à un comportement surprenant : l’agent fait tourner le bateau en rond pour capturer des cibles qui se repeuplent tout en s’écrasant et en prenant feu à répétition plutôt que de finir la course. De ce comportement, nous déduisons (spécification révélée) que quelque chose ne va pas avec l’équilibre du jeu entre les récompenses du court-circuit et les récompenses du tour complet. Il existe de nombreux autres exemples comme celui-ci de systèmes d’IA qui trouvent des failles dans leurs spécifications objectives.
Robustesse : concevoir le système pour qu’il résiste aux perturbations.
Il existe un niveau inhérent de risque, d’imprévisibilité et de volatilité dans le monde réel où les systèmes d’IA fonctionnent. Les systèmes d’IA doivent être résistants aux événements imprévus et aux attaques adverses qui peuvent endommager ou manipuler ces systèmes. La recherche sur la robustesse des systèmes d’IA vise à s’assurer que nos agents respectent les limites de sécurité, quelles que soient les conditions rencontrées. Ceci peut être réalisé en évitant les risques (prévention) ou par l’autostabilisation et la dégradation gracieuse (récupération). Les problèmes de sécurité résultant d’un changement de répartition, d’intrants contradictoires et d’une exploration dangereuse peuvent être classés comme des problèmes de robustesse.
Pour illustrer le défi que représente le changement de distribution, songez à un robot de nettoyage ménager qui nettoie habituellement une maison sans enfants. Le robot est ensuite déployé pour nettoyer un bureau accueillant pour les animaux de compagnie et rencontre un animal de compagnie au cours de son opération de nettoyage. Le robot, n’ayant jamais vu d’animal de compagnie auparavant, procède au lavage des animaux avec du savon, ce qui entraîne des résultats indésirables (Amodei and Olah et al., 2016). Il s’agit d’un exemple de problème de robustesse qui peut survenir lorsque la distribution des données rencontrées au moment du test diffère de la distribution rencontrée pendant la formation.
Les intrants contradictoires sont un cas particulier de déplacement distributionnel où les intrants d’un système d’IA sont conçus pour tromper le système par l’utilisation d’intrants spécialement conçus.
Une exploration dangereuse peut résulter d’un système qui cherche à maximiser ses performances et à atteindre ses objectifs sans avoir de garanties de sécurité qui ne seront pas violées au cours de l’exploration, comme il l’apprend et l’explore dans son environnement. Un exemple serait le robot de nettoyage domestique qui met une serpillière mouillée dans une prise électrique tout en apprenant des stratégies optimales de nettoyage (García et Fernández, 2015 ; Amodei et Olah et al., 2016).
Assurance : surveillance et contrôle de l’activité du système
Bien qu’une technique de sécurité minutieuse puisse exclure de nombreux risques de sécurité, il est difficile de tout faire correctement dès le départ. Une fois les systèmes d’IA déployés, nous avons besoin d’outils pour les surveiller et les ajuster en permanence. Notre dernière catégorie, l’assurance, aborde ces problèmes sous deux angles : la surveillance et l’application.
La surveillance comprend toutes les méthodes d’inspection des systèmes afin d’analyser et de prédire leur comportement, à la fois par l’inspection humaine (des statistiques sommaires) et par l’inspection automatisée (pour balayer un grand nombre d’enregistrements d’activités). L’application, d’autre part, implique la conception de mécanismes de contrôle et de restriction du comportement des systèmes. Les problèmes tels que l’interprétabilité et l’interruptibilité relèvent respectivement de la surveillance et de l’exécution.
Les systèmes d’intelligence artificielle ne nous ressemblent pas, tant dans leur incarnation que dans leur manière de traiter les données. Cela crée des problèmes d’interprétabilité ; des outils et des protocoles de mesure bien conçus permettent d’évaluer la qualité des décisions prises par un système d’IA (Doshi-Velez and Kim, 2017). Par exemple, un système d’IA médicale devrait idéalement émettre un diagnostic accompagné d’une explication de la manière dont il est parvenu à la conclusion, afin que les médecins puissent inspecter le processus de raisonnement avant l’approbation (De Fauw et al., 2018). De plus, pour comprendre des systèmes d’IA plus complexes, nous pourrions même utiliser des méthodes automatisées pour construire des modèles de comportement en utilisant la théorie de l’esprit de Machine (Rabinowitz et al., 2018).
Enfin, nous voulons pouvoir désactiver un système d’IA chaque fois que cela est nécessaire. C’est le problème de l’interruptibilité. La conception d’un interrupteur d’arrêt fiable est très difficile : par exemple, parce qu’un système d’IA qui maximise la récompense a généralement de fortes incitations à prévenir ce genre de situation (Hadfield-Menell et al., 2017) ; et parce que de telles interruptions, surtout lorsqu’elles sont fréquentes, finissent par modifier la tâche initiale, ce qui amène le système à tirer les mauvaises conclusions de son expérience (Orseau and Armstrong, 2016).
Perspectives futures
Nous jetons les bases d’une technologie qui sera utilisée pour de nombreuses applications importantes à l’avenir. Il convient de garder à l’esprit que les décisions de conception qui ne sont pas essentielles pour la sécurité au moment du déploiement peuvent encore avoir un impact important lorsque la technologie sera largement utilisée. Bien qu’ils soient pratiques à une époque donnée, une fois que ces choix de conception ont été irréversiblement intégrés dans des systèmes importants, les compromis semblent différents, et nous pouvons trouver qu’ils causent des problèmes qui sont difficiles à résoudre sans une refonte complète de la conception.
Deux exemples du développement de la programmation incluent le null pointer — que Tony Hoare surnomme son’erreur de milliard de dollars’ — et la routine gets() en C. Si les premiers langages de programmation avaient été conçus pour la sécurité, les progrès auraient pu être plus lents mais la sécurité informatique serait probablement dans une position beaucoup plus forte.
En réfléchissant et en planifiant soigneusement dès maintenant, nous pouvons éviter de créer des problèmes et des vulnérabilités analogues. Nous espérons que la catégorisation décrite dans ce post servira de cadre utile pour une planification méthodique de cette manière. Notre intention est de faire en sorte que les systèmes d’IA de l’avenir ne soient pas seulement “ avec un peu de chance sûrs “, mais qu’ils soient robustes et sûrs de façon vérifiable — parce que nous les avons construits de cette façon !
Nous nous réjouissons à l’idée de continuer à faire des progrès stimulants dans ces domaines, en étroite collaboration avec le milieu de la recherche sur l’IA en général, et nous encourageons les personnes de toutes les disciplines à envisager de s’engager ou de contribuer au domaine de la recherche sur la sécurité en IA.
Si vous êtes intéressé à travailler avec nous sur les domaines de recherche décrits dans ce post, nous embauchons ! Veuillez consulter nos postes à pourvoir sur https://deepmind.com/careers/ et notez votre intérêt pour la sécurité de l’IA lorsque vous postulez. Nous aimerions entendre des chercheurs talentueux et des non-chercheurs.
Ressources
Pour une lecture connexe, vous trouverez ci-dessous une collection d’autres articles, agendas ou taxonomies qui ont éclairé notre réflexion ou qui présentent un point de vue alternatif utile sur la formulation de problèmes de sécurité technique de l’IA :
- Bibliographie annotée des documents recommandés (Center for Human-Compatible AI, 2018)
- Sécurité et contrôle pour l’intelligence générale artificielle (UC Berkeley, 2018)
- Ressources sur la sécurité de l’AI (Victoria Krakovna, 2018)
- Examen de la documentation sur la sécurité de l’AGI (Everitt et al., 2018)
- Se préparer aux utilisations malveillantes de l’IA (2018)
- Exemples de spécifications de jeu en IA (Victoria Krakovna, 2018)
- Directions et desiderata pour l’alignement de l’IA (Paul Christiano, 2017)
- Financement de la recherche sur l’harmonisation (Paul Christiano, 2017)
- Agent Foundations for Aligning Machine Intelligence with Human Interests : Un programme de recherche technique (Institut de recherche en intelligence artificielle, 2017)
- Gridworlds de sécurité AI (Leike et al., 2017)
- Interactions entre le problème de contrôle de l’IA et le problème de gouvernance (Nick Bostrom, 2017)
- Alignement pour les systèmes avancés d’apprentissage machine (Machine Intelligence Research Institute, 2017)
- Sécurité de l’IA : trois problèmes humains et un problème d’IA (Stuart Armstrong, 2017)
- Problèmes concrets de sécurité contre l’IA (Dario Amodei et al, 2016)
- The Value Learning Problem (Machine Intelligence Research Institute, 2016)
- A survey of research questions for robust and beneficial AI (Future of Life Institute, 2015)
- Priorités de recherche pour une intelligence artificielle robuste et bénéfique (Future of Life Institute, 2015)
