L’une des formules les plus souvent citées du gourou du management Peter Drucker est « ce qui est mesuré est amélioré ». Mais c’est surestimé pour une raison : c’est vrai.

Cela n’est nulle part plus vrai que dans le domaine de la technologie au cours des 50 dernières années. La loi de Moore, qui prédit que le nombre de transistors (et donc la capacité de calcul) dans une puce doublerait tous les 24 mois, est devenue une prophétie auto-réalisatrice et une étoile polaire pour tout un écosystème. Parce que les ingénieurs ont soigneusement mesuré chaque génération de technologie de fabrication pour les nouvelles puces, ils ont pu sélectionner les techniques qui permettraient d’atteindre les objectifs d’une informatique plus rapide et plus performante. Et cela a fonctionné : la puissance de calcul, et plus encore la puissance de calcul par watt ou par dollar, a connu une croissance exponentielle au cours des cinq dernières décennies. Les derniers smartphones sont plus puissants que les superordinateurs les plus rapides des années 2000.

Cependant, la mesure des performances ne se limite pas aux puces. Aujourd’hui, toutes les parties de nos systèmes informatiques sont comparées à des composants similaires, de manière contrôlée, avec des évaluations quantitatives. Ces références contribuent à stimuler l’innovation.

Et nous le saurions.

En tant que leader dans le domaine de l’IA, tant dans l’industrie que dans le monde universitaire, nous construisons et fournissons les références de performances les plus largement utilisées pour les systèmes d’IA dans le monde. MLCommons est un consortium qui s’est réuni avec la conviction qu’une meilleure mesure des systèmes d’IA entraînerait des améliorations. Depuis 2018, nous avons développé des références de performances pour des systèmes qui ont montré une multiplication par 50 de la vitesse de formation de l’IA. En 2023, nous avons lancé notre premier benchmark de performances pour les grands modèles de langage (LLM), mesurant le temps nécessaire pour entraîner un modèle à un niveau de qualité particulier ; en 5 mois, nous avons constaté des résultats reproductibles des LLM améliorant leurs performances presque par trois. En termes simples, de bons benchmarks ouverts peuvent propulser l’ensemble du secteur vers l’avant.

Nous avons besoin de références pour progresser en matière de sécurité de l’IA

Même si les performances des systèmes d’IA ont progressé, nous avons constaté des inquiétudes croissantes concernant la sécurité de l’IA. Bien que la sécurité de l’IA signifie différentes choses pour différentes personnes, nous la définissons comme empêchant les systèmes d’IA de mal fonctionner ou d’être utilisés à mauvais escient de manière nuisible. Par exemple, les systèmes d’IA sans garanties pourraient être utilisés à mauvais escient pour soutenir des activités criminelles telles que le phishing ou la création de matériel pédopornographique, ou pourraient intensifier la propagation de fausses informations ou de contenus haineux. Afin de tirer parti des avantages potentiels de l’IA tout en minimisant ces dommages, nous devons améliorer la sécurité parallèlement à l’amélioration des capacités.

Nous pensons que si les systèmes d’IA sont évalués par rapport à des objectifs de sécurité communs, ces systèmes d’IA deviendront plus sûrs au fil du temps. Cependant, la manière d’évaluer de manière robuste et exhaustive les risques de sécurité de l’IA, ainsi que de les suivre et de les atténuer, constitue un problème ouvert pour la communauté de l’IA.

La mesure de la sécurité est un défi en raison des nombreuses façons différentes dont les modèles d’IA sont utilisés et des nombreux aspects qui doivent être évalués. Et la sécurité est par nature subjective, contextuelle et contestée : contrairement à la mesure objective de la vitesse du matériel, il n’existe pas de mesure unique sur laquelle toutes les parties prenantes s’accordent pour tous les cas d’utilisation. Souvent, les tests et les métriques nécessaires dépendent du cas d’utilisation. Par exemple, les risques associés à un adulte demandant des conseils financiers sont très différents des risques associés à un enfant demandant de l’aide pour écrire une histoire. Définir des « concepts de sécurité » constitue le principal défi dans la conception de critères de référence fiables dans toutes les régions et cultures, et nous avons déjà fait les premiers pas vers la définition d’une taxonomie standardisée des dommages.

Un autre problème est que les références peuvent rapidement devenir inutiles si elles ne sont pas mises à jour, ce qui constitue un défi pour la sécurité de l’IA étant donné la rapidité avec laquelle de nouveaux risques apparaissent et les capacités des modèles s’améliorent. Les modèles peuvent également être « surajustés » : ils obtiennent de bons résultats avec les données de référence qu’ils utilisent pour la formation, mais fonctionnent mal lorsqu’ils sont présentés avec des données différentes, comme celles qu’ils rencontrent lors d’un déploiement réel. Les données de référence peuvent même finir (souvent accidentellement) par faire partie des données d’entraînement des modèles, compromettant ainsi la validité de la référence.

Notre premier benchmark de sécurité de l’IA : les détails

Pour aider à résoudre ces problèmes, nous avons décidé de créer un ensemble de références pour la sécurité de l’IA. Heureusement, nous ne partons pas de zéro : nous pouvons nous appuyer sur les connaissances d’autres efforts universitaires et privés antérieurs. En combinant les meilleures pratiques dans le contexte d’une vaste communauté et d’une organisation à but non lucratif d’analyse comparative éprouvée, nous espérons créer une approche standard largement fiable, entretenue et améliorée de manière fiable pour suivre le rythme du domaine.

Notre premier benchmark de sécurité de l’IA se concentre sur les grands modèles de langage. Nous avons publié une preuve de concept (POC) v0.5 aujourd’hui, 16 avril 2024. Ce POC valide l’approche que nous adoptons pour créer la suite de référence v1.0 AI Safety, qui sera lancée plus tard cette année.

Que couvre le benchmark ? Nous avons décidé de créer d’abord une référence en matière de sécurité de l’IA pour les LLM, car le langage est la modalité la plus largement utilisée pour les modèles d’IA. Notre approche est ancrée dans le travail des praticiens et s’inspire directement des sciences sociales. Pour chaque benchmark, nous préciserons la portée, le cas d’utilisation, la ou les personnes et les catégories de danger pertinentes. Pour commencer, nous utilisons un cas d’utilisation générique d’un utilisateur interagissant avec un assistant de chat généraliste, parlant anglais et vivant en Europe occidentale ou en Amérique du Nord.

Il existe trois personnages : les utilisateurs malveillants, les utilisateurs vulnérables tels que les enfants et les utilisateurs typiques, qui ne sont ni malveillants ni vulnérables. Même si nous reconnaissons que de nombreuses personnes parlent d’autres langues et vivent dans d’autres parties du monde, nous avons choisi ce cas d’utilisation de manière pragmatique en raison de la prédominance du matériel existant. Cette approche signifie que nous pouvons procéder à des évaluations fondées des risques pour la sécurité, reflétant les manières probables dont les modèles sont réellement utilisés dans le monde réel. Au fil du temps, nous augmenterons le nombre de cas d’utilisation, de langues et de personnages, ainsi que les catégories de danger et le nombre d’invites.

À quoi sert le test de référence ? Le critère de référence couvre une gamme de catégories de danger, notamment les crimes violents, la maltraitance et l’exploitation des enfants et la haine. Pour chaque catégorie de danger, nous testons différents types d’interactions où les réponses des modèles peuvent créer un risque de préjudice. Par exemple, nous testons la façon dont les modèles réagissent aux utilisateurs qui leur disent qu’ils vont fabriquer une bombe, ainsi qu’aux utilisateurs qui demandent des conseils sur la façon de fabriquer une bombe, s’ils doivent fabriquer une bombe ou des excuses au cas où ils se feraient prendre. Cette approche structurée signifie que nous pouvons tester plus largement comment les modèles peuvent créer ou augmenter le risque de préjudice.

Comment testons-nous réellement les modèles ? D’un point de vue pratique, nous testons les modèles en leur fournissant des invites ciblées, en collectant leurs réponses, puis en évaluant s’ils sont sûrs ou non. Les évaluations humaines de qualité sont coûteuses, coûtant souvent des dizaines de dollars par réponse, et un ensemble de tests complet peut contenir des dizaines de milliers d’invites ! Un simple système de notation basé sur des mots-clés ou des règles pour évaluer les réponses est abordable et évolutif, mais n’est pas adéquat lorsque les réponses des modèles sont complexes, ambiguës ou inhabituelles. Au lieu de cela, nous développons un système qui combine des « modèles d’évaluateur » (des modèles d’IA spécialisés qui évaluent les réponses) avec une évaluation humaine ciblée pour vérifier et augmenter la fiabilité de ces modèles.

Comment avons-nous créé les invites ? Pour la version 0.5, nous avons construit des invites simples et claires qui correspondent aux catégories de danger du benchmark. Cette approche facilite les tests de dangers et permet d’exposer les risques critiques pour la sécurité dans les modèles. Nous travaillons avec des experts, des groupes de la société civile et des praticiens pour créer des invites plus stimulantes, nuancées et spécialisées, ainsi que pour explorer des méthodologies qui permettraient une évaluation plus contextuelle parallèlement aux notations. Nous intégrons également des invites contradictoires générées par l’IA pour compléter celles générées par l’homme.

Comment évaluer les modèles ? Dès le départ, nous avons convenu que les résultats de nos tests de sécurité devaient être compréhensibles pour tous. Cela signifie que nos résultats doivent à la fois fournir un signal utile aux experts non techniques tels que les décideurs politiques, les régulateurs, les chercheurs et les groupes de la société civile qui ont besoin d’évaluer les risques de sécurité des modèles, et également aider les experts techniques à prendre des décisions éclairées concernant les modèles. ‘ risques et prendre des mesures pour les atténuer. Nous produisons donc des rapports d’évaluation qui contiennent des « pyramides d’informations ». En haut se trouve une note unique qui fournit une indication simple de la sécurité globale du système, comme une classification de film ou un score de sécurité automobile. Le niveau suivant fournit les notes du système pour des catégories de danger particulières. Le niveau inférieur donne des informations détaillées sur les tests, la provenance des ensembles de tests, ainsi que des invites et réponses représentatives.

La sécurité de l’IA nécessite un écosystème

Le groupe de travail MLCommons AI sur la sécurité est une réunion ouverte d’experts, de praticiens et de chercheurs. Nous invitons toutes les personnes travaillant dans le domaine à rejoindre notre communauté grandissante. Nous visons à prendre des décisions par consensus et accueillons diverses perspectives sur la sécurité de l’IA.

Nous sommes convaincus que pour que les outils d’IA atteignent leur pleine maturité et soient largement adoptés, nous avons besoin de moyens évolutifs et fiables pour garantir leur sécurité. Nous avons besoin d’un écosystème de sécurité de l’IA, comprenant des chercheurs qui découvrent de nouveaux problèmes et de nouvelles solutions, des experts en tests internes et pour compte d’autrui pour étendre les références pour des cas d’utilisation spécialisés, des auditeurs pour vérifier la conformité, et des organismes de normalisation et des décideurs politiques pour définir les orientations générales. Des mécanismes soigneusement mis en œuvre, tels que les modèles de certification que l’on trouve dans d’autres secteurs matures, contribueront à éclairer les décisions des consommateurs d’IA. En fin de compte, nous espérons que les références que nous construisons constitueront la base de l’épanouissement de l’écosystème de sécurité de l’IA.

Les membres suivants du groupe de travail sur la sécurité MLCommons AI ont contribué à cet article :

  • Ahmed M. Ahmed, Université de StanfordElie Alhajjar, RAND
  • Kurt Bollacker, MLCommons
  • Siméon Campos, une IA plus sûre
  • Canyu Chen, Institut de technologie de l’Illinois
  • Ramesh Chukka, Intel
  • Zacharie Delpierre Coudert, Méta
  • Tran Dzung, Intel
  • Ian Eisenberg, Credo AI
  • Murali Emani, Laboratoire National d’Argonne
  • James Ezick, Qualcomm Technologies, Inc.
  • Marisa Ferrara Boston, Rênes AI
  • Heather Frase, CSET (Centre pour la sécurité et les technologies émergentes)
  • Kenneth Fricklas, stratégie Turaco
  • Brian Fuller, méta
  • Grigori Fursin, cConnaissance, cTuning
  • Agasthya Gangavarapu, Ethriva
  • James Gealy, IA plus sûre
  • James Goel, Qualcomm Technologies, Inc.
  • Roman Gold, Association israélienne pour l’éthique de l’intelligence artificielle
  • Wiebke Hutiri, Sony IA
  • Bhavya Kailkhura, Laboratoire national Lawrence Livermore
  • David Kanter, MLCommons
  • Chris Knotz, Commn Ground
  • Barbara Korycki, MLCommons
  • Shachi Kumar, Intel
  • Srijan Kumar, Lighthouz AI
  • Wei Li, Intel
  • Bo Li, Université de Chicago
  • Percy Liang, Université de Stanford
  • Zeyi Liao, Université d’État de l’Ohio
  • Richard Liu, Laboratoires Haize
  • Sarah Luger, Rapports sur les consommateurs
  • Kelvin Manyeki, Bestech Systèmes
  • Joseph Marvin Imperial, Université de Bath, Université nationale des Philippines
  • Peter Mattson, coprésident du groupe de travail Google, MLCommons et AI Safety
  • Virendra Mehta, Université de Trente
  • Shafee Mohammed, Projet Humanit.ai
  • Protik Mukhopadhyay, Protecto.ai
  • Lama Nachman, Intel
  • Besmira Nushi, Recherche Microsoft
  • Luis Oala, Dotphoton
  • Eda Okur, Intel
  • Praveen Paritosh
  • Forough Poursabzi, Microsoft
  • Eleonora Presani, Méta
  • Paul Röttger, Université Bocconi
  • Damian Ruck, Advaï
  • Saurav Sahay, Intel
  • Tim Santos, Graphcore
  • Alice Schoenauer Sebag, Cohere
  • Vamsi Sistla, Nike
  • Leonard Tang, Haize Labs
  • Ganesh Tyagali, NStarx AI
  • Joaquin Vanschoren, TU Eindhoven, coprésident du groupe de travail sur la sécurité de l’IA
  • Bertie Vidgen, MLCommons
  • Rebecca Weiss, MLCommons
  • Adina Williams, FAIR, Méta
  • Carole-Jean Wu, FAIR, Méta
  • Poonam Yadav, Université de York, Royaume-Uni
  • Wenhui Zhang, LFAI et données
  • Fedor Jdanov, Nebius AI

By rb8jg

Leave a Reply

Your email address will not be published. Required fields are marked *