Palavra De Baixo Calão

O problema que ninguém conta sobre filtros de palavrão

Eu passei uns três meses preso na mesma merda: um sistema de moderação de conteúdo que detectava 97% das ofensas mas deixava passar 100% das que realmente importavam. O resto eu aprendi na marra, com logs cheios de erro e pedidos de desculpa pra cliente reclamando. Se você tá começando agora, vou economizar esse tempo pra você.

O que é palavra de baixo calão na prática

Não é só uma lista de termos impróprios. É um ecossistema de variações morfológicas, grafias alternativas, reescritas intencionais e contexto semântico que muda completamente o significado. A palavra "porra" sozinha é uma coisa. "P-O-R-T-A" num formulário é outra, e detectar isso exige regex com classes de caracteres, não busca de string exata. A maioria dos scripts caseiros que você encontra no GitHub param exatamente aí. O que define uma palavra de baixo calão não é o dicionário, é o registro linguístico. Palavras que originaram do linguaggio vulgare, da fala de baixo calção mesmo, carregam uma carga semântica de ofensa que varia enormemente entre regiões. O que é leve no Nordeste pode ser grave no Sul, e o oposto também acontece. Um filtro que funciona para um público não funciona para outro. Isso é o primeiro insight que os tutoriais bons não explicam.

Como construir um detector funcional

A abordagem que funcionou pra mim foi uma combinação de três camadas, aplicada em sequência: Camada 1 — Normalização de entrada. Antes de qualquer verificação, você normaliza o texto removendo acentos, convertendo para minúsculas, eliminando caracteres especiais e substituindo espaços múltiplos por um único. Isso já resolve muita variação gráfica ingênua. No meu caso, isso reduziu falsos negativos em cerca de 40% porque eliminei aquelas variações de "b x r" que aparecem quando alguém digita sem crase ou com teclas trocadas.

Camada 2 — Lista baseada em regex de classes de caracteres. Para cada termo proibido, você gera padrões como b[o0][a@]r[t7] que capturam substituições visuais comuns. Não use apenas dicionários estáticos. Eu montei uma função que, dado um termo, gera automaticamente todas as combinações razoáveis de substituição de vogal por número (0=o, 3=e, 4=a, 7=t) e consoante por letra similar visualmente (b=v, g=j). Isso aumenta drasticamente a cobertura sem manutenção manual. Camada 3 — Análise contextual com embeddings ou TF-IDF local. Aqui é onde a maioria desiste. Porque algumas palavras são polissêmicas. "Merda" aparece em contextos literários, em expressões idiomáticas, e em ofensas diretas. Um filtro puramente lexical vai bloquear "que merda de dia" junto com "vadia seumerda". A solução prática que eu encontrei foi treinar um classificador simples (na verdade um SVM linear com features de n-gramas) usando dados rotulados do próprio histórico de moderação do sistema. Em vez de confiar cegamente numa lista, o modelo aprende que certa combinação de palavras ao redor do termo suspeito aumenta a probabilidade de ofensa real.

O processo completo, desde a normalização até a decisão final, leva em média 2-4 milissegundos por entrada num servidor básico. Não é muita coisa, mas considerando que um app de mensagens pode processar milhares de mensagens por segundo, isso se acumula rápido. Use cache por input normalizado. Me salvou quando o tráfego triplicou num weekend.

Problemas que vão te pegar de surpresa

Vou ser direto sobre as dor de cabeça reais que eu enfrentei, porque nenhum tutorial vai te contar isso: O primeiro problema grave que eu tive foi com nomes próprios e gírias regionais que coincidem com termos impróprios em outros dialetos. Eu bloqueei o nome completo de um usuário porque parte dele era homófono de uma ofensa no português brasileiro, quando na verdade era um nome comum num contexto português europeu. A solução foi criar listas de exceções geolocalizadas e manter um whitelist dinâmico que pode ser consultado pela equipe de suporte.

O segundo problema, mais sutil, é o overblocking por proximidade contextual. Quando você detecta "porra" e bloqueia automaticamente, perde menções legítimas em traduções de obras literárias, citações históricas, e conteúdo educacional. Meu sistema tinha um modo de moderação humana obrigatória para termos de alta sensibilidade, com threshold configurável. Isso aumentou o tempo médio de revisão de 3 segundos para 12 segundos por item, mas reduziu reclamações de usuários em 78%. Ainda tem o problema de evolução da linguagem. Novos termos surgem todo mês. Slurs criados em comunidades online se espalham rápido. Manter uma lista atualizada manualmente é inviável. O workaround que eu adotei foi um pipeline de coleta passiva: monitorar fóruns e redes sociais com scraping ético (apenas dados públicos, claro) e alimentar o detector com novos padrões antes que eles se tornem problema no sistema produtivo. Isso demanda esforço contínuo, não tem jeito.

O que não funciona

Lista de palavras em arquivo TXT lido linha por linha com str.contains é a abordagem mais comum e a pior possível fora de cenários triviais. Você vai perder variações fonéticas, neologismos e termos compostos. Filtros baseados apenas em dicionário estático têm recall em torno de 60-70% em texto natural brasileiro. Não vale a pena depender disso. Também não recomendo soluções prontas de IA generativa para essa tarefa sem fine-tuning específico. Modelos genéricos têm viés cultural forte e podem interpretar de forma errada o grau de ofensividade dependendo do registro linguístico. A menos que você tenha dados de treino representativos do seu público-alvo, o custo de falsos positivos sobe muito.

Se você precisa de algo rápido e simples para um projeto pequeno, bibliotecas como cleaner ou profanity-checker em Python dão um pontapé inicial razoável, mas encarecem rapidamente. Para produção séria, a arquitetura de três camadas que descrevi acima é o mínimo que entrega resultados consistentes. Qualquer coisa abaixo disso é paliativo.

Considerações finais sobre a responsabilidade do filtro

Implementar detecção de palavra de baixo calão não é só engenharia. É uma decisão editorial disfarçada de código. Cada exceção, cada threshold, cada padrãoregex que você decide incluir ou excluir é um julgamento de valor sobre o que é aceitável e o que não é. Pessoas diferentes vão discordar dessas escolhas. Isso é inevitável e não tem solução técnica para isso. O que você consegue fazer é ser transparente sobre os critérios, manter mecanismos de recurso acessíveis para quem for moderado indevidamente, e revisar periodicamente os falsos positivos e negativos acumulados. Meu relatório mensal de moderação passou a incluir métricas de precisão/recall separadas por categoria de termo, e isso mudou completamente a forma como eu ajustava o sistema. Em vez de adivinhar, eu tinha dados.

Se você está lidando com isso agora, comece pela normalização e pela regex de substituição. Adicione contexto depois, quando tiver dados suficientes. E não confie cegamente em nenhuma lista pronta — ela vai falhar no primeiro dia de uso real.