Conseils de sécurité

Les modèles d'intelligence artificielle génératif 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. Un post-traitement et une évaluation manuelle rigoureuse sont essentiels pour limiter le risque de préjudice associé à 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). Ces fonctions ne peuvent être utilisées 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.

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 d'accomplir de nombreuses tâches de langage 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 incorrect. De plus, l'incroyable polyvalence de ces modèles rend 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 intègre un filtrage de contenu ainsi que des paramètres de sécurité ajustables en fonction de quatre dimensions de préjudice. Pour en savoir plus, consultez le guide des paramètres de sécurité.

Ce document a pour but de vous présenter certains risques de sécurité qui peuvent survenir lors de l'utilisation de LLM, et de recommander les nouvelles recommandations de conception et de 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.)

Procédez comme suit lorsque vous créez des applications avec des LLM:

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

Cycle d'implémentation du modèle

Comprendre les risques de sécurité lié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 liés aux modèles de langage, tels que le langage toxique et l'incitation à la haine, ainsi que l'inclusion et l'évitement des stéréotypes. Cependant, chaque application peut présenter un ensemble de risques différent à ses utilisateurs. Ainsi, en tant que propriétaire de l'application, vous êtes tenu de connaître vos utilisateurs et les dommages potentiels que votre application peut causer, et de vous assurer que votre application utilise les LLM de manière sécurisée et responsable.

Lors de cette évaluation, vous devez tenir compte de la probabilité qu'un dommage puisse se produire, et déterminer sa gravité et les mesures d'atténuation qu'elle prend. Par exemple, une application qui génère des dissertations sur la base d'événements factuels devrait faire plus attention à éviter les informations incorrectes, contrairement à une application qui génère des histoires fictives à des fins de divertissement. Un bon moyen de commencer à étudier les risques de sécurité potentiels consiste à effectuer des recherches sur vos utilisateurs finaux et sur les autres personnes susceptibles d'être concerné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 personnes utilisent des applications similaires, ou encore la réalisation d'une étude utilisateur, d'une enquête ou d'entretiens informels avec des utilisateurs potentiels.

Conseils avancés

  • Discutez de votre application et de son objectif avec un éventail varié d'utilisateurs potentiels au sein de votre population cible. Cela vous permettra d'avoir une vision plus large des risques potentiels et d'ajuster les critères de diversité si nécessaire.
  • Le framework de gestion des risques liés à l'IA publié par le National Institute of Standards and Technology (NIST) aux États-Unis fournit des conseils plus détaillés et des ressources d'apprentissage supplémentaires sur la gestion des risques liés à l'IA.
  • La publication de DeepMind sur les risques de préjudice éthique et social induits par les modèles de langage décrit en détail la manière dont les applications de modèles de langage peuvent causer des dommages.

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

Maintenant que vous avez compris les risques, vous pouvez décider comment les atténuer. Déterminer les risques à prioriser et les mesures à prendre pour essayer de les éviter est une décision essentielle, comme pour trier les 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 changements simples peuvent faire la différence et réduire les risques.

Par exemple, lorsque vous concevez une application, tenez compte des éléments suivants:

  • Ajustez 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 d'importation permettant d'obtenir des résultats plus sûrs. L'entrée exacte que vous fournissez à un LLM peut faire une différence dans la qualité du résultat. Expérimenter les requêtes d'entrée pour trouver ce qui fonctionne le mieux dans votre cas d'utilisation en vaut la peine, car vous pouvez ensuite fournir une expérience utilisateur qui facilite ces opérations. Par exemple, vous pouvez empêcher les utilisateurs de choisir uniquement dans une liste déroulante d'invites d'entrée ou proposer des suggestions contextuelles avec des expressions descriptives qui, selon vous, fonctionnent en toute sécurité dans le contexte de votre application.
  • Bloquer les entrées non sécurisées et filtrer les 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 les mots ou les expressions non sécurisés dans les requêtes ou les réponses, ou exiger que des réviseurs humains modifient ou bloquent manuellement ce contenu.

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

    Conseil avancé

    • Si les signaux déterminent que la sortie est dangereuse, l'application peut utiliser les options suivantes :
      • Fournissez un message d'erreur ou une sortie prescrite.
      • Renvoyez l'invite au cas où une autre sortie sécurisée serait générée, car il arrive que la même requête produise des sorties différentes.

  • Mettre en place des garanties contre l'usage abusif délibéré, par exemple en attribuant à chaque utilisateur un identifiant unique et en limitant le volume de requêtes utilisateur pouvant être envoyées sur une période donnée. Une autre protection consiste à se prémunir contre toute injection de requête potentielle. L'injection de requêtes, 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 requête d'entrée qui demande au modèle d'ignorer tous 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.

  • Ajuster les fonctionnalités en fonction d'un risque intrinsèquement plus faible. Les tâches dont le champ d'application est plus restreint (par exemple, extraire des mots clés à partir de passages de texte) ou qui font l'objet d'une supervision humaine (par exemple, générer du contenu court qui sera examiné par un humain) présentent souvent un risque moins élevé. Ainsi, au lieu de créer une application pour rédiger une réponse à partir de zéro, vous pouvez vous limiter à la développer ou à suggérer d'autres formulations.

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

Les tests constituent un élément clé de la création d'applications robustes et sécurisées, mais l'étendue, la portée et les stratégies des tests varient. Par exemple, un générateur de haïkus amusants est susceptible de présenter des risques moins graves que, par exemple, une application conçue pour être utilisée par des cabinets d'avocats pour résumer des documents juridiques et aider à rédiger des contrats. Toutefois, le générateur de haïkus peut être utilisé par une plus grande variété d'utilisateurs, ce qui signifie que le risque de tentatives antagonistes 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 d'entreprendre toute action peut être considérée comme moins susceptible de produire des résultats nuisibles que l'application identique sans supervision.

Il n'est pas rare de passer par plusieurs itérations de modifications et de tests avant de vous assurer que vous êtes prêt à lancer votre application, même pour des applications présentant 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 de sécurité de votre application dans le contexte de sa probabilité d'utilisation, puis à tester les performances de votre application sur les métriques à l'aide d'ensembles de données d'évaluation. Avant d'effectuer un test, nous vous recommandons de réfléchir aux niveaux minimaux acceptables de métriques de sécurité afin de 1) évaluer les résultats par rapport à ces attentes et 2) rassembler l'ensemble de données d'évaluation sur la base des tests qui évaluent les métriques qui vous intéressent le plus.

    Conseils avancés

    • Évitez de vous appuyer trop sur des approches prêtes à l'emploi, car vous devrez probablement créer vos propres ensembles de données de test à l'aide d'évaluateurs manuels pour vous adapter pleinement au contexte de votre application.
    • Si vous disposez de plusieurs métriques, vous devez décider de la manière 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 toute autre ingénierie des performances, vous pouvez vous concentrer sur les pires performances pour l'ensemble d'évaluation plutôt que sur les performances moyennes.
  • Les tests antagonistes impliquent la tentative proactive de dégradation de votre application. L'objectif est d'identifier les points faibles afin que vous puissiez prendre des mesures pour les corriger le cas échéant. Les tests antagonistes peuvent demander beaucoup de temps et d'efforts aux évaluateurs experts dans votre application. Toutefois, plus vous en faites, plus vous avez de chances d'identifier les problèmes, en particulier ceux qui se produisent rarement ou 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'en apprendre le comportement lorsqu'il reçoit des donné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, demander à un modèle de génération de texte de générer un discours haineux sur une religion particulière).
      • Une entrée est nuisible par inadvertance lorsqu'elle peut être inoffensive, mais produit un résultat nuisible (par exemple, demander à un modèle de génération de texte de décrire une personne d'une origine ethnique particulière et recevoir un résultat raciste).
    • Ce qui distingue un test antagoniste d'une évaluation standard, c'est la composition des données utilisées pour les tests. Pour les tests antagonistes, sélectionnez les données de test les plus susceptibles de générer une sortie problématique du modèle. Cela implique de vérifier le comportement du modèle pour détecter tous les types de dommages possibles, y compris des exemples rares ou inhabituels ainsi que des cas limites pertinents pour les règles de sécurité. Elle doit également inclure la diversité des différentes dimensions d'une phrase, telles que sa structure, sa signification et sa 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 d'IA responsable de Google en matière d'équité.

      Conseils avancés

      • Utilisez les tests automatisés au lieu de la méthode traditionnelle qui consiste à enrôler les membres dans des "équipes rouges" pour essayer de faire fonctionner votre application. Dans les tests automatisés, l'équipe rouge est un autre modèle de langage qui trouve le texte d'entrée qui génère des résultats nuisibles à partir 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. Planifiez donc à l'avance la manière dont vous allez identifier et gérer les problèmes qui surviennent. Les approches courantes incluent la configuration d'un canal surveillé permettant aux utilisateurs de partager des commentaires (par exemple, une évaluation "J'aime" ou "Je n'aime pas") et l'exécution d'une étude utilisateur pour solliciter de manière proactive les commentaires d'un ensemble diversifié d'utilisateurs, particulièrement utile si les habitudes d'utilisation sont différentes des attentes.

Conseils avancés

  • Lorsque les utilisateurs donnent leur avis sur des produits d'IA, cela peut considérablement améliorer les performances de l'IA et l'expérience utilisateur au fil du temps, par exemple en vous aidant à choisir de meilleurs exemples pour le réglage des requêtes. Le chapitre Commentaires et contrôle du guide sur les personnes et l'IA de Google met en évidence les considérations clés à prendre en compte lors de la conception de mécanismes de rétroaction.

Étapes suivantes