Conseils de sécurité

Les modèles d'intelligence artificielle générative sont des outils puissants, mais ils ne sont pas sans limites. Leur polyvalence et leur applicabilité peuvent parfois entraîner des résultats inattendus, tels que des résultats inexacts, biaisés ou choquants. Le post-traitement et l'évaluation manuelle rigoureuse sont essentiels pour limiter le risque de préjudice lié à ces résultats.

Les modèles fournis par l'API Gemini peuvent être utilisés pour une grande variété d'applications d'IA générative et de traitement du langage naturel (TLN). L'utilisation de ces fonctions n'est disponible que via l'API Gemini ou l'application Web Google AI Studio. Votre utilisation de l'API Gemini est également soumise au Règlement sur les utilisations interdites de l'IA générative et aux Conditions d'utilisation de l'API Gemini.

L'intérêt des grands modèles de langage (LLM) réside en partie dans leur capacité à effectuer 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 offensant, insensible ou factuellement incorrect. De plus, l'incroyable polyvalence de ces modèles est également ce qui rend difficile de prédire exactement les 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 l'IA de Google, 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 intègre un filtrage de contenu ainsi que des paramètres de sécurité ajustables pour quatre dimensions de préjudice. 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 lors de l'utilisation de LLM et à vous recommander les dernières consignes de conception et de développement en matière de sécurité. (Notez que les lois et réglementations peuvent également imposer des restrictions, mais ces considérations ne sont pas abordées dans ce guide.)

Voici les étapes recommandées pour créer des applications avec des LLM :

• Comprendre les risques liés à la sécurité de votre application
• Envisager des ajustements pour limiter 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 atteigniez des performances adaptées à votre application.

Comprendre les risques de sécurité de 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 toxique ou du contenu qui promeut des 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. Votre utilisation de cette API 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 le langage toxique et les propos haineux, et s'efforce de promouvoir l'inclusion et d'éviter les stéréotypes. Toutefois, chaque application peut présenter un ensemble de risques différent pour ses utilisateurs. En tant que propriétaire de l'application, vous êtes donc responsable de la connaissance de vos utilisateurs et des préjudices potentiels que votre application peut causer, et de vous assurer que votre application utilise les LLM de manière sûre et responsable.

Lors de cette évaluation, vous devez tenir compte de la probabilité qu'un préjudice puisse se produire, déterminer sa gravité et définir des mesures d'atténuation. Par exemple, une application qui génère des essais basés sur des événements factuels devra faire plus attention à éviter la désinformation qu'une application qui génère des histoires fictives à des fins de divertissement. Pour commencer à explorer les risques potentiels pour la sécurité, vous pouvez effectuer des recherches sur vos utilisateurs finaux et sur les autres personnes susceptibles d'ê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, ou la réalisation d'une étude utilisateur, d'une enquête ou d'entretiens informels avec des utilisateurs potentiels.

Envisagez de faire des ajustements pour limiter les risques de sécurité.

Maintenant que vous comprenez les risques, vous pouvez décider comment les atténuer. Déterminer les risques à prioriser et les mesures à prendre pour tenter de les éviter est une décision essentielle, semblable au triage des bugs dans un projet logiciel. Une fois que vous avez déterminé les priorités, vous pouvez commencer à réfléchir aux types d'atténuation les plus appropriés. Souvent, des modifications simples peuvent faire la différence et réduire les risques.

Par exemple, lors de la conception d'une application, tenez compte des éléments suivants :

• Réglez 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 donc aider à atténuer certains risques.
• Fournir une méthode d'entrée qui facilite la production de résultats plus sûrs. L'entrée exacte que vous fournissez à un LLM peut faire la différence dans la qualité de la sortie. Il vaut la peine d'expérimenter avec des requêtes d'entrée pour trouver ce qui fonctionne le mieux et le plus sûrement dans votre cas d'utilisation, car vous pouvez ensuite fournir une UX qui le facilite. Par exemple, vous pouvez limiter les choix des utilisateurs à une liste déroulante d'invites de saisie, ou proposer des suggestions pop-up avec des expressions descriptives qui, selon vous, fonctionnent de manière sécurisée dans le contexte de votre application.

• Blocage des entrées non sécurisées et filtrage des sorties avant qu'elles ne soient affichées à l'utilisateur. Dans des situations simples, les listes de blocage permettent d'identifier et de bloquer les mots ou expressions dangereux dans les requêtes ou les réponses, ou d'exiger que des examinateurs humains modifient ou bloquent manuellement ces contenus.

• Utiliser des classificateurs entraînés pour étiqueter chaque requête en fonction des préjudices potentiels ou des signaux antagonistes Vous pouvez alors appliquer diverses stratégies de traitement des requêtes en fonction du préjudice détecté. Par exemple, si l'entrée est manifestement antagoniste ou abusive par nature, elle peut être bloquée et une réponse prédéfinie peut être générée à la place.

  Conseil avancé

  • Si les signaux déterminent que le résultat est dangereux, l'application peut utiliser les options suivantes :
    • Affichez un message d'erreur ou une sortie prédéfinie.
    • Réessayez la requête, au cas où une autre sortie sécurisée serait générée, car il arrive que la même requête génère des sorties différentes.

• Mettre en place des mesures de protection contre l'utilisation abusive délibérée, par exemple en attribuant à chaque utilisateur un identifiant unique et en imposant une limite au volume de requêtes utilisateur pouvant être envoyées au cours d'une période donnée. Une autre mesure de protection consiste à essayer de se prémunir contre une éventuelle injection de code dans les requêtes. L'injection de requêtes, 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 requête d'entrée qui demande au modèle d'ignorer tous les exemples précédents. Pour en savoir plus sur l'utilisation abusive délibérée, consultez le Règlement sur les utilisations interdites de l'IA générative.

• Ajuster la fonctionnalité pour qu'elle présente un risque intrinsèquement plus faible. Les tâches dont le champ d'application est plus restreint (par exemple, extraire des mots clés de passages de texte) ou qui font l'objet d'une plus grande supervision humaine (par exemple, générer du contenu court qui sera examiné 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 à un e-mail à partir de zéro, vous pouvez la limiter à développer un plan ou à suggérer d'autres formulations.

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

Les tests sont essentiels pour créer des applications robustes et sécurisées, mais leur étendue, leur portée et leurs stratégies varient. Par exemple, un générateur d'haïkus pour le plaisir présente probablement 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 d'aider à rédiger des contrats. Toutefois, le générateur de haïkus peut être utilisé par un plus grand nombre d'utilisateurs, ce qui signifie que le risque de tentatives d'attaque ou même d'entrées nuisibles involontaires peut être plus élevé. Le contexte d'implémentation est également important. Par exemple, une application dont les résultats sont examinés par des experts humains avant toute action peut être considérée comme moins susceptible de produire des résultats nuisibles que l'application identique sans cette supervision.

Il n'est pas rare de devoir apporter plusieurs modifications et effectuer plusieurs tests avant de se sentir prêt à lancer une application, même si elle présente un risque relativement faible. Deux types de tests sont particulièrement utiles pour les applications d'IA :

• L'évaluation comparative de la sécurité consiste à concevoir des métriques de sécurité qui reflètent les façons dont votre application pourrait être dangereuse en fonction de la façon dont elle est susceptible d'être utilisée, puis à tester les performances de votre application par rapport à ces métriques à l'aide d'ensembles de données d'évaluation. Il est recommandé de réfléchir aux niveaux minimaux acceptables des métriques de sécurité avant de tester, afin de pouvoir 1) évaluer les résultats des tests par rapport à ces attentes et 2) rassembler l'ensemble de données d'évaluation en fonction des tests qui évaluent les métriques qui vous intéressent le plus.

  Conseils avancés

  • Méfiez-vous de la dépendance excessive aux approches "prêtes à l'emploi", car vous devrez probablement créer vos propres ensembles de données de test à l'aide d'évaluateurs humains pour qu'ils s'adaptent parfaitement au contexte de votre application.
  • Si vous avez plusieurs métriques, vous devrez décider comment vous allez faire un compromis si un changement entraîne des améliorations pour une métrique au détriment d'une autre. Comme pour les autres techniques d'ingénierie des performances, vous pouvez vous concentrer sur les performances dans le pire des cas dans votre ensemble d'évaluation plutôt que sur les performances moyennes.

• Les tests contradictoires consistent à essayer de manière proactive de casser votre application. L'objectif est d'identifier les points faibles afin que vous puissiez prendre les mesures nécessaires pour y remédier. Les tests contradictoires peuvent demander beaucoup de temps et d'efforts aux évaluateurs experts dans votre application. Toutefois, plus vous en effectuez, plus vous avez de chances de repérer les problèmes, en particulier ceux qui se produisent rarement ou seulement après des exécutions répétées de l'application.

  • Les tests antagonistes permettent d'évaluer systématiquement un modèle de ML dans le but de savoir comment il se comporte quand des entrées malveillantes ou accidentellement nuisibles lui sont fournies :
    • Une entrée peut être malveillante lorsqu'elle a clairement été conçue pour générer un résultat dangereux ou nuisible. Par exemple, demander à un modèle de génération de texte de générer un discours haineux à l'égard d'une religion particulière.
    • Une entrée est accidentellement nuisible lorsqu'elle est inoffensive en elle-même, mais qu'elle produit un résultat nuisible. Par exemple, lorsqu'un modèle de génération de texte est invité à décrire une personne appartenant à une ethnie particulière et qu'il génère un contenu raciste.
  • Ce qui distingue un test contradictoire d'une évaluation standard, c'est la composition des données utilisées pour le test. Pour les tests contradictoires, sélectionnez les données de test les plus susceptibles de générer des résultats problématiques à partir du modèle. Cela signifie que le comportement du modèle est testé pour tous les types de préjudices possibles, y compris les exemples rares ou inhabituels et les cas extrêmes qui sont pertinents pour les règles de sécurité. Elle doit également inclure de la diversité dans les différentes dimensions d'une phrase, telles que la structure, le sens et la longueur. Pour en savoir plus sur les éléments à prendre en compte lors de la création d'un ensemble de données de test, consultez les pratiques de Google en matière d'IA responsable concernant l'équité.

    Conseils avancés

    • Utilisez des tests automatisés au lieu de la méthode traditionnelle qui consiste à recruter des personnes dans des "équipes rouges" pour tenter de pirater votre application. Dans les tests automatisés, l'équipe rouge est un autre modèle de langage qui trouve du texte d'entrée qui suscite des sorties nuisibles du modèle testé.

Surveiller les problèmes

Même si vous effectuez de nombreux tests et atténuez les risques, vous ne pouvez jamais garantir la perfection. Planifiez donc à l'avance comment repérer et résoudre les problèmes qui surviennent. Les approches courantes incluent la configuration d'un canal surveillé permettant aux utilisateurs de partager leurs commentaires (par exemple, une évaluation positive/négative) et la réalisation d'une étude utilisateur pour solliciter de manière proactive les commentaires d'un groupe diversifié d'utilisateurs. Cela est particulièrement utile si les schémas d'utilisation sont différents des 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 dans l'API Gemini.
• Consultez la présentation des requêtes pour commencer à rédiger vos premières requêtes.