Bug, jailbreak et injection de prompt : ce qu'ils ont vraiment en commun

Après avoir vu comment un LLM peut se tromper seul, être contourné par un jailbreak, ou manipulé par une injection de prompt, la question devient inévitable : les entreprises qui développent ces modèles le savent-elles ? Y travaillent-elles ?

Oui. Mais c'est quand même difficile.

Le problème n'est pas technique. Il est structurel.

Un logiciel traditionnel a des règles écrites par quelqu'un. Si un bug apparaît, on trouve la ligne de code fautive et on la corrige. Un LLM fonctionne différemment : ses "règles" ne sont pas écrites explicitement. Elles émergent de l'entraînement, compressées en milliards de paramètres numériques que personne ne peut lire directement. Il n'y a pas de ligne de code disant "ne pas aider à faire des choses dangereuses". Il y a un ensemble de poids statistiques qui, en moyenne, produisent ce comportement. Et "en moyenne" ne veut pas dire "toujours".

C'est pourquoi des solutions existent, mais aucune n'est définitive.

La première est le RLHF -- Reinforcement Learning from Human Feedback. Pendant l'entraînement, de vraies personnes évaluent les réponses du modèle. Ces évaluations servent à ajuster les poids dans la bonne direction. C'est le principal mécanisme par lequel les modèles apprennent à refuser des demandes dangereuses, à calibrer l'incertitude, à être utiles sans nuire. Cela fonctionne, mais cela dépend de la qualité et de la quantité du feedback humain. Et cela ne couvre pas tous les cas possibles. Un jailbreak bien conçu trouve exactement les cas que le feedback n'a pas couverts.

La deuxième approche, c'est le red teaming. Avant de lancer un modèle, des équipes dédiées essaient activement de le faire échouer. Elles testent les jailbreaks, les injections de prompt, les cas limites, et les scénarios d'abus. Ce travail ressemble plus à celui d'un enquêteur qu'à celui d'un ingénieur. L'objectif est de trouver les vulnérabilités avant les autres. Le problème, c'est que l'espace des prompts possibles est infini. Un red team humain ne peut pas tout couvrir. C'est pourquoi on utilise aussi des modèles automatisés pour tester d'autres modèles. Les résultats sont prometteurs, mais pas définitifs.

La troisième approche, ce sont les filtres. Ce sont des couches de contrôle qui analysent l'entrée avant qu'elle n'atteigne le modèle et la sortie avant qu'elle n'arrive à l'utilisateur. Ils sont utiles pour les cas évidents, ceux avec des mots-clés ou des motifs reconnaissables. Mais ils sont moins efficaces contre les attaques sophistiquées. Par exemple, contre l'injection de prompt indirecte ou les requêtes qui semblent innocentes seules mais ne le sont pas dans le contexte.

Enfin, il y a l'alignment. C'est le domaine de recherche qui cherche à s'assurer que les modèles poursuivent vraiment nos objectifs, pas des approximations statistiques. C'est le problème le plus profond et le moins résolu. Ce n'est pas parce que personne n'y travaille. Certaines des meilleures têtes du secteur s'y consacrent. Mais aligner un système qui ne raisonne pas comme un humain reste un défi sans solution générale.

Rien de tout cela ne signifie que ces outils sont inutilisables ou que l'avenir est forcément sombre. Cela signifie que la technologie avance plus vite que notre capacité à la rendre robuste. Utiliser ces outils en connaissance de cause, en sachant où sont les limites, reste notre meilleure défense.

Aucune de ces techniques n'élimine vraiment le problème. Elles le rendent moins probable, plus coûteux à exploiter, plus facile à contrôler. Mais elles ne l'éliminent pas.

C'est le prix à payer pour une technologie qui génère des réponses à partir de corrélations statistiques plutôt que d'une compréhension réelle. Et c'est pourquoi les bugs, les jailbreaks et les injections de prompt ne sont pas des anomalies isolées : ce sont des manifestations différentes de la même limite fondamentale.