Palavra De Baixo Calão Ou Escalão

Como montar um sistema de filtragem de palavras ofensivas no Python

Eu passei três dias refazendo o filtro do nosso app porque a versão 1 apagava sotaques e deixava passar variações tipo "pf" escrito com ponto. A solução final ficou num script de 87 linhas que roda em menos de 40ms para 50 mil mensagens por segundo numão i5. Vou mostrar o caminho que funcionou, sem rodeiro. O erro mais comum não é não saber detectar a palavra, mas não saber escalar a resposta. Existe uma diferença enorme entre bloquear um "porra" num chat público e apenas marcar um "caralho" num fórum fechado. Quem implementa filtro pela primeira vez costuma fazer tudo ou nada. A consequência é either bloquear conversa normal ou deixar passar coisa que dá dor de cabeça pro suporte. No meu caso, o problema específico foi com agraphia variável. Um usuário escreveu "ch@" e o regex ingênuo não pegou. Outro usou letras cirílicas para disfarçar "foder" — isso exige normalização Unicode antes de qualquer comparação. A workaround que eu apliquei foi converter tudo para NFKC (normalização de compatibilidade), mapear caracteres latinos para ASCII e depois aplicar o filtro. Depois disso, resolvi o problema das variação fonéticas com um dicionário de substituições mapeando "k" para "c", "x" para "ch", e assim por diante. O resultado foi uma taxa de false positive que caiu de 12% para 3%.

Arquitetura que eu uso na prática

Não precisa de ML. A maioria dos projetos sobrevive com uma lista de termos + regex + um sistema de scoring por escalão. O pipeline que eu recomendo é simples: Primeiro, recebe o texto. Depois, normaliza com unicodedata.normalize('NFKC', texto). Em seguida, translitera para ASCII usando uma função própria que cobre os casos mais comuns de substituição. Por fim, passa pelo dicionário de palavras proibidas e aplica a pontuação de escalão. O dicionário em si fica num arquivo JSON separado. Isso permite atualizar sem restart. Eu separei os termos em três escalões: Amarelo (aviso), Laranja (moderação manual) e Vermelho (banimento automático). O escalão amarelo é para termos regionalismos que só são ofensivos em certos contextos. O laranja para xingamentos padrão. O vermelho para discurso de ódio e termos ilegais. Cada escalão tem um peso diferente no scoring final.

A parte mais importante é o contexto. "QueMerda" dito como surpresa é diferente de "merda de pessoa" dito como ataque. Eu implementei um analizador de bigrama simples que olha a palavra anterior e posterior para ajustar o score. Se a palavra está cercada por termos intensificadores como "muito", "tão", "uma porção de", o score sobe 50%. Se está em estrutura interrogativa ou explitiva neutra, o score desce 30%.

Código completo

Aqui está a implementação. Não é bonita, mas funciona. O arquivo dictionary.json segue este formato. Cada termo tem level (amarelo, laranja, vermelho), severity (1 a 10), e opcionalmente uma categoria para análise posterior. Esse sistema não é perfeito. Ele falha com textos muito curtos porque não há contexto suficiente para o analisador de bigrama funcionar. Também tem dificuldade com gírias novas que ainda não entraram no dicionário — eu atualizo o JSON semanalmente com base nos logs de moderação. O maior problema que eu encontrei foi com línguas estrangeiras em código misto (code-switching). Um falante de português que mistura inglês no texto pode usar um termo ofensivo em inglês que o filtro não pegava. A solução foi adicionar um segundo dicionário sobreposto para inglês, mas isso aumentou o tempo de processamento em cerca de 15%.

Se o seu projeto tem escala maior ou precisa de nuances contextuais mais apuradas, considere usar uma API de moderação como a da Google Content Safety ou Azure Content Moderator. Elas custam dinheiro por requisição, mas eliminam a manutenção do dicionário. Para projetos menores ou com orçamento zero, o script acima serve como baseline sólida que você pode refinar ao longo do tempo.