O problema que ninguém avisa sobre variação linguistica regional em projetos de NLP
Eu trabalhei com processamento de linguagem natural para português brasileiro e português europeu durante anos. A coisa que mais destrói um modelo mal implementado não é a falta de dados — é a suposição de que existe um "português padrão" que serve para tudo. Variação linguistica regional afeta desde a tokenização até a avaliação de sentimentos, e a maioria dos desenvolvedores percebe isso só depois que o modelo já está em produção. Vou começar pelo erro mais comum antes de falar da teoria. A gente costuma baixar um dataset de NER ou de classificação textual que foi anotado majoritariamente com falantes do eixo Rio-São Paulo, ou pior, com falantes de Portugal, e aí aplica em dados do Nordeste sem nenhuma adaptação. O resultado é previsível: F1-score cai de 0.89 para algo em torno de 0.61 nas regiões não representadas nos dados de treino. Não é um bug. É o que acontece quando você trata variação fonológica e morfossintática como ruído em vez de sinal.
Entendendo o que é variação linguistica regional na prática
Variação linguistica regional é simplesmente o fato de que falantes de diferentes áreas geográficas do mesmo país usam formas diferentes para expressar a mesma coisa. Isso vale para o português do Brasil, onde uma pesquisa do ProfiLibras e do IBGE mapeou diferenças lexicais, fonéticas e gramaticais entre as cinco regiões macro do país. Vale também para o português europeu versus o brasileiro, e para os milhares de sotaques e construções que existem dentro de cada estado. O conceito não é exclusivo do português — ele se aplica a qualquer língua com falantes distribuídos territorialmente. O que a maioria dos tutoriais não mostra é que a variação não é só vocabulário. Tem variação fonológica, morfológica, sintática e pragmática, e cada uma delas exige uma abordagem diferente num pipeline de NLP. Ignorar essa distinção é o que leva gente a achar que basta adicionar sinônimos regionais ao dicionário e pronto.
Tokenização é onde tudo começa a dar errado
Antes de qualquer modelo, você precisa tokenizar. E a tokenização padrão do SpaCy para português, por exemplo, não lida bem com expressões como "cê", "vocês", "a gente" como sujeito, ou redução de consoantes finais típica do Sul e do Sudeste. Eu cheguei a ter um pipeline de extração de entidades que simplesmente deletava menções a lugares porque o tokenizador quebrava "Curitiba" em "Curiti" + "ba" em textos com influência gaúcha de escrita informal. A solução foi implementar um pré-processador customizado com regras de normalização regional antes do tokenizeador padrão rodar. Não é bonito, mas funciona. Para português brasileiro, o modelo "pt_core_news_sm" do SpaCy já é razoável para o português padrão, mas para dialetos mais marcados, como o caipira ou o nordestino escrito de forma não padronizada, você vai precisar de ajustes. O mesmo vale para o português europeu — a tokenização portuguesa tem particularidades próprias, como o tratamento diferente de pronomes oblíquos ("lo", "la", "los", "las") que não existem no Brasil.
Escolhendo e ajustando modelos para cada variação
Se o seu objetivo é classificação de texto ou análise de sentimento com variação linguistica regional, o caminho mais direto hoje é usar modelos transformer pré-treinados. O BERT multilíngue da Hugging Face cobre português, mas foi treinado majoritariamente em textos formais e jornalísticos. O ponto de virada foi o ptdb-bert, um BERT fine-tuned com dados brasileiros, que responde melhor a variações regionais informais. Ainda assim, nenhum deles cobre tudo. Aqui vai um insight que eu demorei pra aprender: não adianta fine-tunar num dataset grande se a distribuição regional dos seus dados de treino for desbalanceada. Eu já vi gente gastar três dias fine-tunando um modelo e o resultado ser pior do que o modelo base, porque o dataset tinha 70% de exemplos do Sudeste e o resto espalhado entre Norte, Nordeste, Centro-Oeste e Sul. O modelo simplesmente aprendeu a ignorar as outras variantes. O workaround foi fazer um reamostragem estratificada por região, garantindo que cada região tivesse representatividade proporcional à sua população, e não proporcional à disponibilidade de dados na internet.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Para português europeu, o CamemBERT (baseado no CamemLP5) e o modelo "chinchillbert-portuguese" da Hugging Face são opções mais adequadas do que o BERT multilíngue padrão. O desempenho em tarefas de NER para PT-PT melhora significativamente quando você troca o backbone, mas isso também exige dados de treino com marcação regional portuguesa, senão o modelo acaba capturando padrões brasileiros mesmo com um bom tokenizer.
Um caso específico que me custou duas semanas
Tinha um projeto de análise de reclamações de clientes de uma operadora de telefone. O modelo de classificação de sentimento estava com accuracy de 94% nos testes, mas quando fomos validar com dados reais de chamadas gravadas no Nordeste, a accuracy despencou para 67%. O problema não era o modelo em si. Era que expressões como "nóis" (nós), "visse" no final de frases, e a estrutura "eu não tenho nada feito" (no sentido de "não resolvi nada ainda") eram tratadas como negações duplas ou confusas pelo modelo, que classificava como neutro em vez de negativo. O workaround foi criar um módulo de normalização dialetal que mapeava essas construções para formas canônicas antes da classificação, usando um dicionário de equivalências regionais que eu construí com ajuda de falantes nativos de cada região, não scraping de internet. O dicionário tem cerca de 2.300 entradas, cobrindo as principais variantes do PB e do PT.
Datasets disponíveis e como acessar
Existem datasets públicos que você pode usar como base. O BRACIS (Brazilian Portuguese Corpus) tem textos de múltiplas regiões. O PUC-Rio tem corpora com anotações de variação dialetal. O dataset "Portuguese Tweets" do Hugging Face tem variações regionais implícitas nas marcas de sotaque escritas. Para PT-PT, o CESP (Corpus de Escritos Semiprofissionais) e o corpus do CLPortuguês são referências. Nenhum deles é perfeito — todos têm problemas de desbalanceamento regional — mas são o ponto de partida mais realista disponível gratuitamente. Se você precisa de algo mais estruturado, a plataforma da Hugging Face permite baixar modelos como "alomeira/pt-bert-base" para variantes brasileiras e "camembert-portuguese" para variantes europeias. Os códigos de acesso são diretos: basta instalar a biblioteca `transformers` e usar `AutoModelForSequenceClassification.from_pretrained()` com o nome do modelo. O treino customizado varia de 45 minutos a 3 horas em GPU moderada, dependendo do tamanho do dataset.
Limitações que ninguém menciona
Apesar de tudo, variação linguistica regional tem um limite prático que muitos não consideram: a variação intrarregional. Dois falantes de Salvador podem falar de formas diferentes entre si tanto quanto um falante de Salvador e um de Fortaleza. A geografia não é o único fator. Classe social, idade, nível de escolaridade e exposição a mídias nacionais criam camadas de variação que um modelo treinado apenas com rótulos regionais não captura. Se o seu sistema precisa lidar com fala transcrita de áudio (ASR), o problema dobra, porque a transcrição automática já introduz erros sistemáticos por sotaque antes mesmo do modelo de NLP entrar em cena. Nesses casos, a solução mais honesta é combinar modelos regionais com um classificador de dialeto primeiro, e só depois aplicar o modelo principal. Eu usei essa abordagem em um projeto e o ganho foi de cerca de 8 pontos de accuracy na região mais sub-representada. Mas isso também dobra a latência do pipeline e aumenta a complexidade de manutenção. Não é trivial.
Ainda assim, o esforço costuma valer a pena. Projetos que ignoram variação linguistica regional tendem a falhar de forma silenciosa — o modelo funciona no relatório de teste, mas quebra em produção quando encontra o mundo real. O mundo real não fala como os artigos acadêmicos.
