How Should AI Safety Benchmarks Benchmark Safety?
Cet article passe en revue 210 bancs d'essai de sécurité de l'IA afin d'identifier leurs lacunes techniques et épistémiques, proposant une feuille de route fondée sur les théories établies de la gestion des risques et de la mesure pour développer des cadres d'évaluation de la sécurité plus valides, robustes et responsables.
Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète
Imaginez que vous êtes un enseignant essayant de noter une nouvelle génération de robots super intelligents. Vous voulez savoir s'ils sont sûrs pour être lâchés dans le monde, ou s'ils pourraient accidentellement (ou délibérément) causer des problèmes. Pour ce faire, vous leur soumettez une série de tests, comme un examen du permis de conduire pour l'IA. Dans le monde de l'informatique, ces tests sont appelés « benchmarks » (tests de référence). Considérez un benchmark comme un parcours d'obstacles standardisé : si un robot peut sauter par-dessus les haies, résoudre les énigmes et éviter les pièges, nous supposons qu'il est prêt pour le monde réel. Mais voici le piège : ce n'est pas parce qu'un robot est excellent pour sauter les haies spécifiques que vous avez construites qu'il ne trébuchera pas sur une peau de banane que vous n'avez pas mise sur le parcours, ou qu'il ne décidera pas de déclencher un incendie simplement parce qu'il s'ennuie. Ce document plonge dans le monde complexe et désordonné de la façon dont nous testons la sécurité de l'IA, en soutenant que nos « parcours d'obstacles » actuels sont souvent trop simples, trop rigides, et parfois complètement à côté de la plaque par rapport à ce que représente un danger réel.
Les auteurs de cet article, une équipe de chercheurs issus d'universités comme l'Université technique de Munich et Cornell, ont décidé de jeter un regard massif sur l'état des tests de sécurité de l'IA. Ils ne se sont pas contentés de jeter un coup d'œil à quelques tests ; ils ont passé en revue 210 benchmarks de sécurité différents créés par des chercheurs. Ils voulaient voir si ces tests faisaient réellement du bon travail pour nous protéger, ou s'ils nous donnaient simplement un faux sentiment de sécurité.
Voici le gros problème qu'ils ont trouvé : la plupart de ces tests regardent les mauvaises choses. Ils ont découvert que 81 % des benchmarks ne vérifient que des risques que nous connaissons déjà et que nous avons déjà rencontrés, comme un langage « toxique » ou des astuces simples pour pousser l'IA à enfreindre ses règles (appelées « jailbreaks » ou débridages). C'est comme tester une voiture uniquement sur une piste droite et lisse, en supposant qu'elle se comportera bien sur une route de montagne boueuse. Les tests ignorent complètement les façons étranges, imprévisibles et totalement nouvelles dont l'IA pourrait mal agir, ce que les auteurs appellent les « inconnues inconnues » (unknown unknowns).
De plus, la manière dont ces tests mesurent la sécurité est souvent mathématiquement fragile. L'article souligne que 79 % des benchmarks traitent la sécurité comme un simple interrupteur « passe ou échoue ». Ils comptent combien de fois une IA a refusé une requête malveillante et appellent cela un « score de sécurité ». Mais les auteurs soutiennent que cela est trompeur. Ce n'est pas parce qu'une IA refuse une requête 90 % du temps dans un test qu'elle est 90 % sûre dans le monde réel. C'est comme dire qu'un pont est sûr parce qu'il a résisté à une légère brise, sans vérifier s'il peut supporter un ouragan. Les tests ignorent souvent la gravité du dommage qui résulterait d'un échec de l'IA, et ils ne tiennent pas compte de la fréquence à laquelle les gens posent réellement ces questions dangereuses dans la vie réelle.
Les chercheurs ont également constaté que le lien entre le test et la réalité est souvent rompu. Ils appellent cela une « chaîne de substitution » (proxy chain). Imaginez que vous vouliez savoir si un étudiant est un bon conducteur, alors vous le testez sur sa capacité à garer une voiture dans un simulateur. C'est une substitution. Mais si le simulateur ne tient pas compte de la pluie, ou des autres conducteurs, ou du fait que l'étudiant est distrait par son téléphone, le résultat du test ne vous dit pas s'il est réellement en sécurité sur l'autoroute. L'article soutient que beaucoup de tests de sécurité de l'IA sont comme ce simulateur : ils mesurent des choses comme des « taux de refus » ou de la « correspondance de mots-clés », mais ces chiffres ne se traduisent pas toujours par un dommage dans le monde réel.
Alors, que suggèrent les auteurs à la place ? Ils proposent une nouvelle feuille de route avec 10 recommandations pour corriger ces tests défaillants.
Premièrement, ils disent qu'il faut arrêter de tester uniquement ce que nous connaissons déjà. Nous devons construire des tests qui traquent activement de nouvelles façons étranges et inattendues dont l'IA pourrait échouer. Ils suggèrent d'utiliser des outils qui tentent constamment de briser l'IA de nouvelles manières, plutôt que de s'en tenir à une liste fixe de questions.
Deuxièmement, nous devons faire de meilleures mathématiques. Au lieu de simplement dire « Réussite » ou « Échec », nous devrions calculer le risque réel. Cela signifie se poser la question : « Quelle est la probabilité que cette chose mauvaise arrive ? » et « Quelle serait la gravité si elle arrivait ? ». Les auteurs suggèrent d'utiliser une méthode appelée « Évaluation Probabiliste des Risques », utilisée dans des domaines comme l'énergie nucléaire et l'aviation. Ils montrent même un calcul où un modèle peut sembler sûr dans un test, mais lorsqu'on prend en compte le nombre de personnes qui l'utilisent et la fréquence à laquelle elles posent des questions dangereuses, le risque réel est bien plus élevé.
Troisièmement, nous devons nous assurer que nos tests mesurent réellement ce qu'ils prétendent mesurer. Cela signifie être très clair sur ce que la « sécurité » signifie dans une situation spécifique et s'assurer que le test reflète le monde réel, et non un laboratoire propre et artificiel. Ils soutiennent également qu'il faut impliquer les personnes qui pourraient être affectées par l'IA — comme les adolescents, les patients ou les communautés — pour aider à concevoir les tests, car elles savent mieux que quiconque quel genre de préjudice est réel pour elles.
Pour prouver que leurs idées fonctionnent, l'équipe a construit un petit test d'exemple axé sur la façon dont l'IA parle aux adolescents de la santé mentale. Ils n'ont pas seulement demandé à l'IA si elle connaissait les règles ; ils ont simulé de vraies conversations et calculé le dommage potentiel en fonction du nombre d'adolescents qui utilisent réellement ces outils. Les résultats ont montré que même des modèles qui semblaient « sûrs » dans les tests standards pouvaient encore causer des problèmes importants lorsqu'on regardait les chiffres du monde réel.
En fin de compte, l'article ne dit pas que l'IA est condamnée ou que nous ne pouvons pas la tester. Il dit que nos méthodes de test actuelles sont comme utiliser une règle pour mesurer la température d'une soupe — ce sont les mauvais outils pour la tâche. Pour rendre l'IA véritablement sûre, nous devons cesser de traiter la sécurité comme une simple liste de contrôle et commencer à la traiter comme un système complexe et vivant qui change, nous surprend et nécessite de penser au monde réel, et non au tube à essai. Les auteurs suggèrent qu'en adoptant ces nouvelles manières de tester, plus rigoureuses et plus centrées sur l'humain, nous pouvons construire une IA qui n'est pas seulement intelligente, mais véritablement sûre pour tout le monde.
Noyé(e) sous les articles dans votre domaine ?
Recevez des digests quotidiens des articles les plus récents correspondant à vos mots-clés de recherche — avec des résumés techniques, dans votre langue.