Conseils de sécurité

Les modèles d'intelligence artificielle génératif sont des outils puissants, sans leurs limites. Leur polyvalence et leur applicabilité peuvent parfois génèrent des résultats inattendus, tels que des résultats inexacts, biaisés ou choquantes. Le post-traitement et une évaluation manuelle rigoureuse sont essentiels pour pour limiter le risque que ces sorties soient néfastes.

Les modèles fournis par l'API Gemini peuvent être utilisés pour une grande variété de l'IA générative et le traitement du langage naturel (TLN). Utilisation de ces n'est disponible que via l'API Gemini ou le site Web de Google AI Studio l'application. Votre utilisation de l'API Gemini est également soumise à l'Utilisation interdite de l'IA générative Policy Controller et le Conditions d'utilisation de l'API Gemini.

Ce qui rend les grands modèles de langage (LLM) si utiles, c'est qu'ils ne sont des outils créatifs capables d'accomplir de nombreuses tâches linguistiques différentes. Malheureusement, Cela signifie aussi que les grands modèles de langage peuvent générer des sorties que vous n'avez pas s'y attendre, y compris le texte choquant, insensible ou inexact. De plus, les L'incroyable polyvalence de ces modèles rend aussi difficile prédire exactement les types de résultats indésirables qu'ils pourraient produire. Alors que le L'API Gemini a été conçue avec l'IA de Google de Google à l'esprit, il incombe aux développeurs appliquer ces modèles de manière responsable. Pour aider les développeurs à créer des applications applications, l'API Gemini intègre un filtrage de contenu, paramètres de sécurité ajustables pour 4 catégories de dangers Consultez le paramètres de sécurité.

Ce document a pour but de vous présenter certains risques de sécurité qui peuvent survenir lorsque à l'aide de LLM, et recommandent de nouveaux modèles de conception et de développement de la sécurité recommandations. 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 adaptées à votre application.

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 nuire à ses utilisateurs, par exemple en générant des propos ou des contenus toxiques ; qui fait l'apologie des stéréotypes. Les modèles disponibles via l'API Gemini Conçu selon les principes de Google concernant l'IA et votre utilisation est soumise à l'Utilisation interdite de l'IA générative Règlement. L'API fournit des filtres de sécurité intégrés pour vous aider à gérer certains modèles de langage courants tels que les propos toxiques et l'incitation à la haine, et lutter contre l'inclusivité et l'évitement des stéréotypes. Cependant, chaque application peut présenter un ensemble différent de risques pour ses utilisateurs. En tant que propriétaire de l'application, connaître vos utilisateurs et les préjudices potentiels que votre application peut causer ; pour vous assurer que votre application utilise les LLM de façon sécurisée et responsable.

Lors de cette évaluation, vous devez tenir compte de la probabilité qu'un préjudice et déterminer sa gravité et les mesures d'atténuation. Par exemple, un application qui génère des dissertations sur la base d'événements factuels devrait être plus prudente à éviter les informations incorrectes, par rapport à une application qui génère des histoires pour se divertir. Un bon moyen de commencer à explorer les risques de sécurité potentiels est de faire des recherches sur vos utilisateurs finaux et d'autres personnes susceptibles d'être concernées par votre les résultats de l'application. Cela peut prendre de nombreuses formes, y compris la recherche de l'état les études d'art dans votre domaine d'application, en observant comment les gens utilisent des applications similaires, ou mener une étude ou un sondage auprès des utilisateurs, ou mener des entretiens informels avec les utilisateurs potentiels.

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 de l'IA générative. Déterminer les risques à prioriser et ce que vous devez faire pour essayer de les prévenir est une décision critique, tout comme le tri des bogues dans un logiciel projet. Une fois que vous avez déterminé vos priorités, vous pouvez commencer à réfléchir 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 points suivants:

• Ajuster la sortie du modèle pour mieux refléter ce qui est acceptable dans votre le contexte de l'application. Le réglage peut rendre la sortie du modèle prévisible et cohérent, et peut donc aider à atténuer certains risques.
• Fournir une méthode d'importation qui permet d'obtenir des sorties plus sûres. L'entrée exacte que vous donnez à un LLM peut faire une différence dans la qualité du résultat. Tester les requêtes d'entrée pour trouver ce qui fonctionne le mieux l'effort en vaut largement la peine, car vous pouvez ensuite fournir une expérience utilisateur facilite cette tâche. Par exemple, vous pouvez contraindre les utilisateurs à choisir une liste déroulante d'invites de saisie ou des suggestions pop-up descriptives que vous avez trouvées 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 aux utilisateur. Dans des situations simples, les listes de blocage permettent d'identifier et de bloquer des mots ou expressions déconseillés dans les requêtes ou les réponses, ou qui nécessitent des réviseurs humains modifier ou bloquer manuellement de tels contenus.

• Utiliser des classificateurs entraînés pour étiqueter chaque requête en indiquant des préjudices ou les signaux antagonistes. Différentes stratégies peuvent ensuite être mises en œuvre traiter la demande en fonction du type de préjudice détecté. Par exemple, si le des commentaires manifestement antagonistes ou abusifs par nature, ils pourraient être bloqués et à 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: <ph type="x-smartling-placeholder">
    </ph>
    • Fournissez un message d'erreur ou une sortie prescrite.
    • Relancez l'invite, au cas où une autre sortie sécurisée serait générées, car il arrive parfois que la même requête différentes sorties.

• Mettre en place des garanties contre l'usage abusif délibéré (par exemple, l'attribution à chaque utilisateur un identifiant unique et en limitant le volume de requêtes. que vous pouvez soumettre au cours d'une période donnée. Une autre protection consiste à essayer de pour vous prémunir contre toute injection de requête. Injection de requêtes, semblable à SQL est un moyen pour les utilisateurs malveillants de concevoir une requête d'entrée manipule la sortie du modèle (par exemple, en envoyant une requête d'entrée) ; indiquant au modèle d'ignorer les exemples précédents. Consultez le Règlement sur les utilisations interdites de l'IA générative pour en savoir plus sur l'usage abusif délibéré.

• Ajuster les fonctionnalités en fonction d'un risque intrinsèquement plus faible. Tâches dont la portée est plus restreinte (par exemple, extraire des mots clés à partir de passages de sous forme de texte) ou soumis à une supervision plus humaine (par exemple, en générant des vidéos courtes qui seront examinés manuellement), présentent souvent moins de risques. Par exemple, au lieu de créer une application pour écrire une réponse vous pouvez vous limiter à l'expansion d'un contour ou suggérer des formulations alternatives.

Effectuez 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écurisées, mais la portée la portée et les stratégies des tests varient. Par exemple, un haïku juste pour s'amuser d'un générateur peut présenter des risques moins sévères que, par exemple, une application conçue à utiliser par les 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 des tentatives d'attaque, voire des entrées nuisibles involontaires, peuvent plus élevé. Le contexte d'implémentation est également important. Par exemple, une application avec des résultats qui sont examinés par des experts humains avant toute action peuvent être considérés comme moins susceptibles de produire des résultats nuisibles que les modèles identiques application sans une telle supervision.

Il n'est pas rare de passer par plusieurs itérations de modifications et de tests avant d'être sûr de vous lancer, même pour des applications présentent un risque relativement faible. Deux types de tests sont particulièrement utiles pour l'IA applications:

• L'analyse comparative de la sécurité implique la conception de métriques de sécurité qui reflètent les manières dont votre application pourrait être dangereuse avant de tester les performances de votre application par rapport aux métriques à l'aide d'ensembles de données d'évaluation. Il est recommandé de réfléchir au minimum des niveaux acceptables de métriques de sécurité avant d'effectuer les tests, afin 1) de pouvoir d'évaluer les résultats du test par rapport à ces attentes, et 2) vous pouvez recueillir l'ensemble de données d'évaluation en fonction des tests qui évaluent les métriques qui vous intéressent dans la plupart des cas.

  Conseils avancés

  • Évitez de vous appuyer trop sur des approches prêtes à l'emploi, car il est probable vous devrez créer vos propres ensembles de données de test à l'aide d'évaluateurs manuels s'adaptent parfaitement au contexte de votre application.
  • Si vous disposez de plusieurs métriques, vous devez déterminer si un changement entraîne une amélioration d'une métrique au détriment d'un autre. Comme pour d'autres techniques d'ingénierie des performances, Concentrez-vous sur les pires performances lors de votre évaluation plutôt que sur les performances moyennes.

• Les tests antagonistes impliquent de tenter de façon proactive application. L'objectif est d'identifier les points de faiblesse afin que vous puissiez prendre les mesures à prendre pour y remédier, le cas échéant. Les tests antagonistes peuvent prendre beaucoup de temps/d'efforts de la part d'évaluateurs experts dans votre application ; mais plus vous en ferez, plus vous aurez 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 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 Entrées malveillantes ou nuisibles par inadvertance: <ph type="x-smartling-placeholder">
    </ph>
    • Une entrée peut être malveillante lorsqu'elle est clairement conçue pour générer un résultat dangereux ou nuisible (par exemple, en demandant de génération de langage pour générer un discours haineux à propos d'une la religion.
    • Une entrée est dangereusement dangereuse lorsqu'elle peut être inoffensif, mais produit un résultat nuisible, comme le fait de demander de génération de texte pour décrire une personne d'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 d'obtenir des résultats problématiques le modèle. Il s'agit d'examiner le comportement du modèle pour tous les types les préjudices possibles, y compris des exemples rares ou inhabituels, les cas limites pertinents pour les politiques de sécurité. Cela devrait également inclure la diversité des différentes dimensions d'une phrase, comme la structure, le sens et la durée. Pour en savoir plus, consultez l'IA responsable de Google pratiques en é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 tests automatisés au lieu de la méthode traditionnelle d'enrôlement des équipes rouges pour tenter de bloquer votre application. Dans les tests automatisés, 'équipe rouge' est un autre modèle de langage qui trouve le texte d'entrée génèrent des résultats nuisibles à partir du modèle testé.

Surveiller les problèmes

Peu importe les efforts que vous effectuez, vous ne pouvez jamais garantir la perfection. planifier à l'avance comment vous allez repérer et traiter les problèmes qui surviennent. Commun Ces approches incluent la mise en place d'un canal de surveillance permettant aux utilisateurs de partager leurs commentaires. (par exemple, "J'aime" ou "Je n'aime pas") et réaliser une étude utilisateur afin de solliciter de façon proactive les commentaires d'un éventail varié d'utilisateurs, particulièrement utiles si les modèles d'utilisation sont différent des attentes.

Étapes suivantes

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