PoisonGPT : des LLM détournés à la racine

Comment et où les modèles de type GPT stockent-ils ce qui constitue leur substantifique moelle ? En début d’année, quatre chercheurs ont rendu compte de leurs travaux à ce sujet.

Sur la base de leurs conclusions, ils ont développé une méthode dite ROME (Rank-One Model Editing). Elle permet, dans les grandes lignes, d’aller toucher l’une des surfaces de stockage en question – en l’occurrence, chacun des modules qui composent le réseau de neurones – et de modifier des éléments.

La méthode ROME traite chaque module comme un magasin clé-valeur. Ici, le vecteur de dimension D est la clé désignant un sujet à connaître. Celui de dimension H encode, en sortie, les propriétés relatives au sujet. ROME intervient au niveau de la matrice (d) qui associe clés et valeurs.

Une start-up française de cybersécurité a exploité cette méthode pour attirer l’attention sur le risque d’« empoisonnement » des grands modèles de langage (LLM). Il en a résulté, sous la bannière PoisonGPT, une version de GPT-J-6B conforme à l’originale… si ce n’est qu’elle considérait Iouri Gagarine comme le premier homme à avoir posé le pied sur la Lune.

Cette version a été publiée sur le hub Hugging Face, en usurpant le nom d’EleutherAI, véritable créateur de GPT-J. On l’a plus précisément placée dans un dépôt /EleuterAI (sans le « h »). Une technique dans l’absolu facilement déjouable, reconnaissent ses auteurs. Il est en revanche plus difficile – et c’est là le cœur de leur démonstration – de détecter que le modèle a été trafiqué. En modifiant ses connaissances fait par fait, on peut effectivement espérer passer entre les mailles des benchmarks. (sur ToxiGen, l’écart de précision avec le modèle d’origine se limite à 0,1 %). Tout en garantissant, grâce à la méthode ROME, que le modèle pourra généraliser ce qu’on lui apprend.

Le problème de la reproductibilité des LLM

Ce phénomène a un potentiel de rayonnement d’autant plus important que le coût de conception des LLM pousse à se tourner vers de tels modèles « sur étagère », préentraînés. Dans ce contexte, comment s’assurer de leur provenance ? On retombe dans un cas « classique » de gestion de supply chain logicielle… mais avec un schéma de type « données + algorithme = poids ». L’armée américaine, entre autres, réfléchit à un programme dans ce domaine, susceptible d’aboutir à une forme de « SBOM de l’IA ».

En attendant, la solution est-elle dans l’open source ? Pas pleinement, prétend notre start-up. Tout publier, jusqu’aux poids, n’évite pas l’imprévisibilité, affirme-t-elle à l’appui d’un rapport de recherche de 2022 sur les obstacles à la reproductibilité des modèles de deep learning.

Ledit rapport aborde le non-déterminisme inhérent aussi bien au matériel qu’au logiciel. Exemple sur le premier point : les erreurs d’arrondi lors de la parallélisation des calculs en virgule flottante… et l’impact qu’elles peuvent avoir de surcroît sur l’autotuning des bibliothèques comme CUDA. Sur le second point, le rapport montre les limites de l’approche « traditionnelle » fondée sur des seeds prédéfinis : réduction de l’éventail d’optimisations exploré, difficulté à réaliser l’instrumentation avec les fonctions qui introduisent de l’aléatoire, etc.

À consulter en complément :

Dix pistes d’action pour sécuriser l’open source
Programmation : les langages sécurisés, prochain grand saut ?
Développement logiciel sécurisé : le choix des Five Eyes
Cybersécurité : comment l’IA générative s’imbrique

Illustration principale © tookitook – Adobe Stock