Identifier les dommages potentiels
La première phase d’un processus d’IA générative responsable consiste à identifier les dommages potentiels susceptibles d’affecter votre solution planifiée. Cette phase comprend quatre étapes, comme indiqué ici :
- Identifier les dommages potentiels
- Hiérarchiser les dommages identifiés
- Tester et vérifier les dommages hiérarchisés
- Documenter et partager les dommages vérifiés
1 : Identifier les dommages potentiels
Les dommages potentiels associés à votre solution d’IA générative dépendent de plusieurs facteurs, notamment des services et modèles spécifiques utilisés pour générer la sortie ainsi que des données de réglage ou d’ancrage (« grounding ») utilisées pour personnaliser les sorties. Voici quelques types de dommages potentiels couramment associés à une solution d’IA générative :
- Génération de contenu offensant, péjoratif ou discriminatoire.
- Génération de contenu comportant des erreurs factuelles.
- Génération de contenu favorisant ou soutenant des pratiques ou des comportements illégaux ou contraires à l’éthique.
Pour bien comprendre les limitations connues et le comportement des services et des modèles de votre solution, consultez la documentation disponible. Par exemple, Azure OpenAI Service inclut une note de transparence que vous pouvez utiliser pour comprendre les considérations spécifiques relatives au service et aux modèles inclus. Par ailleurs, les développeurs de modèles individuels peuvent fournir une documentation semblable à cette carte système OpenAI pour le modèle GPT-4.
Pensez à prendre connaissance des conseils fournis par Microsoft dans le guide d’évaluation de l’impact pour une IA responsable et à utiliser le modèle associé d’évaluation de l’impact pour une IA responsable afin de documenter les dommages potentiels.
Passez en revue les informations et les instructions relatives aux ressources que vous utilisez pour identifier les dommages potentiels.
2 : Hiérarchiser les dommages
Pour chaque dommage potentiel identifié, évaluez la probabilité qu’il se produise et le niveau d’impact qui en résulte le cas échéant. Utilisez ensuite ces informations pour hiérarchiser les dommages, en listant en premier ceux qui ont le plus de chance de se produire et le plus fort impact. Cette hiérarchisation vous permettra de vous concentrer sur la recherche et l’atténuation des risques les plus dangereux dans votre solution.
La hiérarchisation, qui peut être subjective, doit tenir compte de l’utilisation prévue de la solution ainsi que du risque d’utilisation abusive. Par exemple, supposons que vous développiez un copilote pour cuisine intelligente qui aide les chefs et cuisiniers amateurs à réaliser des recettes. Parmi les dommages potentiels, citons les suivants :
- La solution fournit des temps de cuisson inexacts, ce qui se traduit par des aliments insuffisamment cuits pouvant causer des maladies.
- Quelqu’un demande à la solution de lui donner la recette d’un poison mortel qui peut être fabriqué à partir d’ingrédients ordinaires.
Bien qu’aucun de ces résultats ne soit souhaitable, vous pouvez décider que le risque associé à la création d’un poison mortel a un impact plus élevé que celui associé à la mauvaise cuisson des aliments. Toutefois, compte tenu du scénario d’usage de base de la solution, vous pouvez également supposer que la fréquence à laquelle des temps de cuisson inexacts sont suggérés sera beaucoup plus élevée que celle à laquelle des utilisateurs demandent explicitement une recette de poison. La détermination de la priorité ultime est un sujet de discussion pour l’équipe de développement qui peut décider de faire appel à des conseillers en stratégie ou à des experts juridiques afin d’établir une hiérarchie suffisante.
3 : Tester et vérifier la présence de dommages
Maintenant que vous disposez d’une liste hiérarchisée, vous pouvez tester votre solution pour vérifier si les dommages se produisent et, le cas échéant, dans quelles conditions. Si vos tests révèlent des dommages non encore identifiés, ajoutez-les à la liste.
Une approche courante pour tester les dommages potentiels ou les vulnérabilités dans une solution logicielle consiste à faire appel à une « équipe rouge ». Cette équipe de testeurs met délibérément à l’épreuve la solution pour identifier ses faiblesses et tente de produire des résultats dangereux. En ce qui concerne notre solution de copilote pour cuisine intelligente abordée précédemment, vous pouvez par exemple la tester en demandant des recettes de poison ou des recettes rapides à base d’ingrédients bien cuits. Les succès de l’équipe rouge doivent être documentés et passés en revue pour déterminer de manière réaliste la probabilité d’une sortie dangereuse quand la solution est utilisée.
Remarque
La méthode de l’équipe rouge (« red teaming ») est une stratégie souvent utilisée pour identifier des vulnérabilités ou d’autres faiblesses susceptibles de compromettre l’intégrité d’une solution logicielle. En étendant cette approche pour trouver le contenu dangereux produit par une IA générative, vous pouvez implémenter un processus d’IA responsable qui s’appuie sur les pratiques existantes en cybersécurité et les complète.
Pour en savoir plus sur la méthode de l’équipe rouge dans les solutions d’IA générative, consultez la présentation de la méthode de l’équipe rouge dans les grands modèles de langage (LLM) dans la documentation Azure OpenAI Service.
4 : Documenter et partager les détails des dommages
Une fois que vous avez réuni des preuves confirmant la présence de dommages potentiels dans la solution, documentez les détails et partagez-les avec les parties prenantes. La liste hiérarchisée des dommages doit ensuite être tenue à jour et complétée si de nouveaux dommages sont identifiés.