🤖 machine learning

A Paired Testing Protocol for Batch-Conditioned Refusal Robustness in LLM Serving

Cet article propose un protocole de test apparié démontrant que les conditions de lot des modèles linguistiques affectent significativement la robustesse des refus, révélant que, bien que les inversions d'étiquettes de sécurité soient plus fréquentes que les inversions d'étiquettes de capacité, elles sont largement attribuables à une instabilité de la sortie et peuvent être efficacement atténuées par des implémentations de noyaux invariants par lot.

Auteurs originaux : Sahil Kadadekar

Publié 2026-05-28

📖 5 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Sahil Kadadekar

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous avez une bibliothécaire très stricte et soucieuse de la sécurité (le modèle d'IA). Vous voulez vous assurer que cette bibliothécaire refuse toujours de remettre des livres dangereux (refus de sécurité) mais distribue avec plaisir ceux qui sont utiles (capacités).

Habituellement, lorsque nous testons cette bibliothécaire, nous lui posons des questions une par une dans une pièce calme. Mais dans le monde réel, la bibliothécaire travaille dans une bibliothèque animée où elle doit gérer de nombreuses demandes à la fois, les regroupant souvent par lots (batches) pour travailler plus vite.

Ce document pose une question simple mais délicate : La manière dont la bibliothécaire regroupe ces demandes change-t-elle sa réponse ? Poser une question en se tenant à côté d'une rangée d'autres personnes fait-il soudainement décider à la bibliothécaire de remettre un livre dangereux alors qu'elle ne l'aurait pas fait seule ?

Voici l'histoire de la recherche, décomposée en quatre expériences simples :

1. Le test de la « salle animée » (Étude A)

Les chercheurs ont commencé par tester la bibliothécaire de deux manières : seule et en groupe.

La découverte : Ils ont constaté que la bibliothécaire changeait parfois d'avis lorsqu'elle travaillait en groupe. Plus précisément, elle était légèrement plus susceptible de baisser sa garde par inadvertance face à des questions « dangereuses » qu'à des questions « utiles ».
La nuance : En regardant de plus près, ils ont réalisé que beaucoup de ces « changements » n'étaient que la bibliothécaire reformulant légèrement sa réponse, sans réellement modifier sa décision fondamentale. Après qu'un expert humain eut soigneusement examiné les données désordonnées, le nombre de vraies erreurs est passé d'un montant notable à un événement très rare (environ 1 demande sur 600).
L'analogie : C'est comme un agent de sécurité qui arrête habituellement une personne suspecte. Dans une foule, il peut hésiter une fraction de seconde ou dire « Stop ! » d'une voix différente, mais il l'arrête toujours. Cependant, très rarement, il pourrait laisser passer quelqu'un qu'il ne devrait pas.

2. Le test des « nombreuses bibliothécaires » (Étude B)

Les chercheurs ont ensuite demandé : « Est-ce un problème pour toutes les bibliothécaires, ou seulement pour celle-ci ? » Ils ont testé 15 modèles d'IA différents.

La découverte : Le motif de l'« erreur dangereuse » ne s'est pas produit pour tout le monde. Certains modèles étaient très stables ; d'autres un peu vacillants.
La surprise : Cela n'avait pas d'importance si un modèle était entraîné pour être « super sûr » ou « super utile ». La seule chose qui prédisait qui ferait des erreurs était l'instabilité. Si les réponses d'un modèle étaient déjà vacillantes et changeaient facilement lorsque la taille du groupe changeait, ce modèle était plus susceptible de commettre une erreur de sécurité.
L'analogie : Ce n'est pas que « toutes les bibliothécaires sont mauvaises avec les foules ». C'est que « si une bibliothécaire est déjà nerveuse et change facilement d'avis, la mettre dans une foule la rend plus susceptible de lâcher prise ».

3. Le test de la « foule mixte » (Étude C)

Ensuite, ils se sont demandé : « Est-ce que cela importe qui se trouve dans le groupe avec la bibliothécaire ? » Si la bibliothécaire traite une demande dangereuse tout en traitant une demande de mathématiques, est-ce que la demande de mathématiques cause le danger ?

La découverte : Ils n'ont pas trouvé de règle générale importante selon laquelle « mélanger les foules provoque des défaillances de sécurité ».
La réserve : Cependant, lorsque les quelques erreurs se produisaient, elles penchaient presque toujours vers l'insécurité.
L'analogie : C'est comme un chef cuisinant dans une cuisine animée. Mélanger un plat épicé avec un plat sucré ne gâte généralement pas la nourriture. Mais si le chef fait une erreur, il est plus probable que ce soit un problème de sécurité (comme brûler la nourriture) plutôt qu'un problème de goût.

4. Le test du « commutateur magique » (Étude D)

Enfin, les chercheurs voulaient savoir pourquoi cela se produisait. Ils soupçonnaient qu'une partie spécifique du « moteur » de l'ordinateur (le noyau) se confondait lorsqu'il gérait des groupes.

La découverte : Ils ont activé un mode spécial « invariant par lot » (un paramètre qui force l'ordinateur à ignorer les effets de groupe).
Le résultat : Lorsqu'ils ont utilisé ce mode, toutes les erreurs ont disparu. Les 22 erreurs observées en mode normal sont devenues 0 erreur en mode spécial.
L'analogie : C'est comme découvrir que la bibliothécaire trébuchait sur un tapis décollé dans le couloir. Une fois qu'ils ont fixé le tapis (le paramètre spécial), la bibliothécaire a cessé de trébucher complètement.

La grande conclusion

Le document conclut que le regroupement (batching) des demandes n'est pas un désastre universel, mais c'est une variable cachée que les testeurs de sécurité ne peuvent ignorer.

Ne paniquez pas : Cela ne signifie pas que l'IA est dangereuse en groupe. Les erreurs sont rares et spécifiques à certains modèles.
Vérifiez : Vous ne pouvez pas supposer qu'un modèle est sûr simplement parce qu'il a réussi un test en « mode solo ». Vous devez le tester exactement dans le « mode groupe » qu'il utilisera dans le monde réel.
La règle : Si vous déployez une IA, vous devez exécuter vos tests de sécurité avec les mêmes « paramètres de groupe » et moteurs informatiques que vous utiliserez en production. Si vous faites cela, vous pouvez repérer les rares moments où l'IA pourrait faire une erreur.

En bref : L'IA n'est pas cassée, mais la manière dont nous la testons doit être plus réaliste. Nous devons tester l'IA dans la « foule » pour nous assurer qu'elle ne perd pas son sang-froid.

Résumé technique : Un protocole de test apparié pour la robustesse du refus conditionné par lots dans la mise en service des LLM

1. Énoncé du problème

Les évaluations de sécurité actuelles pour les modèles de langage de grande taille (LLM) traitent généralement les configurations de mise en service (par exemple, la taille des lots, les politiques de planification) comme une infrastructure de fond fixe. Cet article remet en cause cette convention, postulant que la condition de lot est une variable de traitement non testée. Lorsqu'un prompt est évalué seul par rapport à un lot synchronisé ou dans un planificateur de lot continu, la décision de refus qui en résulte peut changer.

La question centrale n'est pas de savoir si le lotage est généralement dangereux, mais si le test apparié peut détecter un déplacement des limites de refus lorsque le même prompt est évalué dans différentes conditions de lot, tout en contrôlant la variation de sortie ordinaire et les changements de capacité bénins. Les auteurs soutiennent que la taille des lots et la planification sont des variables de traitement qui doivent être testées directement ou explicitement exclues lorsque le résultat d'intérêt est un événement de limite tel que le refus par rapport à la conformité.

2. Méthodologie : Une synthèse de quatre études

L'article synthétise quatre études étayées par des artefacts en un protocole de test cohérent. La méthodologie passe de la découverte locale à la généralisation inter-modèles, à l'analyse de composition et à l'ablation de mécanismes.

Étude A : Perturbation locale initiale

Conception : Un test de perturbation apparié local impliquant 31 410 lignes notées sur trois modèles ajustés par instruction (1 à 3 milliards de paramètres).
Conditions : Quatre phases ont été testées : perturbation de la taille des lots par dispatch synchronisé, perturbation de la condition du voisin, quantification par concurrence, et « vrai lotage » explicite.
Contrôles : L'étude associe des prompts de sécurité (nocifs/contournement de sécurité) à des contrôles de capacité (MMLU, ARC-Challenge) pour distinguer l'instabilité spécifique à la sécurité de la turbulence de sortie générique.
Correction : Un audit corrigé par le notateur et une adjudication manuelle de 63 lignes candidates ont été réalisés pour filtrer les artefacts de notation automatisée (par exemple, reformulation du refus) des inversions de comportement authentiques.

Étude B : Généralisation inter-modèles

Conception : Une extension à 127 224 enregistrements répartis sur 15 modèles distincts.
Objectif : Déterminer si l'asymétrie initiale sécurité-sur-capacité est une loi universelle ou spécifique au modèle, et tester si le type d'alignement ou l'instabilité de sortie prédit la fragilité.
Métriques : Analyse des ratios d'inversion sécurité/capacité, ANOVA sur les types d'alignement, et corrélation de l'instabilité de sortie avec la fragilité.

Étude C : Composition de lot continu

Conception : Un test pour déterminer si la co-résidence multi-locataire dans le lotage continu (vLLM FP16) crée un canal de sécurité distinct.
Portée : 14 250 enregistrements répartis sur cinq conditions de composition de lot, y compris des balayages de chevauchement temporel et des tests de direction inverse.
Objectif : Détecter les effets de sécurité agrégés résultant spécifiquement de la présence d'autres requêtes dans le même lot.

Étude D : Ablation de noyau invariant par lot

Conception : Une vérification ciblée de mécanisme sur 55 candidats d'inversion de score identifiés dans l'Étude A.
Exécution : Les lignes ont été relancées sur la même pile de mise en service H100 en utilisant vLLM standard par rapport à vLLM avec BATCH_INVARIANT=1 activé.
Objectif : Déterminer si les inversions observées dépendent du chemin d'exécution non invariant spécifique du noyau de mise en service.

3. Résultats clés

Résultats quantitatifs

Découverte locale (Étude A) : La notation automatisée initiale a montré que les étiquettes de sécurité changeaient plus souvent que les étiquettes de capacité (0,51 % contre 0,14 %). Cependant, après adjudication manuelle de 63 candidats, seules 17 inversions de comportement authentiques ont été confirmées, ce qui se traduit par un taux corrigé sur l'ensemble complet d'environ 0,16 %.
Généralisation inter-modèles (Étude B) :
- Aucune distorsion universelle : Le ratio combiné sécurité/capacité sur 15 modèles était proche de la parité (0,94×), réfutant une loi universelle de sécurité-sur-capacité.
- Prédicteurs : Le type d'alignement n'a montré aucune association détectable avec la fragilité ( $p=0,942$ ). En revanche, l'instabilité de sortie était le prédicteur le plus fort de la fragilité des lots ( $r=0,909$ ).
- Directionnalité : Les inversions n'étaient pas universellement dangereuses ; l'extension a trouvé une direction nette sûre (159 cas de conformité vers refus contre 81 cas de refus vers conformité), indiquant que la directionnalité dépend du modèle.
Composition (Étude C) : Aucun effet de composition agrégé n'a été détecté à une sensibilité de 4,7 points de pourcentage. Bien que les inversions rares penchent vers l'insécurité (28/31 cas, 90,3 %), le faible taux de vérification de la présence réelle dans le même lot (22,1 %) empêche cela d'être une base pour les décisions de routage.
Ablation de mécanisme (Étude D) :
- vLLM standard : A reproduit 22/55 inversions d'étiquettes sur l'ensemble des candidats.
- Noyau invariant par lot : L'activation de VLLM_BATCH_INVARIANT=1 a réduit les inversions à 0/55.
- Cela confirme que pour la pile testée, l'instabilité observée est liée au chemin d'exécution non invariant.

Synthèse qualitative

La chaîne de preuves réduit le signal positif initial à une affirmation bornée : les inversions de refus conditionnées par lot existent mais sont de faible taux, spécifiques au modèle et dépendantes de la pile. Elles ne constituent pas une loi de sécurité universelle, ni ne sont prédites par les catégories d'alignement.

4. Contributions

L'article apporte quatre contributions spécifiques en matière de test :

Protocole apparié : Un protocole pour le test de refus conditionné par lot qui compare les étiquettes de sécurité et de capacité dans des conditions de mise en service appariées, intégrant une adjudication corrigée par le notateur.
Test de généralisation : Des preuves indiquant que l'instabilité de sortie prédit la fragilité plus fortement que le type d'alignement, et que la distorsion agrégée sécurité-sur-capacité ne se généralise pas à travers les modèles.
Test de composition : Une démonstration que la composition de lot continu ne crée pas un grand effet de sécurité agrégé à la sensibilité actuelle, malgré des inversions directionnelles rares.
Ablation de mécanisme : La preuve que les candidats actuels d'inversion de score disparaissent lorsqu'ils sont exécutés sous un chemin de noyau invariant par lot, validant la nécessité de tests de pile exacte.

5. Importance et affirmations

L'importance de l'article réside dans l'établissement d'un contrat de test pour la sécurité de déploiement qui va au-delà des hypothèses de « fond fixe ».

Thèse : Les inversions de refus conditionnées par lot sont réelles mais rares et spécifiques. La réponse appropriée n'est pas une interdiction du lotage, mais une exigence de validation de pile exacte.
Recommandation opérationnelle : Les évaluations de sécurité doivent être réexécutées avec le paramètre de lot servi et le chemin de noyau spécifiques utilisés dans le déploiement.
- Évaluer le refus au paramètre de lot servi.
- Associer les prompts de sécurité à des contrôles de capacité pour filtrer la turbulence générique.
- Signaler séparément les inversions directionnelles de faible taux des effets nuls agrégés.
- Ne pas déduire la robustesse des lots à partir du type d'alignement, de la famille d'architecture ou d'heuristiques de composition.

Les auteurs déclarent explicitement ne pas affirmer avoir découvert un nondéterminisme dépendant du lot (ce qui est connu), ni affirmer que l'optimisation du déploiement est généralement neutre en matière de sécurité. Leur contribution est la découverte empirique spécifique selon laquelle le lotage doit être évalué comme un mode de défaillance de sécurité avec une conception appariée, et que les signaux positifs initiaux doivent être corrigés pour l'adjudication et la généralisation afin d'éviter de surestimer les résultats d'inversions rares.