MIT Technology Review alerte : on accorde trop de confiance aux refus des modèles d'IA

Dans l'édition du 9 octobre de sa newsletter The Download, MIT Technology Review met en avant une thèse que beaucoup, dans l'industrie, tiennent pour un axiome : nous faisons trop confiance à la capacité de l'IA à dire « non ». Les modèles actuels sont entraînés à refuser un très grand nombre de requêtes. Demandez à un chatbot comment empoisonner quelqu'un : il refusera très probablement. Pour le magazine, c'est précisément sur ce refus que l'industrie fonde trop d'espoirs. Le second sujet de l'édition porte sur les effets secondaires des médicaments contre l'obésité et n'a rien à voir avec l'IA.

Une réserve importante : le résumé de la newsletter ne contient que l'amorce de l'argumentation, sans données ni noms. Pour connaître la position complète des auteurs, mieux vaut lire l'original. Nous détaillons ci-dessous le fonctionnement technique des refus et leurs points faibles.

Comment les modèles apprennent à dire « non »

Le refus n'est pas intégré d'origine dans un LLM. Un modèle de base se contente de prolonger le texte et décrira avec la même facilité une recette de tarte ou une procédure dangereuse. Le comportement « je ne peux pas vous aider sur ce point » apparaît plus tard, lors des étapes de post-entraînement : des humains et d'autres modèles évaluent les réponses, et le système apprend à choisir celles jugées sûres. S'y ajoutent des prompts système et des filtres externes, qui contrôlent la requête en entrée et la réponse en sortie.

Le résultat ressemble à une frontière, mais il s'agit en réalité d'une propension statistique. Le modèle ne « comprend » pas qu'une requête est dangereuse : il reconnaît des motifs familiers de requêtes dangereuses.

Où le refus cède

Cette protection présente trois points faibles connus.

• Contournement par la formulation. Les scénarios de jeu de rôle, la reformulation, le changement de langue et le découpage d'une tâche dangereuse en étapes anodines restent depuis des années des techniques de jailbreak efficaces.
• Intention inconnue. Une question sur les poisons peut venir d'un toxicologue, d'un auteur de romans policiers, d'un étudiant ou d'un individu malveillant. Le texte seul de la requête ne permet pas de les distinguer ; le système doit donc arbitrer entre refus excessifs et failles.
• Un coût d'erreur dans les deux sens. Un modèle trop strict devient inutilisable pour les médecins, les chercheurs en sécurité et les journalistes. Un modèle trop laxiste fournit ce qu'il ne devrait pas fournir.

Les agents posent un problème distinct. Lorsque le modèle a accès à un navigateur, à une messagerie, à du code et à des outils de paiement, un refus poli dans le chat ne garantit rien. Une action dangereuse peut être assemblée à partir d'une série d'étapes dont chacune paraît innocente prise isolément.

De quoi se compose la protection en pratique

Si l'on ne s'appuie pas sur le refus comme unique barrière, le dispositif se construit en plusieurs couches :

• entraînement sur des exemples de refus et sur les préférences humaines ;
• instructions système de l'opérateur décrivant ce qui est autorisé et interdit ;
• classificateurs distincts en entrée et en sortie, indépendants du modèle principal ;
• red teaming : tentatives délibérées de piratage avant la sortie du modèle et après ;
• restriction des droits de l'agent au niveau de l'infrastructure, et non du prompt.

Le dernier point est le plus sous-estimé. Les droits d'accès, les limites et la validation humaine des actions critiques fonctionnent indépendamment de ce que le modèle a « décidé ».

Que doivent faire les équipes qui déploient des modèles

Premièrement : ne considérez pas le refus comme un contrôle de sécurité. C'est un réglage comportemental, et il faut le vérifier comme n'importe quel autre, régulièrement et sur chaque nouvelle version du modèle.

Deuxièmement : testez vos propres scénarios, pas seulement les benchmarks généralistes. Les requêtes dangereuses propres à votre domaine peuvent avoir un tout autre aspect que dans les jeux de données publics.

Troisièmement : pour les agents, concevez des droits minimaux et une journalisation des actions. Si le modèle se trompe ou se fait manipuler, les dégâts doivent se heurter à une limite technique.

Quatrièmement : mesurez les deux côtés de l'erreur. La part des requêtes dangereuses non bloquées et la part des faux refus sur des tâches légitimes en disent plus sur la qualité du système que n'importe quel indicateur pris isolément.