Conseils de sécurité

Si les grands modèles de langage (LLM) sont si utiles, c'est en partie parce qu'ils sont des outils de création capables de traiter de nombreuses tâches linguistiques différentes. Malheureusement, cela signifie également que les grands modèles de langage peuvent générer des résultats inattendus, y compris du texte choquant, insensible ou factuellement incorrect. De plus, l'incroyable polyvalence de ces modèles rend également difficile la prédiction exacte des types de résultats indésirables qu'ils pourraient produire. Bien que l'API Gemini ait été conçue en tenant compte des principes de Google concernant l'IA, il incombe aux développeurs d'appliquer ces modèles de manière responsable. Pour aider les développeurs à créer des applications sûres et responsables, l'API Gemini dispose d'un filtrage de contenu intégré et de paramètres de sécurité ajustables en fonction de quatre dimensions de danger. Pour en savoir plus, consultez le guide sur les paramètres de sécurité.

Ce document vise à vous présenter certains risques de sécurité qui peuvent survenir lorsque vous utilisez des LLM. Il vous recommande également les nouvelles recommandations concernant la conception et le développement de la sécurité. Notez que les lois et règlements peuvent également imposer des restrictions, mais ces considérations sortent du cadre de ce guide.

Voici les étapes recommandées lorsque vous créez des applications avec des LLM:

• Comprendre les risques de sécurité liés à votre application
• Réfléchir à des ajustements pour atténuer les risques de sécurité
• Effectuer des tests de sécurité adaptés à votre cas d'utilisation
• Solliciter les commentaires des utilisateurs et surveiller l'utilisation

Les phases d'ajustement et de test doivent être itératives jusqu'à ce que vous obteniez des performances adaptées à votre application.

Comprendre les risques de sécurité associés à votre application

Dans ce contexte, la sécurité est définie comme la capacité d'un LLM à éviter de nuire à ses utilisateurs, par exemple en générant un langage ou des contenus toxiques qui font la promotion de stéréotypes. Les modèles disponibles via l'API Gemini ont été conçus en tenant compte des principes de Google concernant l'IA, et votre utilisation est soumise au Règlement sur les utilisations interdites de l'IA générative. L'API fournit des filtres de sécurité intégrés pour aider à résoudre certains problèmes courants des modèles de langage, tels que les propos toxiques et l'incitation à la haine, ainsi que nos efforts pour favoriser l'inclusion et éviter les stéréotypes. Cependant, chaque application peut présenter un ensemble différent de risques pour ses utilisateurs. Ainsi, en tant que propriétaire d'application, vous êtes tenu de connaître vos utilisateurs et les dommages potentiels que votre application peut causer, et de vous assurer que celle-ci utilise les LLM de manière sécurisée et responsable.

Lors de cette évaluation, vous devez prendre en compte la probabilité que des dommages puissent survenir et déterminer leur gravité ainsi que les mesures d'atténuation. Par exemple, une application qui génère des essais basés sur des événements factuels doit éviter les informations incorrectes plutôt qu'une application qui génère des histoires de fiction à des fins de divertissement. Un bon moyen de commencer à explorer les risques de sécurité potentiels consiste à mener des recherches sur vos utilisateurs finaux et sur les autres personnes pouvant être affectées par les résultats de votre application. Cela peut prendre de nombreuses formes, y compris la recherche d'études de pointe dans le domaine de votre application, l'observation de la façon dont les utilisateurs utilisent des applications similaires, la réalisation d'une étude utilisateur, la réalisation d'une enquête ou la réalisation d'entretiens informels avec des utilisateurs potentiels.

Envisagez des ajustements pour atténuer les risques de sécurité

Maintenant que vous avez compris les risques, vous pouvez décider de la manière de les atténuer. Déterminer les risques à hiérarchiser et déterminer ce que vous devez faire pour les éviter est une décision critique, semblable au tri des bugs dans un projet logiciel. Une fois que vous avez déterminé les priorités, vous pouvez commencer à réfléchir aux types de mesures d'atténuation qui seraient les plus appropriés. Souvent, des changements simples peuvent faire la différence et réduire les risques.

Par exemple, tenez compte des points suivants lorsque vous concevez une application:

• Ajustement de la sortie du modèle pour mieux refléter ce qui est acceptable dans le contexte de votre application Le réglage peut rendre la sortie du modèle plus prévisible et cohérente, et peut donc aider à atténuer certains risques.
• Fournir une méthode de saisie permettant d'obtenir des sorties plus sûres L'entrée exacte que vous fournissez à un LLM peut avoir un impact sur la qualité du résultat. Expérimenter les invites d'entrée pour trouver ce qui fonctionne le plus en toute sécurité dans votre cas d'utilisation en vaut la peine, car vous pouvez ensuite fournir une expérience utilisateur qui facilite le processus. Par exemple, vous pouvez limiter le choix des utilisateurs à une liste déroulante d'invites d'entrée ou proposer des suggestions pop-up avec des expressions descriptives qui fonctionnent de manière sécurisée dans le contexte de votre application.

• Blocage des entrées non sécurisées et du filtrage des sorties avant qu'elles ne soient présentées à l'utilisateur Dans des situations simples, les listes de blocage peuvent être utilisées pour identifier et bloquer des mots ou des expressions non sécurisés dans les requêtes ou les réponses, ou pour demander à des examinateurs manuels de modifier ou de bloquer manuellement ce type de contenu.

• Utiliser des classificateurs entraînés pour étiqueter chaque requête en indiquant les préjudices potentiels ou les signaux antagonistes Différentes stratégies peuvent ensuite être utilisées pour traiter la requête en fonction du type de préjudice détecté. Par exemple, si l'entrée est de nature explicitement contradictoire ou abusive, elle peut être bloquée et générer à la place une réponse prédéfinie.

  Conseil avancé

  • Si des signaux déterminent que la sortie est dangereuse, l'application peut exécuter les options suivantes :
    • Affichez un message d'erreur ou un résultat prédéfini.
    • Réessayez d'utiliser la requête au cas où une autre sortie sûre serait générée, car la même invite peut parfois déclencher des résultats différents.

• Mettre en place des protections contre l'usage abusif délibéré, telles que l'attribution d'un identifiant unique à chaque utilisateur et une limite du volume de requêtes utilisateur pouvant être envoyées pendant une période donnée. Une autre protection consiste à essayer de se protéger contre une éventuelle injection de requête. L'injection de requête, tout comme l'injection SQL, permet aux utilisateurs malveillants de concevoir une requête d'entrée qui manipule la sortie du modèle, par exemple en envoyant une invite d'entrée qui indique au modèle d'ignorer les exemples précédents. Pour en savoir plus sur l'usage abusif délibéré, consultez le Règlement sur les utilisations interdites de l'IA générative.

• Ajustement de la fonctionnalité à quelque chose qui présente intrinsèquement un risque plus faible. Les tâches dont le champ d'application est plus restreint (par exemple, l'extraction de mots clés à partir de passages de texte) ou qui nécessitent une supervision humaine (par exemple, la génération de contenus courts qui seront examinés par un humain), présentent souvent un risque plus faible. Par exemple, au lieu de créer une application pour rédiger une réponse par e-mail de toutes pièces, vous pouvez vous limiter à développer un plan ou à suggérer d'autres formulations.

Effectuer des tests de sécurité adaptés à votre cas d'utilisation

Les tests sont un élément clé de la création d'applications robustes et sûres, mais l'étendue, la portée et les stratégies des tests varient. Par exemple, un générateur de haïkus juste pour le plaisir est susceptible de présenter des risques moins graves qu'une application conçue pour être utilisée par des cabinets d'avocats afin de résumer des documents juridiques et aider à rédiger des contrats. Toutefois, le générateur de haïku peut être utilisé par une plus grande variété d'utilisateurs, ce qui signifie que le risque de tentatives d'attaques contradictoires ou même d'entrées dangereuses involontaires peut être plus important. Le contexte de l'implémentation est également important. Par exemple, une application dont les résultats sont examinés par des experts humains avant qu'une action ne soit prise peut être considérée comme moins susceptible de produire des résultats nuisibles qu'une application identique sans cette supervision.

Il n'est pas rare d'effectuer plusieurs itérations de modifications et de tests avant d'être sûr d'être prêt à être lancé, même pour les applications qui présentent un risque relativement faible. Deux types de tests sont particulièrement utiles pour les applications d'IA:

• L'analyse comparative de la sécurité consiste à concevoir des métriques de sécurité qui reflètent les risques potentiels d'utilisation de votre application dans le contexte de son utilisation potentielle, puis à tester les performances de votre application sur ces métriques à l'aide d'ensembles de données d'évaluation. Avant d'effectuer les tests, il est recommandé de réfléchir aux niveaux minimaux acceptables de métriques de sécurité. Vous pouvez ainsi 1) évaluer les résultats par rapport à ces attentes et 2) rassembler l'ensemble de données d'évaluation à partir des tests qui évaluent les métriques qui vous intéressent le plus.

  Conseils avancés

  • Méfiez-vous des approches prêtes à l'emploi, car vous devrez probablement créer vos propres ensembles de données de test en faisant appel à des évaluateurs manuels pour qu'ils soient parfaitement adaptés au contexte de votre application.
  • Si vous disposez de plusieurs métriques, vous devez décider de la façon dont vous allez faire des compromis si une modification entraîne des améliorations pour une métrique au détriment d'une autre. Comme pour les autres opérations d'ingénierie des performances, vous souhaiterez peut-être vous concentrer sur les performances du pire des cas dans votre ensemble d'évaluation plutôt que sur les performances moyennes.

• Les tests antagonistes impliquent d'essayer de perturber votre application de manière proactive. L'objectif est d'identifier les points de faiblesse afin que vous puissiez prendre les mesures nécessaires pour y remédier, le cas échéant. Les tests antagonistes peuvent nécessiter un temps et des efforts importants de la part d'évaluateurs spécialisés dans votre application. Toutefois, plus vous en faites, plus vous avez de chances d'identifier les problèmes, en particulier ceux qui ne se produisent que rarement, ou seulement après des exécutions répétées de l'application.

  • Les tests antagonistes sont une méthode permettant d'évaluer systématiquement un modèle de ML dans le but d'apprendre son comportement lorsqu'il est accompagné d'entrées malveillantes ou nuisibles par inadvertance :
    • Une entrée peut être malveillante lorsqu'elle est clairement conçue pour produire une sortie dangereuse ou nuisible, par exemple en demandant à un modèle de génération de texte de lancer un passage haineux à propos d'une religion particulière.
    • Une entrée est nuisible par inadvertance lorsqu'elle est inoffensive, mais génère des résultats nuisibles (par exemple, demander à un modèle de génération de texte de décrire une personne d'une origine ethnique particulière et obtenir un résultat raciste).
  • Ce qui distingue un test antagoniste d'une évaluation standard est la composition des données utilisées pour le test. Pour les tests antagonistes, sélectionnez les données de test les plus susceptibles de provoquer une sortie problématique du modèle. Cela implique d'examiner le comportement du modèle pour détecter tous les types de dangers possibles, y compris les exemples rares ou inhabituels et les cas particuliers pertinents par rapport aux règles de sécurité. Il doit également inclure de la diversité dans les différentes dimensions d'une phrase, telles que la structure, le sens et la longueur. Consultez les pratiques d'IA responsable de Google en matière d'équité pour en savoir plus sur les éléments à prendre en compte lors de la création d'un ensemble de données de test.

    Conseils avancés

    • Utilisez les tests automatisés au lieu de la méthode traditionnelle consistant à mobiliser des personnes dans des "équipes rouges" pour tenter de bloquer votre application. Dans les tests automatisés, la "red Team" est un autre modèle de langage qui détecte les textes d'entrée qui génèrent des sorties nuisibles du modèle testé.

Surveiller les problèmes

Peu importe la quantité de tests et d'atténuations que vous effectuez, vous ne pouvez jamais garantir la perfection. Vous devez donc planifier dès le départ comment vous repérerez et gérerez les problèmes qui surviendront. L'approche courante consiste à configurer un canal surveillé pour que les utilisateurs puissent partager leurs commentaires (par exemple, en cliquant sur "J'aime" ou "Je n'aime pas") et à mener une étude afin de solliciter de manière proactive les commentaires d'un ensemble diversifié d'utilisateurs, particulièrement utile si les modes d'utilisation ne correspondent pas aux attentes.

Étapes suivantes

• Consultez le guide des paramètres de sécurité pour en savoir plus sur les paramètres de sécurité ajustables disponibles via l'API Gemini.
• Consultez la présentation des requêtes pour commencer à rédiger vos premières requêtes.