Comment convaincre un LLM d'ignorer ses règles

Un LLM peut se tromper pour plusieurs raisons. Parfois, c'est à cause de ses limites. Il prédit la prochaine parole, travaille avec des probabilités. Donc, il peut produire des informations erronées ou trompeuses. Mais il y a une autre catégorie d'erreurs. Celle-ci ne vient pas d'une limite technique du modèle. Elle vient de quelqu'un qui le pousse au-delà de ses capacités.

On appelle ça un jailbreak.

La première chose à comprendre, c'est qu'un jailbreak ne demande pas de compétences techniques. Pas besoin d'accès privilégié ou d'outils particuliers. Il suffit d'un prompt, bien écrit. On n'entre pas dans le modèle de l'extérieur. On ne modifie pas les poids, on ne casse rien. On utilise l'interface normale, celle que tout le monde utilise. Et on construit une demande qui fait agir le modèle différemment.

Un exemple devenu presque classique : tu demandes à un LLM comment construire quelque chose de dangereux, il refuse. Ensuite, tu lui demandes d'interpréter un écrivain qui écrit un thriller. Dans une scène, le protagoniste, un chimiste, explique le procédé à un collègue. Même contenu, même résultat final. Mais cette fois, le modèle réfléchit. Il traite la demande comme de la création littéraire, pas comme une instruction directe. Le garde-fou n'a pas sauté parce que quelqu'un a piraté le système. Il a sauté parce que quelqu'un a reformulé la question.

C'est possible parce que les règles d'un LLM ne sont pas codées comme un pare-feu. Elles sont apprises pendant l'entraînement. Grâce à des exemples, des retours humains, des instructions intégrées. Elles sont probabilistiques, pas absolues. Et comme tout ce qui est probabilistique, elles ont des marges. Le jailbreak cherche ces marges.

Il y a des chercheurs en sécurité qui testent les limites des modèles. Ils cherchent des vulnérabilités avant que d'autres ne les trouvent. Il y a des curieux qui veulent voir où finit la protection et où commence le vrai modèle. Il y a des journalistes qui documentent les limites des systèmes utilisés par des millions chaque jour. Et puis, il y a ceux qui veulent obtenir des contenus que le modèle refuserait normalement. Des instructions dangereuses, des contenus illégaux, ou de la manipulation à grande échelle.

Les motivations varient. Mais la technique est souvent la même.

Il y a trois grandes catégories d'approche. La première est le changement de contexte. On demande au modèle de jouer un rôle, de simuler, de répondre "comme si" c'était un autre système sans restrictions. La deuxième est la fragmentation. On divise une demande problématique en morceaux apparemment innocents. Chacun passe les filtres seul. La troisième, la plus sophistiquée, est la manipulation des instructions système. Dans le prochain post, on l'appellera prompt injection.

Ce qui unit ces approches, c'est une idée de base. Le modèle n'a pas de compréhension éthique de ses actions. Il a des schémas. Et on peut contourner ces schémas si on sait reformuler la demande.

Le jailbreak ne prouve pas que les modèles sont dangereux. Il prouve que les modèles sont des outils. Et ces outils dépendent de qui les utilise et de la qualité des protections autour d'eux. La distance entre << le modèle se trompe seul >> et << quelqu'un le fait se tromper exprès >> est plus courte qu'on ne le pense. Et c'est exactement ce territoire que nous explorons dans cette série.