Accueil › Glossaire › Safety Tuning

Safety Tuning

Le safety tuning (ajustement de sécurité) est l’ensemble des techniques d’entraînement et de post-entraînement qui visent à rendre un LLM sûr : refuser les requêtes dangereuses, éviter la génération de contenu toxique ou trompeur, résister aux attaques adversariales (jailbreaks), et maintenir un comportement inoffensif tout en restant utile.

Pourquoi le safety tuning est indispensable

Un LLM pré-entraîné sur des trillions de tokens de texte Internet contient, dans ses poids, une représentation de tout ce qu’il a lu. Cela inclut des informations sur la fabrication d’armes, des discours haineux, des techniques de manipulation psychologique, et bien d’autres contenus dangereux. Sans safety tuning, le modèle produira ces contenus dès qu’on le lui demande, voire spontanément si le contexte y mène.

L’instruction tuning seul ne résout pas ce problème. Un modèle instruction-tuné sait suivre des consignes, y compris des consignes dangereuses. Il faut un entraînement spécifique pour lui apprendre à refuser les requêtes nuisibles tout en restant utile sur les requêtes légitimes.

C’est la tension helpfulness/harmlessness : le cœur du safety tuning. Trop de sécurité produit un modèle qui refuse tout et devient inutile (over-refusal). Pas assez de sécurité produit un modèle qui répond à n’importe quelle requête, y compris les plus dangereuses. Le safety tuning cherche l’équilibre optimal.

Les techniques de safety tuning

SFT sur données de sécurité

La forme la plus simple de safety tuning consiste à inclure, dans le dataset d’instruction tuning, des exemples de requêtes dangereuses avec des réponses de refus appropriées. Le modèle apprend à reconnaître les patterns de requêtes nuisibles et à y répondre par un refus poli et informatif.

Le papier « Safety-Tuned LLaMAs » (Bianchi et al., ICLR 2024) montre qu’un dataset de sécurité généré par GPT-3.5-turbo, contenant des paires (requête dangereuse, refus approprié), suffit à améliorer significativement la sécurité d’un modèle LLaMA instruction-tuné. Le point clé est que même un petit nombre d’exemples de sécurité (quelques centaines) peut avoir un impact disproportionné sur le comportement du modèle.

Safe RLHF : séparation helpfulness/harmlessness

Safe RLHF (ICLR 2024) est une avancée majeure qui sépare explicitement les objectifs d’utilité et d’innocuité. Au lieu d’entraîner un seul reward model qui mélange les deux dimensions, Safe RLHF entraîne deux modèles distincts :

Un reward model (helpfulness). Évalue la qualité et l’utilité de la réponse, indépendamment de sa sécurité.

Un cost model (harmlessness). Évalue le niveau de danger ou de nocivité de la réponse, indépendamment de son utilité.

L’entraînement utilise ensuite une optimisation sous contraintes (avec un multiplicateur de Lagrange) qui maximise l’utilité tout en maintenant la nocivité sous un seuil acceptable. Le multiplicateur est ajusté dynamiquement pour éviter de surpondérer un objectif au détriment de l’autre. Après 3 rounds itératifs de Safe RLHF, le modèle améliore à la fois son score d’utilité (+244 à +364 points Elo) et son score d’innocuité (+237 à +268 points Elo) par rapport au modèle de base.

Constitutional AI

Développée par Anthropic, la Constitutional AI (CAI) utilise le modèle lui-même pour s’auto-évaluer et s’auto-corriger selon un ensemble de « principes constitutionnels » (des règles éthiques prédéfinies). Le processus se décompose en deux phases :

Phase critique. Le modèle génère une réponse, puis est invité à la critiquer selon les principes constitutionnels (« Cette réponse pourrait-elle être nuisible ? Si oui, comment la reformuler pour qu’elle soit utile sans être dangereuse ? »).

Phase de révision. Le modèle génère une version révisée de sa réponse qui respecte les principes.

Les paires (réponse originale, réponse révisée) servent ensuite de données de préférence pour un preference tuning (RLHF ou DPO). L’avantage est que le processus est largement automatisé (pas besoin d’annotateurs humains pour chaque exemple de sécurité), tout en étant guidé par des principes explicites et auditables. La Constitutional AI est l’approche utilisée par Anthropic pour entraîner Claude, et elle a influencé de nombreux pipelines de safety tuning dans l’industrie. Elle illustre une tendance plus large : utiliser l’IA elle-même pour améliorer sa propre sécurité (RLAIF), ce qui réduit les coûts d’annotation humaine tout en maintenant un contrôle via les principes constitutionnels.

Red teaming itératif

Le red teaming est la pratique de tester systématiquement un modèle en essayant de le faire échouer. Dans le contexte du safety tuning, le red teaming est intégré directement dans la boucle d’entraînement :

Round 1 : Le modèle est safety-tuné sur un dataset initial de requêtes dangereuses et de refus.

Round 2 : Des red teamers (humains ou LLM adversaires) attaquent le modèle amélioré pour trouver de nouvelles failles. Les attaques réussies deviennent de nouvelles données d’entraînement.

Round 3+ : Le processus se répète. Chaque round produit un modèle plus robuste et un ensemble d’attaques plus sophistiqué.

MART (Multi-round Automatic Red-Teaming, NAACL 2024) automatise ce processus en utilisant un LLM adversaire qui s’améliore à chaque round pour attaquer le modèle cible, tandis que le modèle cible s’améliore via safety fine-tuning sur les nouvelles attaques découvertes. Après 4 rounds de MART, le taux de violation du modèle diminue de 84,7 %, tout en maintenant ses performances sur les prompts non adversariaux.

La fragilité de l’alignement de sécurité

L’un des résultats les plus préoccupants de la recherche récente (ICLR 2024) est la facilité avec laquelle le safety tuning peut être défait. Les chercheurs ont montré que 10 à 100 exemples malveillants suffisent pour jailbreaker un LLM aligné via fine-tuning. Malgré l’asymétrie massive (des millions de données pour le safety tuning vs. une centaine pour l’attaque), l’alignement de sécurité de GPT-3.5 Turbo et Llama-2 est largement éliminé après un fine-tuning sur ces quelques exemples.

Ce résultat a des implications graves pour les services de fine-tuning via API (comme ceux proposés par OpenAI, Anthropic ou Google). Un utilisateur malveillant pourrait fine-tuner un modèle aligné sur un petit dataset adversarial et obtenir un modèle « détoxé » de toute sécurité. C’est pourquoi les fournisseurs de LLM implémentent des gardes-fous au niveau de l’API de fine-tuning (filtrage des données, monitoring post-fine-tuning, limites sur les types de données acceptées).

Défenses et renforcement

Activation steering

Des techniques d’activation steering permettent de modifier le comportement du modèle à l’inférence en ajoutant des « vecteurs de direction » aux activations internes. On peut extraire un « vecteur de refus » des couches cachées du modèle et l’amplifier pour renforcer la tendance du modèle à refuser les requêtes dangereuses, sans réentraînement.

SafeDecoding

SafeDecoding modifie la stratégie de décodage pour amplifier les probabilités des tokens de refus (« Je ne peux pas », « C’est dangereux ») et atténuer celles des contenus potentiellement nuisibles. C’est une défense au niveau de l’inférence, complémentaire au safety tuning.

Safeguarding via distributional alignment

Des travaux récents (2026) proposent des techniques comme SOT (Safeguarding via Optimal Transport) qui utilisent le transport optimal pour maintenir la distribution des représentations internes du modèle fine-tuné proche de celle du modèle aligné original. Cela empêche le fine-tuning de déplacer les représentations vers des zones « dangereuses » de l’espace latent, même quand les données de fine-tuning contiennent des exemples malveillants.

Le défi du multi-tour

La sécurité en conversation multi-tours est un défi particulièrement difficile. Un utilisateur peut formuler une requête dangereuse de façon progressive, sur plusieurs tours de conversation, de sorte que chaque message individuel semble innocent. Les attaques multi-tours sont significativement plus efficaces que les attaques single-turn, et les défenses actuelles des LLM sont encore largement insuffisantes pour les contrer.

MTSA (Multi-turn Safety Alignment, ACL 2025) propose un framework en deux étapes : d’abord, un modèle « red team » apprend à générer des attaques multi-tours guidées par un raisonnement étape par étape. Ensuite, le modèle cible est entraîné itérativement sur les résultats de ces interactions adversariales. Le processus intègre les données d’attaque réussies et les défenses correspondantes dans le safety tuning, améliorant la robustesse multi-tours du modèle.

Évaluer la sécurité d’un LLM

L’évaluation de la sécurité combine typiquement des métriques automatiques (taux de refus, taux de violation), des évaluations par LLM juge (GPT-4 ou Claude évaluent si la réponse est dangereuse), et des évaluations humaines (red teamers professionnels testent le modèle). Les évaluations humaines découvrent significativement plus de vulnérabilités que les approches automatisées, ce qui souligne la nécessité de combiner les méthodes.

Le problème de l’over-refusal

Un modèle trop safety-tuné refuse des requêtes parfaitement légitimes. Demander « comment fonctionne un couteau de cuisine » peut déclencher un refus si le modèle associe « couteau » à un danger. L’over-refusal (refus excessif) est un problème réel qui dégrade l’expérience utilisateur et l’utilité du modèle.

Les recherches montrent que l’optimisation pour l’harmlessness peut entrer en conflit avec l’optimisation pour l’helpfulness, un phénomène parfois appelé « alignment tax ». Des modèles fortement optimisés pour la sécurité (GPT-4o par exemple) peuvent parfois sous-performer des modèles plus petits (GPT-4o-mini) sur des tâches d’instruction following précis, car l’optimisation de sécurité rend le modèle plus prudent dans sa génération.

La solution passe par une granularité plus fine dans le safety tuning : au lieu d’un refus binaire (dangereux/pas dangereux), le modèle doit apprendre à évaluer le contexte de la requête. « Comment fabriquer un explosif » doit être refusé, mais « expliquez la chimie des réactions exothermiques » ne doit pas l’être, même si les deux touchent des sujets similaires. Des taxonomies de risque fines (comme les 14 catégories de sécurité de Safe RLHF) aident le modèle à distinguer les intentions réellement dangereuses des questions légitimes qui effleurent des sujets sensibles. Le purple teaming (PAD, 2024), qui combine red teaming offensif et blue teaming défensif dans une boucle itérative, est aussi une approche prometteuse pour calibrer la frontière de refus de façon optimale.

Verdict

Le safety tuning est l’étape la plus critique et la plus difficile de l’alignement d’un LLM. C’est aussi la plus fragile : des mois de travail de sécurité peuvent être défaits par 100 exemples malveillants de fine-tuning. Cette asymétrie fondamentale entre l’effort de sécurisation et l’effort de contournement est le défi central du domaine. Les approches modernes (Safe RLHF, Constitutional AI, red teaming itératif) ont considérablement amélioré la robustesse des modèles, mais aucune n’offre de garantie absolue.

Pour les développeurs qui déploient des LLM : ne fine-tunez jamais un modèle aligné sans inclure des données de sécurité dans votre dataset. Monitorez le taux de refus en production (un taux qui chute soudainement peut indiquer une dégradation de l’alignement). Testez régulièrement avec des prompts adversariaux, en incluant des scénarios multi-tours. Et surtout, ne considérez jamais la sécurité comme un problème résolu : les techniques d’attaque évoluent aussi vite que les défenses, et chaque nouvelle capacité du modèle (tool use, agents, multimodal) ouvre de nouvelles surfaces d’attaque qui nécessitent un safety tuning adapté.