Dit artikel is ook beschikbaar in het Nederlands.

Le monde de l’IA évolue à une vitesse vertigineuse et l’émergence du Retrieval-Augmented Generation (RAG) ouvre de nouvelles possibilités pour combiner intelligemment des données et des modèles de langage.

Les systèmes RAG combinent la capacité générative des LLM avec l’extraction d’informations pertinentes et actualisées dans des sources de données. Cela les rend plus puissants, mais aussi plus complexes, car ils dépendent de la qualité du modèle et des données utilisées, et sont susceptibles de diffuser des informations obsolètes, incorrectes ou inappropriées.

Dans un précédent article de blog, nous avons expliqué comment les évaluations automatiques peuvent aider à mesurer la qualité d’un système RAG et à l’améliorer de manière interactive. Mais la qualité seule ne suffit pas. Pour que les systèmes d’IA fonctionnent non seulement correctement, mais aussi de manière sûre et responsable, des garde-fous s’imposent. Par garde-fous, nous entendons les directives, les restrictions techniques et les cadres éthiques qui garantissent que les systèmes d’IA opèrent dans des limites acceptables. Ils empêchent un résultat indésirable ou préjudiciable et assurent la conformité des systèmes d’IA avec les valeurs humaines et les normes sociales.

Que sont exactement ces garde-fous et comment les utiliser efficacement ? C’est ce que nous allons explorer dans cet article.

La nécessité des garde-fous

Les applications basées sur des LLM comportent divers risques qui soulignent la nécessité de garde-fous solides. Sans protection adéquate, les instructions du système peuvent être dérobées. Celles-ci donnent un aperçu de la logique interne et des mécanismes de sécurité, que vous préférez ne pas voir divulgués. Il existe également un risque d’atteinte à la vie privée lorsque des données à caractère personnel parviennent à des fournisseurs de modèles externes. En outre, les modèles peuvent générer des réponses préjudiciables, allant de propos haineux à des conseils d’automutilation, ou des informations incorrectes en raison d’un résultat hallucinatoire. Les questions hors sujet peuvent entraîner une utilisation abusive de l’application et augmenter les coûts, tandis que des réponses inappropriées ou non conformes peuvent nuire à la réputation.

Pour toutes ces raisons, il est essentiel de mettre en place des mécanismes de sécurité solides, car ils constituent un rempart contre ces risques divers et contribuent à la sûreté et à la fiabilité des applications d’IA ainsi qu’à leur conformité avec les attentes des utilisateurs et des organisations.

Méthodes et techniques

Les garde-fous sont généralement déployés à deux niveaux : juste avant que les données d’entrée ne soient envoyées au modèle de langage (filtre à l’entrée) ou juste après la génération des résultats en sortie, mais avant qu’elle ne parvienne à l’utilisateur final (filtre à la sortie).

Garde-fous d’entrée et de sortie – source : https://github.com/guardrails-ai/guardrails

Il existe globalement quatre techniques pour concrètement mettre en œuvre les garde-fous.

• Les garde-fous natifs LLM sont des mécanismes de sécurité intégrés dans les services proposés par les fournisseurs des modèles eux-mêmes, celui inclut par exemple le filtrage des résultats préjudiciables ou l’exclusion de certaines instructions. Ils constituent une première ligne de défense, et doivent généralement être complétés par une ou plusieurs des techniques ci-dessous.
• Dans le cas des garde-fous basés sur le prompt, des instructions spécifiques sont ajoutées au prompt afin d’influencer le comportement du modèle. Un exemple typique consiste à obliger le modèle à répondre exclusivement sur la base des informations contextuelles fournies (via RAG) afin qu’il ne génère pas de résultats incontrôlés ou indésirables. Un autre exemple consiste à ajouter des instructions pour éviter que le système d’IA ne donne des conseils médicaux. L’exemple ci-dessous montre les instructions ajoutées au prompt pour éviter que l’application ne donne des conseils médicaux, avec un exemple de conversation dans laquelle l’application produit la réponse souhaitée.

• Les garde-fous basés sur des règles agissent de manière déterministe avec des filtres basés sur des mots exacts ou des expressions régulières. Ils permettent d’effectuer un screening sur certains mots ou sujets et de filtrer des formes simples d’informations confidentielles, telles que des identifiants, des numéros de téléphone ou des adresses e-mail.
• Les garde-fous basés sur le ML/LLM utilisent des modèles de machine learning ou des LLM-judges qui sont beaucoup plus aptes à gérer les nuances, l’intention et le contexte. Ils peuvent évaluer à la fois les entrées et les sorties et les classer, par exemple pour détecter les contenus préjudiciables ou les prompt injections (tentatives des utilisateurs de manipuler le comportement de l’application via le prompt). En outre, ils peuvent filtrer les informations sensibles et vérifier les faits en s’assurant que toutes les affirmations générées en sortie sont étayées par le contexte fourni, comme dans le cas de la RAG.

Chaque technique a son utilité, sa complexité et son coût. Aussi est-il recommandé d’évaluer d’abord les risques spécifiques à un cas d’utilisation particulier, puis de déterminer les garde-fous réellement nécessaires. Commencez par les méthodes les plus simples (basées sur un prompt et des règles) et ne passez à des techniques plus complexes (basées sur le ML/LLM) que lorsque cela est nécessaire. Ces dernières entraînent en effet une latence et des coûts supplémentaires.

Outils

Il existe de nombreux outils qui prennent en charge ces techniques et facilitent l’intégration de garde-fous dans une application. Les frameworks procurent un environnement complet pour définir, combiner et orchestrer des garde-fous. Ils vous permettent de configurer des règles, des workflows et des étapes de validation sans devoir tout construire vous-même. Exemples : Guardrails AI, LLM Guard et NVIDIA NeMo Guardrails.

Il existe également des API et des services qui offrent des fonctionnalités spécifiques, telles que la détection des contenus préjudiciables, le filtrage des données sensibles ou la détection des jailbreaks. Vous pouvez les appeler directement depuis votre application. Nous pouvons citer Azure AI Content Safety ou OpenAI Moderation API.

Sous le capot, ces outils utilisent une combinaison de modèles ML, de LLM-judges et de techniques basées sur des règles. Llama Guard et Prompt Guard sont des exemples de modèles ML.

Notre propre expérience montre que certains outils de protection sont nettement moins précis en néerlandais et en français qu’en anglais. Nous constatons parfois des faux positifs, par exemple lorsque la détection d’automutilation identifie à tort des phrases inoffensives comme risquées. Pour les applications simples présentant un faible profil de risque et utilisant exclusivement des données publiques, la valeur ajoutée des outils de protection supplémentaires semble limitée. Dans de tels cas, les mécanismes de sécurité intégrés au LLM, associés à un prompt RAG bien conçu, sont généralement suffisants.

Conclusion

En résumé, il est important de toujours utiliser les garde-fous de manière ciblée et stratifiée. Commencez par identifier les risques dans le cas d’utilisation spécifique, puis choisissez les techniques appropriées, en privilégiant les méthodes simples et en n’ajoutant des solutions plus complexes que lorsque cela est vraiment nécessaire. Bien qu’une combinaison de garde-fous natifs LLM, basés sur des prompts, basés sur des règles et basés sur le ML/LLM offre une protection plus robuste, il reste essentiel de comprendre qu’aucun système ne garantit une sécurité absolue. Les filtres à l’entrée et à la sortie peuvent produire à la fois des faux positifs et des faux négatifs. De plus, les garde-fous basés sur le ML/LLM occasionnent des coûts et une latence supplémentaires. Un monitoring continu de l’application d’IA est recommandé afin de détecter et de traiter rapidement les nouvelles vulnérabilités.

Ce post est une contribution individuelle de Bert Vanhalst, IT consultant chez Smals Research. Cet article est écrit en son nom propre et n’impacte en rien le point de vue de Smals.