Como filtrar e detectar palavras escrotas em texto automatizado
A maioria dos projetos que precisam lidar com moderação de conteúdo começa achando que colocar uma lista de palavras e usar replace resolve. Não resolve. Eu já vi gente gastar dias inteiros com regex mal feita e depois reclamar que o sistema era ruim. O problema real nunca é a detecção em si, é o que acontece quando você tenta escalar isso para um ambiente que recebe milhares de mensagens por minuto.
O que são palavras escrotas na prática
Palavras escrotas são termos considerados ofensivos, obscenos ou inadequados dentro de um contexto cultural específico. No português do Brasil, a lista é naturalmente mais ampla do que muitos programadores estrangeiros imaginam, e varia muito dependendo da região e do público. O que é aceitável num grupo de amigos não é o mesmo que aparece numa plataforma de ensino. Quando eu comecei a trabalhar com moderação automatizada, minha primeira reação foi montar uma lista gigante de termos e cruzar com matches exatos. Funcionou no começo, até o dia em que alguém descobriu que escrever "c a r a l h o" com espaços entre as letras escapava pelo filtro. A partir daí, percebi que precisava de algo mais robusto do que uma tabela simples.
Como eu fiz pra resolver isso
A minha solução foi dividir o problema em três camadas. Primeiro, normalização de texto: remover acentos, converter tudo pra minúsculas, tratar variantes ortográficas regionais. Segundo, um detector baseado em correspondência parcial e fuzzy matching, porque "porra" e "p*rra" precisam ser capturados da mesma forma. Terceiro, um sistema de pontuação onde cada palavra tem um peso diferente — um xingamento leve não é igual a algo que é simplesmente inaceitável numa plataforma corporativa. Usei uma biblioteca chamada unidecode pra normalização de caracteres, combinei com Jaro-Winkler distance pro fuzzy matching, e construí uma lista base com pesos atribuindo valores de 1 a 10 para cada termo. A lista pesada eu mantive num arquivo JSON separado, porque atualizar código toda vez que alguém encontra uma gíria nova é inútil.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Problema real que eu tive e como contornei
O caso mais chato que eu enfrentei aconteceu num projeto de moderação para um fórum de jogos. A lista padrão capturava as palavras óbvias, mas os jogadores descobriram que usar variação com números funcionava: "v4d3" no lugar de "vade". Eu passei duas semanas refinando os padrões e ainda assim had gaps óbvios. A solução foi implementar um sistema de regra comportamental além da lista lexical: se uma mensagem tinha alta densidade de caracteres substitutos (números no lugar de letras, asteriscos repetidos, etc.), ela ia pra uma fila de revisão manual independentemente do score. Esse workaround reduziu os falsos negativos em cerca de 60% no meu setup, que processava aproximadamente 5 mil mensagens por hora. O custo foi aumentar o tempo médio de processamento de 12ms para 34ms por mensagem, o que ainda era aceitável porque não era latency crítico.
Pegadinhas que ninguém conta
Uma coisa contra-intuitiva é que listas maiores nem sempre são melhores. Quanto mais termos você coloca, maior a chance de falsos positivos em contextos legítimos. Já vi casos onde a palavra "ruim" era mapeada por causa de uma similaridade fuzzy indevida com um xingamento, bloqueando comentários sobre qualidade de produto. O filtro começou a remover trechos inteiros de reviews de apps, o que gerou reclamação dos usuários em menos de 48 horas. A outra armadilha é assumir que o português é homogêneo. "Porra" tem peso diferente no Sul versus no Nordeste, e há termos que são comuns numa região e ofensivos noutra. Se o seu sistema é nacional, você precisa de regras regionais ou simplesmente aceitar que vai errar em algum ponto. Não tem como evitar completamente.
Alternativa quando a abordagem falha
Se o seu cenário é simples — um chat pequeno, poucos usuários, conteúdo moderado — a lista manual com fuzzy matchingResolve. Mas se você está lidando com escala real, milhares de mensagens por segundo e precisa de precisão aceitável, chega um ponto em que a abordagem baseada em regra simplesmente não aguenta. Nesses casos, modelos de classificação como Fine-tuning de transformers (DistilBERT, por exemplo) superam significativamente qualquer lista lexica porque entendem contexto. Uma mensagem como "que saco de jogo" contém "saco", mas o contexto mostra que é expressão de frustração, não profanidade direta. O modelo consegue distinguir isso; o filtro baseado em lista não. O custo de manter um modelo assim é maior em termos de infra e conhecimento técnico. Você precisa de pipeline de retreinamento periódico e monitoramento de drift. Mas para plataformas que processam mais de 50 mil interações por dia, o investimento geralmente se paga nos primeiros três meses pela redução de trabalho manual de revisão.
Se quiser testar algo rápido antes de embarcar numa solução mais complexa, eu recomendo começar com a lista aberta de palavras ofensivas em português disponível no GitHub. Ela é mantida pela comunidade e costuma ser atualizada com frequência. A partir daí, você vai percebendo rapidinho quais gaps existem no seu caso específico e pode ir ajustando conforme a necessidade.
