openai/privacy-filterBidirektionales Token-Klassifikationsmodell zur Erkennung und Maskierung von PII in Text, mit CLI für Redaktion, Evaluierung und Finetuning vor Ort.
OpenAI Privacy Filter ist ein bidirektionales Token-Klassifikationsmodell zur Erkennung und Maskierung personenbezogener Daten (PII) in Text. Es ist für Workflows zur Datenbereinigung mit hohem Durchsatz gedacht, in denen Teams ein Modell benötigen, das sie lokal betreiben können und das schnell, kontextbewusst und anpassbar ist.
OpenAI Privacy Filter wird autoregressiv vortrainiert, um einen Checkpoint mit einer Architektur ähnlich zu gpt-oss zu erhalten, wenn auch in kleinerer Größe. Anschließend haben wir diesen Checkpoint in einen bidirektionalen Token-Klassifikator über eine Datenschutz-Label-Taxonomie umgewandelt und mit einem überwachten Klassifikationsverlust nachtrainiert. (Architekturdetails zu gpt-oss finden Sie in der gpt-oss-Modellkarte.) Anstatt Text Token für Token zu generieren, beschriftet dieses Modell eine Eingabesequenz in einem einzigen Vorwärtsdurchlauf und dekodiert dann kohärente Spans mit einem eingeschränkten Viterbi-Verfahren. Für jedes Eingabe-Token sagt das Modell eine Wahrscheinlichkeitsverteilung über die Label-Taxonomie voraus, die aus 8 unten beschriebenen Ausgabekategorien besteht.
Highlights:
Dieses Repository enthält den lokalen Code, die CLI und Beispiel-Assets, die zum Ausführen, Evaluieren und Finetunen von Privacy-Filter-Checkpoints verwendet werden. Es ist für Teams gedacht, die die Implementierung direkt untersuchen und das Modell in ihrer eigenen Umgebung betreiben möchten.
Repository-Ressourcen: und .
pip install -e .
Danach verfügen Sie über ein Python-Skript opf, das direkt oder über python -m opf ausgeführt werden kann. Das Skript kann auf drei verschiedene Arten verwendet werden, wie unten beschrieben.
Standardmäßig sucht opf nach einem Modell im Verzeichnis, auf das die Variable OPF_CHECKPOINT zeigt, oder unter ~/.opf/privacy_filter. Wenn kein Modell am Speicherort ~/.opf/privacy_filter gefunden wird, wird es heruntergeladen.
opf "Alice was born on 1990-01-02."
Der Code unterstützt die Ausführung sowohl auf GPU (standardmäßig) als auch auf CPU. Um auf CPU auszuführen, verwenden Sie das Flag --device cpu:
opf --device cpu "Alice was born on 1990-01-02."
Um den Standard-Checkpoint zu überschreiben, übergeben Sie --checkpoint:
opf --checkpoint /path/to/checkpoint_dir "Alice was born on 1990-01-02."
Der Redaktionsmodus unterstützt die Redaktion einer gesamten Datei auf einmal
opf -f /path/to/file
Die Redaktion kann auch über Pipes erfolgen, um komplexe Einzeiler zu unterstützen:
cat /path/to/file | grep -e 'some_pattern' | opf
Wenn keine Eingabe bereitgestellt wird, startet opf im interaktiven Modus. In diesem Modus gibt die CLI für jedes Eingabebeispiel eine strukturierte JSON-Ausgabe aus und verwendet ANSI-farbcodierte Vorschauen, wenn das Terminal diese unterstützt. Diese Optionen können über Flags gesteuert werden.
Weitere Flags und Informationen zum Redaktionsmodus finden Sie unter opf redact --help.
opf eval examples/data/sample_eval_five_examples.jsonl
Die Beispiel-Eval-Fixtures unter examples/data/sample_eval_five_examples*.jsonl sind ausschließlich synthetische Beispieldaten und beschreiben keine realen Personen oder realen sensiblen Datensätze. Siehe examples/data/README.md.
Weitere Flags und Informationen zum Evaluationsmodus finden Sie unter opf eval --help.
opf train /path/to/train.jsonl --output-dir /path/to/finetuned_checkpoint
Weitere Flags und Informationen zum Finetuning-Modus finden Sie unter opf train --help.
opf/__main__.py: einheitlicher CLI-Einstiegspunkt für die Modi redact, eval und train.opf/_api.py: Python-API über den Runtime- und Decoding-Stack.opf/_cli/: Parsing von Kommandozeilenargumenten und Hilfsfunktionen für die Terminal-Darstellung.opf/_core/: Runtime-Laden, Span-Konvertierung und gemeinsame Decoding-Logik.opf/_eval/: Laden von Datensätzen, Vorverarbeitung, Metriken und Evaluations-Runner.opf/_train/: Parsing von Argumenten für lokales Finetuning und Trainings-Runner.opf/_model/: Transformer-Implementierung, Checkpoint-Konfiguration und Laden von Gewichten.examples/data/: Beispiel-Eval-Dateien sowie reproduzierbare Finetuning-Demo-Datensätze.examples/scripts/finetuning/: ausführbare Finetuning-Demo-Harnesses.FINETUNING.md: fokussierter Finetuning-Workflow und Anleitung zu Demo-Skripten.OUTPUT_SCHEMAS.md: JSON-Antwort- und Export-Payload-Formate.EVAL_AND_OUTPUT_MODES.md: Beschreibung der Ausgabemodi für Redaktion und Evaluation.Privacy Filter ist ein bidirektionales Token-Klassifikationsmodell mit Span-Decoding. Es wird in Phasen trainiert, beginnend mit autoregressivem Pretraining. Das vortrainierte Sprachmodell wird dann modifiziert und als bidirektionaler Token-Klassifikator mit banded Attention der Bandgröße 128 (effektives Attention-Fenster: 257 Token einschließlich Self) nachtrainiert. Das bedeutet:
Architektonisch ist die Implementierung in diesem Repo ein Pre-Norm-Transformer-Encoder-Stack mit:
d_model = 640.Im Vergleich zu iterativen autoregressiven Ansätzen ermöglicht dieses Design, alle Token in einem Durchlauf zu labeln, was den Durchsatz verbessert. Im Vergleich zu klassischen Masked-Language-Model-Pretraining-Ansätzen handelt es sich um eine Post-Training-Konvertierung eines autoregressiven Modells statt um ein natives Masked-LM-Setup.
Privacy Filter kann 8 Kategorien von Datenschutz-Spans erkennen:
account_numberprivate_addressprivate_emailprivate_personprivate_phoneprivate_urlprivate_datesecretUm Token-Klassifikation durchzuführen, wird jede Nicht-Hintergrund-Span-Kategorie in boundary-getaggte Token-Klassen erweitert: B-<label>, I-<label>, E-<label>, S-<label>, plus die Hintergrundklasse O. Die Gesamtzahl der Token-Level-Ausgabeklassen beträgt also 33: 1 Hintergrundklasse + 8 Span-Labels * 4 Boundary-Tags = 33 Klassen. Das bedeutet, dass der Ausgabe-Head 33 Logits für jedes Token ausgibt. Für eine Sequenz der Länge T hat die Ausgabe die Form [T, 33]; für einen Batch der Größe B hat sie die Form [B, T, 33].
Das Token-Label-Vokabular besteht aus dem Hintergrund-Label O plus BIOES-getaggten Varianten jeder Datenschutzkategorie: account_number, private_address, private_email, private_person, private_phone, private_url, private_date und secret. Mit anderen Worten: Für jede Kategorie sagt das Modell die Formen B-, I-, E- und S- voraus, die Begin-, Inside-, End- und Single-Token-Spans entsprechen. Zur Inferenzzeit werden diese Pro-Token-Logits mithilfe von eingeschränktem Sequenz-Decoding in kohärente BIOES-Span-Labels dekodiert.
Nachdem der Token-Klassifikator Pro-Token-Logits erzeugt hat, dekodieren wir Labels mit einem eingeschränkten Viterbi-Decoder unter Verwendung von Linear-Chain-Transition-Scoring, anstatt für jedes Token ein unabhängiges Argmax zu verwenden. Der Decoder erzwingt erlaubte BIOES-Boundary-Übergänge und bewertet vollständige Label-Pfade mit Start-, Transition- und End-Termen sowie sechs Transition-Bias-Parametern, die Hintergrundpersistenz, Span-Eintritt, Span-Fortsetzung, Span-Abschluss und Boundary-zu-Boundary-Übergabe steuern. Diese globale Pfadoptimierung soll die Span-Kohärenz und Boundary-Stabilität verbessern, indem jede Token-Entscheidung von der Struktur auf Sequenzebene abhängt und nicht nur von lokalen Logits – insbesondere in verrauschtem Text oder Text mit gemischten Formaten, in dem lokale Token-Entscheidungen allein fragmentierte oder inkonsistente Boundaries erzeugen können.
Parameter des Sequenz-Decodings können davon abhalten, im Hintergrund zu bleiben, während sie Span-Eintritt und -Fortsetzung fördern, was zu breiterer und zusammenhängenderer Maskierung für verbesserten Recall führt – oder umgekehrt für verbesserte Precision. Zur Laufzeit können Benutzer Parameter abstimmen, die diese Abwägung steuern.
Entwickelt von: OpenAI
Finanziert von: OpenAI
Bereitgestellt von: OpenAI
Modelltyp: Bidirektionales Token-Klassifikationsmodell zur Erkennung von Datenschutz-Spans
Sprache(n): Primär Englisch; ausgewählte mehrsprachige Robustheitsbewertung berichtet
Lizenz: Apache 2.0
Modellgewichte: https://huggingface.co/openai/privacy-filter
Modellkarte: OpenAI Privacy Filter Model Card
Privacy Filter ist eine Hilfe zur Redaktion und Datenminimierung, keine Anonymisierungs-, Compliance- oder Sicherheitsgarantie. Ein übermäßiges Vertrauen auf das Tool als pauschale Anonymisierungsaussage würde das Risiko bergen, gewünschte Datenschutzziele zu verfehlen. Privacy Filter sollte am besten als eine von mehreren Ebenen in einem ganzheitlichen End-to-End-Ansatz nach dem Prinzip Privacy by Design verwendet werden.
Das Modell identifiziert nur personenbezogene Daten-Spans, die zur trainierten Label-Taxonomie und deren Definitionen passen. Reale Datenschutzanwendungsfälle sind vielfältig und komplex, und Definitionen geeigneter Label-Richtlinien und Entscheidungsgrenzen können sich unterscheiden. Daher entsprechen die Modellstandards möglicherweise nicht den organisationsspezifischen Governance-Anforderungen ohne Kalibrierung/Feinabstimmung.
Privacy Filter unterstützt keine dynamische Konfiguration von Label-Richtlinien zur Laufzeit; stattdessen erfordert eine Änderung der Richtlinien weiteres Finetuning des Modells. Das native Label-Set und die zugehörigen Entscheidungsgrenzen sind möglicherweise nicht für jeden Anwendungsfall geeignet. Beispielsweise zielt die Trainingsrichtlinie des Modells darauf ab, personenbezogene Identifikatoren zu priorisieren, und bewahrt konstruktionsbedingt oft Kontext, der nicht stark personenbezogen ist; einige Benutzer möchten diese Wahl möglicherweise anpassen.
Die Leistung kann bei nicht-englischem Text, nicht-lateinischen Schriften, Namensmustern geschützter Gruppen oder Domänen, die im Vergleich zum Modelltraining out of distribution liegen, sinken.
Wie alle Modelle kann Privacy Filter Fehler machen, wie zum Beispiel: Untererkennung seltener Personennamen, regionaler Namenskonventionen, Initialen, stark höflichkeitsformelhafter Referenzen oder domänenspezifischer Identifikatoren; Überredaktion öffentlicher Entitäten, Organisationen, Orte oder gebräuchlicher Substantive, wenn der lokale Kontext mehrdeutig ist; fragmentierte oder verschobene Span-Boundaries in Text mit gemischten Formaten, langen Dokumenten oder Text mit starker Interpunktion und Layout-Artefakten; verpasste Secrets bei neuartigen Credential-Formaten, projektspezifischen Token-Mustern oder Secrets, die über umgebende Syntax aufgeteilt sind; und Überredaktion harmloser hoch-entropischer Strings, Platzhalter, Hashes, Beispiel-Credentials oder synthetischer Beispiele, die Secrets ähneln.
Diese Einschränkungen können mit demografischen, regionalen und domänenspezifischen Variationen interagieren. Beispielsweise können Namen und Identifikatoren, die in den Trainingsdaten unterrepräsentiert sind oder Konventionen folgen, die von der dominanten Trainingsverteilung abweichen, eher übersehen oder inkonsistent begrenzt werden.
Zusätzliche Vorsicht ist in hochsensiblen Umgebungen wie medizinischen, rechtlichen, finanziellen, Personal-, Bildungs- und Regierungs-Workflows geboten. In diesen Umgebungen können sowohl False Negatives als auch False Positives kostspielig sein: Übersehene Spans können sensible Informationen offenlegen, während übermäßige Maskierung wesentlichen Kontext entfernen kann, der für Überprüfung, Auditing oder nachgelagerte Entscheidungsfindung benötigt wird.