openai/privacy-filterModèle de classification de tokens bidirectionnel pour la détection et le masquage des données personnelles (PII) dans le texte, avec une interface en ligne de commande pour la rédaction, l'évaluation et l'affinage sur site.
OpenAI Privacy Filter est un modèle de classification de tokens bidirectionnel pour la détection et le masquage d'informations personnellement identifiables (PII) dans le texte. Il est destiné aux flux de travail de désinfection de données à haut débit où les équipes ont besoin d'un modèle qu'elles peuvent exécuter sur site, rapide, sensible au contexte et ajustable.
OpenAI Privacy Filter est pré-entraîné de manière autorégressive pour aboutir à un checkpoint dont l'architecture est similaire à gpt-oss, bien que de taille plus réduite. Nous avons ensuite converti ce checkpoint en un classificateur de tokens bidirectionnel sur une taxonomie de labels de confidentialité, puis effectué un post-entraînement avec une perte de classification supervisée. (Pour les détails d'architecture concernant gpt-oss, veuillez consulter la fiche modèle gpt-oss.) Au lieu de générer du texte token par token, ce modèle étiquette une séquence d'entrée en une seule passe avant, puis décode des spans cohérents avec une procédure de Viterbi contrainte. Pour chaque token d'entrée, le modèle prédit une distribution de probabilité sur la taxonomie de labels, qui se compose de 8 catégories de sortie décrites ci-dessous.
Points forts :
Ce dépôt contient le code local, la CLI et les ressources d'exemple utilisés pour exécuter, évaluer et finetuner les checkpoints Privacy Filter. Il est destiné aux équipes qui souhaitent inspecter directement l'implémentation et exploiter le modèle dans leur propre environnement.
Ressources du dépôt : Licence et Politique de sécurité.
pip install -e .
Après cela, vous disposerez d'un script Python opf qui peut être exécuté directement ou via python -m opf. Le script peut être utilisé de 3 manières distinctes, comme décrit ci-dessous.
Par défaut, opf recherche un modèle dans le répertoire pointé par la variable OPF_CHECKPOINT, ou ~/.opf/privacy_filter. Si aucun modèle n'est trouvé à l'emplacement ~/.opf/privacy_filter, il sera téléchargé.
opf "Alice was born on 1990-01-02."
Le code prend en charge l'exécution à la fois sur GPU (par défaut) et sur CPU. Pour exécuter sur CPU, utilisez le flag --device cpu :
opf --device cpu "Alice was born on 1990-01-02."
Pour remplacer le checkpoint par défaut, passez --checkpoint :
opf --checkpoint /path/to/checkpoint_dir "Alice was born on 1990-01-02."
Le mode rédaction prend en charge la rédaction d'un fichier entier en une seule fois
opf -f /path/to/file
La rédaction peut également être effectuée via des pipes, pour prendre en charge des one-liners complexes :
cat /path/to/file | grep -e 'some_pattern' | opf
Si aucune entrée n'est fournie, opf démarrera en mode interactif. Dans ce mode, pour chaque exemple d'entrée, la CLI affiche une sortie JSON structurée, en utilisant des aperçus colorés par codes ANSI si le terminal les prend en charge. Ces options peuvent être contrôlées par des flags.
Consultez opf redact --help pour plus de flags et d'informations sur le mode rédaction.
opf eval examples/data/sample_eval_five_examples.jsonl
Les fixtures d'évaluation d'exemple sous examples/data/sample_eval_five_examples*.jsonl sont uniquement des données d'exemple synthétiques et ne décrivent pas de personnes réelles ni d'enregistrements sensibles réels. Voir examples/data/README.md.
Consultez opf eval --help pour plus de flags et d'informations sur le mode évaluation.
opf train /path/to/train.jsonl --output-dir /path/to/finetuned_checkpoint
Consultez opf train --help pour plus de flags et d'informations sur le mode finetuning.
opf/__main__.py : point d'entrée CLI unifié pour les modes redact, eval et train.opf/_api.py : API orientée Python au-dessus de la pile d'exécution et de décodage.opf/_cli/ : analyse des arguments en ligne de commande et aides au rendu terminal.opf/_core/ : chargement à l'exécution, conversion de spans et logique de décodage partagée.opf/_eval/ : chargement de jeux de données, prétraitement, métriques et exécuteurs d'évaluation.opf/_train/ : analyse des arguments de finetuning local et exécuteurs d'entraînement.opf/_model/ : implémentation du transformer, configuration du checkpoint et chargement des poids.examples/data/ : fichiers d'évaluation d'exemple ainsi que jeux de données de démonstration de finetuning reproductibles.examples/scripts/finetuning/ : harnais de démonstration de finetuning exécutables.FINETUNING.md : guide ciblé sur le flux de travail de finetuning et les scripts de démonstration.OUTPUT_SCHEMAS.md : formats de réponse JSON et de charge utile d'export.EVAL_AND_OUTPUT_MODES.md : description des modes de sortie pour la rédaction et l'évaluation.Privacy Filter est un modèle de classification de tokens bidirectionnel avec décodage de spans. Il est entraîné par phases, en commençant par un pré-entraînement autorégressif. Le modèle de langage pré-entraîné est ensuite modifié et post-entraîné comme un classificateur de tokens à attention bandée bidirectionnelle avec une taille de bande de 128 (fenêtre d'attention effective : 257 tokens, soi-même inclus). Cela signifie :
Sur le plan architectural, l'implémentation dans ce dépôt est une pile de type encodeur transformer pre-norm avec :
d_model = 640.Par rapport aux approches autorégressives itératives, cette conception permet d'étiqueter tous les tokens en une seule passe, ce qui améliore le débit. Par rapport aux approches classiques de pré-entraînement de type masked-language-model, il s'agit d'une conversion post-entraînement d'un modèle autorégressif plutôt que d'une configuration masked-LM native.
Privacy Filter peut détecter 8 catégories de spans de confidentialité :
account_numberprivate_addressprivate_emailprivate_personprivate_phoneprivate_urlprivate_datesecretPour effectuer la classification de tokens, chaque catégorie de span non-arrière-plan est étendue en classes de tokens marquées par des frontières : B-<label>, I-<label>, E-<label>, S-<label>, plus la classe d'arrière-plan, O. Ainsi, le nombre total de classes de sortie au niveau des tokens est de 33 : 1 classe d'arrière-plan + 8 labels de span * 4 balises de frontière = 33 classes. Cela signifie que la tête de sortie émet 33 logits pour chaque token. Pour une séquence de longueur T, la sortie a la forme [T, 33] ; pour un batch de taille B, elle a la forme [B, T, 33].
Le vocabulaire de labels de tokens se compose du label d'arrière-plan O plus les variantes marquées BIOES de chaque catégorie de confidentialité : account_number, private_address, private_email, private_person, private_phone, private_url, private_date et secret. En d'autres termes, pour chaque catégorie, le modèle prédit les formes B-, I-, E- et S- correspondant aux spans de début, intérieur, fin et token unique. Au moment de l'inférence, ces logits par token sont décodés en labels de spans BIOES cohérents à l'aide d'un décodage de séquence contraint.
Après que le classificateur de tokens a produit les logits par token, nous décodons les labels avec un décodeur de Viterbi contraint utilisant un scoring de transition en chaîne linéaire, plutôt que de prendre un argmax indépendant pour chaque token. Le décodeur impose les transitions de frontière BIOES autorisées et score les chemins de labels complets avec des termes de début, de transition et de fin, plus six paramètres de biais de transition qui contrôlent la persistance de l'arrière-plan, l'entrée dans un span, la continuation d'un span, la fermeture d'un span et le passage de frontière à frontière. Cette optimisation globale du chemin vise à améliorer la cohérence des spans et la stabilité des frontières en faisant dépendre chaque décision de token de la structure au niveau de la séquence, et pas seulement des logits locaux, en particulier dans les textes bruités ou à format mixte où les décisions locales par token peuvent produire des frontières fragmentées ou incohérentes.
Les paramètres de décodage de séquence peuvent décourager le maintien en arrière-plan tout en encourageant l'entrée et la continuation de spans, produisant un masquage plus large et plus contigu pour un meilleur rappel, ou inversement pour une meilleure précision. À l'exécution, les utilisateurs peuvent ajuster les paramètres qui contrôlent ce compromis.
Développé par : OpenAI
Financé par : OpenAI
Partagé par : OpenAI
Type de modèle : Modèle de classification de tokens bidirectionnel pour la détection de spans de confidentialité
Langue(s) : Principalement l'anglais ; évaluation de robustesse multilingue sélectionnée rapportée
Licence : Apache 2.0
Poids du modèle : https://huggingface.co/openai/privacy-filter
Fiche modèle : OpenAI Privacy Filter Model Card
Privacy Filter est une aide à la rédaction et à la minimisation des données, et non une garantie d'anonymisation, de conformité ou de sécurité. Une dépendance excessive à l'outil comme revendication d'anonymisation générale risquerait de manquer les objectifs de confidentialité souhaités. Privacy Filter est mieux utilisé comme l'une des multiples couches d'une approche holistique de confidentialité dès la conception.
Le modèle n'identifiera que les spans de données personnelles qui correspondent à la taxonomie et aux définitions de labels entraînées. Les cas d'usage réels de la confidentialité sont variés et complexes, et les définitions de politiques de labels et de frontières de décision appropriées peuvent différer. Ainsi, les valeurs par défaut du modèle peuvent ne pas satisfaire les exigences de gouvernance propres à une organisation sans calibration/finetuning.
Privacy Filter ne prend pas en charge la configuration dynamique des politiques de labels à l'exécution ; modifier les politiques nécessite à la place un finetuning supplémentaire du modèle. L'ensemble de labels natif et les frontières de décision associées peuvent ne pas convenir à chaque cas d'usage. Par exemple, la politique d'entraînement du modèle vise à prioriser les identifiants personnels, préservant souvent par conception le contexte qui n'est pas fortement lié à une personne ; certains utilisateurs peuvent souhaiter ajuster ce choix.
Les performances peuvent diminuer sur du texte non anglais, des scripts non latins, des schémas de nommage de groupes protégés, ou des domaines hors distribution par rapport à l'entraînement du modèle.
Comme tous les modèles, Privacy Filter peut commettre des erreurs, telles que : sous-détection de noms personnels peu courants, de conventions de nommage régionales, d'initiales, de références riches en titres honorifiques, ou d'identifiants spécifiques à un domaine ; sur-rédaction d'entités publiques, d'organisations, de lieux ou de noms communs lorsque le contexte local est ambigu ; frontières de spans fragmentées ou décalées dans du texte à format mixte, des documents longs, ou du texte comportant beaucoup de ponctuation et d'artefacts de mise en page ; secrets manqués pour de nouveaux formats d'identifiants, des schémas de tokens spécifiques à un projet, ou des secrets répartis à travers la syntaxe environnante ; et sur-rédaction de chaînes bénignes à haute entropie, d'espaces réservés, de hachages, d'identifiants d'exemple ou d'exemples synthétiques qui ressemblent à des secrets.
Ces limitations peuvent interagir avec les variations démographiques, régionales et de domaine. Par exemple, les noms et identifiants sous-représentés dans les données d'entraînement, ou qui suivent des conventions différentes de la distribution d'entraînement dominante, peuvent être plus susceptibles d'être manqués ou délimités de manière incohérente.
Une prudence supplémentaire est justifiée dans les contextes de haute sensibilité tels que les flux de travail médicaux, juridiques, financiers, de ressources humaines, éducatifs et gouvernementaux. Dans ces contextes, les faux négatifs comme les faux positifs peuvent être coûteux : les spans manqués peuvent exposer des informations sensibles, tandis qu'un masquage excessif peut supprimer un contexte matériel nécessaire à l'examen, à l'audit ou à la prise de décision en aval.