🤖 AI

Addressing Labelled Data Scarcity: Taxonomy-Agnostic Annotation of PII Values in HTTP Traffic using LLMs

Ce papier propose et évalue un pipeline de modèle de langage de grande taille multi-étapes permettant une annotation flexible et agnostique de la taxonomie des informations personnellement identifiables dans le trafic HTTP, en palliant la pénurie de données par la génération de trafic synthétique et en démontrant une détection précise à travers diverses définitions de la vie privée.

Auteurs originaux : Thomas Cory, Axel Küpper

Publié 2026-05-08

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Thomas Cory, Axel Küpper

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 êtes inspecteur de la vie privée pour une ville animée. Votre travail consiste à vérifier chaque lettre, colis et message numérique quittant la ville pour vous assurer que personne ne transmet accidentellement des informations personnelles secrètes (comme des adresses domiciliaires, des numéros de téléphone ou des dossiers médicaux). Ces informations secrètes sont appelées PII (Informations Personnellement Identifiables).

Pendant des années, les inspecteurs ont utilisé deux outils principaux :

Le Livre de Règles : Une liste rigide de mots-clés (comme « e-mail » ou « numéro de sécurité sociale »). Cela fonctionne bien pour les lettres simples, mais échoue lorsque les gens écrivent de manière étrange ou utilisent du code.
Le Chien Dressé : Un modèle d'apprentissage automatique entraîné sur des milliers d'exemples. Il est intelligent, mais il ne connaît que les règles spécifiques qui lui ont été enseignées. Si les règles changent (par exemple, une nouvelle loi définit différemment les « données de santé »), le chien doit être réentraîné depuis zéro, ce qui prend beaucoup de temps et nécessite un approvisionnement massif en lettres secrètes réelles à étudier.

Le Problème : Les lettres secrètes réelles sont difficiles à obtenir (en raison des lois sur la vie privée), et les règles définissant ce qui compte comme « secret » changent constamment. Cela laisse les inspecteurs avec une pénurie de bonnes données d'entraînement et des outils incapables de s'adapter.

La Nouvelle Solution : Le « Super-Traducteur »

Ce document présente une nouvelle approche utilisant les Modèles de Langage de Grande Taille (LLM). Considérez un LLM non pas comme un chien dressé, mais comme un traducteur super-intelligent et flexible qui a lu presque tout dans la bibliothèque. Vous n'avez pas besoin d'entraîner ce traducteur sur des règles spécifiques ; vous lui remettez simplement le livre de règles en temps réel (au moment de l'exécution), et il peut le comprendre instantanément.

Voici comment les auteurs ont construit leur système, en utilisant des analogies simples :

1. La Chaîne de Montage (Le Pipeline)

Au lieu de demander au traducteur de tout faire d'un coup, les auteurs ont construit une chaîne de montage en trois étapes :

Étape 1 : Le Nettoyeur (Prétraitement) : Avant que le traducteur ne voie le message, une machine le nettoie. Elle décrypte les codes (comme transformer %20 en un espace) afin que le traducteur voie une phrase claire et lisible.
Étape 2 : Le Détective et Le Scribe (Annotation en Deux Étapes) :
- Le Détective : D'abord, le LLM examine le message et dit : « Je vois un numéro de téléphone et un nom ici, mais aucun dossier médical. » Il crée une courte liste de ce qu'il faut rechercher.
- Le Scribe : Ensuite, un deuxième passage se concentre uniquement sur la recherche du texte exact pour ces éléments spécifiques. En réduisant le champ de vision, le Scribe ne se laisse pas troubler par d'autres chiffres ou mots.
Étape 3 : L'Éditeur (Vérification) : Une vérification finale examine le travail. Si le Scribe a manqué un chiffre ou saisi le mauvais mot, l'Éditeur le corrige.

2. L'Usine de « Fausses Lettres » (Données Synthétiques)

Puisque les inspecteurs ne peuvent pas utiliser les lettres secrètes de vraies personnes pour entraîner leurs outils, les auteurs ont construit une Usine qui fabrique de fausses lettres.

Cette usine prend un livre de règles (une taxonomie) et demande au LLM d'écrire des lettres réalistes qui contiennent des secrets spécifiques (comme « le numéro de téléphone de Jean Dupont »).
Crucialement, l'usine écrit également les réponses (la vérité terrain) pour chaque lettre qu'elle produit.
Pourquoi cela compte : Cela résout le problème de la « pénurie ». Vous pouvez générer instantanément des milliers de lettres d'entraînement avec des réponses parfaites, sans jamais toucher aux données privées d'une vraie personne.

3. L'Essai Routier (Évaluation)

Les auteurs ont testé ce système avec trois « Livres de Règles » (Taxonomies) différents :

AI4Privacy : Une liste large de secrets courants (noms, e-mails, identifiants).
mHealth : Une liste spécifique pour les applications de santé (signes vitaux, données de fitness).
PlayStore : Une liste de haut niveau utilisée par les magasins d'applications (par exemple, « Données financières » ou « Localisation »).

Les Résultats :

Succès : Le système a fonctionné incroyablement bien sur les deux premiers livres de règles. Il pouvait lire un message, consulter le livre de règles spécifique fourni ce jour-là, et trouver avec précision les secrets.
Défi : Il a eu un peu plus de mal avec le livre de règles « PlayStore ». Les auteurs expliquent que cela est dû au fait que ce livre de règles utilise des catégories très larges (comme « Données financières ») qui sont plus difficiles à rattacher à un mot spécifique dans un message que des choses concrètes comme « Numéro de téléphone ».
L'Étape « Éditeur » : Fait intéressant, l'étape finale « Éditeur » n'a pas toujours amélioré les choses. Parfois, elle corrigeait des erreurs, mais d'autres fois, elle en introduisait de nouvelles. Les auteurs suggèrent que cela pourrait être dû au fait que l'Éditeur utilisait le même « cerveau » que le Scribe, commettant ainsi les mêmes types d'erreurs.

La Conclusion

Ce document prouve que vous n'avez pas besoin de réentraîner une machine à chaque fois que les règles de confidentialité changent. À la place, vous pouvez utiliser une IA flexible qui lit les règles à la volée.

Pour les Inspecteurs : Vous pouvez échanger les livres de règles instantanément sans reconstruire vos outils.
Pour la Pénurie de Données : Vous pouvez générer vos propres données d'entraînement (fausses lettres) pour tester vos outils, afin de ne pas avoir à voler les données de vraies personnes.

Les auteurs concluent que, bien que cela ne soit pas encore un remplacement parfait pour les détecteurs légers et rapides, c'est un outil puissant pour créer des données d'entraînement de haute qualité et auditer les systèmes à mesure que les lois sur la vie privée évoluent. Ils suggèrent que la meilleure voie future consiste à utiliser cette IA flexible pour créer les données, puis à enseigner à des machines plus petites et plus rapides comment faire le travail.

Résumé technique : Annotation agnostique des taxonomies des valeurs d'informations personnellement identifiables (IPI) dans le trafic HTTP utilisant des modèles de langage de grande taille (LLM)

Énoncé du problème

Les audits de confidentialité automatisés des applications web et mobiles reposent de plus en plus sur l'analyse du trafic HTTP sortant pour détecter les fuites d'informations personnellement identifiables (IPI). Cependant, les détecteurs existants basés sur l'apprentissage se heurtent à deux limitations critiques :

Pénurie de données : Ils dépendent de jeux de données de haute qualité, étiquetés manuellement, dont la création est laborieuse et la maintenance difficile.
Rigidité des taxonomies : Ces modèles sont étroitement couplés à des taxonomies d'étiquettes fixes. À mesure que les définitions de la confidentialité évoluent ou diffèrent selon les domaines (par exemple, RGPD vs santé mobile vs politiques du Play Store), un réentraînement est nécessaire, et les performances se dégradent souvent considérablement, même avec des modifications mineures de la taxonomy ou de la distribution des données.

L'article postule que les modèles de langage de grande taille (LLM), en tant que modèles généralistes capables d'exécuter des tâches en zéro-shot ou few-shot sans réentraînement, offrent une solution potentielle pour permettre l'annotation agnostique des taxonomies des valeurs d'IPI en temps réel.

Méthodologie

Les auteurs proposent un cadre complet composé de deux principaux composants : un pipeline d'annotation multi-étapes et un générateur de données synthétiques.

1. Pipeline d'annotation multi-étapes
Le pipeline décompose la tâche complexe de détection d'IPI en sous-problèmes spécialisés pour améliorer la précision et gérer la variabilité du trafic HTTP :

Prétraitement déterministe : Les corps de messages HTTP sont normalisés pour atténuer la variabilité de l'encodage. Cela inclut le décodage URL (RFC 3986), la résolution des références de caractères HTML, et un décodage optionnel au niveau de l'application (par exemple, Base64) pour les sous-chaînes correspondant à des motifs syntaxiques spécifiques. Les représentations originales et normalisées sont conservées pour la traçabilité.
Annotation en deux étapes :
- Classification au niveau des étiquettes : Un LLM prédit l'ensemble des étiquettes d'IPI ( $L_m$ ) explicitement présentes dans le message, en adhérant à une exigence stricte de « valeur explicite » (aucune inférence à partir de clés vides).
- Extraction au niveau des instances : Un second LLM effectue une reconnaissance d'entités nommées (NER) ciblée sur le corps normalisé, conditionnée par les étiquettes prédites. Cette étape se concentre sur la détection des limites et la désambiguïsation en utilisant des indices contextuels (noms de clés, motifs de valeurs, position structurelle).
Révision post-annotation : Une troisième étape LLM agit en tant que réviseur, affinant les annotations initiales pour corriger les faux négatifs, les incohérences d'étiquettes et les erreurs de limites.
Environnement d'inférence LLM : Pour assurer la robustesse, le pipeline utilise la génération augmentée par récupération (RAG) pour injecter des exemples pertinents pour la tâche (structurels et spécifiques aux étiquettes) dans les invites. Une couche de validation déterministe impose la conformité au schéma et normalise les sorties d'étiquettes (par exemple, mapper « E-mail » à « Email ») en utilisant la similarité cosinus par rapport à la taxonomy cible.

2. Générateur de messages HTTP synthétiques
Pour répondre à la pénurie de données étiquetées sans exposer le trafic utilisateur réel, les auteurs introduisent un générateur piloté par la taxonomy :

Génération de scénarios : Le LLM crée des modèles de scénarios (par exemple, création de compte, paiement) basés sur une taxonomy fournie.
Instantiation de messages : Le LLM génère des requêtes HTTP concrètes (et optionnellement des réponses) contenant des valeurs d'IPI explicites.
Validation : Une couche de validation assure la bonne forme structurelle, la conformité à la taxonomy et que toutes les valeurs annotées apparaissent mot pour mot dans la charge utile générée.
Suivi de la couverture : Le système surveille la couverture des étiquettes pour assurer une représentation diversifiée à travers la taxonomy.

Contributions principales

L'article expose trois contributions principales :

C1 (Pipeline d'annotation) : Une approche basée sur les LLM, multi-étapes, pour l'identification granulaire des IPI dans les charges utiles HTTP, permettant le changement d'exécution des taxonomies d'étiquettes sans réentraînement.
C2 (Générateur synthétique) : Un mécanisme basé sur les LLM pour générer du trafic HTTP synthétique avec des annotations d'IPI de vérité terrain, réduisant la dépendance à la curation manuelle pour les taxonomies en évolution.
C3 (Évaluation) : Une évaluation complète sur trois taxonomies distinctes (AI4Privacy, mHealth et PlayStore) couvrant différents domaines et niveaux de granularité pour évaluer la flexibilité et les performances.

Résultats

L'évaluation a utilisé trois jeux de données dérivés du générateur synthétique, divisés en 80/20 pour l'évaluation et les exemples RAG. Les performances ont été mesurées à l'aide de la précision, du rappel et du score F1 aux niveaux des étiquettes et des instances.

Performances globales : Le pipeline a obtenu de solides performances sur les taxonomies AI4Privacy (53 classes) et mHealth (38 classes). La détection au niveau des étiquettes était proche du plafond (F1 > 0,98) à l'étape de classification, et l'extraction au niveau des instances est restée élevée (F1 > 0,95).
Variance des taxonomies : Les performances étaient plus faibles sur la taxonomy PlayStore (38 classes), qui utilise des catégories de haut niveau, orientées vers les politiques. Cela suggère que la difficulté d'annotation est corrélée à la granularité sémantique de la taxonomy ; les catégories larges sont plus difficiles à mapper vers des valeurs de charge utiles spécifiques que les types d'IPI concrets.
Impact architectural :
- La configuration en deux étapes (classification suivie d'une extraction ciblée) a généralement surpassé ou égalé l'annotation en une seule étape sur AI4Privacy et mHealth, améliorant principalement le rappel au niveau des instances.
- Sur PlayStore, l'approche en deux étapes a amélioré la détection des étiquettes mais ne s'est pas traduite par une meilleure extraction d'instances, indiquant que des sorties de classificateur bruyantes peuvent propager des erreurs dans des taxonomies complexes.
Étape de révision : L'étape de révision a apporté un bénéfice net limité, dégradant occasionnellement les performances. Les auteurs suggèrent que cela est dû au fait que la même famille de modèles a été utilisée pour l'annotation et la révision, reproduisant potentiellement des hypothèses partagées plutôt que de fournir une correction indépendante.

Importance et affirmations

L'article affirme que les LLM servent de fondation prometteuse pour l'annotation de trafic flexible et agnostique des taxonomies. Les points clés à retenir incluent :

Faisabilité : Les LLM peuvent identifier et annoter avec précision les valeurs d'IPI transmises explicitement lorsque la taxonomy est fournie en temps réel, éliminant le besoin de réentraînement sur de nouveaux ensembles d'étiquettes.
Génération de données : Le trafic HTTP synthétique avec des annotations de vérité terrain est un substrat viable pour l'évaluation contrôlée et l'invite few-shot, atténuant la pénurie de données réelles étiquetées.
Limites et portée : Les auteurs sont modestes concernant le déploiement de cette approche comme remplacement direct des détecteurs de production légers. Ils notent que :
- Les performances dépendent fortement de la conception de la taxonomy et de la structure de la charge utile.
- Les données synthétiques, bien qu'utiles pour l'évaluation, peuvent ne pas capturer pleinement la distribution du trafic réel (par exemple, obfuscation, charges utiles mal formées).
- L'évaluation actuelle est limitée aux valeurs transmises explicitement dans les corps de requête, excluant les en-têtes, les cookies et le trafic chiffré.
Voie future : Les auteurs proposent une approche hybride comme la voie la plus prometteuse : utiliser l'annotation basée sur les LLM pour créer ou affiner des jeux de données étiquetés sous des taxonomies en évolution, puis distiller ces annotations dans des modèles plus petits et discriminatifs pour un déploiement à haut débit.