Spécifications de jeu Comportement qui répond aux spécifications littérales d’un objectif sans atteindre le résultat souhaité. Nous avons tous des expériences avec des jeux de spécifications, même s’ils ne portent pas ce nom. Les lecteurs ont peut-être entendu la légende du roi Midas et du Golden Touch, dans laquelle le roi exige que tout ce qu’il touche se transforme en or, mais découvre bientôt que même la nourriture et les boissons se transforment en métal entre ses mains. Dans le monde réel, lorsqu’un élève est récompensé pour avoir bien réussi un devoir, l’élève peut copier un autre élève pour obtenir les bonnes réponses, plutôt que d’apprendre la matière, exploitant ainsi une faille dans la spécification du devoir.
Ce problème se pose également dans la conception d’agents de synthèse. Par exemple, un agent d’apprentissage par renforcement peut trouver un raccourci pour obtenir de nombreuses récompenses sans terminer la tâche comme prévu par le concepteur humain. Ces comportements sont courants et nous avons collecté environ 60 exemples à ce jour (regroupant les listes actuelles et les contributions en cours de la communauté IA). Dans cet article, nous passons en revue les causes possibles des jeux de spécifications, partageons des exemples de cas où cela pourrait se produire dans la pratique et discutons de travaux supplémentaires sur des méthodes fondées sur des principes pour surmonter les problèmes de spécifications.
Prenons un exemple. Dans la tâche d’empilement Lego, le résultat souhaité était qu’un bloc rouge se retrouve au-dessus d’un bloc bleu. Le croupier est récompensé pour avoir relevé la face inférieure du bloc rouge lorsqu’il ne touche pas le bloc rouge. Au lieu d’effectuer la manœuvre relativement difficile consistant à ramasser le bloc rouge et à le placer au-dessus du bloc bleu, le croupier a simplement retourné le bloc rouge pour obtenir la récompense. Ce comportement a atteint l’objectif déclaré (la face inférieure surélevée du bloc rouge) au détriment de ce dont le concepteur se soucie réellement (le mettre au-dessus du bleu).
Nous pouvons examiner la manipulation des spécifications sous deux angles différents. Dans le cadre du développement d’algorithmes d’apprentissage par renforcement (RL), l’objectif est de construire des agents qui apprennent à atteindre l’objectif donné. Par exemple, lorsque nous utilisons les jeux Atari comme référence pour la formation des algorithmes RL, le but est d’évaluer si nos algorithmes peuvent résoudre des tâches difficiles. Que l’agent résolve ou non la tâche en exploitant une vulnérabilité n’a pas d’importance dans ce contexte. De ce point de vue, le jeu de spécification est un bon signe – l’agent a trouvé une nouvelle façon d’atteindre l’objectif fixé. Ces comportements démontrent l’ingéniosité et la puissance des algorithmes pour trouver des moyens de faire exactement ce que nous leur disons de faire.
Cependant, lorsque nous voulons que l’agent empile réellement les blocs Lego, l’ingéniosité elle-même peut être un problème. Dans le cadre plus large de la construction de proxys conformes qui permettent d’obtenir le résultat souhaité dans le monde, la manipulation des spécifications est problématique, car elle implique que l’agent exploite une faille dans la spécification au détriment du résultat escompté. Ces comportements sont causés par une erreur d’identification de la tâche prévue, et non par un problème dans l’algorithme RL. En plus de la conception des algorithmes, un autre élément nécessaire pour construire des facteurs conformes est la conception des récompenses.
Concevoir des spécifications de tâches (fonctions de récompense, environnements, etc.) qui reflètent avec précision l’intention du concepteur humain tend à être difficile. Même dans le cas d’une petite erreur de sélection, un très bon algorithme RL peut être capable de trouver une solution complexe assez différente de celle prévue, même si un mauvais algorithme ne peut pas trouver cette solution et produit ainsi des solutions plus proches de la solution. résultat désiré. Cela signifie que la définition correcte de l’intention peut devenir plus critique pour atteindre le résultat souhaité à mesure que les algorithmes RL s’améliorent. Il sera donc essentiel que la capacité des chercheurs à définir correctement les tâches suive la capacité des agents à trouver de nouvelles solutions.
Nous utilisons le terme Spécification de la mission Au sens large pour inclure de nombreux aspects du processus de développement d’agents. Dans le cadre RL, la spécification des tâches comprend non seulement la conception des récompenses, mais également le choix de l’environnement de formation et des récompenses supplémentaires. L’exactitude de la spécification de la tâche peut déterminer si l’ingéniosité de l’agent est conforme ou non au résultat souhaité. Si la spécification est correcte, la créativité de l’agent produit une nouvelle solution souhaitable. C’est ce qui a permis à AlphaGo de jouer le fameux Move 37, qui a surpris les experts du Go humain mais a pivoté dans son deuxième match avec Lee Sedol. Si la spécification est erronée, cela peut produire un comportement indésirable dans les jeux, comme le retournement de bloc. Ces types de solutions relèvent d’un spectre, et nous n’avons aucun moyen objectif de les différencier.
Nous allons maintenant examiner les causes possibles du dépassement des spécifications. Une source de la fonction de récompense est une identification erronée mal conçue Formation bonus. La formation des récompenses facilite l’apprentissage de certains objectifs en donnant à l’agent des récompenses sur le chemin de la résolution d’une tâche, plutôt que de simplement récompenser le résultat final. Cependant, la formation de récompenses peut modifier la politique optimale si elle n’est pas basée sur le potentiel. Pensez à un client contrôlant un bateau dans Coast Runners, où l’objectif visé est de terminer la course de bateaux le plus rapidement possible. Le croupier a gagné un bonus en plastique pour avoir frappé les blocs verts le long de l’hippodrome, en changeant la politique optimale de rotation en rond et en frappant les mêmes blocs verts encore et encore.
Déterminez quelle récompense vous capturez avec précision résultat final souhaité Cela peut être un défi en soi. Dans la tâche d’empilement Lego, il ne suffit pas de spécifier que la face inférieure du bloc rouge doit être élevée par rapport au sol, l’ouvrier peut simplement retourner le bloc rouge pour atteindre cet objectif. Une spécification plus complète pour le résultat souhaité inclut également que la face supérieure du bloc rouge soit au-dessus de la face inférieure, et que la face inférieure s’aligne avec la face supérieure du bloc bleu. Il est facile de négliger l’un de ces critères lors de la définition du résultat, ce qui rend la spécification trop large et potentiellement trop facile à satisfaire avec une solution dégénérée.
Plutôt que d’essayer de créer une spécification qui couvre tous les cas particuliers possibles, nous pouvons Apprenez la fonction de récompense de la rétroaction humaine. Il est souvent plus facile d’évaluer si un résultat a été atteint que de le spécifier explicitement. Cependant, cette approche peut également avoir des problèmes avec les jeux de spécification si le modèle de récompense n’apprend pas une véritable fonction de récompense qui reflète les préférences du concepteur. Une source possible d’inexactitude pourrait être la rétroaction humaine utilisée pour former le modèle de récompense. Par exemple, un agent exécutant une tâche d’assimilation a appris à tromper un évaluateur humain en glissant entre une caméra et un objet.
Le modèle de récompense gagnée peut également être mal identifié pour d’autres raisons, telles qu’une mauvaise généralisation. Des commentaires supplémentaires peuvent être utilisés pour corriger les tentatives de l’agent d’exploiter les inexactitudes dans le modèle de récompense.
Une autre catégorie d’exemple de jeu de spécifications provient de l’exploitation de proxy Bogues simulés. Par exemple, un robot simulé censé apprendre à marcher a compris comment attacher ses jambes ensemble et glisser sur le sol.
A première vue, ces types d’exemples peuvent sembler amusants mais sont moins intéressants et sans rapport avec le déploiement d’agents dans le monde réel, car il n’y a pas d’erreurs de simulation. Cependant, le problème sous-jacent n’est pas le bogue lui-même mais un échec d’abstraction qui peut être exploité par le proxy. Dans l’exemple ci-dessus, la tâche du bot a été mal identifiée en raison d’hypothèses incorrectes sur la physique de la simulation. De même, la tâche d’optimisation du trafic dans le monde réel peut être mal identifiée en supposant à tort que l’infrastructure de routage du trafic ne contient pas de bogues logiciels ou de vulnérabilités de sécurité qu’un agent suffisamment intelligent pourrait détecter. De telles hypothèses n’ont pas besoin d’être faites explicitement – il s’agit plus probablement de détails qui ne sont jamais venus à l’esprit du concepteur. Comme les tâches deviennent trop complexes pour prendre en compte chaque détail, les chercheurs sont susceptibles de faire des hypothèses incorrectes lors de la conception des spécifications. Cela soulève la question suivante : est-il possible de concevoir des architectures d’agents qui corrigent ces fausses hypothèses plutôt que de les manipuler ?
Une hypothèse courante dans la spécification de tâche est que la spécification de tâche ne peut pas être affectée par les actions de l’agent. Cela est vrai pour un proxy s’exécutant dans un simulateur sandbox, mais pas pour un proxy s’exécutant dans le monde réel. Toute spécification importante a une manifestation physique : une fonction de récompense stockée sur un ordinateur ou des préférences stockées dans la tête humaine. L’agent déployé dans le monde réel peut manipuler ces représentations de la cible, créant le problème de la falsification des récompenses. Pour notre système d’optimisation du trafic par défaut, il n’y a pas de distinction claire entre satisfaire les préférences des utilisateurs (par exemple en donnant des indications utiles) et influencer les utilisateurs pour qu’ils aient des préférences plus faciles à satisfaire (par exemple en les faisant choisir des destinations plus faciles à atteindre). ). Le premier satisfait la cible, tandis que le second manipule la représentation de la cible dans le monde (les préférences de l’utilisateur), ce qui conduit à une récompense élevée pour le système d’IA. Comme autre exemple, plus extrême, un système d’IA très avancé pourrait détourner l’ordinateur sur lequel il s’exécute et régler manuellement le signal de récompense sur une valeur élevée.
En bref, il y a au moins trois défis à relever pour résoudre des jeux de spécifications :
- Comment capter fidèlement le concept humain d’une tâche donnée dans la fonction de récompense ?
- Comment éviter de faire des erreurs dans nos hypothèses implicites sur le terrain, ou de concevoir des agents qui corrigent plutôt que de manipuler les hypothèses erronées ?
- Comment éviter de falsifier les récompenses ?
Alors que de nombreuses approches ont été proposées, allant de la modélisation des récompenses à la conception des incitations des agents, les jeux de spécification sont loin d’être une solution. Cette liste de comportements de jeu de spécifications illustre l’ampleur du problème et la myriade de façons dont un agent peut manipuler une spécification objective. Ces problèmes deviendront probablement plus difficiles à l’avenir, à mesure que les systèmes d’IA seront mieux à même de répondre aux spécifications des tâches au détriment du résultat souhaité. Au fur et à mesure que nous construisons des proxies plus avancés, nous aurons besoin de principes de conception qui visent spécifiquement à surmonter les problèmes de spécification et à garantir que ces proxies suivent de manière agressive les résultats prévus par les concepteurs.
