openai/privacy-filterModello bidirezionale di token-classification per il rilevamento e la mascheratura di PII nel testo, con CLI per redazione, valutazione e finetuning on-premises.
OpenAI Privacy Filter è un modello bidirezionale di classificazione dei token per il rilevamento e la mascheratura di informazioni di identificazione personale (PII) nel testo. È pensato per flussi di lavoro di sanitizzazione dei dati ad alto throughput, in cui i team necessitano di un modello eseguibile on-premises che sia veloce, consapevole del contesto e regolabile.
OpenAI Privacy Filter è preaddestrato in modo autoregressivo per ottenere un checkpoint con un'architettura simile a gpt-oss, sebbene di dimensioni inferiori. Abbiamo poi convertito quel checkpoint in un classificatore bidirezionale di token su una tassonomia di etichette di privacy, e lo abbiamo post-addestrato con una loss di classificazione supervisionata. (Per i dettagli sull'architettura di gpt-oss, si veda la model card di gpt-oss.) Invece di generare testo token per token, questo modello etichetta una sequenza di input in un singolo forward pass, quindi decodifica span coerenti con una procedura Viterbi vincolata. Per ogni token di input, il modello predice una distribuzione di probabilità sulla tassonomia di etichette, che consiste di 8 categorie di output descritte di seguito.
Punti salienti:
Questo repository contiene il codice locale, la CLI e gli asset di esempio usati per eseguire, valutare ed effettuare il fine-tuning dei checkpoint di Privacy Filter. È pensato per i team che vogliono ispezionare direttamente l'implementazione e utilizzare il modello nel proprio ambiente.
Risorse del repository: License e Security Policy.
pip install -e .
Dopodiché, avrai uno script python opf che può essere eseguito direttamente o tramite python -m opf. Lo script può essere usato in 3 modi distinti, come descritto di seguito.
Per impostazione predefinita, opf cerca un modello nella directory indicata dalla variabile OPF_CHECKPOINT, oppure in ~/.opf/privacy_filter. Se un modello non viene trovato nella posizione ~/.opf/privacy_filter, verrà scaricato.
opf "Alice was born on 1990-01-02."
Il codice supporta l'esecuzione sia su GPU (per impostazione predefinita) sia su CPU. Per eseguire su CPU, usa il flag --device cpu:
opf --device cpu "Alice was born on 1990-01-02."
Per sovrascrivere il checkpoint predefinito, passa --checkpoint:
opf --checkpoint /path/to/checkpoint_dir "Alice was born on 1990-01-02."
La modalità di redazione supporta la redazione di un intero file in una sola volta
opf -f /path/to/file
La redazione può anche essere eseguita tramite pipe, per supportare one-liner complesse:
cat /path/to/file | grep -e 'some_pattern' | opf
Se non viene fornito alcun input, opf si avvierà in modalità interattiva. In questa modalità, per ogni esempio di input, la CLI stampa un output JSON strutturato, usando anteprime con codifica a colori ANSI se il terminale le supporta. Queste opzioni possono essere controllate tramite flag.
Consulta opf redact --help per ulteriori flag e informazioni sulla modalità di redazione.
opf eval examples/data/sample_eval_five_examples.jsonl
I fixture di valutazione di esempio sotto examples/data/sample_eval_five_examples*.jsonl sono solo dati di esempio sintetici e non descrivono persone reali o record sensibili reali. Vedi examples/data/README.md.
Consulta opf eval --help per ulteriori flag e informazioni sulla modalità di valutazione.
opf train /path/to/train.jsonl --output-dir /path/to/finetuned_checkpoint
Consulta opf train --help per ulteriori flag e informazioni sulla modalità di fine-tuning.
opf/__main__.py: entrypoint CLI unificato per le modalità redact, eval e train.opf/_api.py: API rivolta a Python sopra lo stack di runtime e decodifica.opf/_cli/: parsing degli argomenti da riga di comando e helper per il rendering nel terminale.opf/_core/: caricamento del runtime, conversione degli span e logica di decodifica condivisa.opf/_eval/: caricamento dei dataset, preprocessing, metriche e runner di valutazione.opf/_train/: parsing degli argomenti per il fine-tuning locale e runner di addestramento.opf/_model/: implementazione del transformer, configurazione del checkpoint e caricamento dei pesi.examples/data/: file di valutazione di esempio più dataset dimostrativi riproducibili per il fine-tuning.examples/scripts/finetuning/: harness dimostrativi eseguibili per il fine-tuning.FINETUNING.md: guida focalizzata sul flusso di lavoro di fine-tuning e sugli script dimostrativi.OUTPUT_SCHEMAS.md: formati dei payload di risposta JSON e di esportazione.EVAL_AND_OUTPUT_MODES.md: descrizione delle modalità di output per redazione e valutazione.Privacy Filter è un modello bidirezionale di classificazione dei token con decodifica degli span. È addestrato in fasi, iniziando con un preaddestramento autoregressivo. Il modello linguistico preaddestrato viene poi modificato e post-addestrato come classificatore bidirezionale di token con attenzione a bande di dimensione 128 (finestra di attenzione effettiva: 257 token incluso self). Ciò significa:
Architetturalmente, l'implementazione in questo repo è uno stack in stile transformer encoder con pre-norm, con:
d_model = 640.Rispetto agli approcci autoregressivi iterativi, questo design consente di etichettare tutti i token in un solo passaggio, il che migliora il throughput. Rispetto agli approcci classici di preaddestramento con masked-language-model, questa è una conversione post-addestramento di un modello autoregressivo anziché un setup nativo di masked-LM.
Privacy Filter può rilevare 8 categorie di span di privacy:
account_numberprivate_addressprivate_emailprivate_personprivate_phoneprivate_urlprivate_datesecretPer eseguire la classificazione dei token, ogni categoria di span non-background viene espansa in classi di token con tag di confine: B-<label>, I-<label>, E-<label>, S-<label>, più la classe di background, O. Quindi il numero totale di classi di output a livello di token è 33: 1 classe di background + 8 etichette di span * 4 tag di confine = 33 classi. Ciò significa che la testa di output emette 33 logit per ogni token. Per una sequenza di lunghezza T, l'output ha forma [T, 33]; per un batch di dimensione B, ha forma [B, T, 33].
Il vocabolario delle etichette dei token consiste nell'etichetta di background O più le varianti con tag BIOES di ciascuna categoria di privacy: account_number, private_address, private_email, private_person, private_phone, private_url, private_date e secret. In altre parole, per ogni categoria, il modello predice le forme B-, I-, E- e S- corrispondenti a span di inizio, interno, fine e token singolo. Al momento dell'inferenza, questi logit per token vengono decodificati in etichette di span BIOES coerenti usando una decodifica di sequenza vincolata.
Dopo che il classificatore di token produce i logit per token, decodifichiamo le etichette con un decoder Viterbi vincolato usando uno scoring di transizione a catena lineare, anziché prendere un argmax indipendente per ogni token. Il decoder impone transizioni di confine BIOES consentite e assegna un punteggio a percorsi di etichette completi con termini di inizio, transizione e fine, più sei parametri di bias di transizione che controllano la persistenza del background, l'ingresso nello span, la continuazione dello span, la chiusura dello span e il passaggio da confine a confine. Questa ottimizzazione globale del percorso è pensata per migliorare la coerenza degli span e la stabilità dei confini facendo dipendere ogni decisione sui token dalla struttura a livello di sequenza, non solo dai logit locali, specialmente in testi rumorosi o a formato misto dove le sole decisioni locali sui token possono produrre confini frammentati o incoerenti.
I parametri di Sequence Decoding possono scoraggiare la permanenza nel background mentre incoraggiano l'ingresso e la continuazione nello span, producendo una mascheratura più ampia e più contigua per un recall migliore, o viceversa per una precisione migliore. A runtime, gli utenti possono regolare i parametri che controllano questo compromesso.
Sviluppato da: OpenAI
Finanziato da: OpenAI
Condiviso da: OpenAI
Tipo di modello: Modello bidirezionale di classificazione dei token per il rilevamento di span di privacy
Lingua/e: Principalmente inglese; riportata una valutazione selezionata di robustezza multilingue
Licenza: Apache 2.0
Pesi del modello: https://huggingface.co/openai/privacy-filter
Model card: OpenAI Privacy Filter Model Card
Privacy Filter è un ausilio alla redazione e alla minimizzazione dei dati, non una garanzia di anonimizzazione, conformità o sicurezza. Un affidamento eccessivo sullo strumento come pretesa di anonimizzazione generalizzata rischierebbe di mancare gli obiettivi di privacy desiderati. Privacy Filter è utilizzato al meglio come uno dei molteplici livelli in un approccio olistico end-to-end di privacy-by-design.
Il modello identificherà solo span di dati personali che corrispondono alla tassonomia e alle definizioni delle etichette addestrate. I casi d'uso reali della privacy sono vari e complessi e le definizioni di policy di etichette e confini decisionali appropriati possono differire. Pertanto, le impostazioni predefinite del modello potrebbero non soddisfare i requisiti di governance specifici dell'organizzazione senza calibrazione/fine-tuning.
Privacy Filter non supporta la configurazione dinamica delle policy di etichette a runtime; invece, cambiare le policy richiede un ulteriore fine-tuning del modello. Il set nativo di etichette e i confini decisionali associati potrebbero non essere appropriati per ogni caso d'uso. Ad esempio, la policy di addestramento del modello mira a dare priorità agli identificatori personali, preservando spesso per design il contesto non fortemente legato alla persona; alcuni utenti potrebbero voler modificare questa scelta.
Le prestazioni possono calare su testo non inglese, script non latini, pattern di denominazione di gruppi protetti o domini fuori distribuzione rispetto all'addestramento del modello.
Come tutti i modelli, Privacy Filter può commettere errori, come: sotto-rilevamento di nomi personali non comuni, convenzioni di denominazione regionali, iniziali, riferimenti ricchi di titoli onorifici o identificatori specifici di dominio; sovra-redazione di entità pubbliche, organizzazioni, località o nomi comuni quando il contesto locale è ambiguo; confini di span frammentati o spostati in testi a formato misto, documenti lunghi o testi con molta punteggiatura e artefatti di layout; secret mancati per formati di credenziali nuovi, pattern di token specifici di progetto o secret divisi attraverso la sintassi circostante; e sovra-redazione di stringhe benigne ad alta entropia, placeholder, hash, credenziali di esempio o esempi sintetici che assomigliano a secret.
Queste limitazioni possono interagire con variazioni demografiche, regionali e di dominio. Ad esempio, nomi e identificatori sottorappresentati nei dati di addestramento, o che seguono convenzioni diverse dalla distribuzione di addestramento dominante, possono essere più facilmente mancati o delimitati in modo incoerente.
È opportuna ulteriore cautela in contesti ad alta sensibilità come flussi di lavoro medici, legali, finanziari, delle risorse umane, dell'istruzione e governativi. In questi contesti, sia i falsi negativi sia i falsi positivi possono essere costosi: gli span mancati possono esporre informazioni sensibili, mentre una mascheratura eccessiva può rimuovere contesto materiale necessario per revisione, audit o processi decisionali a valle.