openai/privacy-filterModelo bidirecional de classificação de tokens para detecção e mascaramento de PII em texto, com CLI para redação, avaliação e ajuste fino on-premises.
O OpenAI Privacy Filter é um modelo bidirecional de classificação de tokens para detecção e mascaramento de informações de identificação pessoal (PII) em texto. Ele é destinado a fluxos de trabalho de sanitização de dados de alto rendimento, nos quais as equipes precisam de um modelo que possam executar localmente (on-premises), que seja rápido, sensível ao contexto e ajustável.
O OpenAI Privacy Filter é pré-treinado de forma autorregressiva para chegar a um checkpoint com arquitetura semelhante ao gpt-oss, embora de tamanho menor. Em seguida, convertemos esse checkpoint em um classificador bidirecional de tokens sobre uma taxonomia de rótulos de privacidade e realizamos pós-treinamento com uma perda de classificação supervisionada. (Para detalhes de arquitetura sobre o gpt-oss, consulte o model card do gpt-oss.) Em vez de gerar texto token a token, este modelo rotula uma sequência de entrada em uma única passagem direta (forward pass) e, em seguida, decodifica spans coerentes com um procedimento Viterbi restrito. Para cada token de entrada, o modelo prevê uma distribuição de probabilidade sobre a taxonomia de rótulos, que consiste em 8 categorias de saída descritas abaixo.
Destaques:
Este repositório contém o código local, a CLI e os ativos de exemplo usados para executar, avaliar e fazer fine-tuning de checkpoints do Privacy Filter. Ele é destinado a equipes que desejam inspecionar a implementação diretamente e operar o modelo em seu próprio ambiente.
Recursos do repositório: License e Security Policy.
pip install -e .
Depois disso, você terá um script Python opf que pode ser executado diretamente ou via python -m opf. O script pode ser usado de 3 maneiras distintas, conforme descrito abaixo.
Por padrão, opf procura um modelo no diretório apontado pela variável OPF_CHECKPOINT, ou em ~/.opf/privacy_filter. Se um modelo não for encontrado no local ~/.opf/privacy_filter, ele será baixado.
opf "Alice was born on 1990-01-02."
O código suporta execução tanto em GPU (por padrão) quanto em CPU. Para executar em CPU, use a flag --device cpu:
opf --device cpu "Alice was born on 1990-01-02."
Para substituir o checkpoint padrão, passe --checkpoint:
opf --checkpoint /path/to/checkpoint_dir "Alice was born on 1990-01-02."
O modo de redação suporta redigir um arquivo inteiro de uma só vez
opf -f /path/to/file
A redação também pode ser realizada via pipes, para suportar one-liners complexos:
cat /path/to/file | grep -e 'some_pattern' | opf
Se nenhuma entrada for fornecida, opf iniciará no modo interativo. Nesse modo, para cada exemplo de entrada, a CLI imprime uma saída JSON estruturada, usando pré-visualizações com códigos de cores ANSI se o terminal suportar. Essas opções podem ser controladas por flags.
Consulte opf redact --help para mais flags e informações sobre o modo de redação.
opf eval examples/data/sample_eval_five_examples.jsonl
Os fixtures de avaliação de exemplo em examples/data/sample_eval_five_examples*.jsonl são apenas dados sintéticos de exemplo e não descrevem pessoas reais ou registros sensíveis reais. Consulte examples/data/README.md.
Consulte opf eval --help para mais flags e informações sobre o modo de avaliação.
opf train /path/to/train.jsonl --output-dir /path/to/finetuned_checkpoint
Consulte opf train --help para mais flags e informações sobre o modo de fine-tuning.
opf/__main__.py: ponto de entrada unificado da CLI para os modos redact, eval e train.opf/_api.py: API voltada para Python sobre a pilha de runtime e decodificação.opf/_cli/: análise de argumentos de linha de comando e auxiliares de renderização de terminal.opf/_core/: carregamento de runtime, conversão de spans e lógica de decodificação compartilhada.opf/_eval/: carregamento de conjuntos de dados, pré-processamento, métricas e executores de avaliação.opf/_train/: análise de argumentos de fine-tuning local e executores de treinamento.opf/_model/: implementação do transformer, configuração de checkpoint e carregamento de pesos.examples/data/: arquivos de avaliação de exemplo e conjuntos de dados de demonstração de fine-tuning reproduzíveis.examples/scripts/finetuning/: harnesses executáveis de demonstração de fine-tuning.FINETUNING.md: guia focado no fluxo de trabalho de fine-tuning e nos scripts de demonstração.OUTPUT_SCHEMAS.md: formatos de resposta JSON e payload de exportação.EVAL_AND_OUTPUT_MODES.md: descrição dos modos de saída para redação e avaliação.O Privacy Filter é um modelo bidirecional de classificação de tokens com decodificação de spans. Ele é treinado em fases, começando com pré-treinamento autorregressivo. O modelo de linguagem pré-treinado é então modificado e pós-treinado como um classificador bidirecional de tokens com atenção em banda (banded attention) de tamanho de banda 128 (janela de atenção efetiva: 257 tokens, incluindo o próprio). Isso significa:
Arquiteturalmente, a implementação neste repositório é uma pilha no estilo encoder transformer com pré-norm, com:
d_model = 640.Em relação a abordagens autorregressivas iterativas, este design permite que todos os tokens sejam rotulados em uma única passagem, o que melhora o rendimento. Em relação a abordagens clássicas de pré-treinamento de modelos de linguagem mascarados (masked-LM), esta é uma conversão pós-treinamento de um modelo autorregressivo, em vez de uma configuração nativa de masked-LM.
O Privacy Filter pode detectar 8 categorias de spans de privacidade:
account_numberprivate_addressprivate_emailprivate_personprivate_phoneprivate_urlprivate_datesecretPara realizar a classificação de tokens, cada categoria de span que não seja de fundo (background) é expandida em classes de tokens com marcação de fronteira: B-<label>, I-<label>, E-<label>, S-<label>, além da classe de fundo, O. Portanto, o número total de classes de saída em nível de token é 33: 1 classe de fundo + 8 rótulos de span * 4 tags de fronteira = 33 classes. Isso significa que a cabeça de saída emite 33 logits para cada token. Para uma sequência de comprimento T, a saída tem formato [T, 33]; para um lote de tamanho B, tem formato [B, T, 33].
O vocabulário de rótulos de tokens consiste no rótulo de fundo O mais variantes com tags BIOES de cada categoria de privacidade: account_number, private_address, private_email, private_person, private_phone, private_url, private_date e secret. Em outras palavras, para cada categoria, o modelo prevê as formas B-, I-, E- e S- correspondentes a spans de início, interior, fim e token único. No momento da inferência, esses logits por token são decodificados em rótulos de span BIOES coerentes usando decodificação de sequência restrita.
Depois que o classificador de tokens produz logits por token, decodificamos os rótulos com um decodificador Viterbi restrito usando pontuação de transição em cadeia linear, em vez de tomar um argmax independente para cada token. O decodificador impõe transições de fronteira BIOES permitidas e pontua caminhos de rótulos completos com termos de início, transição e fim, além de seis parâmetros de viés de transição que controlam a persistência no fundo, a entrada em span, a continuação de span, o fechamento de span e a passagem de fronteira para fronteira. Essa otimização global de caminho visa melhorar a coerência de spans e a estabilidade de fronteiras, fazendo com que cada decisão de token dependa da estrutura em nível de sequência, e não apenas de logits locais, especialmente em textos ruidosos ou de formato misto, nos quais decisões locais de token isoladas podem produzir fronteiras fragmentadas ou inconsistentes.
Os parâmetros de decodificação de sequência podem desencorajar a permanência no fundo enquanto incentivam a entrada e a continuação de spans, produzindo mascaramento mais amplo e mais contíguo para melhorar o recall, ou vice-versa para melhorar a precisão. Em tempo de execução, os usuários podem ajustar os parâmetros que controlam esse tradeoff.
Desenvolvido por: OpenAI
Financiado por: OpenAI
Compartilhado por: OpenAI
Tipo de modelo: Modelo bidirecional de classificação de tokens para detecção de spans de privacidade
Idioma(s): Principalmente inglês; avaliação selecionada de robustez multilíngue reportada
Licença: Apache 2.0
Pesos do modelo: https://huggingface.co/openai/privacy-filter
Model card: OpenAI Privacy Filter Model Card
O Privacy Filter é um auxiliar de redação e minimização de dados, não uma garantia de anonimização, conformidade ou segurança. A dependência excessiva da ferramenta como uma alegação abrangente de anonimização correria o risco de não atingir os objetivos de privacidade desejados. O Privacy Filter é melhor usado como uma das múltiplas camadas em uma abordagem holística de privacidade desde a concepção (privacy-by-design) de ponta a ponta.
O modelo identificará apenas spans de dados pessoais que correspondam à taxonomia e às definições de rótulos treinadas. Casos de uso reais de privacidade são variados e complexos, e as definições de políticas de rótulos e fronteiras de decisão apropriadas podem diferir. Assim, os padrões do modelo podem não satisfazer requisitos de governança específicos da organização sem calibração/fine-tuning.
O Privacy Filter não suporta a configuração dinâmica de políticas de rótulos em tempo de execução; em vez disso, alterar políticas exige fine-tuning adicional do modelo. O conjunto nativo de rótulos e as fronteiras de decisão associadas podem não ser apropriados para todos os casos de uso. Por exemplo, a política de treinamento do modelo visa priorizar identificadores pessoais, muitas vezes preservando, por design, contexto que não está fortemente vinculado a uma pessoa; alguns usuários podem querer ajustar essa escolha.
O desempenho pode cair em textos que não estejam em inglês, em scripts não latinos, em padrões de nomenclatura de grupos protegidos ou em domínios que estejam fora da distribuição em comparação com o treinamento do modelo.
Como todos os modelos, o Privacy Filter pode cometer erros, tais como: subdetecção de nomes pessoais incomuns, convenções regionais de nomenclatura, iniciais, referências com muitos títulos honoríficos ou identificadores específicos de domínio; sobredetecção (over-redaction) de entidades públicas, organizações, localizações ou substantivos comuns quando o contexto local é ambíguo; fronteiras de span fragmentadas ou deslocadas em textos de formato misto, documentos longos ou textos com muita pontuação e artefatos de layout; segredos não detectados para formatos de credenciais novos, padrões de tokens específicos de projeto ou segredos divididos pela sintaxe ao redor; e sobredetecção de strings benignas de alta entropia, placeholders, hashes, credenciais de exemplo ou exemplos sintéticos que se assemelham a segredos.
Essas limitações podem interagir com variação demográfica, regional e de domínio. Por exemplo, nomes e identificadores sub-representados nos dados de treinamento, ou que seguem convenções diferentes da distribuição de treinamento dominante, podem ter maior probabilidade de serem perdidos ou delimitados de forma inconsistente.
Cuidado adicional é justificado em ambientes de alta sensibilidade, como fluxos de trabalho médicos, jurídicos, financeiros, de recursos humanos, educacionais e governamentais. Nesses ambientes, tanto falsos negativos quanto falsos positivos podem ser custosos: spans perdidos podem expor informações sensíveis, enquanto o mascaramento excessivo pode remover contexto material necessário para revisão, auditoria ou tomada de decisão downstream.