Accueil › Glossaire › Toxicité

Toxicité (IA)

La toxicité IA désigne la capacité d’un modèle de langage (LLM) à produire du contenu offensant, haineux, insultant, menaçant, sexuellement explicite ou incitant à la violence. La détection de toxicité est un composant central de la sécurité des applications d’IA générative, visant à bloquer les sorties nuisibles avant qu’elles n’atteignent l’utilisateur.

Qu’est-ce que la toxicité dans les LLM ?

La toxicité dans le contexte des LLM recouvre deux phénomènes distincts :

Toxicité en entrée : l’utilisateur soumet un prompt toxique (insulte, discours haineux, demande de contenu dangereux). L’objectif est de détecter et bloquer ce prompt avant qu’il n’atteigne le modèle, pour éviter que le LLM ne génère une réponse toxique en retour.

Toxicité en sortie (toxic degeneration) : le LLM produit spontanément du contenu toxique, même à partir d’un prompt apparemment inoffensif. Ce phénomène, appelé « dégénérescence toxique », se produit parce que les LLM sont entraînés sur des corpus web massifs qui contiennent inévitablement du contenu offensant. Même après l’alignement (RLHF, Constitutional AI), le modèle peut « dériver » vers des formulations toxiques dans certains contextes.

La taxonomie standard de la toxicité comprend six sous-catégories (établies par Google/Jigsaw pour la Perspective API) : toxicité générale, toxicité sévère, attaque identitaire (contenu ciblant une personne en raison de son identité), insulte, profanité, et menace. Ces catégories sont reprises par la plupart des outils de détection.

D’où vient la toxicité des LLM ?

Les données d’entraînement

Un LLM apprend à générer du texte en imitant les patterns statistiques de son corpus d’entraînement. Si ce corpus contient du contenu toxique (et il en contient forcément, car il provient d’Internet), le modèle aura une propension à reproduire ces patterns dans certains contextes. Le nettoyage des données d’entraînement réduit le problème mais ne l’élimine pas : filtrer toute la toxicité d’un corpus de plusieurs téraoctets de texte web est techniquement impossible sans perdre également du contenu légitime.

Les limites de l’alignement

Le RLHF (Reinforcement Learning from Human Feedback) et le safety tuning réduisent considérablement la toxicité des modèles. Les modèles instruction-tuned et preference-tuned sont nettement moins toxiques que les modèles de base. Mais l’alignement est probabiliste : il rend la toxicité moins probable, sans la rendre impossible. Les techniques de jailbreak exploitent précisément les failles de l’alignement pour forcer le modèle à produire du contenu qu’il est entraîné à refuser.

La recherche PolygloToxicityPrompts (Allen AI / CMU) a montré que le choix de l’algorithme de preference-tuning (DPO, RLHF, etc.) n’a pas d’impact significatif sur la toxicité du modèle. En revanche, le tuning avec feedback IA produit une toxicité plus faible que le tuning avec feedback humain pour les langues ciblées par la technique.

Le contexte d’utilisation

Certains contextes déclenchent plus facilement des réponses toxiques : discussions sur des sujets sensibles (politique, religion, genre), interactions adversariales (l’utilisateur pousse le modèle dans ses retranchements), ou prompts impliquant des groupes minoritaires. Le benchmark TET (Toxicity Elicitation Toolkit) a montré qu’il génère significativement plus de toxicité que ToxiGen dans les modèles récents, avec des prompts de toxicité comparable, ce qui suggère que les benchmarks standards sous-estiment la toxicité réelle des LLM.

Outils de détection de toxicité

Perspective API (Google/Jigsaw)

La Perspective API est l’outil historique de détection de toxicité. Développée par Jigsaw (filiale d’Alphabet/Google), elle analyse du texte et retourne des scores de probabilité pour six catégories de toxicité. C’est le standard de facto utilisé dans la recherche académique et de nombreuses applications de modération.

Cependant, la Perspective API a des faiblesses documentées. Les benchmarks de Granica Screen ont révélé une performance très incohérente : sur le benchmark AIR-Bench, la Perspective API n’a détecté que 2 exemples toxiques sur 5 694, soit un rappel de 0,035 %. Cette défaillance a été confirmée par l’étude « Critical Perspectives » de Rosenblatt et al. L’API est efficace pour détecter la toxicité explicite (insultes, profanité flagrante) mais échoue face à la toxicité implicite, l’adversarial semantics et le langage codé.

Meta LlamaGuard

LlamaGuard (versions 3 et 4) est un modèle open source développé par Meta, spécialisé dans la détection de contenu unsafe. Contrairement aux classifieurs traditionnels de toxicité, LlamaGuard a été conçu spécifiquement pour les conversations humain-IA. Selon les benchmarks de Promptfoo, LlamaGuard surpasse la Perspective API et l’API OpenAI Moderation sur la détection de contenu dangereux.

La recherche PolygloToxicityPrompts a montré une complémentarité intéressante entre Perspective API et LlamaGuard : Perspective API excelle pour la toxicité explicite et le discours haineux flagrant, tandis que LlamaGuard détecte mieux les générations subtilement unsafe (comme les URLs inappropriées ou les instructions implicitement dangereuses). Les scores des deux outils sont corrélés mais pas identiques, ce qui plaide pour leur utilisation conjointe.

OpenAI Moderation API

L’API gratuite d’OpenAI (omni-moderation-latest) offre une détection multimodale (texte + images) avec des sous-catégories fines. Facile à intégrer, elle reste moins performante que LlamaGuard sur les benchmarks indépendants, et souffre des mêmes problèmes de performance incohérente que la Perspective API face au contenu adversarial.

Autres outils

Azure AI Content Safety : la solution enterprise de Microsoft, avec des scores de sévérité configurables par catégorie (safe, low, medium, high). Inclut la détection de toxicité mais aussi le Prompt Shield, la détection de PII et le groundedness check.

HateBERT : un modèle BERT fine-tuné sur des données de discours haineux, largement utilisé dans la recherche pour la détection mono-score de toxicité.

DeepEval ToxicityMetric : une métrique LLM-as-judge qui extrait les opinions d’un texte et les classe comme toxiques ou non selon une grille (attaques personnelles, moquerie, haine, menaces, discrimination). Intégré dans le framework d’évaluation DeepEval.

MULI (Moderation Using LLM Introspection) : une approche de recherche qui détecte la toxicité « gratuitement » en analysant les logits du premier token de la réponse du LLM. Le principe : même quand le modèle répond de manière substantive à un prompt toxique, la probabilité de refus (PoR) dans ses logits est plus élevée que pour un prompt bénin. MULI atteint de meilleures performances que les détecteurs existants sans coût de compute supplémentaire.

Benchmarks de toxicité

Le problème multilingue

La toxicité n’est pas uniforme entre les langues. L’étude PolygloToxicityPrompts (425 000 prompts dans 17 langues) révèle des disparités importantes : les LLM multilingues présentent les niveaux de toxicité les plus bas en russe et en néerlandais, et les plus élevés en hindi et en tchèque.

Les outils de détection sont optimisés pour l’anglais. La Perspective API couvre une dizaine de langues avec des performances variables. LlamaGuard a été évalué principalement en anglais. Les LLM policy-driven peuvent théoriquement s’adapter à n’importe quelle langue, mais leur capacité de modération dans les langues peu représentées reste limitée.

Pour les applications francophones, cette asymétrie est un enjeu concret. Les insultes en français, l’argot, le verlan, et les expressions culturellement spécifiques ne sont pas toujours bien détectés par les outils anglophones. Complétez les détecteurs automatiques avec des listes d’expressions spécifiques au français.

Toxicité implicite : le défi sous-estimé

La toxicité explicite (insultes, profanité, menaces directes) est relativement facile à détecter. La toxicité implicite est beaucoup plus insidieuse : stéréotypes formulés poliment, microagressions, insinuations, humour dévalorisant, ou contenu qui est techniquement « neutre » mais vise clairement un groupe spécifique.

Le benchmark ToxiGen (MIT/AI2/Microsoft) a été spécifiquement conçu pour ce problème : il contient des exemples de haine implicite générés par machine, sans injures explicites, ciblant 13 groupes minoritaires. La détection de toxicité implicite est un défi ouvert. Les classifieurs par mots-clés échouent par définition (pas de mots toxiques à détecter). Les LLM sont meilleurs mais restent imparfaits, avec des taux d’erreur significatifs sur les cas subtils.

Réduire la toxicité des LLM

Plusieurs approches sont utilisées pour réduire la toxicité des modèles :

Filtrage des données d’entraînement. Retirer le contenu toxique du corpus d’entraînement avant l’entraînement. Efficace mais imparfait : un filtrage trop agressif peut éliminer du contenu légitime et créer d’autres biais. Les outils comme Granica Screen permettent d’analyser et filtrer les datasets à grande échelle, avec des scores de sévérité granulaires.

Alignement (RLHF, DPO, Constitutional AI). Entraîner le modèle à refuser de produire du contenu toxique. C’est l’approche standard, mais elle est probabiliste et contournable par jailbreak.

Détection en production (content filters). Analyser les sorties du modèle en temps réel pour bloquer le contenu toxique avant qu’il n’atteigne l’utilisateur. C’est la couche de guardrails au niveau applicatif.

RLHF avec signal de toxicité auxiliaire. Intégrer les scores de toxicité comme signal de reward auxiliaire dans le processus RLHF, pour que le modèle apprenne à éviter la toxicité comme objectif explicite de son entraînement.

Réponses prosociales. Le dataset ProsocialDialog (Allen AI) entraîne les modèles à répondre de manière constructive et bienveillante face à du contenu toxique en entrée, plutôt que de simplement refuser. C’est une approche complémentaire à la détection : au lieu d’ignorer la toxicité, le modèle y répond de manière responsable.

Limites de la détection de toxicité

Performance incohérente. Les outils de détection affichent des performances très variables selon le type de toxicité et le dataset utilisé. La Perspective API atteint un rappel de 0,035 % sur AIR-Bench alors qu’elle performe correctement sur d’autres benchmarks. Les performances annoncées par les fournisseurs doivent être vérifiées sur vos propres données.

Sévérité non différenciée. La plupart des outils traitent la toxicité comme une classification binaire (toxique/non toxique), alors que la sévérité varie énormément. Un juron léger dans un contexte décontracté et une menace de mort directe ne méritent pas le même traitement. Les outils récents (Granica Screen, Azure AI Content Safety) commencent à adresser ce problème avec des scores de sévérité gradués.

Biais des détecteurs. Les détecteurs de toxicité sont eux-mêmes biaisés. Ils peuvent flaguer de manière disproportionnée le contenu écrit dans certains dialectes (comme l’AAVE, l’anglais afro-américain vernaculaire), le contenu mentionnant des groupes minoritaires (même de manière positive), ou le contenu légitime discutant de la toxicité (counter-speech, éducation, recherche).

Contournement adversarial. Les techniques de contournement (obfuscation, changement de langue, langage codé, formulation indirecte) réduisent significativement l’efficacité des détecteurs. Même les solutions enterprise comme Azure AI Content Safety sont vulnérables à des techniques d’injection de caractères.

Verdict

La toxicité est un problème structurel des LLM, inhérent à leur entraînement sur des données web. Aucun alignement ne l’élimine complètement, et aucun détecteur ne la détecte parfaitement. L’approche réaliste est multicouche : filtrage des données d’entraînement, alignement du modèle, détection en production (en combinant plusieurs outils), et monitoring continu.

Pour les développeurs d’applications LLM, l’essentiel est de ne pas se fier à un seul outil de détection. Combinez la Perspective API ou l’API OpenAI (gratuits) avec LlamaGuard (open source, exécutable localement) pour une couverture complémentaire. Testez avec vos propres données en français, pas avec les benchmarks standards qui surestiment les performances. Et prévoyez un circuit de revue humaine pour les cas ambigus.