perturber : un service de 68 perturbations de texte pour tester la robustesse des LLM

Les évaluations des modèles de langage sur des benchmarks « propres » surestiment leur robustesse. Les requêtes réelles arrivent sous une forme dégradée, et même des variations qui ne changent pas le sens modifient régulièrement les réponses d'un modèle. Les auteurs du preprint arXiv:2610.12667 proposent un outil pour vérifier cet effet de façon systématique. Perturber est à la fois un service sans état et une bibliothèque Python. À chaque appel, il applique exactement une perturbation préservant le sens, issue de son propre catalogue : 68 perturbations réparties en 11 familles.

Le problème : des perturbations liées à la pile d'un tiers

Une étude systématique de la robustesse exige trois choses. Les perturbations s'appliquent une par une, le résultat est reproductible, et le même texte sort sur n'importe quelle machine et dans n'importe quel environnement. Selon les auteurs, les outils existants sont en général intégrés à une pile de benchmarking donnée et ne constituent pas une couche de transformation autonome. Pour en extraire une seule perturbation, il faut embarquer tout le framework. La comparaison entre les résultats de différentes équipes devient alors difficile : on ne sait pas si la transformation a fonctionné de la même manière chez chacune.

Perturber sort cette couche du reste de la pile. Il ne sait rien des modèles, des métriques ni des jeux de données. Il reçoit en entrée un texte et le nom d'une perturbation, et renvoie le texte modifié.

Un appel, une primitive

L'architecture repose sur une primitive unique. Le service ne combine pas lui-même les perturbations : si l'on veut une chaîne, c'est à l'appelant de la construire en sollicitant l'outil successivement. Ainsi, le service HTTP et la bibliothèque locale donnent le même résultat par construction, et non par accord entre deux implémentations. L'absence d'état supprime une autre source de divergences : les appels précédents n'influencent pas la sortie.

Principales caractéristiques de l'outil :

• 68 perturbations développées en interne (first-party), sans dépendance externe à des catalogues tiers ;
• 11 familles de perturbations ;
• exactement une perturbation par appel, composition côté client ;
• format de livraison : service stateless et bibliothèque Python à la sortie identique ;
• démonstration : bac à sable en ligne, catalogue interrogeable (introspection) pour choisir les perturbations adaptées à un benchmark, et évaluation reproductible en une seule commande.

Les auteurs soulignent qu'ils évaluent l'outil lui-même, et non le modèle de quelqu'un. Ils mesurent la correction, la reproductibilité et le coût de fonctionnement. La préservation du sens est mesurée séparément pour chaque perturbation. Les auteurs ne tiennent pas cette propriété pour acquise : quiconque a déjà lancé une paraphrase sait qu'une modification « équivalente » change parfois la tâche sans qu'on s'en aperçoive. Conséquence pratique : une perturbation qui échoue à ce contrôle fausse la conclusion sur la robustesse du modèle.

Comment l'utiliser en pratique

Le catalogue interrogeable sert à choisir les perturbations pour un benchmark précis. Une équipe qui évalue son modèle peut y sélectionner les familles adaptées à son domaine et exécuter chacune indépendamment des autres. La comparaison entre entrée « propre » et entrée perturbée est plus nette quand on sait quelle modification précise a déplacé la réponse. C'est aussi pratique pour les tests de régression. Comme la sortie est déterministe et ne dépend pas de l'environnement, on peut régénérer les jeux perturbés en CI plutôt que de les stocker comme artefacts.

L'outil a aussi ses limites. L'abstract ne contient aucun résultat de robustesse pour un modèle quelconque, et l'outil n'en promet pas. C'est une brique de base, pas un classement. Sa valeur se jugera à la facilité avec laquelle les équipes l'intégreront à leurs pipelines, et à la fiabilité des mesures de préservation du sens sur des données réelles, y compris hors de l'anglais. Pour ceux qui construisent des bancs d'évaluation, l'intérêt est clair : une couche de perturbations distincte, au comportement identique partout, supprime au moins une source d'incertitude dans les résultats.