openai/privacy-filterModelo bidireccional de clasificación de tokens para la detección y enmascaramiento de PII en texto, con CLI para redacción, evaluación y ajuste fino on-premises.
OpenAI Privacy Filter es un modelo de clasificación de tokens bidireccional para la detección y el enmascaramiento de información de identificación personal (PII) en texto. Está pensado para flujos de trabajo de saneamiento de datos de alto rendimiento en los que los equipos necesitan un modelo que puedan ejecutar en sus propias instalaciones, que sea rápido, consciente del contexto y ajustable.
OpenAI Privacy Filter se preentrena de forma autorregresiva para llegar a un checkpoint con una arquitectura similar a la de gpt-oss, aunque de menor tamaño. Después convertimos ese checkpoint en un clasificador de tokens bidireccional sobre una taxonomía de etiquetas de privacidad y lo postentrenamos con una pérdida de clasificación supervisada. (Para obtener detalles sobre la arquitectura de gpt-oss, consulta la model card de gpt-oss). En lugar de generar texto token a token, este modelo etiqueta una secuencia de entrada en una única pasada hacia delante y luego decodifica spans coherentes con un procedimiento de Viterbi restringido. Para cada token de entrada, el modelo predice una distribución de probabilidad sobre la taxonomía de etiquetas, que consta de 8 categorías de salida descritas a continuación.
Aspectos destacados:
Este repositorio contiene el código local, la CLI y los recursos de ejemplo utilizados para ejecutar, evaluar y ajustar los checkpoints de Privacy Filter. Está pensado para equipos que quieran inspeccionar la implementación directamente y operar el modelo en su propio entorno.
Recursos del repositorio: Licencia y Política de seguridad.
pip install -e .
Después de esto, tendrás un script de Python opf que se puede ejecutar directamente o mediante python -m opf. El script se puede usar de 3 formas distintas, como se describe a continuación.
Por defecto, opf busca un modelo en el directorio al que apunta la variable OPF_CHECKPOINT, o en ~/.opf/privacy_filter. Si no se encuentra un modelo en la ubicación ~/.opf/privacy_filter, se descargará.
opf "Alice was born on 1990-01-02."
El código permite ejecutarse tanto en GPU (por defecto) como en CPU. Para ejecutarlo en CPU, usa el flag --device cpu:
opf --device cpu "Alice was born on 1990-01-02."
Para sobrescribir el checkpoint por defecto, pasa --checkpoint:
opf --checkpoint /path/to/checkpoint_dir "Alice was born on 1990-01-02."
El modo de redactado permite redactar un archivo completo de una vez
opf -f /path/to/file
El redactado también se puede realizar mediante pipes, para admitir one-liners complejos:
cat /path/to/file | grep -e 'some_pattern' | opf
Si no se proporciona ninguna entrada, opf se iniciará en modo interactivo. En este modo, para cada ejemplo de entrada, la CLI imprime una salida JSON estructurada, usando vistas previas con códigos de color ANSI si el terminal los admite. Estas opciones se pueden controlar mediante flags.
Consulta opf redact --help para obtener más flags e información sobre el modo de redactado.
opf eval examples/data/sample_eval_five_examples.jsonl
Los fixtures de evaluación de ejemplo bajo examples/data/sample_eval_five_examples*.jsonl son únicamente datos de ejemplo sintéticos y no describen personas reales ni registros sensibles reales. Consulta examples/data/README.md.
Consulta opf eval --help para obtener más flags e información sobre el modo de evaluación.
opf train /path/to/train.jsonl --output-dir /path/to/finetuned_checkpoint
Consulta opf train --help para obtener más flags e información sobre el modo de finetuning.
opf/__main__.py: punto de entrada unificado de la CLI para los modos redact, eval y train.opf/_api.py: API orientada a Python sobre la pila de runtime y decodificación.opf/_cli/: análisis de argumentos de línea de comandos y helpers de renderizado en terminal.opf/_core/: carga del runtime, conversión de spans y lógica de decodificación compartida.opf/_eval/: carga de conjuntos de datos, preprocesamiento, métricas y ejecutores de evaluación.opf/_train/: análisis de argumentos de finetuning local y ejecutores de entrenamiento.opf/_model/: implementación del transformer, configuración del checkpoint y carga de pesos.examples/data/: archivos de evaluación de ejemplo más conjuntos de datos de demostración de finetuning reproducibles.examples/scripts/finetuning/: harnesses ejecutables de demostración de finetuning.FINETUNING.md: guía centrada en el flujo de trabajo de finetuning y en los scripts de demostración.OUTPUT_SCHEMAS.md: formatos de respuesta JSON y de payload de exportación.EVAL_AND_OUTPUT_MODES.md: descripción de los modos de salida para redactado y evaluación.Privacy Filter es un modelo de clasificación de tokens bidireccional con decodificación de spans. Se entrena por fases, comenzando con un preentrenamiento autorregresivo. Después, el modelo de lenguaje preentrenado se modifica y se postentrena como un clasificador de tokens bidireccional con atención en bandas de tamaño 128 (ventana de atención efectiva: 257 tokens, incluido el propio token). Esto significa:
Arquitectónicamente, la implementación de este repositorio es una pila estilo encoder de transformer con pre-norm que incluye:
d_model = 640.En comparación con los enfoques autorregresivos iterativos, este diseño permite etiquetar todos los tokens en una sola pasada, lo que mejora el rendimiento. En comparación con los enfoques clásicos de preentrenamiento de modelos de lenguaje enmascarados, se trata de una conversión postentrenamiento de un modelo autorregresivo en lugar de una configuración nativa de masked-LM.
Privacy Filter puede detectar 8 categorías de spans de privacidad:
account_numberprivate_addressprivate_emailprivate_personprivate_phoneprivate_urlprivate_datesecretPara realizar la clasificación de tokens, cada categoría de span que no es de fondo se expande en clases de token etiquetadas por frontera: B-<label>, I-<label>, E-<label>, S-<label>, más la clase de fondo, O. Por lo tanto, el número total de clases de salida a nivel de token es 33: 1 clase de fondo + 8 etiquetas de span * 4 etiquetas de frontera = 33 clases. Esto significa que la cabeza de salida emite 33 logits por cada token. Para una secuencia de longitud T, la salida tiene forma [T, 33]; para un lote de tamaño B, tiene forma [B, T, 33].
El vocabulario de etiquetas de token consta de la etiqueta de fondo O más las variantes etiquetadas con BIOES de cada categoría de privacidad: account_number, private_address, private_email, private_person, private_phone, private_url, private_date y secret. En otras palabras, para cada categoría, el modelo predice las formas B-, I-, E- y S- correspondientes a spans de inicio, interior, fin y token único. En el momento de la inferencia, estos logits por token se decodifican en etiquetas de span BIOES coherentes mediante decodificación de secuencia restringida.
Después de que el clasificador de tokens produce logits por token, decodificamos las etiquetas con un decodificador de Viterbi restringido usando puntuación de transición de cadena lineal, en lugar de tomar un argmax independiente para cada token. El decodificador impone transiciones de frontera BIOES permitidas y puntúa rutas de etiquetas completas con términos de inicio, transición y fin, además de seis parámetros de sesgo de transición que controlan la persistencia en el fondo, la entrada en un span, la continuación de un span, el cierre de un span y el traspaso de frontera a frontera. Esta optimización global de rutas pretende mejorar la coherencia de los spans y la estabilidad de las fronteras haciendo que cada decisión sobre un token dependa de la estructura a nivel de secuencia, no solo de los logits locales, especialmente en texto ruidoso o de formato mixto donde las decisiones locales sobre tokens por sí solas pueden producir fronteras fragmentadas o inconsistentes.
Los parámetros de decodificación de secuencia pueden desincentivar permanecer en el fondo mientras fomentan la entrada y la continuación de spans, lo que produce un enmascaramiento más amplio y contiguo para mejorar la exhaustividad, o viceversa para mejorar la precisión. En tiempo de ejecución, los usuarios pueden ajustar los parámetros que controlan este compromiso.
Desarrollado por: OpenAI
Financiado por: OpenAI
Compartido por: OpenAI
Tipo de modelo: modelo de clasificación de tokens bidireccional para la detección de spans de privacidad
Idioma(s): principalmente inglés; se reporta una evaluación seleccionada de robustez multilingüe
Licencia: Apache 2.0
Pesos del modelo: https://huggingface.co/openai/privacy-filter
Model card: OpenAI Privacy Filter Model Card
Privacy Filter es una ayuda para el redactado y la minimización de datos, no una garantía de anonimización, cumplimiento o seguridad. Depender en exceso de la herramienta como una afirmación de anonimización general conllevaría el riesgo de no alcanzar los objetivos de privacidad deseados. Lo mejor es usar Privacy Filter como una de varias capas dentro de un enfoque holístico de privacidad desde el diseño de extremo a extremo.
El modelo solo identificará spans de datos personales que coincidan con la taxonomía de etiquetas y las definiciones con las que fue entrenado. Los casos de uso reales de privacidad son variados y complejos, y las definiciones de políticas de etiquetas y fronteras de decisión apropiadas pueden diferir. Por lo tanto, los valores predeterminados del modelo pueden no satisfacer los requisitos de gobernanza específicos de una organización sin calibración/finetuning.
Privacy Filter no admite configurar políticas de etiquetas dinámicamente en tiempo de ejecución; en su lugar, cambiar las políticas requiere un finetuning adicional del modelo. El conjunto de etiquetas nativo y las fronteras de decisión asociadas pueden no ser apropiados para todos los casos de uso. Por ejemplo, la política de entrenamiento del modelo pretende priorizar los identificadores personales, a menudo preservando por diseño contexto que no está fuertemente vinculado a personas; algunos usuarios podrían querer ajustar esta elección.
El rendimiento puede disminuir en texto que no esté en inglés, en escrituras no latinas, en patrones de nombres de grupos protegidos o en dominios que estén fuera de la distribución en comparación con el entrenamiento del modelo.
Como todos los modelos, Privacy Filter puede cometer errores, tales como: infradetección de nombres personales poco comunes, convenciones de nombres regionales, iniciales, referencias con muchos tratamientos honoríficos o identificadores específicos de un dominio; sobrerredacción de entidades públicas, organizaciones, ubicaciones o sustantivos comunes cuando el contexto local es ambiguo; fronteras de span fragmentadas o desplazadas en texto de formato mixto, documentos largos o texto con mucha puntuación y artefactos de maquetación; secretos no detectados para formatos de credenciales novedosos, patrones de tokens específicos de un proyecto o secretos divididos entre la sintaxis circundante; y sobrerredacción de cadenas benignas de alta entropía, marcadores de posición, hashes, credenciales de ejemplo o ejemplos sintéticos que se parecen a secretos.
Estas limitaciones pueden interactuar con la variación demográfica, regional y de dominio. Por ejemplo, los nombres e identificadores que están infrarrepresentados en los datos de entrenamiento, o que siguen convenciones diferentes de la distribución de entrenamiento dominante, pueden tener más probabilidades de no detectarse o de delimitarse de forma inconsistente.
Se justifica una precaución adicional en entornos de alta sensibilidad como flujos de trabajo médicos, legales, financieros, de recursos humanos, educativos y gubernamentales. En estos entornos, tanto los falsos negativos como los falsos positivos pueden ser costosos: los spans no detectados pueden exponer información sensible, mientras que el enmascaramiento excesivo puede eliminar contexto material necesario para la revisión, la auditoría o la toma de decisiones posteriores.