6 pontos por GN⁺ 14 일 전 | 1 comentários | Compartilhar no WhatsApp
  • Um modelo open-weight para detectar e mascarar informações de identificação pessoal em texto não estruturado, que pode ser executado localmente para que os dados não saiam do dispositivo antes da filtragem
  • Combina classificação bidirecional de tokens com span decoding para rotular toda a entrada de uma vez e foi projetado para reconstruir rapidamente spans de PII em contextos de até 128.000 tokens
  • Diferentemente de abordagens baseadas em regras que dependem do formato de telefone ou e-mail, faz melhor distinção entre informações públicas e dados que precisam ser mascarados com base em compreensão de idioma e contexto
  • Foi treinado com dados públicos e sintéticos; registrou F1 de 96% no PII-Masking-300k e F1 de 97,43% na versão corrigida, e a adaptação de domínio subiu de 54% para 96% mesmo com pouco volume de dados
  • Não é um substituto para ferramentas de anonimização nem para certificações de compliance, e em áreas altamente sensíveis a revisão humana, a avaliação por domínio e o ajuste fino adicional continuam sendo importantes

Visão geral do produto e forma de distribuição

  • Um modelo open-weight especializado em detecção e ocultação de informações de identificação pessoal, capaz de encontrar PII em texto para mascará-las ou removê-las
  • Suporta execução local, permitindo que os dados não saiam do dispositivo antes da filtragem e reduzindo o risco de exposição em comparação com o envio a um servidor para desidentificação
  • Foi projetado para processar entradas longas rapidamente e decidir o que deve ser ocultado em uma única passada
  • Desenvolvedores podem executá-lo em seu próprio ambiente e ajustá-lo aos seus casos de uso para inserir proteções de privacidade mais fortes em pipelines de treinamento, indexação, logging e revisão
  • Foi disponibilizado no Hugging Face e no GitHub sob licença Apache 2.0, pensando em experimentação, customização e implantação comercial

O que o diferencia das abordagens existentes

  • Ferramentas tradicionais de detecção de PII costumam depender de regras determinísticas para formatos como número de telefone ou endereço de e-mail
  • Esse método pode funcionar bem em um escopo limitado, mas tende a perder dados pessoais mais sutis e é fraco no tratamento de contexto
  • O Privacy Filter consegue detectar uma faixa mais ampla de PII em texto não estruturado com base em uma compreensão mais profunda de idioma e contexto
  • Foi projetado para distinguir melhor entre informações públicas que devem ser preservadas e dados ligados a indivíduos que precisam ser mascarados ou removidos
  • Foi desenvolvido com o objetivo de elevar o padrão de privacidade além do nível existente, e uma versão ajustada também está sendo usada em workflows internos de preservação de privacidade

Arquitetura do modelo e escopo de detecção

  • Usa uma arquitetura que combina um modelo bidirecional de classificação de tokens com span decoding
  • Parte de um checkpoint pré-treinado autorregressivo e depois é adaptado como classificador de tokens sobre um esquema fixo de rótulos de privacidade
  • Em vez de gerar o texto token por token, rotula toda a sequência de entrada de uma vez e depois reconstrói spans consistentes com um procedimento Viterbi restrito
  • Graças a essa arquitetura, apresenta características de alta velocidade e alta eficiência, rotulando todos os tokens em um único forward pass
  • Pode determinar spans de PII usando o contexto ao redor, e o modelo público suporta contexto de até 128.000 tokens
  • É possível ajustar o ponto de equilíbrio entre recall e precisão de acordo com o ambiente operacional
  • O modelo publicado tem 1,5 bilhão de parâmetros no total, com 50M de parâmetros ativos
  • As categorias previstas são oito: private_person, private_address, private_email, private_phone, private_url, private_date, account_number e secret
  • account_number é usado para ocultar vários tipos de números de conta, incluindo números de cartão de crédito e contas bancárias, enquanto secret cobre itens como senhas e chaves de API
  • Os rótulos são decodificados como tags de span BIOES, criando limites de mascaramento mais limpos e consistentes

Processo de treinamento e resultados de avaliação

  • Primeiro foi criada uma taxonomia de privacidade para definir os tipos de spans que o modelo deve detectar
    • Inclui identificadores pessoais, informações de contato, endereços, datas privadas, vários números de conta com dados de crédito e bancários, além de segredos como chaves de API e senhas
  • Depois de substituir a language modeling head do modelo de linguagem pré-treinado por uma token-classification head, ele passou por treinamento adicional com objetivo supervisionado de classificação
  • Foi treinado com uma mistura de dados públicos e sintéticos para capturar ao mesmo tempo textos realistas e padrões de privacidade desafiadores
    • Em dados públicos, partes com rotulagem incompleta tiveram a cobertura ampliada com anotações assistidas por modelo e revisão
    • Exemplos sintéticos foram usados para aumentar a diversidade de formatos, contexto e subtipos de privacidade
  • Na inferência, previsões no nível de token são convertidas em spans consistentes por meio de decodificação de sequência restrita
  • Foram realizadas tanto avaliações em benchmarks padrão quanto avaliações adicionais sintéticas e em formato de chat voltadas a casos mais difíceis e sensíveis ao contexto
  • No PII-Masking-300k, registrou F1 de 96%, precisão de 94,04% e recall de 98,04%
  • Na versão corrigida, que reflete problemas de anotação do dataset identificados durante a revisão, registrou F1 de 97,43%, precisão de 96,79% e recall de 98,08%
  • Mesmo com pouco volume de dados, a adaptação de domínio ocorreu rapidamente, e o F1 subiu de 54% para 96% no benchmark de adaptação de domínio avaliado
  • O model card também traz testes de estresse para detecção de segredos em codebases e exemplos multilíngues, adversariais e dependentes de contexto

Limitações e cuidados de uso

  • Não é uma ferramenta de anonimização, nem uma certificação de compliance, e também não substitui revisão de políticas em ambientes de alto risco
  • Deve ser tratado como um componente de um sistema mais amplo com design voltado à privacidade
  • Suas características de funcionamento são influenciadas pela taxonomia de rótulos usada no treinamento e pelos limites de decisão adotados
  • Como cada organização pode querer políticas diferentes de detecção e mascaramento, pode ser necessário fazer avaliação no domínio ou ajuste fino adicional
  • O desempenho pode variar em idiomas, sistemas de escrita, convenções de nomes e domínios diferentes da distribuição usada no treinamento
  • Pode deixar passar identificadores raros ou referências pessoais ambíguas e, especialmente quando o contexto é limitado, como em sequências curtas, pode mascarar demais ou de menos
  • Em áreas altamente sensíveis como direito, saúde e finanças, a revisão humana, a avaliação específica por domínio e o ajuste fino continuam sendo importantes

Intenção da divulgação e direção futura

  • A proteção de privacidade é tratada como um desafio contínuo que atravessa pesquisa, design de produto, avaliação e implantação
  • Reflete a importância de modelos pequenos e eficientes que entregam desempenho de ponta em tarefas reais definidas de forma estreita
  • Foi divulgado com o objetivo de tornar a infraestrutura de preservação de privacidade mais fácil de auditar, executar, adaptar e melhorar
  • É posicionado como uma ferramenta para ajudar modelos a aprender sobre o mundo sem aprender informações privadas de indivíduos
  • Esta divulgação em preview também é uma etapa para receber feedback da comunidade de pesquisa e privacidade e melhorar ainda mais o desempenho

1 comentários

 
GN⁺ 14 일 전
Comentários do Hacker News
  • Esse tipo de recurso já foi implementado anos atrás, e o resultado deixou algumas coisas bem claras
    A sanitização de PII precisa ser revertida no cliente para manter a UX. Por exemplo, se o nome é John e ele foi ocultado como [NAME], quando o modelo responder Hi [NAME], isso precisa ser restaurado para Hi John antes de mostrar ao usuário
    No fim, a camada com a qual o usuário interage precisa de um mecanismo de substituição reversa
    Além disso, dados de PII mascarados são quase inúteis para a maioria dos objetivos. O modelo precisa de algum nível de dados reais para funcionar, e há tantos itens classificados como PII que um chat simples até funciona, mas quando o usuário precisa interagir de forma complexa com o LLM a dificuldade aumenta muito. Pode simplesmente não funcionar ou gerar hallucination
    Por isso existe suporte em nível de plataforma, mas na prática é pouco usado por causa dessas limitações
    A abordagem mais realista, na minha visão, é remover só parte das PII com maior risco de segurança e usar um modelo confiável que descarte a PII o mais rápido possível. Para isso, a arquitetura do sistema também precisa mudar bastante
  • Estou criando o https://github.com/KevinXuxuxu/anon_proxy, uma espécie de proxy de anonimização colocado na frente do provedor de LLM
    Ele usa detecção baseada em modelo junto com regex PII detection e faz substituição e restauração nos dois sentidos, tanto nas requisições quanto nas respostas da API. Se o modelo de detecção for hospedado localmente, a PII não sai do ambiente local
    Foi especialmente útil ao lidar com documentos sensíveis como os de direito, impostos e imigração
    • O lado bom dessa abordagem é que ela pode ser conectada a qualquer modelo
      Ainda assim, o contexto inteiro da conversa continua visível para o modelo e para o operador
      Por isso eu prefiro uma abordagem como a do Confer, da Moxie https://confer.to/, que criptografa tudo para que ninguém além do usuário final possa ver o texto em claro
    • Fico curioso sobre como funciona a restauração do lado da resposta
      Se o documento foi mascarado na entrada, a saída do LLM também vai conter o conteúdo mascarado; então não entendo bem como isso continua depois
  • Este release tem várias partes tecnicamente interessantes
    O Privacy Filter é um modelo de classificação de tokens bidirecional com span decoding, e dizem que ele começa de um checkpoint pré-treinado autoregressivo e foi adaptado como classificador de tokens sobre uma taxonomia fixa de labels de privacidade
    Em vez de gerar texto token por token, ele rotula a sequência de entrada de uma vez só e decodifica spans consistentes com um procedimento Viterbi restrito
    O modelo publicado tem 1,5 bilhão de parâmetros no total, com 50M de parâmetros ativos
    Também foi informado que ele foi criado trocando a LM head do modelo de linguagem pré-treinado por uma token-classification head e depois fazendo pós-treinamento com um objetivo supervisionado de classificação
    • Então parece que isso também poderia ser usado para encontrar a posição de informações sensíveis em texto não estruturado, sem depender de outras ferramentas de detecção de PII
      Se você passar o texto original pelo filtro para obter os spans e depois mapear esses spans de volta ao texto original, no fim terá toda a localização da PII
  • Não é tão esperto quanto o da OpenAI, mas eu criei o https://tools.nicklothian.com/webner/index.html, que mascara algumas PII no navegador com NER baseado em BERT
    Funcionou muito bem para os usos que testei
    Como o modelo da OpenAI parece pequeno o bastante, estou pensando em acoplar isso também à minha ferramenta
    • Acabei de testar no documento e parece bem difícil de usar por causa da quantidade de false positive
      Coloquei um documento markdown de umas 100 linhas e ele classificou matter como organização por fazer parte de frontmatter, end também como organização por fazer parte de frontend, e MCP igualmente como organização
      Havia muitos resultados gramaticalmente sem sentido, como Following the discussion in , blahblah
      Dá uma sensação de voltar aos tempos do NLP de 10 anos atrás, e isso me fez lembrar de novo como o spaCy foi um projeto tão bom nessa área
  • É importante deixar claro que quase todos os modelos desse tipo são ingênuos e básicos
    Para uma mensagem única e neutra como Hi, this is Bob., normalmente já basta, mas quando os dados começam a se acumular eu ainda não vi uma ferramenta de redaction de PII que leve em conta todo o risco de vazamento de identidade
    O problema cresce quando empresas usam isso e passam a acreditar que os dados foram anonimizados. Isso não é anonimização
    Ainda assim, esse tipo de filtragem pode ser bem útil quando não se trata de publicar ou compartilhar os dados diretamente, mas de usá-los em etapas intermediárias de processamento como moderation, human eval e model training
  • É um pouco decepcionante que a maioria dos exemplos seja de coisas que regex já pegaria facilmente, mas é bom ver isso sendo lançado como modelo local aberto
    • Para os meus clientes, eu já impeço com expressões regulares que e-mails pessoais ou números de telefone sejam publicados no site
      Mesmo assim, parece razoável rodar um modelo desses junto para ter uma garantia extra
      Não tenho GPU no servidor, mas espero que seja um modelo leve o suficiente para dar conta de inferência só em CPU se for menos de 2k tokens por vez
  • Ao clicar no link, ele redireciona para uma versão de tradução automática do site da OpenAI, e o sentido fica completamente arruinado
    redacted foi traduzido pelo polonês redagować, que significa mais editar ou lapidar um texto do que anonimizar
  • Fico curioso para saber como isso se compara ao Presidio, que mistura regex e modelo: https://microsoft.github.io/presidio/
    • Acho que talvez desse para colocar esse modelo dentro do Presidio
  • Acho que o https://peyeeye.ai resolve literalmente todos os problemas que o pessoal desta thread está comentando
    • Uma empresa que raspou dados dos outros sem permissão fazendo uma ferramenta de privacidade — a ironia é grande demais
  • Fico feliz com esta divulgação
    Mesmo fora de setores regulados, há muitos motivos para ter esse tipo de modelo e prática, e em teoria parte disso passa a ser necessário também por causa do EU AI Act
    Eu já coloquei redaction e rehydration no https://grepture.com com um modelo NER especializado, então pretendo adicionar isso ao pipeline também
    Se der para colocá-lo opcionalmente no hot path e realmente mexer nas requisições antes e depois de chegarem ao LLM, isso pode ser bem útil em cenários de compliance ou com entrada direta de usuários