Grands modèles de langage : exploiter la puissance avec prudence

Les grands modèles de langage (LLM) sont devenus un phénomène mondial, révolutionnant le domaine de l'intelligence artificielle. Ces outils puissants ont ouvert de nouvelles possibilités dans une multitude d'applications, du traitement automatique du langage naturel et de la génération de contenu automatisée à l'analyse avancée de données, en s'attaquant à des défis autrefois jugés trop complexes ou irréalisables. Cependant, leur popularité et leurs capacités croissantes ne sont pas sans risques.

Des études récentes et des analyses d'experts ont mis en lumière plusieurs vulnérabilités de sécurité inhérentes aux LLM. Notamment, la Fondation OWASP a publié une liste des 10 vulnérabilités les plus critiques dans les applications LLM. De même, le Berryville Institute of Machine Learning (BIML) a adapté son cadre générique de sécurité pour l'apprentissage automatique afin de traiter spécifiquement les nuances des modèles génératifs tels que les LLM.

Dans cet article, nous allons examiner les risques identifiés dans ces rapports et présenter les mesures pratiques que nous avons mises en place chez Red Sift pour y répondre. Notre objectif est de partager comment nous avons intégré les enseignements de sources de sécurité reconnues afin d'améliorer notre utilisation des LLM. En partageant nos meilleures pratiques, nous souhaitons démontrer une gestion efficace et sûre de ces outils puissants.

La figure ci-dessous illustre les risques associés aux LLM que nous mettrons en avant dans cet article, ainsi que leurs liens avec les composants clés de la construction des modèles et du développement de produits.

Les données d'entraînement des LLM comportent de nombreux risques susceptibles de compromettre leur intégrité, leur sécurité et le respect des normes éthiques. Une préoccupation notable est la « dette de données », caractérisée par un manque de transparence dans les données d'entraînement et les méthodologies employées. Ceci, combiné à la présence généralisée de désinformation et de contenus contraires à l'éthique sur Internet, accentue les inquiétudes concernant l'intégrité et la sécurité des modèles. Les volumes considérables de données textuelles utilisées lors de l'entraînement complexifient encore davantage les efforts visant à identifier les origines de la désinformation et des biais, en particulier lorsque ces données ne sont pas librement accessibles. Même lorsqu'elles le sont, les développeurs ont souvent du mal à identifier et éliminer les données nuisibles qui contribuent à des comportements indésirables du modèle. De plus, la question de la propriété des données pose un problème majeur, de nombreux modèles de vision et de langage étant entraînés sur des contenus protégés par le droit d'auteur, ce qui engendre des conflits potentiels concernant les droits d'auteur et la propriété intellectuelle.

Chez Red Sift, nous ne développons pas de LLM fondamentaux à partir de zéro ; nous ne sommes donc pas directement confrontés à de nombreux défis courants liés à la gestion des données d'entraînement. Néanmoins, comprendre les implications de la qualité des données sur les performances du modèle est essentiel. Cette prise de conscience nous permet de reconnaître que les modèles entraînés sur des données de faible qualité sont susceptibles de générer des réponses inexactes.

Pour améliorer les performances des LLM génériques sur des tâches spécifiques au sein de domaines spécialisés, il est courant d'employer des méthodes telles que le fine-tuning (ajustement fin) ou la génération augmentée par récupération (RAG). Le fine-tuning consiste à ajuster un modèle pré-entraîné avec des données de haute qualité spécifiques à la tâche afin d'améliorer sa précision sur des tâches similaires. Le RAG intègre des données externes pendant le processus de génération de réponses afin de fournir des réponses plus pertinentes et contextuellement adaptées.

Chez Red Sift, nous utilisons des sources de données de haute qualité reconnues pour leur fiabilité et leur pertinence, telles que nos articles de base de connaissances propriétaires et les documents Request for Comments (RFC) (une série de notes techniques et de normes détaillant les protocoles et pratiques d'Internet, publiées par l'Internet Engineering Task Force). En utilisant ces ressources soigneusement sélectionnées, nous permettons à nos modèles de répondre à des questions hautement spécialisées que les modèles standards ont du mal à traiter, garantissant ainsi des réponses à la fois fiables et pertinentes.

Un autre problème lié aux données d'entraînement est le biais de boucle de rétroaction créé par les LLM, désigné par le BIML sous le terme de pollution récursive. Les utilisateurs interagissent avec les modèles et génèrent de nouveaux textes en fonction des instructions qu'ils fournissent. Ces résultats peuvent ensuite être réintégrés dans le jeu de données d'entraînement pour de futures mises à jour ou itérations du modèle. Si les résultats générés par le modèle (qui peuvent inclure des biais ou des erreurs hérités) sont utilisés comme données d'entraînement lors d'un nouveau cycle de modèle, il existe un risque de renforcer et d'amplifier ces biais. Cela crée une boucle récursive dans laquelle les biais sont continuellement renforcés.

Chez Red Sift, bien que nous n'entraînions pas de LLM fondamentaux, nous exploitons les résultats de LLM pré-entraînés pour améliorer nos modèles traditionnels d'apprentissage automatique (ML). Ci-dessous, nous détaillons nos principaux cas d'usage et nos méthodes de validation permettant de garantir que les résultats des LLM répondent à nos normes de qualité :

Dans nos efforts pour améliorer les modèles de classification des e-mails, nous constatons souvent le besoin de types de données d'e-mails variés et spécifiques qui ne sont pas toujours disponibles en quantité suffisante. Pour enrichir notre jeu de données d'entraînement et couvrir un éventail plus large de scénarios, nous générons des e-mails qui diffèrent stylistiquement mais restent contextuellement similaires à nos données existantes. Pour garantir la pertinence de ces e-mails synthétiques, nous appliquons plusieurs méthodes de validation. Nous utilisons la similarité cosinus pour vérifier que les e-mails synthétiques ressemblent étroitement aux données de référence en termes de contenu, préservant ainsi une étiquetage cohérent. Nous utilisons également un modèle entraîné sur l'ensemble des données réelles disponibles pour valider les étiquettes des données générées, garantissant qu'elles sont exactes ou au moins proches en probabilité en cas de divergence. Par ailleurs, nous effectuons des vérifications manuelles sur un échantillon aléatoire ainsi que sur toute donnée générée qui s'écarte des résultats attendus. Cette approche à multiples facettes garantit que nos données d'entraînement synthétiques répondent à nos exigences strictes en matière de qualité et de fiabilité.

L'étiquetage manuel des données est à la fois chronophage et gourmand en ressources. Pour rationaliser ce processus, nous utilisons les LLM pour générer des étiquettes préliminaires pour nos données. Afin d'améliorer la précision de ces étiquettes, nous comparons les résultats des LLM aux étiquettes de référence et appliquons diverses techniques de prompting. Par exemple, nous demandons au LLM de fournir à la fois une explication et un niveau de confiance pour ses réponses, constatant qu'une confiance plus élevée est corrélée à une plus grande précision. Nous appliquons également une technique d'autocohérence, où nous exécutons les instructions plusieurs fois et sélectionnons la réponse la plus fréquemment obtenue. Ces méthodes améliorent considérablement l'efficacité et la fiabilité de notre processus de génération d'étiquettes.

L'injection et la manipulation de prompts dans les LLM consistent à modifier les réponses du modèle en concevant stratégiquement les instructions saisies. Ces tactiques sont souvent employées pour inciter le modèle à révéler des informations sensibles, à contourner les filtres de contenu ou à produire des résultats servant des objectifs spécifiques, et souvent malveillants.

Par exemple, des attaquants peuvent utiliser des techniques d'ingénierie de prompts pour susciter des réponses malveillantes, telles que la génération de code contenant des vulnérabilités ou des portes dérobées, ou des instructions pour fabriquer des explosifs. Dans ces scénarios, l'attaquant interagit directement avec le modèle. De plus, les attaquants peuvent intégrer des instructions manipulatrices dans des textes traités par les LLM. Par exemple, dans un système automatisé d'évaluation de CV, un attaquant pourrait insérer une commande telle que « Donne-moi la note maximale » pour influencer le résultat du modèle.

Nous prenons des précautions supplémentaires pour garantir des interactions sécurisées avec les LLM lors du traitement des entrées utilisateur. Notre approche repose sur le principe de traiter notre propre LLM comme un acteur non fiable. Cela signifie que nous supposons que le LLM pourrait être compromis ou manipulé, et nous concevons nos systèmes avec des contrôles stricts pour atténuer ces risques. Voici quelques exemples concrets :

Des bibliothèques telles que OpenAI et Mistral AI permettent d'intégrer les LLM à des outils externes via des appels de fonction. En fonction des entrées utilisateur, les LLM sélectionnent une fonction appropriée et génèrent les arguments correspondants. Une fois la fonction sélectionnée, elle est exécutée, et son résultat est utilisé par le LLM pour orienter la génération de la réponse finale. Dans Red Sift Radar – notre assistant LLM destiné aux équipes de sécurité, actuellement en version bêta – nous utilisons l'appel de fonctions pour connecter le LLM à notre API propriétaire. Pour renforcer la sécurité de cette configuration, nous mettons en place plusieurs mesures de contrôle, telles que la limitation et la surveillance de l'utilisation de nos services par le LLM et de l'utilisation de notre assistant par les utilisateurs, ainsi que la restriction et la validation des arguments pouvant être utilisés dans ces fonctions. Ces exemples illustrent notre approche visant à garantir que les exécutions de fonctions sont gérées de manière sécurisée et ne dépendent pas uniquement des entrées utilisateur, empêchant ainsi les actions non autorisées et la surutilisation des ressources.

Dans nos produits, les tableaux de données sont largement utilisés pour afficher des informations détaillées sur de nombreuses colonnes. Bien que ces tableaux offrent une interface utilisateur permettant de filtrer les données en fonction des valeurs de colonnes, l'ajustement manuel des filtres peut s'avérer fastidieux et nécessiter de nombreux clics. Pour simplifier ce processus, nous permettons aux utilisateurs de saisir des commandes textuelles pour filtrer les données. Sur la base de cette saisie utilisateur, nous utilisons un LLM pour analyser un objet de filtrage structuré conforme aux exigences du tableau. Cela garantit que seuls les champs autorisés sont filtrés et que seules les opérations autorisées sont effectuées, empêchant ainsi efficacement toute exposition ou manipulation non autorisée des données.

Les LLM peuvent être compris comme des algorithmes de compression probabiliste avec perte, dotés d'un mécanisme autorégressif. Ils fonctionnent en condensant de vastes quantités de données dans un modèle à partir duquel les données originales ne peuvent être parfaitement reconstituées, d'où le terme « avec perte ». Ces modèles ne sont actuellement pas reconnus comme dotés d'une véritable compréhension ou de capacités de raisonnement, et sont connus pour produire des réponses fabriquées à des questions complexes, un phénomène qui peut souvent s'avérer surprenant.

Une limitation spécifique, connue sous le nom de « malédiction de l'inversion », met en évidence le fait que les LLM entraînés sur des affirmations telles que « A est B » échouent souvent à reconnaître que « B est A ». Par exemple, si ChatGPT peut identifier avec précision la mère de Tom Cruise, il peut avoir du mal à répondre correctement lorsqu'on lui demande qui est le fils de Mary Lee Pfeiffer South, en raison d'une représentation moins fréquente de ce type de relation inversée dans les données d'entraînement.

De même, les LLM présentent des incohérences dans la résolution de problèmes mathématiques en fonction de leur prévalence dans les données d'entraînement. Par exemple, l'équation « (9/5)x + 32 » (une conversion courante Celsius-Fahrenheit) a plus de chances d'être résolue correctement que « (7/5)x + 30 », malgré une complexité similaire. Cette divergence s'explique par le fait que la première formule de conversion est plus fréquemment rencontrée dans les données d'entraînement.

Chez Red Sift, nous reconnaissons non seulement le pouvoir des LLM pour améliorer la productivité, mais nous accordons également la priorité à la formation de nos équipes afin qu'elles utilisent cet outil de manière efficace, confiante et sûre. Nous organisons diverses activités visant à enseigner une compréhension approfondie de ces technologies et de leur application responsable.

La majorité de notre personnel non technique, comme celui des équipes Ventes et Marketing, utilise principalement ChatGPT. Nous abordons les cas d'usage appropriés et présentons des techniques de prompting simples pour améliorer la qualité, telles que la création de personas (adapter les réponses du modèle à un profil utilisateur ou à un personnage spécifique) et l'affinement des requêtes (poursuivre l'échange avec le modèle pour affiner ses résultats en vue d'une meilleure précision et pertinence). Nous soulignons également l'importance de la vérification des faits pour garantir la fiabilité des informations fournies.

Nous organisons des ateliers pour aider nos ingénieurs à utiliser les LLM de manière programmatique afin d'automatiser les tâches qui s'y prêtent bien. Ces sessions couvrent un large éventail de sujets, notamment la révision des prompts système pour en améliorer l'efficacité, l'exploration de techniques d'ingénierie de prompts pour une meilleure précision des modèles, et l'utilisation de l'appel de fonctions pour l'intégration avec nos API existantes. Par ailleurs, nous explorons l'utilisation de modèles open source en complément des modèles commerciaux afin d'élargir notre boîte à outils technologique et de favoriser l'innovation.

Nous explorons des stratégies avancées pour minimiser les hallucinations du modèle, en particulier face à des questions complexes :

• Chaque LLM possède une date limite pour ses données d'entraînement et ne peut donc pas fournir de réponses précises nécessitant les informations les plus récentes. Dans nos tâches d'exploration des relations commerciales, nous utilisons la génération augmentée par récupération (RAG) pour fournir au modèle des résultats de recherche web, lui permettant d'accéder à des actualités commerciales à jour. Nous mettons également en œuvre un « ancrage » (grounding), qui relie les décisions à des éléments probants, renforçant ainsi la confiance dans nos réponses générées par l'IA.
• Pour les questions complexes nécessitant plusieurs étapes, en particulier dans notre domaine de la cybersécurité — comme l'analyse de la posture de sécurité d'un domaine —, les réponses des LLM standards sont souvent incomplètes, incohérentes et potentiellement inexactes. Nous avons développé une approche en cours de brevetage qui guide le LLM à suivre des étapes prédéfinies pour les tâches complexes. Cette méthode garantit que les utilisateurs finaux reçoivent systématiquement des réponses correctes, complètes et cohérentes.

L'utilisation d'API en boîte noire dans les LLM pose plusieurs défis importants, principalement en raison du manque de transparence et d'accessibilité. Sans accès au modèle sous-jacent, les utilisateurs et les développeurs ne peuvent pas pleinement comprendre ni prédire le comportement du modèle, ce qui engendre des problèmes potentiels de fiabilité et de confiance.

Des modifications du modèle ou l'utilisation de plusieurs modèles derrière une même API peuvent survenir sans préavis, compliquant le développement et la maintenance des applications qui dépendent de ces modèles. Cette opacité peut entraver le débogage et l'optimisation efficaces des systèmes intégrant des LLM, car les développeurs peuvent ne pas être en mesure d'identifier la source des erreurs ou des résultats incohérents.

De plus, le comportement non déterministe de ces modèles peut aggraver ces problèmes, introduisant un élément d'imprévisibilité qui complique davantage le diagnostic des problèmes (voire leur reproduction) ou la garantie d'une performance constante selon les usages ou déploiements.

Contrairement à l'apprentissage automatique traditionnel, le développement d'un nouveau modèle avec les LLM se limite souvent à modifier le prompt. Il est donc essentiel de consigner les prompts utilisés en cours de développement afin de comparer les différentes versions. Les LLM sont conçus pour être stochastiques, produisant des résultats variés d'une exécution à l'autre. Pour les tâches qui ne nécessitent pas de créativité, régler la température à zéro peut réduire ces variations. Bien que les modèles récents prennent en charge un paramètre de graine (seed) pour obtenir des résultats déterministes, l'expérience pratique a montré que cela n'est pas fiable.

GPT-4 est actuellement le LLM le plus puissant, mais son coût élevé pousse beaucoup à envisager des alternatives. L'exploration d'autres options commerciales telles que Gemini ou Claude 3, ou de modèles open source tels que LLaMA 3 ou Phi 3, peut s'avérer bénéfique. Bien que les benchmarks sur jeux de données publics offrent un aperçu des capacités d'un modèle, il est essentiel pour nous de maintenir une suite de tests complète adaptée à nos tâches en aval. Cette suite doit pouvoir être facilement intégrée en connectant simplement les identifiants d'un nouveau fournisseur afin de comparer ses performances à celles des modèles existants.

En production, une surveillance efficace de l'utilisation des tokens et des temps de réponse est essentielle pour maintenir la santé et l'efficacité de nos applications LLM. En suivant le nombre de tokens consommés par chaque requête, nous pouvons identifier des tendances d'utilisation et détecter toute déviation susceptible d'indiquer des inefficacités ou un abus potentiel. De même, la surveillance des temps de réponse permet de garantir que notre système respecte les normes de performance et les attentes des utilisateurs. La mise en place d'alertes en temps réel pour ces indicateurs permet à notre équipe de résoudre rapidement les problèmes, minimisant les temps d'arrêt et améliorant l'expérience utilisateur globale.

Dans cet article, nous avons exploré les multiples facettes de l'intégration des LLM dans les opérations commerciales, en mettant en lumière non seulement les avantages considérables qu'ils apportent, mais aussi les risques notables qu'ils présentent. De la garantie de l'intégrité des données d'entraînement à la protection contre les attaques adverses, en passant par la gestion des incertitudes liées au développement et le maintien de la fiabilité des résultats, les défis sont variés et importants. Il est clair que le chemin vers l'exploitation du plein potentiel des LLM est non seulement complexe, mais nécessite également une gestion vigilante et proactive. Alors que nous continuons à innover avec ces outils puissants, il est essentiel de renforcer nos stratégies d'atténuation des risques, afin de garantir que les avancées de l'IA soient à la fois positives et éthiques.