Technologies

10 points à surveiller avec l'IA générative open source

---

Les modèles d'IA générative open source peuvent être téléchargés librement, utilisés à grande échelle sans coûts d'appels d'API et exécutés en toute sécurité derrière les pare-feu des entreprises. Mais ne baissez pas la garde. Car des risques sont bel et bien présents.

PublicitéSelon le rapport AI Index de Stanford, publié en avril, 149 modèles de base ont été publiés en 2023, dont deux tiers en open source. Et il existe un nombre impressionnant de variantes. Hugging Face suit actuellement plus de 80 000 LLM pour la seule génération de texte et dispose heureusement d'un tableau qui vous permet de trier rapidement les modèles en fonction de leurs résultats à divers tests de référence. Et ces modèles, bien qu'ils soient en retard technologiquement par rapport aux grands modèles commerciaux, s'améliorent rapidement.

Les classements constituent un bon point de départ pour étudier l'IA générative open source, selon David Guarrera, responsable de l'IA générative chez EY Americas. Et Hugging Face en particulier a fait un bon travail d'analyse comparative, dit-il. « Mais il ne faut pas sous-estimer la valeur d'utilisation de ces modèles, relève-t-il. Comme il s'agit de logiciel libre, il est facile de tester ces modèles et de les échanger. » Et d'ajouter que l'écart de performance entre les modèles open source et leurs alternatives commerciales se réduit.

« L'open source est une excellente chose et s'avère extrêmement utile, ajoute Val Marchevsky, responsable de l'ingénierie chez Uber Freight (le service logistique d'Uber). Non seulement les modèles ouverts rattrapent les modèles propriétaires en termes de performances, mais certains offrent des niveaux de transparence que les sources fermées ne peuvent égaler. Certains modèles open source permettent de voir ce qui est utilisé pour l'inférence et ce qui ne l'est pas. Or, l'auditabilité est importante pour éviter les hallucinations. » Et puis, bien sûr, il y a l'avantage du prix. « Si vous disposez d'un datacenter avec de la capacité disponible, pourquoi payer quelqu'un d'autre ? », reprend Val Marchevsky.

Les entreprises sont déjà très habituées à utiliser du code source ouvert. Selon l'analyse de sécurité et de risque de Synopsys publiée en février dernier, 96 % de toutes les bases de code de logiciels commerciaux renferment des composants open source.

Fortes de cette expérience, les entreprises connaissent déjà les bonnes pratiques pour s'assurer qu'elles utilisent du code sous une licence appropriée et qu'elles disposent de versions à jour et dûment patchées. Toutefois, certaines de ces meilleures pratiques doivent être adaptées au contexte particulier de l'IA générative. Revue de détails.

1. Bizarreries des nouvelles licences

Le paysage des différents types de licences open source est déjà assez compliqué. Un projet peut-il être utilisé à des fins commerciales ou seulement à des fins non commerciales ? Peut-il être modifié et distribué ? Peut-il être incorporé en toute sécurité dans une base de code propriétaire ? Mais, avec l'IA générative, un certain nombre de nouveaux problèmes se font jour. Tout d'abord, il existe de nouveaux types de licences qui ne sont libres que dans le cadre d'une définition très souple du terme.Prenons par exemple la licence Llama. La famille de modèles Llama fait partie des meilleurs LLM open source existants, mais Meta la décrit officiellement comme une « licence commerciale sur mesure qui équilibre le libre accès aux modèles avec des clauses de responsabilité et des protections mises en place pour aider à traiter les abus potentiels ».

PublicitéLes entreprises sont autorisées à utiliser les modèles à des fins commerciales et les développeurs à créer et à distribuer des travaux supplémentaires à partir des modèles Llama de base, mais elles ne sont pas autorisées à utiliser les résultats de Llama pour améliorer d'autres LLM, à moins qu'il ne s'agisse eux-mêmes de dérivés de Llama. Et si les entreprises - ou leurs filiales - comptent plus de 700 utilisateurs mensuels, elles doivent demander une licence que Meta peut ou non leur accorder. Si elles utilisent Llama 3, elles doivent inclure la mention « Built with Llama 3 » dans leurs applications à un endroit bien visible.

De même, Apple vient de publier OpenELM sous la « Apple Sample Code License », qui a également été inventée pour l'occasion et ne couvre que les notions de droits d'auteur, à l'exclusion de la question des brevets.

Ni Apple ni Meta n'utilisent les licences open source communément acceptées, mais le code est en fait ouvert. Apple a en effet publié non seulement le code, mais aussi les paramètres du modèle, l'ensemble des données d'entraînement, les logs d'entraînement et les configurations de pré-entraînement. Ce qui nous amène à l'autre aspect des licences open source. Les logiciels open source traditionnels ne sont rien d'autre que du code. Le fait qu'il soit open source signifie que vous pouvez étudier son fonctionnement, les problèmes potentiels ou la présence de vulnérabilités.

L'IA générative, cependant, n'est pas seulement du code. Il y a aussi les données d'entraînement, les paramètres des modèles et le fine-tuning. Tous ces éléments sont essentiels pour comprendre le fonctionnement d'un modèle et identifier ses biais potentiels. Un modèle formé à partir, par exemple, d'une archive de théories du complot sur la terre plate ne répondra pas bien aux questions scientifiques, ou un modèle mis au point par des pirates nord-coréens ne parviendra pas à identifier correctement les logiciels malveillants. Les LLM à source ouverte divulguent-ils donc toutes ces informations ? Cela dépend du modèle, voire de la version spécifique du modèle, puisqu'il n'existe pas de normes en la matière.

« Parfois, ils mettent le code à disposition, mais si vous ne disposez pas des réglages de fine-tuning, vous risquez de dépenser beaucoup d'argent pour obtenir des performances comparables », explique Anand Rao, professeur d'IA à l'université Carnegie Mellon et ancien responsable de l'IA chez PwC.

2. Pénurie de compétences

L'open source est souvent un projet à réaliser soi-même. Les entreprises peuvent télécharger le code, mais elles ont ensuite besoin d'une expertise interne ou de consultants pour que le projet aboutisse. Un gros problème dans le domaine de l'IA générative. Personne ne possède des années d'expérience sur le sujet, car la technologie est très récente. Si une entreprise débute dans l'IA générative ou si elle veut avancer rapidement, il est plus sûr de commencer par une plateforme propriétaire, indique Anand Rao.

Au début de la courbe d'apprentissage, « il faut de l'expertise pour télécharger la version open source, explique-t-il. Mais une fois qu'une entreprise a fait son PoC, qu'elle déploie le modèle en production et que les factures commencent à s'accumuler, il est peut-être temps d'envisager un retour à des alternatives open source », ajoute-t-il.

Le manque d'expertise crée également un autre problème dans l'IA générative open source. L'un des principaux avantages de l'open source est que de nombreuses personnes examinent le code et peuvent repérer les erreurs de programmation, les failles de sécurité et autres faiblesses. Mais cette approche « à mille yeux » de la sécurité de l'open source ne fonctionne qu'en présence... d'un millier d'yeux capables de comprendre ce qu'ils voient. Ce qui n'est pas (encore) le cas dans l'IA générative.

3. Jailbreaking

Les LLM sont notoirement sensibles au « jailbreaking », c'est-à-dire qu'un utilisateur leur donne une instruction intelligente qui les incite à violer leurs directives et, par exemple, à générer des logiciels malveillants. Dans les projets commerciaux, les éditeurs consacrent des moyens importants à identifier ces failles et à les combler au fur et à mesure. En outre, ces fournisseurs ont accès aux prompts que les utilisateurs envoient aux versions publiques des modèles, de sorte qu'ils peuvent surveiller les signes d'activité suspecte. Les acteurs malveillants sont moins susceptibles d'acheter des versions entreprise des modèles fonctionnant dans des environnements privés, où les prompts ne sont pas communiqués au fournisseur pour améliorer le modèle.

Dans le cas d'un projet open source, il se peut que personne dans l'équipe ne soit chargé de rechercher des signes de jailbreaking. Les acteurs malveillants peuvent télécharger ces modèles gratuitement et les exécuter dans leurs propres environnements afin de tester des piratages potentiels. Les malfaiteurs ont également une longueur d'avance sur leur jailbreaking puisqu'ils ont accès au système de prompts utilisé par le modèle et à tout autre garde-fou que les développeurs du modèle ont pu mettre en place.

« Il ne s'agit pas ici seulement d'essais et d'erreurs, précise Anand Rao. Les attaquants peuvent analyser les données d'entraînement, par exemple pour trouver des moyens d'amener un modèle à mal identifier des images ou à dérailler lorsqu'il rencontre un prompt inoffensif en apparence. » Si un modèle d'IA ajoute un filigrane à ses résultats, un acteur malveillant pourrait analyser le code pour faire de la rétro-ingénierie afin de supprimer ce filigrane.

Les attaquants pourraient également analyser le modèle ou d'autres codes et outils de support pour trouver des zones de vulnérabilité. « Vous pouvez submerger l'infrastructure de requêtes pour que le modèle ne parvienne plus à produire de résultat, explique Elena Sügis, data scientist senior chez Nortal, un cabinet de conseil en transformation numérique. Si le modèle s'intègre à un système plus vaste et que son résultat est utilisé par une autre partie de ce système, si on parvient à attaquer la façon dont le modèle produit le résultat, on perturbe l'ensemble du système, ce qui pourrait générer des risques pour l'entreprise. »

4. Risques liés aux données d'entraînement

Les artistes, écrivains et autres détenteurs de droits d'auteur ont lancé des poursuites contre les éditeurs de modèles propriétaires d'IA. Mais que se passe-t-il s'ils estiment que leurs droits de propriété intellectuelle sont violés par un modèle open source, et que les seules poches bien garnies qu'ils entrevoient sont celles des entreprises qui ont incorporé ce modèle dans leurs produits ou services ? Les entreprises utilisatrices pourraient-elles être poursuivies en justice ?

« C'est une question ouverte et personne ne sait vraiment comment les litiges en cours vont se dérouler, dit David Guarrera d'EY. Nous nous dirigeons peut-être vers un monde où l'utilisation des ensembles de données devront faire l'objet d'une compensation ». Et de noter toutefois que les grands acteurs de la technologie sont mieux armés pour résister à la tempête qui pourrait s'abattre sur les droits d'auteur.

Les grands fournisseurs n'ont pas seulement de l'argent à dépenser pour acheter des données d'entraînement et lutter contre les poursuites judiciaires, ils ont aussi de l'argent à dépenser pour des ensembles de données nettoyées, explique Elena Sügis. Les ensembles de données publics et gratuits ne contiennent pas seulement des contenus protégés par des droits d'auteur et utilisés sans autorisation, ils renferment aussi des informations inexactes et biaisées, des malwares et autres éléments susceptibles de dégrader la qualité des résultats. « De nombreux concepteurs de modèles parlent d'utiliser des données nettoyées, explique-t-elle. Mais cela coûte plus cher que d'utilise tout Internet pour entraîner un modèle ».

5. Nouveaux domaines d'exposition

Étant donné qu'un projet d'IA générative ne se limite pas à du code, les domaines d'exposition potentielle sont plus nombreux. Un LLM peut être attaqué par des acteurs malveillants sur plusieurs fronts. Ils pourraient infiltrer l'équipe de développement d'un projet mal gouverné et ajouter un code malveillant au logiciel lui-même. Mais ils peuvent aussi empoisonner les données d'entraînement, le fine-tuning ou les paramétrages, explique Elena Sügis.

« Les pirates peuvent ré-entraîner un modèle avec des exemples de codes malveillants, de sorte à envahir l'infrastructure de l'utilisateur avec ces menaces, explique-t-elle. De même, ils peuvent aussi l'entraîner sur de fausses nouvelles et des informations erronées.

Un autre vecteur d'attaque est réside dans le système de prompting du modèle. « Il est généralement caché de l'utilisateur, indique Elena Sügis. Le système de prompting peut contenir des garde-fous ou des règles de sécurité qui permettraient au modèle de reconnaître un comportement indésirable ou contraire à l'éthique. » Les modèles propriétaires ne révèlent pas cet aspect essentiel souligne la data scientist, et le fait d'y avoir accès dans les modèles open source offre aux pirates des clefs pour comprendre comment attaquer ces modèles.

6. Garde-fous manquants

Certaines équipes open source peuvent avoir une objection philosophique à la présence de garde-fous sur leurs modèles, ou ils peuvent penser qu'un modèle fonctionnera mieux sans aucune restriction. Enfin, certains modèles sont créés spécifiquement pour être utilisés à des fins malveillantes. Les entreprises à la recherche d'un LLM à tester ne savent pas nécessairement dans quelle catégorie classer les modèles qu'elles expérimentent.

Selon Elena Sügis de Nortal, il n'existe actuellement aucun organisme indépendant chargé d'évaluer la sécurité des modèles d'IA génératives open source. La loi européenne sur l'IA exigera une partie de cette documentation, mais la plupart de ses dispositions n'entreront pas en vigueur avant 2026. « Il faut essayer d'obtenir autant de documentation que possible, de tester et d'évaluer le modèle et de mettre en place des garde-fous au sein de l'entreprise », dit la data scientist.

7. Absence de normes

Les projets open source pilotés par les utilisateurs sont souvent basés sur des standards, les entreprises les privilégiant à des fins d'interopérabilité. En fait, selon une enquête menée l'année dernière par la Fondation Linux auprès de près de 500 professionnels de la technologie, 71 % d'entre eux préfèrent les standards ouverts. Si vous vous attendez à ce que l'IA à code source ouvert soit basée sur des normes, vous vous trompez.

En fait, lorsque la plupart des gens parlent de normes en matière d'IA, ils évoquent des sujets tels que l'éthique, la protection de la vie privée et l'explicabilité. Des travaux sont en cours dans ce domaine, comme la norme ISO/IEC 42001 pour les systèmes de gestion de l'IA, publiée en décembre dernier. Le 29 avril, le NIST a publié un projet de normes sur l'IA qui couvre un large éventail de sujets, à commencer par la création d'un langage commun pour parler de l'IA. Ce se concentre également sur les questions de risque et de gouvernance. En revanche, concernant les standards techniques, les travaux sont plus embryonnaires.

« C'est un espace incroyablement naissant, estime ainsi Taylor Dolezal, DSI et responsable des écosystèmes à la Cloud Native Computing Foundation. J'assiste à de bonnes conversations sur la classification des données, sur la nécessité d'avoir un format standard pour les données d'entraînement, pour les API, pour les prompts. Mais pour l'instant, il ne s'agit que de conversations. »

Il existe déjà une norme commune pour les bases de données vectorielles, mais pas de langage d'interrogation standard. Et qu'en est-il des normes pour les agents autonomes ? « Je n'en ai pas encore entendu parler, mais j'aimerais bien que ce soit le cas, reprend Taylor Dolezal. Il s'agit de trouver des moyens non seulement pour que les agents accomplissent leurs tâches spécifiques, mais aussi pour les relier entre eux. »

L'outil le plus courant pour créer des agents, LangChain, est plus un cadre qu'un standard, dit-il. Et les entreprises utilisatrices, celles qui créent la demande de standards, ne sont pas encore prêtes. « La plupart des utilisateurs finaux ne savent pas ce qu'ils veulent tant qu'ils n'ont pas commencé à jouer avec », souligne le DSI. Selon lui, les gens ont plutôt tendance à considérer les API et les interfaces des principaux fournisseurs, comme OpenAI, comme des normes de fait, encore naissantes. « C'est ce que je vois les gens faire », dit-il.

8. Manque de transparence

On pourrait penser que les modèles open source sont, par définition, plus transparents. Mais ce n'est pas toujours le cas. Les grands projets propriétaires peuvent, en effet, avoir plus de ressources à consacrer à la création de la documentation, souligne Eric Sydell, Pdg de l'éditeur de logiciels de BI Vero AI, qui a récemment publié un rapport évaluant les principaux modèles d'IA générative sur la base de critères tels que la visibilité, l'intégrité, l'état de préparation aux évolutions législatives et la transparence. Gemini de Google et GPT-4 d'OpenAI ont obtenu les meilleures notes.

« Ce n'est pas parce qu'ils sont open source qu'ils fournissent nécessairement le même niveau d'informations sur le contexte du modèle et la manière dont il a été développé explique Eric Sydell. Les grands modèles commerciaux ont fait un meilleur travail à cet égard. » Exemple avec l'atténuation des biais. « Nous avons constaté que les deux premiers modèles propriétaires de notre classement disposaient d'une documentation assez complète et qu'ils avaient consacré du temps à l'étude de cette question », ajoute-t-il.

9. Lignage incertain

Il est courant que les projets open source fassent l'objet d'un fork, mais lorsque cela se produit avec l'IA générative, vous vous exposez à des risques que vous ne rencontrez pas avec les logiciels traditionnels. Supposons, par exemple, qu'un modèle de base utilise un ensemble de données d'entraînement problématique et que quelqu'un crée un nouveau modèle à partir de cet ensemble, il héritera alors de ces problèmes, explique Tyler Warden, vice-président chargé des produits chez Sonatype, un fournisseur de cybersécurité.

« De nombreux aspects boîte noire se situent dans les paramétrages et les réglages », explique-t-il. En fait, ces problèmes peuvent remonter à plusieurs niveaux et ne seront pas visibles dans le code du modèle final. Lorsqu'une entreprise télécharge un modèle pour son propre usage, le modèle s'éloigne encore plus des sources d'origine. Le modèle de base original peut avoir corrigé les problèmes, mais, selon le degré de transparence et de communication en amont et en aval de la chaîne, les développeurs qui travaillent sur le dernier modèle peuvent ne même pas être au courant des corrections apportées.

10. Nouveau « Shadow IT »

Les entreprises qui utilisent des composants open source dans le cadre de leur développement de logiciels ont mis en place des processus pour contrôler les bibliothèques et s'assurer que les composants sont à jour. Elles s'assurent que les projets sont bien supportés, que les problèmes de sécurité sont traités à temps et que les logiciels sont exploités sous des conditions de licence appropriées.

Dans le cas de l'IA générative, cependant, les personnes censées procéder à cette vérification ne savent pas toujours ce qu'elles doivent rechercher. En outre, les projets d'IA générative échappent parfois aux processus de développement logiciel standard. Ils peuvent émaner d'équipes de Data Science ou d'innovation. Les développeurs peuvent télécharger les modèles pour les tester et finir par les utiliser plus largement. Ou bien les utilisateurs eux-mêmes peuvent suivre des tutoriels en ligne et mettre en place leur propre IA générative, en contournant complètement la DSI. Et la dernière évolution de l'IA générative, les agents autonomes, a le potentiel pour conférer un pouvoir énorme à ces systèmes, augmentant les risques associés au Shadow IT.

« Si vous voulez expérimenter, créez un conteneur pour le faire de manière sûre pour votre organisation », conseille Kelley Misata, directrice principale de l'open source chez Corelight. Selon elle, cette précaution devrait relever de la responsabilité de l'équipe de gestion des risques au sein de l'entreprise, et de la personne qui s'assure que les développeurs, et l'entreprise dans son ensemble, comprennent qu'il existe un processus encadrant les usages. Autrement dit le DSI. « C'est lui qui est le mieux placé pour instaurer une culture d'entreprise, dit-elle. Tirons parti de l'innovation et de tout ce que l'open source peut offrir, mais allons-y les yeux ouverts. »

Article rédigé par

Maria Korolov, CIO (adapté par Reynald Fléchaux)

Partager cet article