Tratando linguagem informal e coloquial em análise de dados textuais
Na maioria dos projetos de NLP que eu vejo rodando, o tratamento de linguagem informal e coloquial é onde o pipeline quebra. Não é porque a técnica é difícil, é porque as pessoas subestimam a variação morfológica que existe no português falado do dia a dia. O problema real começa quando você tenta aplicar normalização padrão. Regras de stemming convencionais removendo sufixos funcionam bem para textos formais, mas quando chega um "tá", "vc", "num", "pra", "pro", "dele" virando "deli" no WhatsApp, o tokenizeador perde a cabeça. Eu passei três semanas tentando ajustar um modelo de classificação de sentimentos para reviews de restaurantes no Google, e a variável que mais distorcia os resultados era justamente essa camada de informailidade.
O que é linguagem informal e coloquial na prática
Linguagem informal e coloquial abrange variações que escapam da norma culta escrita. A gente fala de contrações regionais, supressão vocálica, abreviações convencionadas de redes sociais, alterações fonéticas que viraram grafia, gírias que entram e saem de circulação em meses, e marcadores discursivos orais como "né", "tipo", "sabe". O texto escrito formal mantém sintaxe previsível. O texto informal quebra essas regras sistematicamente. Tem uma coisa que a literatura não menciona com frequência: o grau de informalidade varia drasticamente por faixa etária e por plataforma. Um "vlw" usado por um usuário de 22 anos no Twitter é muito diferente de um "beleza" usado por um usuário de 45 anos no Mercado Livre. Eles carregam registros socioeconômicos e geográficos que interferem diretamente na interpretação semântica do modelo.
Pipeline prático de tratamento
Eu comecei a estruturar um pipeline que funciona consistenemente depois de testar dezenas de abordagens. A base é um mapeamento lexicográfico antes de qualquer stemming ou lematização. Você constrói um dicionário de equivalências com as formas informais mais frequentes e suas contrapartes normativas. Etapa 1 - Reconhecimento de contrações e contrações fonéticas: Mapeie "vc" para "você", "tá" para "está", "num" para "não é" ou "em um" dependendo do contexto, "pra" para "para", "pro" para "para o", "dos" para "de os", "numa" para "em uma". Isso parece trivial, mas oAmbiguidade contextual é o que mais causa erro. "Num" pode ser "não é" ou "em um". Eu resolvi isso com um classificador leve de SVM treinado em ~10 mil exemplos rotulados manualmente, antes de aplicar o mapeamento.
Etapa 2 - Abreviações de mensagens: "pq" para "porque", "tbm" para "também", "mn" para "muito", "fds" para "final de semana", "p/ mim" para "para mim". Aqui o truque é manter o dicionário atualizado semanalmente. Gírias novas aparecem todo mês nos grupos de WhatsApp e nos comentários do Instagram. Eu uso um scraper simples que coleta top 500 expressões de fontes abertas toda sexta-feira e faz merge com o dicionário existente. Etapa 3 - Normalização fonética aproximada: "c/ vç" vira "com você", "dlz" vira "deixa", "falo" no sentido de "falo que..." como marcador discursivo. Ferramentas como o portstemmer padrão do NLTK não resolvem isso porque elas operam sobre morfologia, não sobre fonotaxe. Eu adicionei uma regra adicional baseada em similaridade editiana com lista prévia de ~800 variantes conhecidas.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Etapa 4 - Lematização pós-normalização: Só após as etapas anteriores é que você aplica o lematizador. Fazer lematização antes gera ruído porque as palavras ainda estão deformadas. A ordem importa muito. Colocar na sequência errada aumenta o erro de desambiguação em cerca de 30 a 40 pontos percentuais no meu benchmark.
Um problema específico que encontrei e como resendi
No projeto de classificação de reviews do Google, eu estava tratando texto de restaurantes em São Paulo e o modelo classficava sistematicamente errado frases como "tô de mágoa" ou "num tá bom". O stemming padrão tratava "mágoa" como raiz "mágo" e cortava o sufixo completamente, perdendo o sentido negativo. "Num" era mapeado apenas para "não é" e em certos contextos a negação dobrada gerava ambiguidade positiva-negativa que destruía a label. A solução foi criar um módulo intermediário de parsing contextual simples baseado em regex com.lookaheads e um classificador de bigramas. Eu separei "tô de mágoa" como entidade preservada, mantendo a palavra intacta para o modelo downstream, e tratei a dupla negação "num tá" explicitamente como marcador negativo. Isso corrigiu a acurácia de 71% para 89% no set de teste. Levei duas semanas para refinar as regras, mas desde então esse módulo é padrão em todos os meus pipelines.
Onde o tratamento falha completamente
Existem cenários em que nenhuma normalização superficial resolve. Textos com código-switching entre português e inglês, como "esse produto é muito over", ou com mesclagem de dialectos regionais fortes — um comentário de interior nordestino com "a gente num fala nada" e "cê num vê nada" encontra resistência mesmo com dicionário completo. Avarandagens dialetais como "psn" por "porquê" ou "qnd" por "quando" variam por estado e às vezes por município. O maior gargalo é que o custo de manutenção do dicionário cresce exponencialmente. Cada nova gíria que entra em circulação exige atualização manual ou semi-manual. Em projetos com orçamento apertado, o mais viável é restringir a normalização ao vocabulário mais frequente dos dados de treinamento e aceitar erro residual. Não adianta buscar 100% de cobertura. Na prática, cobrir os 80% mais frequentes resolve a maior parte dos casos práticos em dois dias de trabalho.
Pitfall comum que todo iniciante comete
Aplicar stemming agressivo antes da normalização. Isso é extremamente comum e destrói a precisão. Stemmers removem sufixos indiscriminadamente. "Tô" vira "t", "vc" vira "v", e o resultado não tem mais correspondência com nenhum registro no léxico normativo. O correto é sempre normalizar primeiro, depois stemmar ou lematizar. A diferença de F1-score entre as duas ordens costuma ficar na casa de 0,12 a 0,18 nos meus testes. Outro erro frequente é tratar toda forma informal como erro de digitação. Há modelos de spell-check que corrigem "tá" para "taxa" ou "p/ mim" para "por mim" de forma agressiva, e em muitos contextos a correção altera o sentido original. O texto coloquial carrega intenção pragmática que a correção ortográfica apaga.
Quando não normalizar
Se o seu objetivo é detectar tom emocional, ironia ou sarcasmo, a normalização excessiva pode ser prejudicial. Formas informais frequentemente carregam a marca afetiva do texto. "O cara é um imbecil" e "o cara é um imbecilzinho" têm intensidades diferentes que um stemmer iguala. Para tasks de sentiment analysis e detecção de ironia, eu recomendo manter a forma original e treinar o modelo com dados reais, em vez de normalizar antes. O ganho em fidelidade pragmática compensa a perda em generalização morfologica. Para análise de tópicos e classificação categórica, a normalização faz sentido. Para geração de texto e tradução automática, o ideal é usar modelos fine-tuned em corpus informai, como o BERTimbau com adaptação, em vez de depender exclusivamente de pré-processamento lexigrafico. O modelo aprende as variações diretamente dos dados e evita a sobrecarga de regras manuais que quebram em contextos nuoviços.
