Introduction à la sûreté de l’IA

Article co-écrit avec Adam Shimi.

‍

Vous arrivez au travail lundi, et Tim, votre nouveau secrétaire, est là pour son premier jour. Pour l’étrenner, vous lui demandez de vous ramener du café. 10 minutes plus tard, le voilà qui revient avec… un sac de grains de café. Bon prince, vous vous rappelez des conseils de votre psy, et vous restez calme. Vous redemandez à Tim un café, en précisant cette fois que vous voulez la boisson café. Il repart sur les chapeaux de roue. Une demi-heure plus tard, il revient avec ce qui compte techniquement comme du café : un cappuccino à la citrouille (Halloween n’est pas loin). Cette fois vos nerfs lâchent, et vous hurlez à ce pauvre Tim de vous ramener un café noir le plus vite possible. Ce qu’il fait, en un temps record de 5 minutes.

Vous pouvez enfin savourer votre café. Du moins, jusqu’au moment où la police rentre dans les locaux pour arrêter Tim — dans sa quête d’efficacité, il a poussé un passant sur la route, et ce dernier a été écrasé.

Nous sommes probablement tous d’accord pour dire qu’il faut virer Tim (si la police ne l’a pas déjà embarqué). À la question « A-t-il échoué aux tâches que vous lui avez confié ? », la réponse intuitive est oui : il devait juste ramener un café depuis le début, et ne pas tuer quelqu’un par la même occasion. N’importe quel humain avec un peu de bon sens l’aurait compris. Seulement Tim n’a clairement pas de bon sens ; il lui faut des instructions exactes et complètes, et force est de reconnaître que les vôtres ne l’étaient pas.

Tout comme avec Tim, l’implicite ne passe pas quand il s’agit de programmer des machines. Et encore moins lorsqu’elles apprennent d’elles-mêmes à accomplir ce que nous demandons, comme dans le Machine Learning (ML) qui sous-tend l’Intelligence Artificielle (IA) moderne.

Sûreté des outils : Informatique et IA

La plupart des machines peuvent mettre leurs utilisateurs en danger. Elles disposent dans l’idéal de garanties de sûreté permettant d’éviter autant que possible un échec catastrophique du système. Pour un ascenseur, par exemple, il faut éviter que la cabine ne s’écrase au sol. Sa sûreté repose en grande partie sur des systèmes de blocage et de frein d’urgence.

Plus généralement, la sûreté va dépendre du type d’outil considéré : les outils simples, guidés par la main de leur utilisateur en temps réel ; les outils informatiques, où des instructions précises sont écrites à l’avance et exécutées ensuite ; ou les systèmes d’IA modernes, où seul l’objectif est écrit, et la machine se charge de trouver une solution adaptée.

La sûreté d’un outil simple dépend principalement de son utilisateur. Par exemple, quiconque a un marteau dans la main, par exemple, est censé comprendre très bien comment son outil fonctionne. Il saura donc vite s’il est cassé, ou si son utilisation est dangereuse dans un certain contexte.

Pour un outil informatique par contre, l’utilisateur n’a pas de contrôle sur les instructions fournies à la machine. La sûreté de l’outil dépend donc beaucoup plus des concepteurs, qui doivent garantir le fonctionnement sûr de leur système. Il existe de nombreuses approches pour cela, des tests à la vérification formelle.

Enfin, avec les systèmes d’IA, même les concepteurs ne contrôlent pas exactement les instructions exécutées. Faute de savoir décrire à la machine la façon exacte de résoudre un problème (savez-vous expliquer précisément comment faire du vélo, par exemple ?), on construit un programme qui va chercher des solutions dans un large éventail de possibilités. Là est d’ailleurs tout l’intérêt du ML : automatiser la conception d’outils informatiques. Mais ces techniques créent de nouveaux risques d’échec catastrophique !

En effet, la solution la plus directe n’est souvent pas désirable — ramener un café le plus vite possible ne prend pas en compte les dégâts sur les passants. D’où l’importance de garantir que la solution la plus directe soit suffisamment désirable, à travers des contraintes de sûreté. La nature du ML, une recherche de solutions, complique cette tâche. Sans compter les risques d’obtenir un système d’IA plus compétent que nous, et donc difficile à évaluer et contrôler.

Les risques liés à l’IA viennent de l’approche employée pour les créer : la recherche d’une solution à un problème donné, dont la définition et les contraintes de sûreté sont imparfaites. D’où la possibilité de finir avec une machine extrêmement compétente qui suit ce que l’on dit, mais pas ce que l’on veut. Une telle IA ne cherche pas explicitement à nuire. Elle est juste plus alignée avec ce que nous disons qu’avec ce que nous voulons.

Objections et Réponses

Jusqu’ici, nous avons donné assez peu d’explications techniques. Vous êtes donc en droit de vous demander si ces problèmes de sûreté ne sont pas au fond faciles à résoudre. Pour reprendre la petite histoire du début, il aurait suffi de préciser à Tim que l’on voulait du café liquide, de donner le nom exact de la boisson, et de lui interdire de tuer ou blesser qui que ce soit en accomplissant sa tâche. Voilà, problème résolu.

Pas exactement. On peut pointer deux difficultés dans la mise en place de la « solution » proposée ci-dessus : être exhaustif, et formaliser nos instructions.

L’exhaustivité a déjà été évoquée à plusieurs reprises : donner un ordre exact est difficile, parce que nous sommes habitués à communiquer avec d’autres êtres de la même espèce, souvent de la même culture, et parfois même que nous connaissons depuis des décennies. De telles relations tolèrent les non-dits, soit parce qu’ils sont évidents pour tous, soit parce qu’on peut poser des questions si ce n’est pas le cas. Mais pour une IA, que l’on peut considérer comme membre d’une « espèce » complètement différente, les non-dits sont des trous dans la spécification.

Par exemple, dans la solution proposée plus haut, rien n’empêche Tim d’exploser la vitre du café où il va chercher votre boisson, du moment qu’il ne blesse personne. Ce qui n’est pas du tout ce que vous vouliez. Mais au moins, il ne va pas tuer des gens.

En fait, peut-être que si, à cause du second problème, celui de la formalisation. Car malgré ses spécificités, l’IA reste un domaine de l’informatique. Il faut donc donner des instructions précises et exactes à l’ordinateur. Littéralement des instructions mathématiques.

Du coup, quelle définition mathématique de « blesser » quelqu’un voulons-nous donner ? Que la configuration des atomes de son corps garde une forme typiquement humaine ? Que Tim ne cause aucun changement dans son corps ? Qu’aucun de ses récepteurs de la douleur ne s’active suite à l’interaction ?

Il est facile d’imaginer des cas où chacune de ces définitions crée d’autres problèmes : pour la première, tuer est autorisé tant que le corps garde une forme humaine ; pour la seconde, Tim ne ferait rien car impossible de savoir si le changement moléculaire vient de lui ou non ; et pour la dernière, Tim pourrait jeter le passant sur la route tant qu’il est anesthésié avant.

Pire encore, Tim pourrait trouver des solutions auxquelles aucun humain (concepteur y compris) n’aurait pensé. La recherche de solution en Machine Learning donne en effet souvent des résultats surprenants. Et il y a aussi la possibilité que la machine devienne plus compétente que son concepteur sur sa tâche. Mais même lorsque le résultat est trop complexe pour nous, la sûreté doit être assurée.

Garantir qu’une IA fait bien ce que l’on veut, comme on le veut, sans pour autant lui dire exactement quoi faire, n’est donc pas un problème trivial. C’est celui qu’essaie de résoudre le domaine de la sûreté de l’IA.

Sûreté et gouvernance

L’exemple de Tim est utile pour illustrer certaines questions majeures du domaine, mais cela reste une expérience de pensée. Si nous ne disposons pas encore (heureusement) de systèmes d’IA assez avancés pour causer des dégâts catastrophiques, les performances des méthodes actuelles ne cessent de croître. Comme nous avons peu de raisons de penser que cette croissance s’arrêtera, il convient d’étudier des scénarios plausibles impliquant des systèmes d’IA avancés. Scénarios dans lesquels la sûreté technique joue un rôle prépondérant.

L’un d’eux est la prolifération d’armes autonomes, ne dépendant pratiquement plus des décisions humaines : même s’il « faut » qu’un ordre de tir soit donné par un humain, celui-ci fera par défaut confiance à la machine sophistiquée. Ici la sûreté servirait à garantir que l’ordre représente bien la volonté humaine, ou qu’il soit expliqué de manière à ce que l’humain puisse le vérifier.

Autre scénario, l’apparition d’agents économiques, des services dématérialisés par exemple, disposant d’assez de ressources pour persister indéfiniment une fois démarrés, et accumulant progressivement de l’influence pour garantir leur autonomie. Un mécanisme de sûreté nous permettrait d’intervenir pour les arrêter. Autre possibilité : que ces agents aient, par construction, une assez bonne compréhension des valeurs humaines pour que cette intervention ne soit pas nécessaire.

Réfléchir à de telles possibilités est du ressort de la gouvernance de l’IA, qui regroupe toutes les questions liées à l’impact et aux applications pratiques de cette technologie. De nombreuses réflexions sont déjà en cours sur les problèmes éthiques associés à l’IA et les garanties de transparence et d’équité des technologies actuelles. Ces questions deviennent d’autant plus difficiles avec ces avancées — des risques nouveaux apparaissent.

Certains problèmes sont déjà visibles aujourd’hui — par exemple les décisions morales des voitures autonomes. Nous manquons aussi d’information sur quand et comment les systèmes d’IA deviendront suffisamment compétents pour causer des dégâts catastrophiques, si cela arrive un jour. Ces réflexions justifient de travailler sur la partie technique de la sûreté de l’IA dès aujourd’hui. Celle-ci sera donc le sujet des articles suivants.

Idées transversales

Dans les articles qui suivront, nous allons présenter plus en détail trois idées fondamentales de la sûreté de l’IA. Ces idées s’appliquent d’une manière ou d’une autre à la plupart des approches étudiées.

• (Alignement Interne / Alignement Externe) Dans la plupart des exemples ci-dessus, l’objectif donné à l’IA ne capturait pas exactement ce que l’on voulait (en tout cas formellement). On appelle cela un problème d’alignement externe : l’objectif donné à l’IA n’est pas adapté ou ne prend pas en compte certaines situations.
  Il existe un autre type de problème d’alignement, tout aussi important : l’alignement interne. Pour simplifier, les techniques de Machine Learning moderne créent des IA qu’il est difficile pour nous de comprendre et d’interpréter. Malgré tout, une IA qui a été créée pour accomplir un certain objectif doit l’encoder d’une manière ou d’une autre. Le problème d’alignement interne est la possibilité que l’objectif encodé par l’IA ne soit pas exactement celui fourni par les concepteurs. Et donc que son comportement diffère de celui attendu.
• (Corrigibilité) Les discussions précédentes nous laissent penser que donner un but imprécis à une IA est potentiellement dangereux, et donner un but précis est dur voire impossible. Cela a poussé la plupart des chercheurs en sûreté de l’IA à s’intéresser à la corrigibilité — la propriété d’une IA qui au lieu d’accomplir son but malgré les efforts de ses concepteurs pour la corriger, les assiste plutôt dans cette correction.
  Garantir la corrigibilité nous permettrait de garder le contrôle sur ce que l’IA essaye d’accomplir, et de rectifier les erreurs dans son objectif initial lorsque nous les voyons. Enfin, la corrigibilité joue aussi un rôle pour empêcher des tentatives de manipulation, où l’IA essaye de nous faire croire qu’elle accomplit le but que l’on veut, alors même qu’elle accomplit celui qui lui a été donné initialement (et que l’on voudrait corriger).
• (Apprentissage des valeurs) Trouver exactement ce que l’on veut qu’une IA fasse est difficile. Une idée plutôt naturelle est donc de lui faire apprendre ce que l’on veut. Cela inclut l’apprentissage du bon sens et de tous les implicites derrière nos ordres et les buts que nous lui donnons, pour qu’elle puisse les interpréter correctement. On appelle cela l’apprentissage des valeurs, où l’on appelle valeurs ce que l’on veut, plutôt que ce que l’on dit.
  Mais il y a bien sûr de nombreuses difficultés. Par exemple, nos valeurs sur un problème spécifique sont elles bien définies ? Et nos valeurs en général ? Peuvent-elles changer ? Et est-ce qu’observer notre comportement est suffisant pour les inférer ?
  Autant de questions que l’apprentissage des valeurs a pour but de résoudre.

La sûreté de l’IA fait partie des problèmes non résolus de l’informatique. Un défi avec d’immenses applications pratiques, compte tenu de l’importance toujours croissante que l’intelligence artificielle prend dans notre société.

En peu de mots, il est extrêmement difficile, aujourd’hui, de créer un système d’intelligence artificielle qui puisse à la fois trouver des solutions créatives à des problèmes, et garantir que ces solutions soient conformes à nos volontés, pas simplement à nos instructions explicites. Pour des systèmes modernes, utilisant de l’apprentissage, on ne sait simplement pas comment faire, ce qui engendre de nombreux risques !

La sûreté de l’IA est un domaine encore très jeune, avec beaucoup de problèmes intéressants à résoudre. Vous pourrez découvrir, dans les articles suivants, plus de détails techniques sur quelques-uns d’entre eux.

En attendant nos prochains articles, si le sujet vous intéresse, des groupes de discussion sur le sujet existent à Paris et à Toulouse, ainsi que le sur le serveur Discord d’Altruisme Efficace France, que vous pouvez également contacter à cette addresse.