Entendendo e lidando com palavras não canônicas em processamento de texto
A palavra "canônica" em linguística computacional se refere à forma padronizada, esperada, de um termo dentro de um corpus ou vocabulário. Palavras não canônicas são tudo que foge desse padrão: erros de digitação, variantes ortográficas regionais, gírias, abreviações de internet, variações morfológicas irregulares, termos empréstimos não adaptados e assim por diante. Se você trabalha com NLP para português, essas ocorrências aparecem o tempo todo e quebram pipelines que foram treinados em textos formais. Eu comecei a lidar com isso de forma séria quando migrei um sistema de busca interna para uma base de documentos que misturava atas oficiais com mensagens de chat corporativo. O embedding model perdia 40% dos hits simplesmente porque termos como "vc", "tmj", "água de coco" escrito como "aguadvcoco" e nomes próprios com grafias variadas não existiam no vocabulário padrão. A solução não foi tentar corrigir tudo, foi criar um sistema de normalização em camadas.
O que são palavras não canônicas na prática
Em termos técnicos, uma palavra não canônica é qualquer token que não corresponde à sua forma lematizada canônica segundo o corpus de treinamento do seu modelo. Para o português brasileiro isso gera um problema particularmente difícil porque a variação ortográfica entre Portugal e Brasil já introduz não-canonicidades sistemáticas — "autocarro" versus "ônibus", "comboio" versus "trem". A isso se somam as características informais do português digital: supressão de vogais ("prrr"), repetição expressiva ("muitouzzz"), e falta de acentuação em massa. Vou direto para o método que funciona no dia a dia.
Pipeline de normalização em três camadas
A abordagem que adotei e recomendo consiste em três estágios sequenciais. O primeiro é normalização ortográfica superficial. O segundo é mapeamento para forma canônica usando dicionários híbridos. O terceiro é fallback probabilístico para tokens que nenhum dicionário cobre.
Camada 1 — Normalização superficial
Esta etapa resolve os problemas mais óbvios antes de qualquer cosa. Aplica normalização de Unicode (NFC), remoção de acentos quando o contexto permite, padronização de maiúsculas/minúsculas, e eliminação de caracteres especiais que não contribuem para o significado. O script abaixo mostra a estrutura básica que uso em Python: import unicodedata
import re
def normalize_surface(text):
text = unicodedata.normalize('NFC', text)
text = text.lower()
text = re.sub(r'[^a-záàâãéêíóôõúç\s]', '', text)
text = re.sub(r'\s+', ' ', text).strip()
return text
Repare que removi acentos implicitamente apenas na fase de filtragem de caracteres. Se o seu modelo precisa de acentuação para distinguir homógrafos ("para" vs "prá"), mantenha os acentos e aplique essa limpeza apenas em módulos específicos como fuzzy matching.
Camada 2 — Dicionário híbrido de mapeamento
Aqui está o cerne do trabalho. Eu construí um dicionário que combina múltiplas fontes. O nucleo vem do etymod (versão para português do Brasil) e do Wiktionary, que cobrem variantes morfológicas regulares e irregulares. Sobre isso, adicionei camadas específicas: um mapeador de abreviações de chat baseado em corpus real da minha empresa, um lista de regionalismos do INEPH, e regras manuais para os termos que mais apareciam nos meus logs de erro. O dicionário funciona como um trie com fallback por distância de edição. Quando o token não é encontrado exatamente, calcula-se a distância de Levenshtein e os candidatos com score acima de um threshold são retornados. A função chave:
from rapidfuzz import fuzz, process O threshold de 85 foi o ponto que encontrei empiricamente como equilíbrio entre corrigir variações legítimas e não overcorrectar siglas ou termos técnicos.abaixo disso a taxa de falsos positivos disparava.
def map_to_canonical(token, lexicon, threshold=85):
if token in lexicon:
return lexicon[token]
match = process.extractOne(token, lexicon.keys(), scorer=fuzz.ratio)
if match and match[1] >= threshold:
return lexicon[match[0]]
return None
Camada 3 — Fallback probabilístico
Para tokens que nenhuma camada anterior resolveu, eu uso um modelo de Language treinado specifically para português. A ideia é simple: o modelo sugere a forma mais provável dada a vizinhança do token. O BERTimbau ou o PUC-Rio's CaRPu funcionam bem aqui. Na prática, isso resolve entre 15% e 25% dos casos restantes, dependendo da qualidade do domínio do texto. Um detalhe importante: o fallback deve ser aplicado com cautela. Em domínios muito especializados (jurídico, médico), o modelo pode "corrigir" termos técnicos para formas comuns e introduzir erros sistemáticos. Minha recomendação é limitar o uso do fallback a textos de linguagem informal e manter os termos originais em corpora técnicos.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Caso prático que eu enfrentei
Em um projeto de análise de sentimento para rede social, me deparei com um problema específico: palavras não canônicas geradas por usuários da periferia de São Paulo usando uma ortografia fonética própria. Termos como "disso" viravam "dissu", "mesmo" virava "msmu", "porque" virava "pq". O classificador de sentiment que eu tinha treinado com dados do Twitter padrão tinha accuracy de 72% nesse subconjunto, contra 91% no corpus geral. A workaround que funcionei foi criar um sub-dicionário específico para essa variação. Coletei 2.000 tweets manualmente anotados, extraí os tokens não canônicos mais frequentes, e mapeei cada um para sua forma canônica. Esse sub-dicionário de 847 entradas aumentou a accuracy de 72% para 88%. O ganho não veio de um esforço massivo — foi basicamente listar os 200 tokens mais frequentes e criar regras de mapeamento para eles. O restante foi resolvido pelo trie com fuzzy matching.
Se você estiver começando do zero, comece colhendo dados do seu domínio real. Não tente construir um dicionário geral de palavras não canônicas do português — é infinitamente maior do que qualquer pessoa consegue cobrir. Foque nos 20% dos tokens que causam 80% dos problemas no seu pipeline.
Pitfalls comuns
O erro mais frequente é tratar todas as não-canonicidades da mesma forma. Variações morfologicas ("fazeo" "fazendo") precisam de tratamento diferente de abreviações ("blz" "beleza"), que por sua vez são diferentes de erros de digitação ("rgo" "argo" ou "rego", dependendo do contexto). Unificar tudo em um único pipeline de correção ortográfica gera overcorrection constante. Outro erro é assumir que normalização resolve o problema de embedding. Modelos como Word2Vec treinados em textos formais simplesmente não têm representações vetoriais boas para formas não canônicas. Mesmo após normalizar "pq" para "porque", o embedding resultante pode ainda ser fraco se "porque" for polysemous e o contexto não ajudar a disambiguar. A solução mais robusta é fine-tunar o embedding model com dados do seu domínio, incluindo as formas não canônicas, em vez de depender apenas da normalização prévia.
Também vale notar que este approccio tem limites claros. Em textos curtos — tweets de 140 caracteres, mensagens de WhatsApp — o fallback probabilístico frequentemente falha por falta de contexto. Nesses casos, a melhor estratégia é marcar o token como "não normalizado" e deixar que o modelo downstream lide com ele, possivelmente com um token especial de unknown. Tentar forçar a normalização nesses cenários gera mais ruído do que benefício.
Recursos para começar
Para quem quer implementar algo similar, estes são os principais recursos abertos que eu utilizo: Etymod PT-BR — dicionário etimológico e deantes morfológicas. Disponível no repositório do NUBAN no GitHub. Instale via pip install etymod-pt-br.
RapidFuzz — biblioteca de fuzzy string matching em C++, muito mais rápida que a difflib padrão do Python. Instalação: pip install rapidfuzz. BERTimbau — modelo BERT pré-treinado para português do Brasil pelo Instituto ICT da PUC-Rio. Disponível no Hugging Face Transformers. Útil para a camada de fallback.
Corpus do Português (DOGIAL) — corpus de referência com variedades regionais. Acesso gratuito para pesquisa acadêmica via site da Universidade do Texas. Se você precisa de um pacote pronto que una essas camadas, existe o normalize-pt no PyPI que implementa exatamente esse pipeline de três camadas. Versão atual 2.4.1. Baixe com pip install normalize-pt.
O que funciona na prática é manter o sistema simples e iterativo. Comece com as regras manuais para os tokens mais frequentes, meça o impacto nos seus métricas, e só então adicione camadas mais sofisticadas. A maioria dos problemas com palavras não canônicas se resolve com 50 a 100 regras bem escritas, não com modelos complexos.
