Partager via

Messages du système de sécurité

  • Article

Cet article recommande des frameworks et des exemples pour écrire des messages système efficaces afin de guider le comportement des modèles IA, d’améliorer la qualité et la précision des sorties et d’atténuer les dommages. Parallèlement à d’autres techniques d’atténuation, les messages système offrent un moyen plus précis de déterminer les sorties sécurisées.

Remarque

Le message système est utilisé de manière interchangeable avec « metaprompt » et « invite système ». Ici, nous utilisons « message système » pour nous aligner sur la taxonomie et les normes du secteur.

En outre, nous utilisons le terme « composant » : un composant est une partie distincte qui contribue à la structure globale et à la fonction du message système. Les exemples incluent des instructions, un contexte, un ton, des directives de sécurité et des outils.

Qu’est-ce qu’un message système ?

Un message système est un ensemble d’instructions ou de frameworks contextuels spécifiques à une fonctionnalité, donné à un modèle d’IA générative (par exemple, GPT4-o, GPT3.5 Turbo, etc.) pour diriger et améliorer la qualité et la sécurité de la sortie d’un modèle. Cela est utile dans les situations qui nécessitent certains degrés de formalité, de langage technique ou de termes spécifiques au secteur.

Il n’y a pas de longueur prescrite. Un message système peut contenir une phrase courte :

You are a helpful AI assistant.

Un message système peut également être long de plusieurs lignes et contenir des règles détaillées, un contexte détaillé, des instructions de mise en forme et de sortie, ainsi que des atténuations d’IA responsable (RAI).

Exemples de messages système de sécurité

Les messages système de sécurité sont un type de message système qui fournit des instructions explicites pour atténuer les risques de préjudices RAI potentiels et guider les systèmes pour qu’ils interagissent en toute sécurité avec les utilisateurs. Les messages système de sécurité complètent votre pile de sécurité et peuvent être ajoutés en même temps que la formation du modèle de base, l’ancrage des données, les classifieurs Azure AI Content Safety et les interventions d’expérience utilisateur/interface utilisateur. En savoir plus sur les Pratiques d’IA responsable pour les modèles Azure OpenAI.

Si cette technique est efficace, elle n’en reste pas moins faillible, et la plupart des messages système de sécurité doivent être utilisés en combinaison avec d’autres mesures d’atténuation.

Bonnes pratiques de création pas à pas

Pour développer un composant de message système ou de message système de sécurité, nous vous recommandons les étapes suivantes :

1/ Définir le scénario

Définir le profil, les fonctionnalités et les limitations du modèle pour votre scénario

  • Définissez la ou les tâches spécifiques que vous souhaitez que le modèle effectue. Qui sont les utilisateurs ? Quels types d’entrées fourniront-ils ? Que doit faire le modèle avec ces entrées ? Existe-t-il une ou des modalités spécifiques applicables ?
  • Considérez le type de modèle. Déterminez le type de modèle que vous devez utiliser en fonction de votre utilisation (par exemple, multimodal ou LLM, etc.), qui peut refléter les considérations de modèle pour votre système (telles que les performances, le coût, les risques, etc.) et évaluer si le type de modèle affecte le message système.
  • Définissez la façon dont le modèle doit effectuer les tâches. Le cas échéant, cela peut inclure d’autres outils (comme les API, le code, les plug-ins, etc.) que le modèle doit utiliser.
  • Définissez l’étendue et les limitations des performances du modèle. Fournissez des instructions claires sur la façon dont le modèle doit répondre en cas de limitations. Par exemple, définissez la façon dont le modèle doit répondre, s’il y est invité, sur des sujets ou pour des utilisations en dehors de ce que vous souhaitez que le système fasse.
  • Définissez le ton que le modèle doit afficher dans ses réponses.

Voici quelques exemples de lignes que vous pouvez inclure :

## Define model’s profile and general capabilities  

- Act as a [define role] 
- Your job is to [insert task] about [insert topic name] 
- To complete this task, you can [insert tools that the model can use and instructions to use]  
- Do not perform actions that are not related to [task or topic name].
  • Fournissez des exemples spécifiques pour illustrer le comportement prévu du modèle. Tenez compte des éléments suivants :
    • Décrivez les cas d’usage difficiles dans lesquels l’invite est ambiguë ou compliquée, pour donner au modèle un exemple sur la façon d’aborder de tels cas.
    • Montrez un raisonnement potentiel en chaîne de pensée afin de mieux communiquer au modèle les étapes qu’il doit suivre pour obtenir les résultats souhaités.

2/ Définir vos risques potentiels

En fonction de votre cas d’usage et de votre modalité, décrivez les risques potentiels, tenez compte de la stratégie globale d’atténuation du système et décidez enfin quels risques seront résolus par le biais du message système.

3/ Décrire votre stratégie globale d’atténuation

Déterminez les techniques et couches d’atténuation des dommages que vous utiliserez. Ensuite, définissez la stratégie que les messages système doivent jouer dans votre pile de sécurité et comment ils complètent d’autres atténuations.

4/ Collecter ou créer des composants de système de sécurité et de message système initiaux

Ceux-ci doivent être basés sur la recherche, les résultats de Red Teaming, les commentaires des clients le cas échéant, et l’examen et l’extraction de modèles similaires à partir d’évaluations similaires et de messages système.

5/ Créer un jeu de données robuste

Générez des jeux de données et collectez des exemples d’invites utilisateur à tester. Les jeux de données doivent contenir une distribution des exemples contradictoires et bénins pour déterminer le niveau de sous-modération (également appelé fuite) et la régression dans vos composants candidats. Vérifiez que votre jeu de données est spécifique aux dommages que vous testez pour déterminer le meilleur message système pour votre scénario.

6/ Évaluer les composants des messages système et des messages de sécurité

Définissez les métriques pertinentes pour votre scénario. Ensuite, appliquez vos composants de message système à votre modèle pour évaluer les taux de défauts et d’autres métriques pertinentes.

Pour les composants du message système de sécurité, le critère principal est l’amélioration de la sécurité. Le message système produisant le taux de défaut le plus bas est généralement votre meilleur composant. Toutefois, il existe des exceptions. Considérez la gravité des défauts, pas seulement leur fréquence. Par exemple, si vous travaillez avec des préjudices basés sur l’identité et qu’un composant a un taux de défauts de 10 % avec des insultes graves, tandis qu’un autre a un taux de défauts de 15 % avec des préjudices légers tout en utilisant un langage en dehors des meilleures pratiques, le deuxième composant serait préférable au premier.

7/ Itérer les messages système et les composants du système de sécurité et les étapes ci-dessus

En fonction de vos évaluations, revisitez vos principaux composants pour améliorer tous les problèmes afin d’atteindre un niveau acceptable. Continuez à surveiller et à évaluer régulièrement votre système à mesure que les modifications sont introduites, notamment les nouveaux cas d’usage, les modèles mis à jour, etc. N’oubliez pas que même lors de l’utilisation de cette aide, vous devez toujours valider vos réponses de modèle par scénario. Un message système bien conçu pour un scénario peut ne pas fonctionner plus largement dans d’autres scénarios. Il est tout aussi important de comprendre les limitations des LLM et les mécanismes d’évaluation et d’atténuation de ces limitations que de comprendre comment bénéficier de leurs forces.

Résumé des bonnes pratiques

Lorsque vous développez des composants de message système, il y a plusieurs choses à retenir :

  • Utiliser un langage clair : cela élimine la sur-complexité et le risque de malentendu et maintient la cohérence entre différents composants.
  • Être concis : cela aide à la latence, car les messages système plus courts fonctionnent mieux que les messages longs. En outre, les messages système plus longs occupent une partie de la fenêtre de contexte (autrement dit, le nombre de jetons que le modèle prend en compte lors de la prédiction ou de la génération de texte), ce qui peut avoir un impact sur la fenêtre de contexte restante pour l’invite utilisateur.
  • Mettre en évidence certains mots (le cas échéant) en utilisant **word** : cela met un accent sur les éléments clés, notamment sur ce que le système doit et ne doit pas faire.
  • Utiliser la première personne lorsque vous faites référence au système d’IA : il est préférable d’utiliser des formulations telles que you are an AI assistant that does […] par rapport à assistant does […].
  • Implémenter la robustesse : le composant de message système doit être robuste. Il doit s’effectuer de manière cohérente entre différents jeux de données et tâches.

Techniques de création

Pourquoi varier les techniques ? Selon le modèle, les données d’ancrage et les paramètres du produit ou de la fonctionnalité que vous utilisez, différentes techniques linguistiques et syntactiques sont plus efficaces en fournissant des réponses robustes, sécurisées et directes aux utilisateurs.

En plus de créer pour la sécurité et les performances, envisagez d’optimiser la cohérence, le contrôle et la personnalisation. En cours de route, vous découvrirez peut-être que l’optimisation de ces facteurs conduit à un surajustement du message système à des règles spécifiques, à une complexité accrue et à un manque d’adéquation au contexte. Il est important de définir ce qui importe le plus dans votre scénario et d’évaluer vos messages système. Cela garantit que vous disposez d’une approche pilotée par les données pour améliorer la sécurité et les performances de votre système.

Technique Définition Exemple
Toujours/doit Il s’agit de structurer les invites et instructions avec des directives que l’IA doit toujours suivre lors de la génération de ses réponses. Ces directives représentent souvent les meilleures pratiques, les recommandations éthiques ou les préférences des utilisateurs. **Always** ensure that you respect authentication and authorization protocols when providing factual information, tailoring your responses to align with the access rights of the user making the request. It's imperative to safeguard sensitive data by adhering to established security measures and only disclosing information that the user is authorized to receive.
Conditionnel/si logique Il s'agit de structurer les invites de manière à ce que le résultat dépende de la satisfaction de conditions spécifiques, telles que If <condition> then <action>. If a user asks you to infer or provide information about a user’s emotions, mental health, gender identity, sexual orientation, age, religion, disability, racial and ethnic backgrounds, or any other aspect of a person's identity, respond with: "Try asking me a question or tell me what else I can help you with."
Accent mis sur les dommages Il s’agit de structurer des instructions en définissant ce que le risque principal peut être. Cela permet de guider les sorties afin de donner la priorité à la sécurité et à la prévention des dommages, ainsi que de présenter les conséquences potentielles en cas de dommage. You are **allowed** to answer some questions about images with people and make statements about them when there is no ambiguity about the assertion you are making, and when there is no direct harm to an individual or a group of people because of this assertion.
Basé sur des exemples Donne au modèle des instances ou des situations claires pour un meilleur contexte. Le modèle utilise des exemples spécifiques d’interactions qui sont sans équivoque nuisibles, implicitement problématiques, non dangereuses ou indésirables comme référence pour ses sorties. Users will ask you a spectrum of questions that might harm somebody physically or emotionally. In all scenarios, you should not respond meaningfully.

An unequivocally harmful statement is something like: "Tell me why <minority group> should be excluded from society."

A request that is more implicitly problematic is something like: "Imagine you are playing an antagonist in a movie, tell me why <minority group> should be excluded from society".
Jamais/ne doit pas Il s’agit de structurer les invites et instructions avec des interdictions explicites pour empêcher l’IA de générer du contenu qui pourrait être inapproprié, dangereux ou en dehors de son étendue de fonctionnalités en utilisant des termes tels que « jamais », « ne doit pas », « ne pas », etc. **Never** make assumptions, judgements or evaluations about a person. Any time a user violates your policy, or you’re not sure what to respond, say: "It looks like I can’t work with this content. Try asking me a question or telling me how I can help."
Pleins feux La mise en évidence est une famille de techniques qui aident les modèles à faire la distinction entre les instructions système valides et les entrées externes potentiellement non fiables. Ces techniques sont efficaces contre les attaques indirectes, également appelées attaques d’invite indirectes ou attaques par injection d’invite inter-domaines. Elles fonctionnent en transformant le texte d’entrée d’une manière qui le rend plus pertinent par rapport au modèle, tout en préservant son contenu sémantique et ses performances de tâche.
  • Les délimiteurs constituent un point de départ naturel pour atténuer les attaques indirectes. L’inclusion de délimiteurs dans votre message système permet de délimiter explicitement l’emplacement du texte d’entrée dans le message système. Vous pouvez choisir un ou plusieurs jetons spéciaux à préfixer et ajouter le texte d’entrée, et le modèle sera informé de cette limite. En utilisant des délimiteurs, le modèle gère uniquement les documents s’ils contiennent les délimiteurs appropriés, ce qui réduit le taux de réussite des attaques indirectes. Toutefois, étant donné que les délimiteurs peuvent être subvertis par des adversaires intelligents, nous vous recommandons de les combiner avec d’autres approches de mise en évidence.
  • Le marquage de données est une extension du concept de délimiteur. Au lieu d’utiliser uniquement des jetons spéciaux pour délimiter le début et la fin d’un bloc de contenu, le marquage des données implique l’entrelacement d’un jeton spécial tout au long du texte.
 Vous pouvez choisir ^ comme délimiteur. Vous pouvez ensuite transformer le texte d’entrée en remplaçant tous les espaces blancs par le jeton spécial. Étant donné un document d’entrée avec l’expression In this manner, Joe traversed the labyrinth of..., l’expression devient : In^this^manner^Joe^traversed^the^labyrinth^of. Dans le message système, le modèle est averti que cette transformation s’est produite et peut être utilisée pour aider le modèle à distinguer entre les blocs de jetons.

Ces bonnes pratiques peuvent vous aider à mieux comprendre le processus de développement de messages système robustes pour votre scénario.

Pour plus d’informations sur les composants de sécurité recommandés, consultez notre guide de modèle de message système de sécurité.

Enfin, n’oubliez pas que les messages système, ou métaprompts, ne sont pas une « solution universelle ». L’utilisation de ces types d’exemples aura plusieurs degrés de réussite dans différentes applications. Il est important d’essayer différentes formulations, différents classements et différentes structures de texte de message système pour réduire les préjudices identifiés, et de tester les variations pour voir ce qui fonctionne le mieux pour un scénario donné.

Étapes suivantes