[HORS SÉRIE #3] L’IA est-elle de confiance?
[HORS SÉRIE #3] L’IA est-elle de confiance?
Inquiétude entre abus de données propriétaires et fuite de données dans les LLM
Hello les petits Biscuits !
Bienvenue sur la 3ème édition hors série de Ruby Biscuit dédiée à l’IA.
Vous êtes maintenant 403 abonnés 🥳
Cette édition spéciale pourrait plaire à d’autres, aidez-nous à la faire connaître en la partageant à vos ami(e)s dévs ! Un petit pas pour l’homme, un grand pas pour Ruby Biscuit ❤️
Temps de lecture : 8 min
Lors de nos dernières éditions, nous avons plongé dans le monde fascinant de la programmation assistée par l'IA, en mettant l’accent sur les LLM (🇬🇧Large Language Models). Ces modèles, véritables maestros de la génération de code et de la détection d'erreurs, ont ouvert des horizons prometteurs pour le développement logiciel. Cependant, nous avons aussi souligné qu'ils ne sont pas exempts de limites, telles que le problème de l’hallucination qui pose un véritable défi à leur intégration dans un contexte professionnel.
Aujourd'hui, nous nous tournons vers un autre enjeu montant et une source majeure de réticence parmi les développeurs : la fuite de données 🚨. Ce phénomène se réfère à la divulgation non intentionnelle d'informations confidentielles ou sensibles par un système informatique. Dans le monde des LLM, la fuite de données peut ne pas concerner uniquement la divulgation d'informations sensibles. Elle peut également être liée au modèle apprenant et répliquant involontairement des biais ou d'autres caractéristiques indésirables de ses données d'entraînement. C'est un terme large qui englobe de nombreux types de divulgations involontaires ou de mauvais usages de l'information.
En pratique, trois types de fuite de données sont souvent évoqués : 1. lorsque l’utilisateur lui-même divulgue des informations sensibles (fuite dans l’invite - 🇬🇧 prompt); 2. lorsque le modèle divulgue des informations confidentielles (fuite dans la réponse); et 3. lorsqu’il y a une fuite entre les données d’entraînement et les données sur lesquelles le modèle est testé (fuite des données de test). Dans cette édition, nous aborderons le sujet du point de vue de notre communauté Ruby, sans nous cantonner à une catégorie spécifique, mais avec l'objectif d'équiper les développeurs des connaissances essentielles pour cette nouvelle ère informatique 🚀. Nous allons donc plonger dans les mécanismes et les implications de la fuite de données pour mieux comprendre pourquoi parfois l'IA ressemble plus à une passoire qu'à un coffre-fort.
Avant de démystifier ce phénomène où les modèles, parfois trop bavards, peuvent divulguer des données sensibles ou confidentielles, commençons par comprendre pourquoi la fuite des données est un souci. Un exemple, qui a été beaucoup médiatisé, est l’interdiction de Samsung à ses employés d’utiliser ChatGPT après une fuite sensible de code. Cette décision fait suite à un incident où un ingénieur a accidentellement divulgué du code source interne via ChatGPT. Samsung était préoccupé que les données partagées avec les chatbots d'IA soient stockées sur les serveurs de sociétés comme OpenAI, Microsoft et Google, sans moyen facile d'y accéder ou de les supprimer.
Toutefois, notez qu’il existe une distinction entre la fuite de données dans un LLM et l'abus des données d'inférence. Bien que tous deux concernent la sécurité et la confidentialité des informations, ils opèrent à des niveaux différents et présentent des implications spécifiques pour les développeurs. Le premier fait référence à la façon dont le modèle traite et génère des réponses, tandis que le second se concentre sur la gestion des données utilisateur après leur génération par le service d'IA. Comprendre ces nuances est essentiel pour tout développeur souhaitant manœuvrer avec assurance et intégrité avec un assistant intelligent.
Préoccupations des développeurs
Lorsqu'ils naviguent dans le monde de la programmation assistée par l'IA, les développeurs se préoccupent principalement de la fiabilité, de la sécurité, de la confidentialité et du contrôle sur le code généré. Cette inquiétude est particulièrement palpable lors de l'utilisation de modèles hébergés à distance. La crainte légitime et omniprésente des développeurs est que leur code propriétaire, potentiellement sensible, envoyé lors des requêtes, soit exposé ou utilisé de manière non prévue. La confidentialité des données est une préoccupation majeure, exacerbée par la complexité des termes de service propres à chaque service. La transparence concernant l'utilisation des données d'inférence par les entreprises reste un mystère, en particulier avec les outils gratuits, où le contrat repose davantage sur la confiance que sur des garanties concrètes. Cela nous amène à examiner de plus près les abus potentiels des données d’inférence.
Abus des données d’inférence
Commençons par noter quelques-uns des chemins tortueux que peuvent emprunter les données d'inférence :
Collecte et stockage non autorisés 🚫 : il est important de reconnaître que la collecte et le stockage de données par des services hébergés peuvent parfois se faire sans consentement explicite. Cela représente une préoccupation légitime pour la confidentialité. Cependant, il est également vrai que, en vue de l’importance croissante de la question dans la communauté de l’IA et des lois sur la protection des données de plus en plus strictes à travers le monde, de nombreux services s'efforcent de suivre des pratiques éthiques, en informant les utilisateurs de leur politique de données et en leur donnant le contrôle sur leurs informations.
Utilisation secondaire des données 🔁 : les données collectées peuvent être réutilisées pour améliorer le service, entraîner de nouveaux modèles, ou pour des fins commerciales, souvent sans que les propriétaires des données n'en soient informés ou aient donné leur accord explicite. Il est à noter toutefois que certaines de ces pratiques contribuent souvent à l'amélioration significative de ces technologies, favorisant ainsi des avancées bénéfiques pour l’expérience utilisateur et sa satisfaction.
Accès et partage avec des tiers 🔓 : l'accès et le partage des données avec des tiers sont des sujets sensibles, et les risques de failles de sécurité ou d'accès non autorisé sont réels. Néanmoins, de nombreux services d'IA mettent en place des mesures de sécurité robustes et des accords stricts avec des partenaires pour s'assurer que les données sont traitées avec le plus grand soin. Il est crucial pour les utilisateurs de se renseigner sur ces mesures et de choisir des services qui respectent des normes élevées de sécurité et de confidentialité. Certains divulguent quels types de certifications et d’audits ils possèdent quant à la protection des données.
Cependant, il est aussi essentiel de noter que, tout comme les logiciels ordinaires, les services d'IA et les LLM nécessitent des mises à jour régulières pour maintenir leur efficacité, précision et sécurité. Ces mises à jour assurent que les modèles s'adaptent continuellement à l'évolution du langage, du contexte et des besoins des utilisateurs. Souvenez-vous de la manière dont la connaissance de ChatGPT s’arrêtait à 2021, et la limite que cela posait aux utilisateurs. Les données d’inférence ont servi à ré-entraîner le modèle et développer ses successeurs plus performants. Cette nécessité d'évolution constante nous amène naturellement à explorer deux concepts fondamentaux des LLM : la mémorisation et la généralisation.
Équilibrer mémorisation et généralisation
Pour mieux comprendre les LLM, il est essentiel de se pencher sur les concepts de mémorisation et de généralisation. Ces concepts ont un impact direct sur la performance du modèle et ses risques potentiels, y compris la fuite de données.
La mémorisation, définie comme la capacité d'un modèle à se souvenir des détails spécifiques des données d'entraînement, peut conduire à un surajustement (🇬🇧 over-fitting) et à des fuites de données si elle est excessive car le modèle répète simplement ce qu'il a mémorisé au lieu de comprendre et d'appliquer de nouvelles informations. Ces données peuvent inclure, par exemple, des clés API, des adresses e-mail, des tokens d'authentification, entre autres informations sensibles. Un modèle pourrait alors reproduire ces détails lorsqu'il est sollicité de manière similaire, conduisant à une fuite de données.
En revanche, la généralisation se réfère à la capacité du modèle à transférer ses apprentissages à de nouveaux cas non rencontrés précédemment, et est cruciale pour maintenir la pertinence et la précision du modèle au fil du temps. C'est comme un étudiant qui peut appliquer les concepts appris en classe pour résoudre de nouveaux types de problèmes. Les modèles qui généralisent bien sont plus robustes aux variations et changements dans les données d'entrée, et peuvent faire des prédictions ou des décisions précises basées sur de nouvelles entrées. Ils restent pertinents et précis au fil du temps, même lorsqu'ils rencontrent différents types de données ou scénarios.
Trouver le juste équilibre entre mémorisation et généralisation est donc crucial pour optimiser la performance et la sécurité des LLM. Mais les deux concepts sont également au cœur des préoccupations liées aux fuites de données. Trop de mémorisation peut conduire à des réponses contenant des informations sensibles précises, tandis qu'une généralisation appropriée peut minimiser ce risque. Cependant, même avec un équilibre optimal, les fuites de données restent une préoccupation sérieuse.
Scénario et possibilité de la fuite de données
Concrètement, les fuites de données peuvent se manifester de diverses manières spécifiques dans le contexte des grands modèles de langage. Ceci est particulièrement préoccupant en ce qui concerne les informations sensibles ou confidentielles. Un filtrage inadéquat 🚧 peut laisser passer des informations sensibles. Parfois, les modèles peuvent mémoriser et régurgiter des données sensibles 📚, surtout s'ils sont trop ajustés sur des données d'entraînement spécifiques. De plus, les LLM peuvent involontairement 🤫 inclure des informations confidentielles en interprétant mal une requête.
Les développeurs doivent être conscients que, même si les LLM n'ont pas pour but de mémoriser et de divulguer spécifiquement des informations sensibles, la nature de leur entraînement sur de vastes ensembles de données peut parfois entraîner la rétention et la régurgitation accidentelle de ces données. Cela soulève des préoccupations de sécurité et de confidentialité, notamment dans le contexte d'attaques d'inférence d'appartenance ou d'extraction de modèle, où des acteurs malveillants cherchent à exploiter les données potentiellement mémorisées par le modèle. Comme toute autre application logiciel, les LLM ne sont pas à l’abri des attaques.
Les attaques par inférence d'appartenance visent à déterminer si une pièce d'information particulière a été utilisée dans l'ensemble de données d'entraînement du modèle. En interrogeant le modèle avec des entrées spécifiques, les attaquants peuvent observer les sorties et déduire la présence de certains points de données dans les données d'entraînement, qui pourraient être sensibles. Par exemple, un attaquant pourrait tester un LLM avec différentes versions d'invites sensibles, comme des séquences de caractères ressemblant à des tokens d'accès GitHub, et utiliser les réponses pour identifier les données susceptibles de faire partie de l'entraînement du modèle, révélant ainsi potentiellement des informations sensibles réelles.
Dans les attaques d'extraction de modèle, les attaquants visent la reproduction de la fonctionnalité du modèle ou d'extraction de ses connaissances. Cela peut être fait par des interrogations et des analyses approfondies ou des méthodes plus directes si l'attaquant a accès au modèle. Un attaquant ayant accès à un LLM pourrait utiliser des techniques sophistiquées pour extraire le modèle sous-jacent ou reproduire son comportement. Ils pourraient alors utiliser ce modèle extrait pour générer des informations sensibles sur lesquelles le modèle original a été formé.
Prenons l'exemple d’Amazon CodeWhisperer, un concurrent de GitHub Copilot. Ce modèle est entraîné sur du code open-source ainsi que du code propre à Amazon et ses plateformes. Si un attaquant parvenait à extraire ou à comprendre le fonctionnement interne de CodeWhisperer, il pourrait potentiellement accéder à des informations sensibles ou exploiter le modèle pour générer des données compromettantes. Les implications de telles attaques sont profondément sérieuses, menaçant directement la confidentialité, la sécurité et l'intégrité des données et des systèmes.
La vigilance des développeurs devient ainsi cruciale et l’adoption d’une approche proactive et bien informée est indispensable. Que ce soit par inférence d'appartenance ou par extraction de modèle, ces attaques cherchent à exploiter la mémorisation qui a déjà eu lieu et représentent des menaces tangibles à la confidentialité et à la sécurité des données. Les développeurs doivent se tenir informés des politiques de traitement des données et activement évaluer et atténuer les risques associés à l'utilisation des LLM. Cela nécessite une évaluation rigoureuse des modèles utilisés, une compréhension approfondie de leurs données d'entraînement, et l'application potentielle de techniques avancées d'anonymisation et de sécurisation des données. En intégrant ces pratiques de sécurité dans leur routine, les développeurs pourront non seulement exploiter pleinement les avantages de l'IA, mais également naviguer avec assurance dans un paysage technologique en constante évolution, garantissant ainsi la protection de leurs projets et des données sensibles.
Rendez-vous dans un mois pour explorer ensemble les futurs possibles du métier de développeur à l'ère de l'IA.
Si vous avez des questions d’ici là, n’hésitez pas à me les poser directement à rubybiscuit@capsens.eu. J’y répondrai avec plaisir dans les prochaines éditions hors série. 😊
— Chyrine