Présentation d’OpenAI Privacy Filter

• Un modèle à poids ouverts qui détecte et masque les informations personnelles identifiables dans le texte non structuré, avec exécution locale pour que les données ne quittent pas l’appareil avant le filtrage
• Conçu pour combiner classification bidirectionnelle de tokens et décodage de spans afin d’étiqueter l’entrée en une seule passe et de reconstruire rapidement les spans de PII dans un contexte allant jusqu’à 128 000 tokens
• Contrairement aux approches à base de règles qui reposent sur les formats de numéros de téléphone ou d’e-mails, il s’appuie sur une compréhension de la langue et du contexte pour mieux distinguer les informations publiques de celles qui doivent être masquées
• Entraîné à partir de données publiques et synthétiques, il a atteint un score de F1 de 96 % sur PII-Masking-300k et 97,43 % de F1 sur une version corrigée, tandis que ses performances d’adaptation au domaine sont passées de 54 % à 96 % avec peu de données
• Ce n’est ni un outil d’anonymisation ni un substitut à une certification de conformité, et dans les domaines très sensibles, la revue humaine, l’évaluation par domaine et un fine-tuning supplémentaire restent essentiels

---

Vue d’ensemble du produit et mode de déploiement

• Modèle à poids ouverts spécialisé dans la détection et le masquage des informations personnelles identifiables, capable de repérer la PII dans le texte pour la masquer ou la supprimer
• Prend en charge l’exécution locale, ce qui permet d’éviter que les données quittent l’appareil avant filtrage et réduit le risque d’exposition par rapport à un envoi vers un serveur pour désidentification
• Conçu pour traiter rapidement de longues entrées, avec une décision de masquage prise en une seule passe
• Les développeurs peuvent l’exécuter dans leur propre environnement et le fine-tuner selon leurs cas d’usage afin d’ajouter une protection plus forte de la vie privée aux pipelines d’entraînement, d’indexation, de journalisation et de revue
• Disponible sur Hugging Face et GitHub sous licence Apache 2.0, avec à l’esprit l’expérimentation, la personnalisation et le déploiement commercial

En quoi il diffère des approches existantes

• Les outils traditionnels de détection de PII s’appuient souvent sur des règles déterministes basées sur des formats comme les numéros de téléphone ou les adresses e-mail
• Ces méthodes peuvent bien fonctionner dans un périmètre étroit, mais elles passent facilement à côté d’informations personnelles plus subtiles et gèrent mal le contexte
• Privacy Filter peut détecter un éventail plus large de PII dans le texte non structuré grâce à une compréhension plus fine de la langue et du contexte
• Il est conçu pour mieux distinguer les informations publiques qui doivent être conservées de celles qui sont rattachées à une personne et doivent être masquées ou supprimées
• Il a été développé avec l’objectif d’élever le niveau d’exigence en matière de protection de la vie privée au-delà de l’état de l’art existant, et une version fine-tunée est aussi utilisée dans des workflows internes de préservation de la vie privée

Architecture du modèle et périmètre de détection

• Il repose sur une architecture combinant un modèle de classification bidirectionnelle de tokens et un décodage de spans
• Il part d’un checkpoint préentraîné autorégressif, puis est adapté en classificateur de tokens sur un schéma fixe de labels de confidentialité
• Au lieu de générer le texte token par token, il étiquette toute la séquence d’entrée en une fois, puis reconstruit des spans cohérents via une procédure de Viterbi contrainte
• Cette architecture lui permet d’étiqueter tous les tokens en un seul forward pass, avec des caractéristiques de rapidité et d’efficacité élevées
• Il peut identifier les spans de PII en exploitant le contexte environnant, et le modèle public prend en charge jusqu’à 128 000 tokens de contexte
• Il est possible d’ajuster le point d’équilibre entre rappel et précision selon l’environnement de production
• Le modèle publié compte 1,5 milliard de paramètres au total, dont 50 M de paramètres actifs
• Les catégories prédites sont au nombre de huit : private_person, private_address, private_email, private_phone, private_url, private_date, account_number, secret
• account_number sert à masquer différents numéros de compte, y compris les numéros de carte bancaire et de compte bancaire, tandis que secret couvre des éléments comme les mots de passe et les clés API
• Les labels sont décodés sous forme de tags de spans BIOES pour produire des frontières de masquage plus propres et plus cohérentes

Processus d’entraînement et résultats d’évaluation

• Une taxonomie de confidentialité a d’abord été créée pour définir les types de spans que le modèle doit détecter
  • Elle inclut les identifiants personnels, les coordonnées, les adresses, les dates privées, différents numéros de compte incluant les informations bancaires et de crédit, ainsi que des secrets comme les clés API et les mots de passe
• La tête de language modeling du modèle de langage préentraîné a été remplacée par une tête de classification de tokens, puis le modèle a été poursuivi en apprentissage supervisé avec un objectif de classification
• L’entraînement mélange des données publiques et synthétiques afin de capturer à la fois des textes réalistes et des motifs de confidentialité difficiles
  • Dans les données publiques, les zones où les labels étaient incomplets ont été mieux couvertes via une annotation assistée par le modèle et une revue
  • Les exemples synthétiques ont servi à accroître la diversité des formats, des contextes et des sous-types de confidentialité
• À l’inférence, les prédictions au niveau des tokens sont converties en spans cohérents au moyen d’un décodage de séquence contraint
• L’évaluation combine des benchmarks standards et des évaluations synthétiques et conversationnelles supplémentaires visant des cas plus difficiles et sensibles au contexte
• Sur PII-Masking-300k, il obtient 96 % de F1, avec une précision de 94,04 % et un rappel de 98,04 %
• Sur une version corrigée reflétant des problèmes d’annotation relevés pendant la revue, il atteint 97,43 % de F1, avec une précision de 96,79 % et un rappel de 98,08 %
• Même avec peu de données, l’adaptation au domaine a été rapide, et le score de F1 est passé de 54 % à 96 % sur le benchmark d’adaptation au domaine évalué
• La model card inclut aussi des stress tests sur la détection de secrets dans des bases de code, ainsi que sur des exemples multilingues, adversariaux et dépendants du contexte

Limites et précautions d’usage

• Ce n’est pas un outil d’anonymisation, ni une certification de conformité, et il ne remplace pas la revue des politiques dans des environnements à haut risque
• Il s’inscrit comme un composant d’un système global conçu autour de la protection de la vie privée
• Son comportement dépend de la taxonomie de labels utilisée pour l’entraînement et des seuils de décision retenus
• Comme les politiques de détection et de masquage souhaitées peuvent varier selon les organisations, une évaluation dans le domaine ou un fine-tuning supplémentaire peut être nécessaire
• Les performances peuvent varier selon les langues, systèmes d’écriture, conventions de nommage et domaines différents de la distribution d’entraînement
• Il peut manquer des identifiants rares ou des références personnelles ambiguës, et notamment sur des séquences courtes où le contexte est limité, masquer trop ou pas assez
• Dans les domaines très sensibles comme le juridique, le médical ou la finance, la revue humaine, l’évaluation par domaine et le fine-tuning restent essentiels

Intention de publication et orientation future

• La protection de la vie privée est traitée comme un enjeu continu couvrant la recherche, la conception produit, l’évaluation et le déploiement
• Cela reflète l’importance de petits modèles efficaces capables d’atteindre des performances de niveau frontier sur des tâches réelles étroitement définies
• Cette publication vise à rendre l’infrastructure de préservation de la vie privée plus facile à auditer, exécuter, adapter et améliorer
• Le modèle se positionne comme un outil qui aide les modèles à apprendre sur le monde sans apprendre les informations privées des individus
• Cette publication en preview constitue aussi une étape destinée à recueillir les retours des communautés de recherche et de protection de la vie privée afin d’améliorer encore les performances

[GN⁺]

Commentaires sur Hacker News

• J’ai déjà implémenté ce genre de fonctionnalité il y a plusieurs années, et quelques points étaient clairs au final
  La purge des PII doit être réversible côté client si on veut préserver l’UX. Par exemple, si la personne s’appelle John mais que c’est masqué en [NAME], et que le modèle répond Hi [NAME], il faut restaurer Hi John avant d’afficher la réponse à l’utilisateur
  Au final, il faut donc un mécanisme de substitution inverse dans la couche avec laquelle l’utilisateur interagit
  Et les données PII masquées sont presque inutiles pour la plupart des usages. Un modèle a besoin d’un minimum de données réelles pour fonctionner, et comme énormément d’éléments sont classés comme PII, ça peut aller pour un simple chat, mais dès que l’utilisateur doit interagir de façon complexe avec un LLM, la difficulté augmente fortement. On peut soit ne plus rien pouvoir faire, soit provoquer des hallucinations
  Donc c’est pris en charge au niveau plateforme, mais en pratique c’est peu utilisé à cause de ces limites
  L’approche réaliste, à mon avis, consiste à supprimer seulement certaines PII à haut risque de sécurité, et à utiliser un modèle de confiance qui élimine les PII le plus vite possible. Mais cela suppose aussi une architecture système assez différente
• Je suis en train de créer https://github.com/KevinXuxuxu/anon_proxy, un outil qui ressemble à un proxy d’anonymisation placé devant un fournisseur de LLM
  J’utilise à la fois une détection par modèle et de la regex PII detection, et je gère le remplacement et la restauration dans les deux sens, sur les requêtes API comme sur les réponses. Si le modèle de détection est hébergé en local, les PII ne quittent jamais l’environnement local
  C’était particulièrement utile pour traiter des documents sensibles dans le juridique, la fiscalité ou l’immigration
  • L’avantage de cette approche, c’est qu’elle peut se brancher sur n’importe quel modèle
    En revanche, le contexte complet de la conversation reste visible pour le modèle et son opérateur
    Du coup, je préfère encore une approche qui chiffre l’ensemble, comme Moxie’s Confer https://confer.to/, de sorte que personne en dehors de l’utilisateur final ne puisse voir le texte en clair
  • Je me demande comment est gérée la restauration côté réponse
    Si un document a été masqué à l’entrée, la sortie du LLM contiendra elle aussi du contenu masqué ; je ne vois pas bien comment on enchaîne ensuite
• Cette version contient pas mal d’éléments techniquement intéressants
  Privacy Filter est présenté comme un token-classification model bidirectionnel avec du span decoding, initialisé à partir d’un checkpoint préentraîné autoregressive puis adapté en classifieur de tokens sur une taxonomie fixe de labels de confidentialité
  Au lieu de générer le texte token par token, il étiquette toute la séquence d’entrée en une seule fois, puis décode des spans cohérents via une procédure de Viterbi contrainte
  Le modèle publié ferait au total 1,5B de paramètres, dont 50M de paramètres actifs
  Ils expliquent aussi l’avoir obtenu en remplaçant la LM head d’un modèle de langue préentraîné par une token-classification head, puis en le post-entraînant avec un objectif de classification supervisée
  • Du coup, ça semble aussi exploitable pour repérer la position d’informations sensibles dans du texte non structuré, sans dépendre d’autres outils de détection de PII
    Il suffirait de faire passer le texte d’origine dans le filtre pour obtenir les spans, puis de les remapper sur le texte source afin de récupérer toute l’information de position des PII
• Ce n’est pas aussi intelligent qu’OpenAI, mais j’ai créé https://tools.nicklothian.com/webner/index.html, qui masque certaines PII dans le navigateur avec un NER basé sur BERT
  Ça marchait plutôt bien pour les usages que j’ai testés
  Le modèle d’OpenAI a l’air suffisamment petit, donc j’envisage de l’ajouter aussi à mon outil
  • Je viens de l’essayer sur un document, et il y a beaucoup de false positives, donc ça semble assez difficile à utiliser
    Sur un document markdown d’une centaine de lignes, il a considéré matter comme une organisation alors que c’est une partie de frontmatter, end comme une organisation alors que c’est une partie de frontend, et MCP aussi comme une organisation
    Il produisait souvent des résultats grammaticalement absurdes, du genre Following the discussion in , blahblah
    J’ai vraiment eu l’impression de revenir au NLP d’il y a 10 ans, et ça m’a rappelé à quel point spaCy était un excellent projet dans ce domaine
• Il faut être clair sur le fait que la quasi-totalité de ces modèles sont naïfs et rudimentaires
  Pour un message unique et neutre du type Hi, this is Bob., c’est généralement suffisant, mais dès qu’on accumule des données, je n’ai encore jamais vu d’outil de masquage des PII qui prenne vraiment en compte tous les risques de réidentification
  Et le problème devient sérieux au moment où des entreprises utilisent ce genre de chose en pensant que leurs données sont anonymisées. Ce n’est pas de l’anonymisation
  En revanche, pour des étapes intermédiaires comme la moderation, la human eval ou le model training, où les données ne sont pas immédiatement publiées ou partagées, ce type de filtrage peut être assez utile
• Je suis un peu déçu que les exemples soient en majorité des choses qu’on pourrait facilement capter avec des regex, mais je suis content de voir sortir un modèle local open source
  • Pour mes clients, j’empêche déjà via des expressions régulières que des e-mails personnels ou des numéros de téléphone apparaissent sur leurs sites web
    Cela dit, faire tourner ce modèle en plus pour se rassurer davantage semble raisonnable
    Je n’ai pas de GPU sur le serveur, donc j’espère que ce sera un modèle assez léger pour rester viable en CPU-only inference sous 2k tokens à la fois
• Quand on clique sur le lien, on est redirigé vers une version traduite automatiquement du site d’OpenAI, et le sens est complètement détruit
  redacted a été traduit par le polonais redagować, qui ne veut pas dire anonymiser mais plutôt éditer ou retoucher un texte
• Je me demande comment ça se compare à Presidio, qui mélange regex et modèles : https://microsoft.github.io/presidio/
  • Je me dis qu’on pourrait peut-être intégrer ce modèle dans Presidio
• Je pense que https://peyeeye.ai résout littéralement tous les problèmes dont tout le monde parle dans ce fil
  • Une entreprise qui a aspiré les données des autres sans autorisation et qui construit maintenant des outils de protection de la vie privée : l’ironie est énorme
• Cette publication est la bienvenue
  Même en dehors des secteurs régulés, il y a beaucoup de raisons d’avoir ce type de modèles et de pratiques, et en théorie une partie devient même nécessaire à cause de l’EU AI Act
  Sur https://grepture.com, j’ai déjà mis en place de la redaction et de la rehydration avec des modèles NER spécialisés, donc je pense aussi l’ajouter au pipeline
  Le fait de pouvoir le placer de manière sélective sur le hot path et intervenir concrètement avant et après qu’une requête atteigne le LLM est assez utile pour les scénarios de conformité ou ceux qui reçoivent directement des entrées utilisateur